e-Parking Meter Management System

 

 

Home

 

Related
Work

 

System
Specifications

 

Hardware

 

Initialization

 

SAFE

 

Head
Meter
Rotation

 

Failure
Recovery

 

Energy
Consumption
Model

 

Central
Station

 

Challenges

 

Ethics

 

Conclusion

 

References

 

Documents

 

 

 

 

 

Central Station:

 

Graphical User Interface:

 

The Graphical User Interface (GUI) for the central server was developed using the Java programming language.  The GUI consists of a tabbed window with two tabs, the first one called “Table” and the second one called “Map”.

 

The “Table” tab contains the current status of all the parking meters in our “city” in a table format.  The table consists of the following columns:

  1. Group Number contains the group number of the group to which the meter belongs
     

  2. Meter Number contains the meter ID of the meter within the group (Group Number and Meter Number together serve as a unique identifier for any meter)
     

  3. Car contains a checkbox indicating whether or not there is a car parked in that meter's spot
     

  4. Time Left indicates the number of minutes left in the meter's counter
     

  5. Violation contains a checkbox indicating whether or not there is a violation in that parking spot (Violation is a logical combination of Car and Time Left)
     

  6. Battery indicates the level of the meter's battery, the percentage of the battery that remains unused
     

  7. Time Received indicates the date and time in which the last update was received (if no update has been received for a meter, the date and time shown are that of the epoch, January 1 00:00:00 GMT 1970)

The table is interactive, in that the user can click on the column headings to specify various sorting schemes, even sorting by multiple columns.  The “Refresh” button at the bottom can be pressed to refresh the information contained in the table.  This action displays the latest information received by a listening C program.  Click on the thumbnail below for a screenshot of the GUI’s “Table”.

 

The “Map” tab provides a graphical representation of some statistical/system information for our “city”.  Each meter is represented by a circle.  Meters are color-coded depending on their current status or role: yellow is a normal meter, blue was the meter that sent the central server the last update from its group (i.e. the last head meter), red is a meter from which the central server has received no information, orange is a meter for which the central server has not received the last three or more updates.  Next to each meter there is representation of its battery level.  A green battery represents a battery at 25% or better; a red battery represents a battery below 25%.  The battery’s level is indicated underneath.  The second portion of the screen contains statistics for each meter, most notably the number of updates received and missed since the program was started.  Click on the thumbnail below for a screenshot of the GUI’s “Map”.

 

 

Our GUI currently depicts a “city” of 12 meters.  This was done from the beginning to give us room to run with up to 12 meters and have the GUI capture all that information without any changes to the GUI.  However, due to the limited hardware we possess, we are only able to run 6 meters.  We chose them to be the meters with meter numbers 1, 2, 3, 7, 8, and 9.  Therefore, in our report and demo the GUI will never receive any information from the rest of the meters.  In a real system, the GUI would contain the entire city.  The map would have to be more sophisticated, depicting one little chunk of the city at a time but allowing the user to navigate his way around the city.

 

Statistics:

 

The central server also keeps a number of statistics and logs. As mentioned above, the "Map" tab shows the number of updates that have been received and missed by each meter since the program started running.  Every packet that is processed by the central station is saved to a file called "log.txt".  Every time a packet is processed, the maximum and minimum batteries are noted in a file called "battery_stats.txt"; therefore this file provides a history of the ranges of the batteries.  Every time the central server sends a packet with probabilities, it saves the probabilities to a file called "probs_stats.txt"; therefore this file provides a history of the probabilities used by the meters throughout the run.

 

Adaptive-Forwarding Probability Determination:

 

The central station will have access to a wealth of both short-term and long-term information about specific meters and groups of meters. This information can be used to determine the probabilities necessary to achieve the desired levels of reliability.

 

Size and Use of the SAFE Probability Matrix:

 

There are levels of increasing efficiency in which these probabilities can be calculated:

 

Level 1: A single probability which is independent of the source and the current head meter will be used when deciding whether or not to forward data not directed at a particular meter. This can be used to set the loss rate of the entire group to a particular level. But this can be energy inefficient as some meters may have a higher loss rate than others while all the data is being forwarded with identical probability. There are two special cases of level 1 SAFE. If this global probability is set to zero, then routing will be the standard single path determined by the Hop Values. If the global probability is set to one, then absolutely all overheard information will be appended, leading to the greatest degree of reliability as well as the lowest level of energy efficiency.

 

Level 2: A single probability which depends on the source but independent of the current head meter will be used when deciding whether or not to forward data not directed at a particular meter. This can be used to achieve a per meter level of reliability over a period of time. However, there will be some degree of inefficiency associated with this. As the head meter changes, paths will change and the reliability of the links may change. It could be the case that a meter’s information gets lost only when a particular meter is the head meter. This level will set a probability which will apply regardless of the head meter leading to data being forwarded when not necessary.

 

Level 3: A probability which depends on both the source and the current head meter will be used when deciding whether or not to forward data not directed at a particular meter. This will lead to the highest efficiency as data will only be forwarded when the path to a particular head meter are known to be unreliable. The disadvantage of this, however, is the large number of probabilities necessary. For a group of n meters, the size of the packet needed to hold this information as well as the size of memory needed to store this information will be O(n2).

 

Determination the SAFE Probability Matrix:

 

There are several factors that need to be considered when determining the SAFE probability matrix. The desired reliability threshold would depend on the application for which SAFE is used. For applications where very high degree of reliability is important, the threshold should be set to a high mark.

 

Long-Term Periodic Variations: In a busy city, the wireless traffic would be expected to vary depending on the time of day. If this is the case, and high traffic periods leads to higher loss rates, then the forwarding probabilities should reflect this periodic variations with higher probabilities to compensate for higher loss rates. If the central station can identify those patterns, it can adjust the probabilities proactively.

 

Short-Term Variations: Depending on the current situations, some links which have been consistently reliable in the past may experience a higher loss rate due to temporary changes in the immediate environment. In determining the probability matrix, such short-term factors should be included. Once the reliability rises above the reliability threshold, it is possible that the temporary disturbance is no longer present and it would be desirable to gradually lower the probability until there is equilibrium close to the threshold.

 

Consistently Bad Links: If a link is permanently bad, the scheme above for short-term variations will not stabilize. If, for a long period of time, a probability is seen to fluctuate up and down as the reliability threshold is violated and then met again, the link should be considered more permanently damaged and the process of decreasing the probability should be slowed down.

 

There will be some latency in the probabilities. The central station should not react right away to data loss as this will prevent the true identification of the type of disturbance. Immediate reaction would lead to an immediate increase in the probability, causing an almost immediate increase in reliability which will in turn cause a drop in probability. But if the disturbance is ongoing this will lead to unnecessary fluctuations. Instead, the meter should be monitored to determine whether the loss was due to a random event or an ongoing condition. Furthermore, it would be beneficial to have the probabilities increase faster than they decrease as this will result in fewer fluctuations and potentially greater reliability at the cost of some extra energy.