Witzenburg Municipality Tender No: 8/2/5/18

2.4Back Office System

Figure 6 Toll back office payment

The proposed back office system is a complete TOLL SYSTEM Internet Data hosting and reporting portal specifically designed for the TOLL management industry. An unlimited number of sites data can be transmitted to a central server where the data is made available in real time. If the data lines go down, up to 100 000 transactions can be stored locally, until the central server is available. The data lines which can be provided are leased lines, wireless, GPRS and ADSL, any TCP/IP connection.

The reports that can be generated include: Uptime and site availability;

• 
  Month end statements and customer reports;
  
• 
  Vehicle number per site, average time on site, average through put, etc.;
  
• 
  Operator reports and no of vehicles handled per operator.
  
• 
  A wide range of other reports as required.
  

All the above are available via SMS, E-Mail, Internet web sites, printed or self service kiosks.

3Issues for Consideration

A comprehensive solution is proposed which will ensure all transaction are captured and billed at the suitable rate. Both users and staff will be forced to adhere to best practice, making the airport a safer place for all. Illegal entry will no longer be tolerated, as the equipment to capture this activity will be provided. The same solution will ensure the right price is paid for the correct vehicle type.
There are a number of important research issues in the toll plaza design problem. Some of these are 1. how many of each type of booth should we have

2. how should we layout and what should be the relative positions of the different types of

toll payment methods

3. what is the traffic delay as a function of the no’s of different types of toll booths / layouts,

4. what other traffic control methods should be used to ease the traffic congestion.

The importance of the first two problems is obvious. The third issue comes from the fact that, at different period of the day or different days of the week there are different traffic intensities, hence a good toll plaza design and personnel scheduling should be dependent on the delay analysis for different parameters of the traffic patterns/intensities. Finally, the last issue should incorporate traveller behaviour and human factors into the design to make the system most convenient for travellers.

Each direction has a number of stationary lanes and reversible lanes. These reversible lanes were introduced to provide flexibility in handling the significant difference in the peak and off-peak directional traffic volumes. The plaza development, including implementation of AVI (E-- PASS), is defined by the following stages:

* Stage 1: Conventional lanes (manual and automatic lanes only);

* Stage 2: Mixed AVI lanes (no dedicated AVI lanes); introduction of E-PASS; 10 percent of transactions targeted to be E-PASS;

* Stage 3: Single dedicated AVI lane (i.e., only one dedicated AVI lane per direction and all other lanes are mixed AVI lanes); 20 percent of transactions targeted to be E-PASS;

* Stage 4. Two dedicated AVI lanes (i. e., only two dedicated AVI lanes per direction and all other lanes are mixed AV lanes); 30 percent of transactions targeted to be E-PASS.
With the approach to the toll plaza, a driver must decide which lane to enter. Some determining factors for this decision include payment type, shortest queue length and the lane status. One of the most difficult tasks in designing any toll plaza is the plaza lane configuration. Lane configuration implies the arrangement of toll lanes at a plaza according to the payment methods. This arrangement should accommodate the traffic demand required for each payment type and prevent any potential confusion among drivers that could result in crashes. Sometimes multiple collection methods, like mixed AVI lanes, could create potential confusion among drivers and result in some crashes.
I-Cube has developed a model to determine the optimum plaza size based on queuing theory. It can get quite complicated trying to determine how many lanes are required. Using the model I-Cube can input various criteria to calculate the serving time. For instance, a client could specify a maximum queuing length of 6 vehicles + 1 vehicle being served for 95% of the time.

This model is ideal for different client's specific requirements. Using this model, we can accommodate peak direction flows by designing a proportion of the lanes to be reversible. This model does give an edge in the market place.

The normal design horizon is 30 years with expansion intervals of 8 years. So while this will start as an 8-lane plaza, it will end up with 18-lanes.

Electronic toll collection is the future for all plazas - on certain toll projects, with overhead sensors as for example in Canada, 95% of all vehicles using the toll road is equipped with electronic tags, so they don't have to stop at all.

In compiling this quotation we have endeavoured to provide you with the best value solution fit. Our offer includes available solutions of either an upgrade of the existing system,
Our proposal is based on the following enclosed documents:

Covering letter

History of the Company & Differentiating Factors

Executive Summary

Response to your bid document – as is with supporting documentation

Qualification of Proposal Document

Schedule of pricing

Appendices and other documentation as diagrams, etc. not included above.

MAJOR SYSTEM FEATURES

1. 
   Control of Transient Parkers via Magnetic stripe.
   
2. 
   Control of Monthly/Tenant parkers via mag stripe cards or proximity reader “tags”.
   
3. 
   “Real-time” transaction data transmission to Central Management Computer
   
4. 
   Highly flexible Tariff Structure.
   
5. 
   Comprehensive Alarm Detection and fault reporting and analysis.
   
6. 
   Posting of statistical and financial reports over Internet and/or email.
   
7. 
   Automatic reporting of specified events via cell phone SMS
   
8. 
   Remote software and system maintenance.
   
9. 
   Distributed, networked management control.
   
10. 
    Graphical User interface.
    
11. 
    Ticket Validations by Machines or Vouchers.
    
12. 
    Pay-On-Foot payment by Banknote, Coins, Credit/Debit Card
    

13. 
    Change given at Pay-On-Foot machines via Coins and Banknotes
    
14. 
    Voice annunciation at Entry/Exit and Pay-On-Foot machine.
    
15. 
    Credit card in/out capability; Multiple language support; Multiple currency support
    
16. 
    Full Access Control System; System security via layered password configuration
    
17. 
    Multiple “nested” zone capability; Blacklist ticket function
    
18. 
    Local Databases for communications network redundancy
    
19. 
    Automatic database analysis and repair
    
20. 
    “Mirrored disks” for database backup (optional).
    
21. 
    Remote control of all devices in parking system
    

1. 
   Reports: Transaction ; Financial
   
2. 
   Exception reports; Capacity & Flow
   
3. 
   Parking & device usage
   
4. 
   Parked period; Access Control Reports and Card Tracking
   
5. 
   Pay Station Cash status report
   
6. 
   Customer specified Event reports
   

7. 
   
   
8. 
   Automatic Internet and/or email reporting