Automated Parking System - Final Report

  Yat Lai 243781

1.0 INTRODUCTION

This report culminates the design of the Automated Parking System Controller. The device will be able to monitor and regulate the complete operation of a car park. The behavior of the device was coded in VHDL and simulated using the Altera MaxPlusII software. Upon successful simulation of our code, the design was downloaded to the Altera UP1 education board and tested with the prototype hardware for an Automated Parking System. Each step of our design and verification process is documented here.

 2.0 SYSTEM OVERVIEW

 The overall Automated Parking System consists of the Automated Parking System Controller (2 Altera FLEX10K20 FPGA chips) as the central unit, controlling a pay terminal interface, a photo-detector system, and a parking slot availability indicator board. The system block diagram is given below followed by the description of the functionality of each block.

2.1 Automated Parking System Controller

The main function of this device is to regulate the operation of a parking facility. This includes navigating the user to an available parking slot, storing the entrance time, calculating the parking charges, providing a interface for paying and handling security matters.

Firstly, the device interfaces with a LED Parking Slot Availability board that indicates the location of available parking slots to the customer at the entrance of the parking facility. It provides a ‘1’ signal when a particular slot is occupied and ‘0’ otherwise. A car park full signal is also provided when all slots are occupied. Now, as soon as the customer completely parks their vehicle, this device will store the corresponding entrance time for that particular slot in its memory. This process is triggered by the photo-detector system which senses the presence of a vehicle at each parking slot. The controller would poll the photo-detector system at a 3 seconds interval. When a transition from ‘1’ to ‘0’ is observed and the signal stays at ‘0’ for the next 3 polling (9 seconds), the controller assumes that the vehicle is stationary (customer completes parking routine) and stores the current time. A memory of 256 x 16 bit is available for storage of the entrance time (capable of supporting 256 slots).

Parking charges are calculated by the ½ hour and two different rates ( $0.25 every ½ hour (rate 0) or $0.50 every ½ hour (rate 1) ) can be selected. Selection is done in the supervisory mode (refer to User Manual). To calculate the charge, the customer first enters the slot number which will be used by the device as an address pointer to retrieve the stored entrance time for that slot. Then, the stored time (in a 24 hour format) is subtracted from the current time to obtain the parking duration and subsequently the parking charge.

A user-friendly interface terminal is controlled by this device for the customer to pay their parking charges as well as the parking supervisor to preset the system. The current time (24 hour format), slot number and parking charges or duration is displayed on the terminal. Push-buttons and a 10-digit keypad are available here for user input as well as LED lights to guide the user in making their selections. This device will accept $2.00 and $1.00 coin payment and provides the exact change in $0.25 increments. The charge display on the terminal will be updated constantly as payment is being made to indicate the remaining charge. In our design, 2 push buttons were used to provide the coin payment signals and 4 LEDs to indicate the number of quarters provided in change.

When the customer pays off all the parking charges for his slot, a paid signal would be set to ‘1’. This allows the customer to leave. An alarm will be triggered if a customer attempts to leave the parking slot without paying. A switch is provided to turn off the alarm when necessary.

On the whole, the Automated Parking System Controller has 2 operating modes: supervisory and normal. Supervisory mode allows the parking supervisor to setup the time and parking rate. Then, the system goes into normal operation until the reset button is pressed. Please refer to the User Manual in the Appendix C for initialization sequence and operating procedures. The table below summarizes the I/O of the controller.

   2.2 Parking Slot Availability Indicator

This indicator, which is located at the entrance to the car park, helps navigate the customer to an empty parking slot. It contains 9 LED lamps indicating the available parking slots in the car park. By letting the customer know the location of the available parking slots, this will effectively reduce their searching time.

Eight LED lamp is used to indicate the availability of each of the 8 parking slots and one more to indicate that the car park is full. The slot LED would turn ON when the parking slot is available (empty) and OFF when the parking slot is occupied. When all the parking slots are occupied, the "Car Park FULL" LED turns ON.

2.3 Photo-Detector System

The photo-detector system consists of 8 infrared transmitter-receiver pair, one located at each parking slot, which detects the presence of a vehicle at the parking slots. The schematic of our designed detection circuit is as follows.

When the parking slot is available (i.e. no vehicle is present), the light emitted by the LD 271 Infrared Emitter would be detected by the SFH300 Phototransistor, thus giving rise to an ~ 0 V output (logic level ‘0’). If a vehicle comes along and occupies the parking slot, the light path would be blocked. Then, the phototransistor would be OFF and the output would be clamped to ~ 5V (logic level ‘1’). Note here that the emitter and receiver would be lined up in such a way that the light path would be blocked by the presence of a vehicle at the parking slot.
 

2.4 User Interface Terminal

The user interface terminal serves as the main interface between the car park customer (as well as supervisor) and the parking system. It enables the customer to pay their parking charges and the parking supervisor to initialize the system. The illustration of our designed interface is given below.

The terminal consists of 8 LEDs, 9 seven-segment displays, 4 push buttons and 1 keypad. The LED lamps help make the interface user-friendly. Four of the LEDs are used as Panel Indicators which lights up the active panel. This guides the customer through the paying cycle by indicating which field of buttons to select. Five other LEDs are used as Selection Indicators which lights up the customers selections. This reminds the customer on his/her selections. Another LED (Supervisory Indicator) is used to indicate the current mode of the system. It will turn ON when the system is in supervisory mode and goes OFF during normal operation. Apart from this, 9 seven-segment displays are present to display the current time (4 displays), slot # (1 display), and charge, duration or password (4 displays). All the seven-segment displays are controlled by 16 signal lines form the FPGA (7 data lines and 9 enable lines – one for each display). The BCD to seven-segment conversion is done internally in the FPGA and the data is written to each display in a cycle at a frequency fast enough to avoid flickering of the display.

A 10 button keypad (0-9) is available for the customer or supervisor to input data into the system. The keypad is implemented using 10 signal lines (1 for each push button) which is decoded in the FPGA to give the corresponding value (4 bit signal value – 0 to 9). Apart from this, a START / END push button is present to restart or end the paying sequence. Two push buttons (Loonie and Toonie) are used for coin payment while another push-button (TOGGLE) is used to toggle between displaying the duration parked or total charge. Finally, this terminal houses an array of 4 LEDs that displays the amount of quarters provided as change.

Note that a supervisory reset push button is available at the terminal to reset the system and invoke the supervisory mode. This push button is usually locked up and is only accessible by authorized personnel.

3.0 DESIGN DETAILS

Our design was synthesized using VHDL via the Altera MaxPlusII software package. A bottom-up design methology was used. The lower level entities were individually coded first and we proceeded up the design hierarchy, as given below.

Since the design was too large to fit into one chip (1328 /1152 logic cells), we decided to implement the design on 2 separate Flex10K20 chip. This is because we were able to separate the system into 2 almost independent parts and we do not want to remove any features from the system. Thus, the device consists of 2 ICs, namely terminal controller and monitor.

3.1 Terminal Controller IC Design

The terminal controller IC includes 8 high-level entities and the top-level entity "term_con". The following is the list of entity declarations of the VHDL codes, followed by explanatory notes for each module.

Term_con (TERMINAL CONTROLLER)

entity term_con is
port (clock, reset : in std_logic;
        clk_ext : in std_logic;
        start_end, charge_display : in std_logic;
        in_toonie, in_loonie : in std_logic;
        keypad_input : in std_logic_vector(9 downto 0);
        sel_coin, sel_keypad, sel_sup, sel_startend : out std_logic;
        paid : out std_logic;
        paid_slot : out std_logic_vector(3 downto 0);
        data_7display : out std_logic_vector(6 downto 0);
        enable_7display : out std_logic_vector(8 downto 0);
        total_change : out std_logic_vector(3 downto 0);
        changer_ready : in std_logic; ctime : out std_logic_vector(15 downto 0)
        );
end term_con;

This entity is to monitor the pay terminal. It uses the entities, calculate_charge and cash_vendor, to calculate the charge for selected slot and take care of the paying process respectively. After the system is being reset, the terminal controller will enter to supervisory mode and be asked to input the current time as well as the rate. As soon as the time and the rate are set, the terminal controller will be in normal operation mode. During the normal operation mode, customer can select the slot number which user wants to pay for and then the charge will be displayed on 7-segment LEDs. The duration can be displayed on the same 7-segment LEDs when the toggle button is pressed. User can pay either by toonie or loonie. The remaining charge will be displayed on the 7-segment LEDs when the customer is paying. After the paying process, the change will be dispensed in quarters only if there is change and customer is asked to press the "End" button to end the paying process.

Clock_inc2 (used by CLOCK)

clock_inc2

entity clock_inc2 is
port (clock :in std_logic;
        reset : in std_logic;
        h2i, h1i, m2i, m1i : in std_logic_vector(3 downto 0) ;
        h2o, h1o, m2o, m1o : out std_logic_vector(3 downto 0) := "0000";
        clock_go : in std_logic
        ) ;
end clock_inc2;

This entity is used to increment time and pass the incremented time to clock2 entity. The inputs are the current time from clock2 entity. This entity is designed to use a counter to increment time. When the counter has reached the clock frequency minus 3, it will increment the time by a minute and pass the output to clock2 entity.

Clock2 (CLOCK)

entity clock2 is

port (clk1, reset : in std_logic;
        keypad : in std_logic_vector (3 downto 0);
        enter : in std_logic;
        normal_op : out std_logic;
        cur_time : out std_logic_vector (15 downto 0)
        );
end clock2;

This entity allows user to input the current time from the keypad after the system is being reset. It does not accept any invalid input. If the acceptable input has been entered from keypad, it will be echoed on the correspondent 7-segment LED. If invalid input has been entered from keypad, the system will ask user to input a valid number again. After a valid time has been entered, the clock will be in normal operation mode and a signal, normal_op, is asserted high. This entity uses the entity clock_inc2 to increment the time. The current time, in BCD format, will be encoded to 7-segment format using decode_7seg entity and then will use output_7seg_display entity to output the current time to the correspondent 7-segment LEDs.

Calculate_charge (CALCULATE CHARGE)

entity calculate_charge is
port ( clk, reset, restart : in std_logic;
         keypad : in std_logic_vector(3 downto 0);
        set_slot, enter, set_rate : in std_logic;
        cur_time : in std_logic_vector(15 downto 0);
        duration : out std_logic_vector(15 downto 0);
        total_charge : out std_logic_vector(7 downto 0);
        done_rate : out std_logic;
        slot_number : out std_logic_vector(3 downto 0);
        done_cal : out std_logic
        );
end calculate_charge;

This entity is a synchronous state machine that calculates the total charge for an entered slot based on the stored entering time and the current time. It also allows the car park supervisor to change the parking rate multiplier which specifies the charge on a half-an-hourly basis. When certain slot number has been selected, it will retrieve the entered time for the corresponding slot and then calculate the difference between the current time and the entered time. Furthermore, it also computes the number of 30-minute blocks for the duration and multiplies the selected rate to obtain the total charge.

Cash_vendor (CASH VENDOR)

entity cash_vendor is

port (reset : in std_logic; clk,
        sel_cash : in std_logic;
        total_charge : in std_logic_vector(7 downto 0);
        in_toonie, in_loonie : in std_logic;
        changer_ready : in std_logic; total_change : out std_logic_vector(3 downto 0);
        output_charge : out std_logic_vector(15 downto 0);
        complete_cash : out std_logic
        );
end cash_vendor;

This entity regulates the paying/coin slot at the terminal controller. It accepts only toonie and loonie for paying and the changer only provides 25 cents change. It takes in an 8-bit word, representing the total charge, and then output it into the 7-segment LEDs. When payment is received, the total charge will be decrement by the paid amount and then output the remaining charge into the 7-segment LEDs. This process repeats until the remaining charge has reached zero. A signal, complete_cash, will be asserted when all charges have been paid.

Keypad_decode1 (KEYPAD DECODER)

entity key_decode1 is
port ( reset : in std_logic;
        clk : in std_logic;
        keypad_input : in std_logic_vector (9 downto 0);
        keypad : out std_logic_vector (3 downto 0);
        enter : out std_logic
        );
end key_decode1;

This entity will take in 10 binary words from keypad and decode them into a BCD word. Each BCD word represents a digit of the desired input from the keypad. Furthermore, a "enter" signal will be asserted when any of the ten keys is pressed.

Decoder_7seg (7 SEGMENT DECODER)

entity decoder_7seg is

port (input: in std_logic_vector(3 downto 0);
        led: out std_logic_vector(6 downto 0)
        );
end decoder_7seg;

This entity will take in a BCD code and decode it into a 7-segment code. It will be used in output_7seg_display entity.

Output 7-segment display (OUTPUT 7 SEGMENT SELECTOR)

entity output_7seg_display is
port ( clk : in std_logic;
        reset : in std_logic;
        cur_time : in std_logic_vector(15 downto 0);
        duration : in std_logic_vector(15 downto 0);
        charge : in std_logic_vector(15 downto 0);
        slot_num : in std_logic_vector(3 downto 0);
        charge_display : in std_logic;
        data_7display : out std_logic_vector(6 downto 0);
        enable_7display : out std_logic_vector(8 downto 0)
        );
end output_7seg_display;

This enitiy is used to output the current time, the slot number, the charge and the duration in 9 common cathode 7-segment LEDs on the pay terminal. The data will be displayed one digit after one digit and the sequence repeats at a rate of 347kHz which is fast enough for human eyes seeing the 7-segment LEDs remain turned on.

3.2 Monitor IC Design

The monitor IC includes 2 high-level entities and the top-level entity "monitor". The following is the list of entity declarations of the VHDL codes, followed by explanatory notes for each module.

Ram (RAM CONTROLLER)

entity ram is
port (clk : in std_logic;
        reset : in std_logic;
        sel_avail, sel_cal : in std_logic;
        avail_data : in std_logic_vector(15 downto 0);
        avail_addr : in std_logic_vector(7 downto 0);
        cal_data : out std_logic_vector(15 downto 0);
        cal_addr : in std_logic_vector(7 downto 0);
        avail_done, cal_done : out std_logic;
        ram_ready : out std_logic
        );
end ram;

Since the memory is shared by two components, access control is required to avoid data collision on the data bus and address bus. The access control is done by a hand-shaking mechanism.

When idle, the RAM will check the two components in turns to see if either select line (sel_avail or sel_cal) is asserted. The components also have to check if the ram_ready signal is high before they put the select line to high. If a sel_line is high, it will output a low ram_ready signal to acknowledge the other to wait. Even if the two components put the select line on high on the same clock edge, they will not cause collision because the RAM poll either select signal in alternative clock period. The other will just have to wait for several clock periods until its neighbor finishes. After the RAM access finishes, it will assert the done signals (avail_done or cal_done) to acknowledge the components, and the components put the select line back to low. The ram_ready is high again to wait for another access request.

Availibility

entity availability is
port (clk : in std_logic;
        reset : in std_logic;
        photo_detect : in std_logic_vector(7 downto 0);
        full_sign : out std_logic;
        avail : out std_logic_vector(7 downto 0);
        paid : in std_logic;
        slot_num : in std_logic_vector(3 downto 0);
        alarm : out std_logic;
        alarm_off : in std_logic;
        sel_avail : out std_logic;
        avail_addr : out std_logic_vector(7 downto 0);
        done_avail : in std_logic;
        ram_ready : in std_logic
        );
end availability;

This entity will detect arrival or departure of the cars using photo-detector and set the availability of the parking slots. For arrival, the arrival time will be recorded into the RAM and it will be retrieved later to calculate the duration. In the case of all parking slots are occupied, the full sign signal goes high to light up the sign. An alarm will be turned on if it detects any car leaves without paying.

3.3 External Hardware Design

CLOCK

The system clock for the Terminal Controller is chosen to be 120Hz. The reason behind this choice is related to the size of counter being used in the clock_inc2 entity. It only takes seven bits to encode 120 and it will require more bits to implement higher clock frequency. Consequently, it will require more logic cells for the clock_inc2 entity. At first, a "clock divider" circuit was planned. The circuit was to have a slower clock pulse. Depending on the size of the counter, the "clock divider" approach can generate a second clock signal that is much slower than the system clock. There are two problems are associated with this method. On the one hand, the counter can take up much valuable space on the FPGA if the system clock is much faster than the new clock signal. On the other hand, the new (slower) clock is fed to, fan-out problems will likely occur. Consequently, the "clock divider" approach was dropped.

For ease of design and implementation, a 555-timer is used to generate the system clock. It is relatively easy to design a 555-timer circuit that produces a pulse train with periods in the millisecond range. The main drawback of the 555-timer approach is that it is difficult to achieve a high timing accuracy with RC components. As a result, the real-time clock of the Terminal Controller will not be very accurate. The schematic of the 555-timer circuit can be found in the Appendix D.

PUSH BUTTONS

The Terminal Controller has fifteen push button inputs: 10 keypad buttons, "reset", "toonie_in", "loonie_in", "Start/End", and "Charge/Duration". At each rising clock edge, the system checks the level of the each button to determine if actions need to be taken. The buttons can be directly affected by the clock frequency. For example, if the user pushes the "1" buttons when user is being asked to input the current time and the "1" input at the FPGA will stay high for several clock edges. The current time may be set as 11:11 when "1" button is being pressed once. In order to correct this problem, a large capacitor is required for de-bouncing.

7-SEGMENT LEDs (common cathode)

There are two groups of pins connected to each group of 7-segment LEDs: the "selector" pins and the "segment" pins. Each "selector" pin is connected to the common cathode of a 7-segment display, while each "segment" pin is connected to the corresponding anodes. When a display needs to be turned on, a "selector" pin will go low to supply current to the common cathode. On the other hand, a logic value "1" at the "segment" pin will allow current flow and turn on the diode. Similarly, a logic value "1" at the "segment" pin will turn off the diode.

Moreover, it is determined that a 100W resistor between a "selector" pin and a common cathode will limit the current flow at the "selector" pin to 35mA. The purpose of the resistor is to ensure that the maximum I/O current of the FPGA is not exceeded.

4.0 DESIGN VERIFICATION

The back-annotated simulation has been successfully carried out to demonstrate the functionality of the car park system. The following simulation results are carefully selected that can cover almost all aspects of our design.

The system clock is connected to the on-chip oscillator, which runs at 25.175Mhz speed. Actually, this clock speed is too fast for the system, especially for the displaying clock on the terminal controller. Instead of using tremendous amount of logic cells to implement a clock divider, an external clock of 120Hz is used.

However, simulation of 120Hz rate caused a problem because it requires very long simulation time and it is turn requires huge amount of memory, which even the CAD lab machine cannot handle. Therefore, 10MHz was used in the simulation. It is believed that if faster clock works, the slower one should also work.

Waveform 1 (refer to Appendix A1)

• Startup

• Setting Displaying Clock

• Display on Seven-Segment LEDs

• Clock Display

• Rate Setting

• Car Arrival at Slot One

• Car Arrival at Slot Two

• Paying for Slot One

• Car Arrival at Slot Three

• Paying Coins

• Security Alarm

• Second Transaction

• Car Arrival at Slot Two Again

Since the FPGAs was designed to serve as a controller for a parking system, the most efficient way of testing it is to incorporate the FPGAs into a prototype Automated Parking System and then verify the functionality of the complete system. As time was a constraint, the photo-detector system peripheral was replaced by DIP switches (same logic retained) and each FPGA was tested separately. This could be done since the terminal controller IC and monitor IC are almost independent of one another.

5.1 Terminal Controller IC Testing

To test the terminal controller chip independently, we pre-assign the entrance time of each parking slot to the following.

Slot 1 Þ 00:00

Initially, the 7-segment displays were giving us erroneous and inconsistent output. Also, all the pushbutton switches, although not hooked up together, were causing the system to reset. Also, the LED display seems to have problems displaying 8 (all segments lid). We realized later that our external hardware is drawing more current that it is supposed to from the V_CC pin (+5 V). This problem explained our observations and was solved by powering our hardware with an external supply of 5 V (4 A).

The other problem we encountered was with the "reset" push button. Apparently, the "reset" button does not reinitialize all the crucial signals to the same initial state every time it is pressed. This is a coding error which possibly occurred when we were trying to reduce the size of the design by removing repetitive signal assignments. This bug was fixed by including some additional signal assignment statements in the reset state.

1. RESET the system (push button). Enter "1", "2", "3", "4" via the push button keypad

RESULT : The clock display shows 12:34 and the clock starts counting up at

the rate of 1 minute every 1 second (real-time).

2. Enter "1" via push button keypad

RESULT : The parking rate is set to $0.50 every ½ hour. The yellow LED

(indicates supervisory mode) turns OFF. This indicates normal operation and the system is waiting for the customer to enter a slot number for charge calculation.

TEST #2 : Basic Functionality – Paying Sequence (Normal Mode)

3. Enter "1" via push button keypad (current time = 12:55)

RESULT : 1 appears on the slot number display. The correct parking charge

of $13.00 and parking duration of 12:55 was shown. The charge / duration push button is use to toggle between displaying these 2 data.

MATH : Time in = 00:00 (initialized for slot 1)

Time out = 12:55

Duration = 12:55 – 00:00 = 12:55

# of ½ hour blocks = 12:55 / 30 minutes = 24

Total Charge = ( # of ½ hour block ) * parking_rate

= 24 * 0.50 = $12.00

 

4. Pay using the toonie and loonie push buttons.

RESULT : The charge displays decrements correspondingly when the buttons

were pressed. The paid LED turn ON when all charge have been

paid. The number of quarters provided as change is displayed in using the 4 LEDs. The parking rate is set to $0.50 every ½ hour.
The parking duration could still be viewed by pressing the charge / duration push button.

 

5. Hit Start / End push button (anytime during the cycle)

RESULT : The slot number display, duration and total charge resets to zero.

 

6. The paying sequence is repeated for different parking slots and parking rate

  TEST #3 : Clock Functionality

1. Initialize the clock to 29:00

RESULT : The clock display shows 20:00 because 29:00 is an invalid time setting. Thus, 9 was not accepted by the system and it is still waiting for a valid input. Reset could be pressed to reenter a new time.
2. Enter 3

RESULT : The clock display shows 23:00 because 23 is a valid hour setting.

2. Monitor IC Testing

The monitor consists mainly of the availability entity and the ram entity. It was tested by simulating several arrivals of car and the changes of photo_detect and avail signals were observed. The paid signal was preset to 1, and then a car departed from slot 2 was simulated. The alarm was sound and the alarm_off input turned it off. Then a car departed from slot 1, alarm did not sound. The full_sign light was observed when all the slots were occupied.

The ram was not tested directly. Another entity was written to read at a specific slot memory location when the trigger_sel button was pushed. The output data was mapped to four LEDs, therefore, we could test four bit of the data each time. The stored time was verified.

The testing entity is listed as below:

entity test_ram is
port ( clock, reset : in std_logic;
        trigger_sel : in std_logic;
        address : out std_logic_vector(7 downto 0);
        sel : out std_logic;
        ram_ready : in std_logic
        };
end test_ram;

6.0 OTHER CONSIDERATIONS

Speed vs. Area trade-off

The terminal controller and monitor entities were compiled using area optimization and then speed optimization. The result is documented below.

Thus, we see that by optimizing the design speed (faster) there would be an increase in the required logic cells and vice-versa. So, a trade-off would need to be made when the designing the system. Speed is not a major concern is a parking system controller, thus we would go for area optimization if required.

7.0 CONCLUSION

We have learned a lot from coming up with the idea of designing an automated parking system to building the actual system. During this period, we have gained valuable experience in writing VHDL codes, doing simulations, and implementing the system with hardware. Due to time constraint, the implementation of Automated Parking System is a little different from its original design. The Maxplus2 program is fairly easy to follow and to use. Since the Flex 10K Device is re-programmable, it is quite useful for us to redesign some of the entities. During the course of implementing our design, we encountered a lot of timing problem because we had many asynchronous inputs. We solved this problem by closely examining the simulation waveforms and subsequently correcting the VHDL codes. We consider our project is very successful and we are proud of our final product. The experience obtained during the course of designing the system is extremely valuable.

Presentation...

Presentation Photo #1

Presentation Photo #2

Presentation Photo #3

  Last Update: April 9, 1998