Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
SYSTEM AND METHOD FOR AUTOMATED CONTROL OF STREET OCCUPANCY BY A VEHICLE
Document Type and Number:
WIPO Patent Application WO/2020/249985
Kind Code:
A1
Abstract:
A system and method for automatic street occupancy control comprising means, such as a camera, for identifying a vehicle in a street segment, data transmission means and a central unit. A camera identifies said vehicle at the beginning of the street segment and the associated entry time and at the end of the street segment and the associated exit time, a microprocessor calculates the time difference between exit and entry of the vehicle and transmits the vehicle identification and the time difference to a central unit. There can only be a single camera or other means for identification of the vehicle at the beginning or at the end of the street segment, which identifies the entry and exit of the vehicle and the associated time, or besides the first, there can be second or more cameras, preferably at the end of the street segment, which would send the registered data related to the exit of the vehicle at the end of the street segment.

Inventors:
PATEROPOULOS CHRISTOS (GR)
Application Number:
PCT/GR2020/000029
Publication Date:
December 17, 2020
Filing Date:
June 10, 2020
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
PATEROPOULOS CHRISTOS (GR)
International Classes:
G08G1/017; G07B15/02; G08G1/04; G08G1/065; G08G1/14
Domestic Patent References:
WO2014072971A12014-05-15
Foreign References:
US20140145862A12014-05-29
EP2814002A12014-12-17
US20190050634A12019-02-14
US8698895B22014-04-15
US9064415B22015-06-23
US9224062B22015-12-29
EP1870868A12007-12-26
Attorney, Agent or Firm:
VERTELLIS, Socratis (GR)
Download PDF:
Claims:
CLAIMS

1. A street occupancy control system comprising means for identifying a vehicle in a street segment, data transmission means and a central unit, characterised in that it further comprises means for identifying said vehicle at the beginning of the street segment and the associated entry time and at the end of the street segment and the associated exit time, means for calculating the time difference between exit and entry of the vehicle and means for transmitting the vehicle identification and the time difference to a central unit.

2. The system of claim 1, wherein said means for identifying the vehicle are a camera module, a radar speed detector, a laser speed detector, and/or a radio frequency identification (RFID) detector.

3. The system of claims 1 or 2, wherein said means for identifying the vehicle comprises

means for reading the license plate number of the vehicle, or for reading a radio frequency (RF) identification tag of the vehicle, or for using geolocation of the vehicle or vehicle to infrastructure (V2X) communication or other identification data transmitted from the vehicle.

4. The system of claim 1 wherein the means for identifying the vehicle comprise first means positioned at the beginning of the street segment and at least second means, said second means are positioned at the end of the street segment.

5. The system of any of claims 1 to 4, wherein a street comprises one or more street

segments.

6. The system of any of claims 1 to 5, further comprising means to count the number of

vehicles parked in a street segment and calculate the number of available parking spots.

7. The system of claim 1, further comprising means for calculating the average time necessary to a vehicle to go through said street segment and subtracting from said time difference the calculated average time.

8. The system of claim 7, in which said means for calculating the average time necessary to a vehicle to go through said street segment are able to calculate the average time based on real traffic conditions at that specific time of the day.

9. The system of claims 1-8 in which the street segment is an area of a city.

10. A method for street occupancy control of a vehicle in a street segment comprising the steps of identifying a vehicle at the beginning of the street segment and the associated entry time, identifying said vehicle at the end of the street segment and the associated exit time, calculating the time difference between exit time and entry time, transmitting the vehicle identification and the time difference to a central unit, assessing whether said time difference exceeds a threshold time and assessing a fee when the elapsed time exceeds said threshold time.

11. The method of claim 10 in which the threshold time is the time necessary to a vehicle to go through the street segment under normal conditions. 12. The method of claim 11 in which the threshold time is calculated according to traffic

conditions of the specific date and time.

13. The method of any of the claims 10 to 12, further comprising the steps of:

- receiving a payment for the street occupancy of the vehicle

- comparing a value of the payment to the value of the assessed fee and

- issuing a fine to the driver of the vehicle when the assessed fee is greater than the payment received from the driver of the vehicle.

14. Use of the system of claims 1 to 8 for enforcing parking restrictions.

15. Use of the system of claims 1 to 9 for assessing the time a vehicle is spending within a city area.

Description:
SYSTEM AND METHOD FOR AUTOMATED CONTROL OF STREET OCCUPANCY BY A VEHICLE

The present disclosure relates to on-street parking control and, more specifically, to a system and method for providing automated control of street usage by a vehicle and for detection of unoccupied parking spot availability.

Parking management and enforcement of other restrictions are nowadays a core problem of smart cities. Revenue from parking is becoming a major source of income for cities to fund their local activities and investment plans and to lower citizens' taxation. As a result, cities are trying to optimize the parking enforcement solutions, to make the best out of their human resources and maximize the efficiency of their teams in terms of street coverage, man-hours and human error minimization. These efforts are often related to smart city infrastructures, such as smart on-street parking systems, which are typically used for identifying available parking spots in a street or area.

As increasing number of cars flood the roadways, locating a vacant parking space has become problematic. Difficulties in finding an available parking place require drivers to undertake prolonged searching, thus resulting in increased air and sound pollution, traffic, accidents, reduction of productivity and lots of lost man-hours.

Therefore, it is desirable for the parking management and enforcement systems to not only provide insights to the parking enforcement authorities, but also to help motorists find vacant parking spaces. Eliminating parking search can reduce city traffic up to a reported value of 30%, leading to direct significant environmental and economic benefits.

At present, payment for on-street parking is mostly done through online applications with the use of a handheld device, by paying at a parking meter, or by buying a prepaid parking card with fixed duration validity from local stores. Under these systems, motorists often have to identify their vehicles by online means (e.g., handheld device payment apps), or by entering and/or declaring their license plate numbers at the parking meter, which is tedious especially for the elderly or people with limited skills for utilizing technology. The experience can be more stressful because motorists need to act and pay again in case of an extended stay. Having the license plate numbers registered helps parking enforcement officers easily identify whether a vehicle is parked in a street without paying. However, the officers, while in duty, do need to scan all the driving plates in each street, or use other expensive solutions such as vehicles equipped with cameras having automatic number/license plate recognition capabilities. The efficiency of those systems depends heavily on the re-visit rate (e.g. how often a street is checked) and the rate of mistake the personnel makes. On the other hand, an automatic payment and parking enforcement system could increase the efficiency of parking enforcement teams to the maximum by practically 1) setting the re-visit time to zero, 2) minimizing any human mistakes, and 3) maximizing the coverage area.

Most on-street smart parking systems work with the principle of single parking spot occupancy/release detection. One disadvantage here is that the number of the single parking spot occupancy sensors increases in proportion to the length of the street and that this number increases further in case of non-delineated or non-slotted parking spots. At the same time, such sensors typically need to be embedded in the asphalt, which is a tedious and lengthy activity. An alternative solution involves the use of video cameras mounted at elevated positions at the side of a street which may detect more than one spot at a time. Such solutions are presented in the documents US8698895 (Nerayoff et al.) and US9064415 (Nerayoff et al.). This solution though is sensitive to physical obstacles such as tall vehicles or trees and has high installation and maintenance cost given the big numbers of cameras needed in order to improve accuracy. Furthermore, those on-street smart parking systems provide only parking spot occupancy information, but not any vehicle identification. Due to this limitation, the implementation of a fully automatic payment system is not possible. Also, the US9224062 (Wu et al.) is a hybrid video and vision-based method for controlling and managing parking conditions.

The present invention provides an automatic street occupancy control system and method comprising means for identifying a vehicle in a street segment, data transmission means and a central unit, means for identifying said vehicle at the beginning of the street segment and the associated entry time and at the end of the street segment and the associated exit time, means for calculating the time difference between exit and entry of the vehicle and means for transmitting the vehicle identification and the time difference to a central unit. There can only be a single means at the beginning or at the end of the street segment, which identifies the entry and exit of the vehicle and the associated time. In addition, besides the first means at the beginning of the street segment there can be second or more means, preferably but not necessarily at the end of the street segment, which would send the registered data related to the exit of the vehicle at the end of the street segment. A street segment may be defined by segment limits arranged on the ends of the street segment. Means for identifying vehicles may be provided at the segment limits in order to monitor and/or identify the vehicles passing by and crossing the segment. Also, two or more street segments may be merged and constitute a whole area of a city, which can be as big as a city centre, provided that in such an area all entries and exits are controlled by means for identifying vehicles. Inversely, one single street may comprise one or more street segments.

The means for identifying a vehicle, also called smart node, can be a camera module, a radar speed detector, a laser speed detector, and/or a radio frequency identification (RFID) detector or a combination of the above detectors. The smart node is able to read the license plate number of the vehicle, or to read a radio frequency (RF) identification tag of the vehicle, or to use geolocation of the vehicle or vehicle to infrastructure (V2X) communication or other identification data transmitted from the vehicle. More than one ways to identify a vehicle may be used.

The system and method may further include determining a traffic flow through a street segment. The vehicle and the time that a vehicle enters the street segment are determined using the first sensor and/or the second sensor. A time that the vehicle exits the street segment is identified using the first sensor and/or the second sensor and calculating an elapsed time as a difference between the determined time that the vehicle exits the street segment and the determined time that the vehicle enters the street segment. A threshold time that is dependent upon the traffic flow through the street segment is determined such that as the traffic flow through the street segment is faster, the threshold time is shorter. It is determined whether the elapsed time a vehicle is spending in a street segment exceeds the threshold time, said time is considered as the sum of the threshold time and the parking time, and a fee is assessed only when the elapsed time exceeds the threshold time. The value of the assessed fee may be proportional to the elapsed time, but may also follow another rule, which is not part of the present invention. The city authorities may also allow a grace period, which can be longer than the threshold time.

The system and method may further include means for determining the number of vehicles parked in a street segment and calculate the number of available parking spots. This information can be transmitted to the driver at the beginning of the street segment or even at any time at an electronic device, such as a smartphone.

A method for automated street tolling includes determining a time that a vehicle enters a street segment using a first sensor disposed at a first end of the street segment and/or a second sensor disposed at a second end of the street segment. The vehicle is identified using the first sensor and a second sensor. A time that the vehicle exits the street segment is determined using the first sensor and/or the second sensor and an elapsed time is calculated as a difference between the determined time that the vehicle exits the street segment and the determined time that the vehicle enters the street segment. A fee is assessed for the time spent within the street segment according to the elapsed time. This method for street occupancy control is also called street tolling, as is particularly useful when a city decides to impose restrictions to the use of a part of the city, such as a historical centre or a congested area. In this configuration every access and exit of said part of the city are equipped with smart nodes, such as cameras.

A method for automated on-street parking control includes receiving, at a central server, a parking request from a mobile device/electronic apparatus controlled by a user concerning a specified period of time and a specific vehicle. A payment request is sent back to the mobile device/electronic apparatus based on the specified period of time and the specified vehicle. Payment from the mobile device/electronic apparatus is received in response to the payment request. These communication and payment request and any payment handling may be processed via electronic apparatuses such as an electronic parking meter, a handheld or mobile device or the telematics system of a vehicle or by means of wired or mobile/wireless communication. A time that a vehicle of the user enters a street segment is determined using a first sensor disposed at a first end of the street segment and/or a second sensor disposed at a second end of the street segment, the second end being an opposite end to the first end. A time that the vehicle exits the street segment is determined using the first sensor and/or the second sensor and calculating an elapsed time as a difference between the determined time that the vehicle exits the street segment and the determined time that the vehicle enters the street segment. It is determined whether the elapsed time exceeds the specified period of time. A fine is assessed to the vehicle's owner, and/or a notification of a fine is sent to the vehicle's owner only when the elapsed time exceeds the specified period. Alternatively, the user may issue a parking payment request without specifying a time/duration, but by specifying a monetary amount. In this case the above fine is issued, if the elapsed time corresponds to a total payment greater than what was paid by the user. A more complete appreciation of the present in and many of the attendant aspects thereof will be readily obtained as the same becomes better understood by reference to the following detailed description. The description of the invention will be better understood when considered in connection with the accompanying drawings, wherein:

FIG. 1 is an embodiment of an on-street parking system applied in six one-way city streets; FIG. 2 is an embodiment of the components of a smart node;

FIG. 3 is an embodiment of the on-street parking system applied in a street segment;

FIG. 4 is an arrangement of the smart nodes for a crossroad with four streets;

FIG. 5 is a flowchart of the method providing on-street parking payment solutions and unoccupied parking spot detection;

FIG. 6 is a simplified flowchart for the method for providing on-street parking payment solutions and unoccupied parking spot availability detection;

FIG. 7 is a flowchart for the subprocess of street segment occupancy detection and calculation of parking fees;

FIG. 8 is a state diagram for available parking spot indication; and

FIG. 9 is an illustration showing the user/sensor/system interactions of the invented system.

In describing exemplary embodiments of the present disclosure illustrated in the drawings, specific terminology is employed for sake of clarity. However, the present disclosure is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents which operate in a similar manner.

In what follows, the term "street" may be defined as the space between building blocks of a city where there is a vehicle circulation. A street may have a specific length and a maximum allowed speed for vehicles that drive therethrough.

In order to simplify the identification and counting of vehicles, a street may be divided into two or more street segments. A "street segment" is any part of a street or of a path of any length that does not have a way leading to off-street parking facilities, entrance or exit of a parking facility, or a junction to another road or a street or any kind of exit route for a vehicle towards private facilities or public infrastructure where access is not controlled/monitored by means of a smart node or a sensor. In absence of any parking facility and of any junction, the street segment may be identical to the length of the street. Also, two or more street segments may be merged, provided that the identification and counting of vehicles would not be compromised. This might even result to an area formed from a plurality of adjoint street segments, or even a whole area of the city, provided that the in- and the outgoing traffic of vehicles is monitored.

A street segment may have parking spaces, for example, in one or in both sides of the driving lanes. While it may be less common, some streets may have parking between driving lanes. However, in all cases, a street must have at least one driving lane whose primary purpose is for vehicles to pass therethrough for some purpose other than entering or exiting a parking space. In contrast, a parking lot or parking garage is an area that is not a thoroughfare and serves no purpose for permitting vehicles to pass therethrough other than to enter, exit or navigate to an available parking space within the parking lot or parking garage.

At each end of a street segment there is a segment limit. The term "segment limit" may be defined as point of entrance or exit to a street segment. The length of the street segment may be defined as the distance between the two segment limits.

It is to be further understood that an end to one street segment may be considered a beginning of another street segment, with the terms "end" and "beginning" being used interchangeably herein. However, in some instances a street segment may terminate with a dead end though which vehicles may not pass.

As a further object of the present invention may relate to the billing of a driver/owner of a vehicle for time spent parked within a roadway, it is to be understood that, as used herein, the phrase "charging a vehicle" relates to an assessment of monetary fees to the driver/owner of the vehicle in exchange for the time spent parked within the roadway, or for just using the roadway, and this phrase is not intended to relate to the electrical recharging of batteries for electric and hybrid vehicles.

It is further to be understood that when it comes to parking payments the words "driver", "owner", "motorist" and "user" are being used interchangeably herein. In most of the cases they only mean to specify the person that initiated the payment for a specific vehicle that corresponded to a specific parking event. This person may be the driver of a vehicle, a passenger or any other person. On the other hand, when it comes to parking fines and penalties or fees for using a street, they are associated to a vehicle and or the vehicle's owner and not to the person that may have initiated a payment.

Each segment limit may be provided with a smart node. The smart node is a device that can identify vehicles entering and/or leaving a defined street segment. Identification of vehicles is performed by using one or more sensors integrated in the smart node. The sensors may use one or a combination of the following manners to identify vehicles, however it is noted that the present invention is not so limited and other approaches may be utilized: Radio Frequency Identification (RFID) techniques, video processing, telematics, mobile and wireless data communication services, and vehicle to infrastructure communication. Any data received from the vehicle via one of the above methods may include information such as but not only limited to the identification of the vehicle, geo-location data and vehicle status information and may change the system data and the system state. The identification of a vehicle may have various dimensions such as, but not limited to, the vehicle's driving plate, brand, model, color, shape, height, width, and length. Typically, when a vehicle traverses one street segment from segment limit SL1 to segment limit SL2, the vehicle is being identified a) entering the street segment from the smart node at segment limit SL1, and b) leaving the smart segment from the smart node at segment limit SL2. In case of a U-turn within a street segment, the same smart node may detect the entrance and the exit of the vehicle from the street segment.

The sensor may also carry out vehicle counting capabilities. It may use one or a combination of the following techniques to count vehicles, but not only limited to: computer vision, radar sensing, laser sensing (Light Detection and Ranging (LIDAR)), magnetic sensing, acoustic sensing, infrared sensing, inductive loop, pneumatic road tubes, and piezoelectric cables. Besides vehicle identification and counting, the sensor may also provide various other measurements, including, but not only limited to, the vehicles' rate of entry and exit in and out of a street segment respectively. It is to be further understood that although the word "sensor" may refer to one building element of the smart node, it is also being used interchangeably herein with the term "smart node".

Alternatively, the vehicle counting and measuring capacities may be performed by a microprocessor that may be integrated within the smart node and analyze the data from the sensor.

According to at least one exemplary embodiment, a method and a system for providing on- street parking payment and unoccupied parking spot availability detection may be shown and disclosed. When a smart node identifies a vehicle entering a street segment, the time and date of that event may be logged. Subsequently, when a subsequent smart node identifies the same vehicle leaving the street segment, the exit time and date may be logged as well. By detecting the entrance and exit of the vehicle, the system may calculate the total time the vehicle has spent parked in the street segment and charge a registered user or owner of the vehicle accordingly. Payments may be done seamlessly via an automatic payment system where the users need to sign up in advance and associate their account with a vehicle. Alternatively, the users may employ other forms of payment such as but not only limited to: the use of a parking meter, via mobile or handheld devices, via the telematic services of a vehicle or via online payments. In this case any paid amount and or the specified parking time is compared with the calculated parking fee and or with the calculated parking time respectively and in case of a mismatch, a fine may be issued. This fine, or citation, or Penalty Charge Notice (PCN) may be sent to the user and/or to an appropriate authority in charge of the parking fines.

A fee may be further calculated for using a specific street or a specific city area. Based on calculations such as these, the system may issue a fine or charge automatically the account of a registered user accordingly. Payments and/or charging of the account corresponding to a vehicle may be done seamlessly via an automatic payment system where the users need to sign up in advance and associate their account with a vehicle. Alternatively, a fine for using the street may be sent to the user and/or to an appropriate authority in charge of the street usage fees.

In Figure 1 is shown an illustration of the on-street parking system applied in six one-way city streets. Streets 101, 102 and 103 have traffic direction from east to west, and streets 110, 111 and 112 from south to north. The buildings 120 and 121 along street 101 may have pathways leading to off-street parking 131 and 132, respectively. As a result, street 101 may be covered by three street segments defined by the segment limits 180 & 181, 182 & 183, and 184 & 185, respectively. The segment limits 180-185 may have their dedicated smart nodes 190-195. Alternatively, a smaller number of smart nodes, that can monitor multiple segment limits may be used. In one embodiment, streets 102, 103 and 111 may have three street segments defined by the segment limits 150 & 152, 153 & 187, 151 & 164, respectively. Here, since there is no other uncontrolled pathway or route leading to or originating from the street segments, all vehicles entering the street 103, 102, and 111 from the street segment limits 187, 152, and 151 respectively, unless violating the traffic direction of the street, will have to go out from the street limits 153, 150, or 164 respectively before passing from any other segment limit. Alternatively, streets 102, 103, and 111 may be combined into one big street segment defined by an entrance segment limit 187, an exit segment limit 164, and a second exit segment limit 150. The segment limits 187 and 164 may have smart nodes 197 and 174, respectively. Since a vehicle passing from the segment limit 150 can either go north crossing the segment limit 162 (and thus be identified by the smart node 172) or go west crossing the segment limit 185 (and thus be identified by the smart node 195), the segment limit 150 may have no smart node. In essence, smart nodes 195 and 172 become the "end nodes" of segment limit 150, since both of them, together, can capture and identify all the vehicle traffic crossing segment limit 150.

The smart node may be arranged at such a physical location as on the street, on the sidewalk, on the side of the street or in an elevated position, depending on the type of sensor used. For example, a video sensor and a Radio Frequency Identification (RFID) sensor may need to be placed in an elevated position. The elevated position may be on traffic lights, lighting poles, signs, standalone poles and columns, or even on building walls. Furthermore, a smart sensor monitoring a segment limit might not need to be physically aligned with the limit but may be disposed close by.

In Figure 2 is shown an embodiment of the components of a smart node 200. The smart node 200 may have four main functional blocks: a power supply 210, a transceiver (Rx/Tx) 220, a microcontroller 230, with or without an embedded memory, and a sensor 240. The power supply 210 may provide the necessary voltage and current to the other components. The transceiver (Rx/Tx) 220 may enable wireless and/or wired communication. The sensor 240 may perform vehicle identification and counting tasks. The microcontroller 230 may be responsible for synchronizing all the other components, analyzing the data from the sensor 240 and/or the transceiver (Rx/Tx) 220, organizing and sending the information via the transceiver (Rx/Tx) 220.

Identification of vehicles may be carried out in a variety of manners such as, but not only limited to, RFID, Vehicle to Infrastructure (V2I, or V2X) connectivity, vehicle telematics data, and vehicle license plate recognition (with the use of cameras). In one embodiment, a smart node may use one or more of the three different ways to identify a vehicle, as desired. Furthermore, the identification process may be performed at a remote server while using the data one smart node may provide. A smart node may communicate wirelessly and/or wired with other smart nodes, with vehicles, or with other infrastructures including, but not only limited to, parking meters, traffic lights, streetlights, and remote servers. The smart node may receive information including, but not only limited to, configuration commands, commands for performing various calculations, data analyzing commands, and commands for transmitting and relaying information. The smart node may transmit information including, but not only limited to, vehicle counts, rate of vehicle count, timing of the event, vehicle identification data such as the driving plate, color of a vehicle, shape, dimensions, the brand of a vehicle and its model type. Furthermore, it may transmit stored and/or live video and images, sounds and any other environmental measurements, already processed by the smart node or not.

In Figure 3 is shown an illustration of the on-street parking system applied in a street segment. The street segment 301 on street 300 may be defined by segment limits 310 and 311 and the direction of the street is from right (segment limit 311) to left (segment limit 310). Smart nodes 320 and 321 may be responsible for monitoring the segment limits 310 and 311 respectively and measuring the time a vehicle 390 spent in the street segment. This time measurement may be performed from a smart node or from a remote server 332 by comparing the timestamps taken for smart nodes 320 and 321 corresponding to the identification of vehicle 390 crossing the segment limits 310 and 311 respectively. The smart nodes 320 and 321 may communicate with each other. They may also communicate with a parking meter 333, a remote server 332, and the vehicle 390. The communication can be done directly or through a remote server.

In an embodiment, the measured time may be used for calculating the appropriate parking fees and for charging the vehicle 390 automatically the corresponding parking costs for being parked within the street segment defined by the segment limits 310 and 311. This process may be associated with an automatic payment system but may also take into account any other payments done via a parking meter 333, a mobile or handheld device 331 and or vehicles with connectivity and payment capabilities 390.

In another embodiment, in order to complete a parking payment, a user might register the license plate of the vehicle 390 at/with the parking meter 333 and specify a monetary amount and or a parking duration. The parking payment might also be completed with a handheld or a mobile device 331 or via a vehicle 390 that has an advanced microcontroller and connectivity capabilities. If the vehicle 390 is not registered in the automatic on-street payment system as disclosed, the measured time the vehicle has spent in the street segment may be compared against the specified parking duration. At the same time, the corresponding parking fees may also be compared against any payments the user might have done via at least one electronic transaction.

In another embodiment, the vehicle 390 may be equipped with one of the following or a combination of the following (but not only limited to): wireless/data connectivity, Vehicle to Infrastructure (V2X) communication capabilities and with RFID capability.

In another embodiment, if the paid parking time for the vehicle has expired or if a user never paid any parking fees or if the calculated charges are more than what was paid for the specific parking event, the system may automatically calculate a fee and or a fine and do at least one or more of the following (but not only limited to): sending to the vehicle's owner the bill or a citation, charging the account corresponding to the specific vehicle, and notifying appropriate authorities.

The remote server 332 may be connected to a database 334, in which car identification information and corresponding account information is stored. Users/drivers may setup account information and/or pay for parking using a remote computer 335 and/or a mobile electronic device, such as a smartphone or a mobile device 331, via vehicle with communications capabilities, like 390 or, over a computer network 330, such as the Internet.

In another embodiment, the measured time the vehicle 390 has spent in the street segment defined by the segment limits 310 and 311 may be used for charging the vehicle automatically a fee for using/passing through this street segment. This may also include, but is not only exclusive to, parking charges. If the vehicle is registered in an automatic payment system, then the payment of the above fee may be performed automatically/ seamlessly. If not, the fine and/or a notice may be sent to the vehicle's owner and/or the appropriate authorities.

In Figure 4 is shown an arrangement of the smart nodes for a crossroad with four streets. The four street segments 441, 442, 443, and 444 may have segment limits 451, 452, 453 and 454, respectively. These four segment limits may be monitored by four dedicated smart nodes, but, in this case, by two smart nodes 430 and 440 that have the capability to monitor all four street segment limits. The smart nodes 430 and 440 may identify vehicles by means of such as, video monitoring, automatic license plates recognition, RFID or V2X communication.

In an embodiment, the smart node 430 may be responsible for monitoring segment limits 453 and 454, while the smart node 440 for monitoring segment limits 451 and 452.

In another embodiment, one smart node placed carefully may be responsible for monitoring all four segment limits 451, 452, 453, and 454 (although in this case, monitoring only two of them (e.g. 451 and 454) may be enough). Such a smart node may use multiple video sensors, or a video sensor with wide lenses, and/or RFID and V2X capabilities.

It is noted that while the drawings show that there may be an unassigned portion of street between two proximate street segments, exemplary embodiments of the present invention need not be limited to such an arrangement and two proximate street segments may abut such that there is no unassigned portion of street therebetween. However, it is noted that where unassigned portions of street are present between proximate street segments, these unassigned portions of street may be portions of street in which parking is either illegal or improbable, such as in an intersection.

In Figure 5 is shown a flowchart for a method providing automatic on-street parking payment and unoccupied parking spot availability detection. In order not to confuse the key steps of the method, a simplified flowchart is shown in Figure 6. The process may be performed for every vehicle that enters a street segment S, and for every monitored street segment, regardless the traffic conditions. The process may start when a vehicle V enters the street segment S and its parameters and calculations are not correlated with possible data existing, if this vehicle was in this street segment before.

The street segment S may have two smart nodes Nin and Nout arranged at the beginning and the end of the street segment, respectively. The smart nodes Nin and Nout may detect the vehicles that enter and exit the street segment S and record the timing of those events.

A parameter, "pass through delay" Tptd, may be defined as the time it takes for a vehicle to drive through the street segment S without stopping in order to park. The "pass through delay" Tptd may be specific to the street segment S and take different values over the day depending on traffic conditions. Tptd may have two parts: a fixed part, which may depend on the characteristic of the street segment S including, but not only limited to, its length, the street's maximum allowed speed, the presence of stop signs or traffic lights, and whether the vehicles coming out of the street segment S have priority; and a variable part, which may depend on traffic conditions and/or weather conditions. In one embodiment, the variable part of Tptd may take its value from other external systems including, but not only limited to, mapping and traffic monitoring applications, such as WAZE and GOOGLE MAPS, each of which is developed by GOOGLE LLC and or its parent company ALPHABET INC., or another city traffic calculation systems. In another embodiment, Tptd may be determined internally. For example, the time that the last vehicle spent going through the street segment S may be used to set the new value of the "pass through delay" Tptd. In another embodiment, previous measurements from the vehicles that passed through the street segment S might be taken into account in an average or weighted average manner. In another embodiment, the "pass through delay" Tptd of adjacent street segments may be also taken into account. In another embodiment, historical data, including traffic of the day before, may be taken into account.

A parameter, "no pay time" Tnp, may be defined as the time period beyond which a vehicle within a street segment needs to have a valid payment. This parameter may be street segment specific and be set by the parking authorities. In one embodiment, the no pay time Tnp takes into account the actual traffic conditions and may change therefore dynamically, with the threshold time being dependent upon the vehicles' traffic flow and the time it takes to traverse the street segment. For example, the traffic conditions may include a characterization of the congestion and speed of traffic moving through the street segment and/or through other regions of the street close in proximity to the street segment. This characterization of traffic conditions may vary from "light" meaning traffic is sparse and/or fast moving, to "heavy" meaning traffic is congested and/or slow moving. The measure of speed may be an average speed of individual vehicles traveling through the roadway. The measure of congestion may be based on a total number of moving vehicles within a designated region of the roadway, such as the street segment.

The no pay time Tnp may be calculated using data provided by the sensors, such as cameras, of the smart nodes, with the maximum period of time within which no payment is assessed being extended as the time it takes for a vehicle to traverse the street segment increases. In another embodiment, Tnp may be set on the basis of the "pass through delay" Tptd. In another embodiment, Tnp may be set to zero. This may be the case when the system administrator wants to charge the vehicles for using (passing through) the street segment and not only for parking in it.

A variable, "circulation flow disruption" Circ_dist, may be defined, and triggered with the presence of some events in a street segment S that do not allow the vehicles to continue moving towards the exit of the street segment S that may include but is not only limited to a road closure or an accident.

In an embodiment, the whole process may start at Block 1001, when the smart node Ninl of the street segment SI detects that a vehicle VI enters SI. Then, at Block 1020, Ninl may identify the vehicle VI, register the entrance time, and mark VI as "not parked". In one embodiment, the smart node Ninl may identify the vehicle VI by means of license plate recognition. Alternatively, Ninl may identify VI through RFID or V2X communication or from other data originating from the car and communicated wirelessly.

Vehicle VI may be marked as "parked" in the street segment SI at Block 1038 if: (1) it is determined that vehicle VI is still in street segment SI at Block 1030, (2) it is determined at Block 1031 that the vehicle VI stays within SI for a time period longer than expected, given the traffic conditions, (e.g. the criteria may be, but not only limited to, the pass through delay Tptd of the street segment SI for the specific time) and it is determined at Block 1032 that the circulation flow in SI is not disrupted, or (3) although VI has not stayed within SI longer than expected, it is determined at Block 1035 that another vehicle V2 that entered SI after VI has exited SI, while VI is still in SI.

If at Block 1032 it is determined that the circulation is disrupted, then the parking authorities may be notified at Block 1033.

At Block 1038, as the vehicle VI is registered as parked, the system may be updated to show one less available parking spots in the street segment SI. The registration of the vehicle VI as parked may also happen earlier, if a parking notification is received originating from the vehicle VI or the motorist/user by means of telematics and or wireless communication. A notification like that might include identification, geolocation and vehicle's status data. Alternatively, an early registration may happen if the smart nodes Ninl and Noutl have remote tracking and motion detection capabilities and detect the parking event of VI. If the node Noutl, at Block 1030, detects that the vehicle VI exits SI and VI was not marked earlier as parked in SI, then, at Block 1040, the system may calculate the time that the vehicle VI spent within SI and its average speed. The average speed may be calculated by taking into account the length of the street segment SI and the timestamps corresponding to the identification of vehicle VI -performed by the smart nodes Ninl and Noutl- when entering and leaving SI respectively. If it is determined at Block 1041 that the average speed is more than the max allowed speed in SI, then the authorities may be notified at Block 1042, and then, the "pass through delay" Tptd for SI is set at Block 1043 to a minimum defined value. If it is not determined at Block 1041 that the average speed is more than the speed limit of SI, the time that the vehicle VI spent in SI may be set at Block 1044 as the new "pass through delay" for the street segment SI.

In an embodiment, this average speed calculation may be estimated between two points A and B that are not necessary part of the same street segment, but may be segment limits of different street segments. In this case, the average speed may be calculated by taking into account a) the timing information retrieved from the sensors/smart nodes monitoring point A and B and b) the minimum possible route/distance between points A and B, such as to calculate the best-case scenario for the driver.

It is noted that the average speed referred to by Block 1041 may be determined by any known approach. For example, the average speed may be determined as taught by European Patent Specification EP 1870868, published on October 8, 2008.

At Block 1060, the process proceeds to a payment subprocess for the vehicle VI, which has been registered as "parked", by searching in a remote database whether the vehicle VI has been registered in the automatic payment system as disclosed in this disclosure. A motorist may enroll in the automatic payment system in advance to automate his parking payments. If the determination at Block 1060 is "yes", then when the smart node Noutl detects at Block 1061 that VI exits SI, it records the exit time and the automatic payment system may calculate at Block 1062: a) the total time that the vehicle VI spent in SI, and b) the parking charges for this calculated time that may include any fines. The calculation of the time may take into account parameters such as, but not only limited to, the no pay time Tnp parameter, the "pass through delay" Tptd at the time of entrance and exit of the street segment SI and the time delay because of a circulation flow disruption. If the determination at Block 1061 is "yes", it is determined at Block 1065 whether there is a maximum allowed parking time limit (e.g., as a parameter imposed by the cities) and it has been exceeded. When the maximum allowed parking time limit is exceeded, a separate fine may be issued, and the authorities may be notified in block 1066.

If it is determined at Block 1060 that the vehicle VI is not registered in the automatic payment system, then the process may proceed to Block 1070 to determine whether there is a valid payment registered in the remote database through means of, but not only limited to, online, handheld and/or mobile device, any integrated payment system the vehicle may have, and payment through a parking meter. If it is determined at Block 1070 that there is no valid payment and it is determined at Block 1071 that the unpaid time is more than the "no pay time" Tnp, a designated time for which no payment is due, then at Block 1072, the authorities may be notified, a parking violation fine may be calculated, and the value for the next parking payment fine for VI in SI may be increased. The steps illustrated in Blocks 1070-1072 may be repeated till the smart node Noutl detects at Block 1073 that VI exits SI. Then, when it is determined at Block 1073 that the vehicle VI is still in the street segment SI, it is assessed at Block 1075 whether there is a maximum allowed parking time limit and it has been exceeded. When the maximum allowed parking time limit is exceeded, a separate fine may be issued, and the authorities may be notified in block 1076. If it is determined at Block 1073 that the vehicle VI has left the street segment SI, in Block 1074, a total fine may be calculated and issued, which may be a cumulation of smaller ones. This calculation might take into account the recorded time of VI leaving SI as determined/captured from the smart node Noutl.This calculation might also take into account parameters such as, but not only limited to, Tnp and Tptd. In one embodiment, any repeated payments during a prolonged stay may be taken into account. On the other hand, if it is determined at Block 1070 that there is a valid payment, a fine of zero value (or a void fine) may be calculated at Block 1074.

Because the vehicle VI, which was marked as "parked" in the street segment SI, is detected by the output smart node Noutl as leaving SI, at Block 1080, a notification may be issued indicating the availability of an extra available parking spot in SI. This might happen earlier if by means of telematics and/or wireless communication originating from the vehicle VI or the motorist, the system gets notified directly that the vehicle VI is not parked any more. Alternatively, an early notification may happen if the smart nodes Ninl and Noutl have remote tracking and motion detection capabilities and detect the departure of VI.

The above described embodiments of automatic on-street parking payment system and method may apply to one-way streets. With slight modification, the system and method may also apply to streets with bidirectional traffic. Two street segments parallel to each other may be defined in a two-way street. Smart nodes may be provided in the segment limits, and responsible for bidirectionally detecting the vehicles that enter and exit the street segments.

According to the simplified flowchart of Figure 6, first the vehicle VI is registered as entering the segment SI (Block 1101). Thereafter it is determined whether the vehicle VI is traveling through the segment or parking therein (Block 1102). If the vehicle VI is determined to be parked, then it is determined whether the vehicle VI is registered in the automatic payment database (Block 1103). If it is registered, then payment may be deducted (Block 1104). If it is not registered, then it is determined whether alternative payment is available (Block 1105). Then total fees may be calculated and authorities may be notified if needed (Block 1106). Thereafter notice of payment may be sent (Block 1107). If, however, it is determined that the vehicle VI is not parked (Block 1102), then maximum speed of the vehicle through the segment may be monitored (Block 1108) and then it is determined if the vehicle has exceeded the speed limit (Block 1109). If it is so determined, then the authorities may be notified and/or a fine assessed (Block 1110).

Figure 7 represents a flowchart for the subprocess of street segment occupancy detection and calculation. The vehicles may be charged based on occupancy in a specific street segment. Such system may also include the parking charges and may be used together or independently from the system of Figure 5. Charges may be varied according to the following parameters (but not only limited to): the duration of the street segment occupation, day and time, traffic conditions, city rules and circulation restrictions, vehicle size, age and type.

The same principle may be applied to a joint combination of a plurality of nearby street segments forming a street segment area where the vehicles coming in and out from the area are monitored.

This process may be performed simultaneously for every vehicle that enters a street segment of any length and for every monitored street segment, regardless the traffic conditions.

The process starts at Block 1200 with the detection of a vehicle entering a segment. When, at Block 1210, the same vehicle exits the segment, the system, that has logged the vehicle's entrance and exit time at Blocks 1200 and 1210 respectively, may calculate the total time the vehicle has spent in the street segment at Block 1220 and the total applicable chargesfor using/occupying the segment at Block 1230. Then the system determines if the vehicle is registered in the automatic payment database/system at Block 1240. If the vehicle is indeed registered, then the charges are deducted automatically from an account/digital wallet registered for the specific vehicle at Block 1250. If not, a payment notice may be sent to the owner of the vehicle or to the officials in charge of the system usage or to another appropriate organization at Block 1260. The process may end at Block 1270.

Figure 8 represents a state diagram for available parking spot indication. There may be three states of parking occupancy or availability of a street segment: Lots of spots, Saturated, and Full. In other embodiments, there could be more or fewer states. In Figure 8, "W" may refer to the number of vehicles in the street segment; it may be changed by the flowchart shown in Figure 5. The parameter "increased traffic" may be defined as a parameter of the street segment and correlated to the increased "pass through delay".

A parameter Pmin may be a threshold specific to a street segment, referring to the number of occupied parking spots in the street segment below, which there are plenty of available parking spots.

A parameter Psat may be another threshold specific to a street segment, referring to the number of occupied parking spots in the street segment beyond which it is difficult to find an available parking spot. Psat is greater than Pmin (Psat>Pmin). The parameter Psat may be influenced by various parameters, including, but not only limited to, the theoretical number of slotted parking spots the street segment may fit, and the type of parking allowed in the street segment (e.g., parallel parking, or parking in angle). Psat may change dynamically based on the summation of the length of the identified vehicle parked in the street segment. For example, the length of a vehicle may be calculated based on the vehicle identification (e.g., brand, model or the like) or by simply video processing performed from the smart nodes.

A parameter Pmax may be another threshold specific to a street segment, referring to the maximum number of occupied parking spots a street segment may have. Pmax is greater than Psat (Pmax>Psat). The parameter Pmax may be dynamic in the street segment, depending on various factors, including, but not only limited to, the length of the street segment, whether there are parking spots under angle or parallel to the street segment, and the length of the vehicles identified within the street segment.

Kx may refer to a plurality of system-defined parameters that are specific to a street segment. The number of Kx depends on the number of states. In a state diagram for a street segment with three states, a group of four parameters Kl, K2, K3 and K4 may be enough. The purposes of Kx is to provide hysteresis (if needed) to the state transitions and they may be positive or negative numbers. Furthermore Kx may also be dynamic parameters: they might depend, for example, on the time of the day or on the traffic conditions

In Figure 8, the state "Lots of Spots" shown in Block 1210 may be a state in which the street segment may have a plurality of available parking spots. From the state "Lots of Spots", if the number of parked vehicles W increases above the value of "Pmin+Kl", there may be a state transition as illustrated by the arrowed line 1211 to the state "Saturated" shown in Block 1220. Also, from the state "Lots of Spots", if there is a determination of "circulation block" (or "circulation flow disruption"), there may be a state transition as illustrated by the arrowed line 1212 to the state "Full" shown in Block 1230.

From the state "Saturated" shown in Block 1220, if W becomes smaller than the value of "Pmin+K2", then there may be an opposite state transition as illustrated by the arrowed line 1225 back to the state "Lots of Spots" shown in Block 1210. Or, if there is a determination of "increased traffic" in the street segment SI and/or in the nearby street segments (1221), or if there is a determination of "circulation flow disruption", or if W increases above the value of "Psat+K3", there may be a state transition as illustrated by the arrowed lines 1221 and 1222 to the state "Full" shown in Block 1230.

From the state "Full" shown in Block 1230, if W decreases below the value of "Psat+K4" and there is neither a determination of "circulation flow disruption" nor of "increases traffic" in SI and/or in the nearby street segments, an opposite state transition as illustrated by the arrowed line 1235 to the state "Saturated" shown in Block 1220 may happen.

From the state "Full" shown in Block 1230, the increase of W may lead to the increase of Pmax as illustrated by the arrowed line 1231. Under this circumstance, there may be no state transition, though a change in other state diagram parameters may be caused. The information on the status of a street segment such as, but not only limited to, the following: the parking occupancy state (e.g., Full, Saturated, Lots of Spaces, Someone Just Left, etc.), the actual number of cars in a street segment, the estimated traffic conditions and any circulation flow disruption may be reported to the parking authorities, the motorists and the public through a dedicated website and/or applications for handheld or other portable devices or vehicles.

In Figure 9 are shown the data interactions between the different components of the system.. The first level of interaction may begin with the users signing up for the automatic payment system. This may be done via a web form and a dedicated application by using an electronic device such as, but not only limited to, a handheld device 1310 or a computer. Alternatively, it may be done with a written form 1312, but, in this case, an authorized person may need to process the data electronically by using a computer system 1311. The registration may include, among other data, parameters such as but not only limited to the following: the vehicle's registration data, its license plate, the brand, the model the color and a preferred payment method. The preferred payment method may be, but not only limited to, credit card information, a bank account where charges may be deducted, a digital online wallet or a demand to receive the bill electronically or to be sent to the user. All this information may be stored securely in a remote database 1320.

The second level of data interaction may be between the hardware of the system and the users while parking or trying to pay. This may be coordinated from a remote server 1321. The remote server may communicate with a plurality of electronic devices including, but not only limited to, a plurality of smart nodes like 1330 and 1331, with electronic parking meters 1332, mobile and/or handheld devices 1333 or Vehicles 1334. This information may be transmitted in the form of block- chained cryptographic or any other encrypted data and may be stored to a database such as 1320. Furthermore, the server 1321 may also communicate with other remote databases, such as 1322, and remote servers in order to access information regarding an identified vehicle. This information may include, but not only limited to, vehicles' registration data, insurance data and law enforcement databases.

The smart nodes 1330-1331, via wired or wireless communication, may communicate with the server 1321, the parking meter 1332, a vehicle 1334 or any user with a mobile and/or handheld device 1333 or relay to each other information such as, but not only limited to, the identification of vehicles, timing events, or other messages/data they received from other system components/users. If this information concerns vehicles registered in the automatic payment system, then a payment may be deducted automatically. The smart nodes may also send information such as, but not only limited to, live or stored: captured images, video and audio signals. Furthermore, the smart nodes may interact with other city infrastructure such as traffic lights or city lights or display boards.

A vehicle like 1334 may wirelessly communicate with a smart node like 1330-1331 or a parking meter 1332 or a server 1321, transmitting information such as but not only limited to: vehicle identification information and payment commands or vehicle state data, geolocation data and payment transaction data and commands. This may be done by means such as, but not only limited to, RFID, V2X communication by using , any wireless connectivity data protocol such as Global System for Mobile Communications data (such as GSM or cellular data, G3, G4, G5) or Short Message Service (SMS, text messages). This information might include commands from digital wallets.

A user, after parking his vehicle, may use the parking meter 1332 to pay the parking charges by declaring his vehicle's license plate, the desired duration and using a mean of payment such as but not only limited to cash or any electronic transaction. This information may be transmitted from the parking meter 1332 with wired or wireless communication to the smart nodes 1330-1331 and/or to the server 1321.

Alternatively, a motorist may use, within his vehicle 1334 or out of it, one of the following but not only limited to: a handheld and/or mobile device 1333 or any other electronic device, or a personal digital assistant, or any embedded application or software in the vehicle utilizing the vehicle's communication capabilities to send payment commands through a website or an application. This may be done by identifying the vehicle and specifying the desired parking duration and or the desired amount of money to be paid. The payment itself may be done by means such as but not only limited to a digital wallet, a credit card and by a bank transfer. This information may be sent directly to the server 1321 or to any other intermediate repeaters.

A third level of data interaction may have to do with the communication of the system with the parking authorities, and the motorists. These may be administration commands and may also include information on the status of each street segment such as (but not only limited to): the parking occupancy state (e.g., Full, Saturated, Lots of Spaces, Someone Just Left, etc.), the actual number of cars in a street segment, the estimated traffic conditions and any circulation flow disruption. This information may be shared through a dedicated website, software packages or applications for handheld and/or mobile device or for vehicles or a digital assistant which may have different flavors and capabilities, when being used from system administrators, parking authorities, city officials, subscribed motorists or the public. This information may be accessed wirelessly or with wired communication by means of electronic devices, such as computers 1340 or any kind of mobile and handheld device 1341, digital assistants, or may be even accessed from motorists via the vehicles' infotainment system 1342.

The present invention finds application in on-street parking management and enforcement in urban areas. However, this may be used to other applications. For example, the system and method as disclosed may be used to street segments of indoor parking lots, in order to find empty spots.. Also, the time that a vehicle spent within an area such as in a city center may be tracked for the purpose of assessing a fee associated with road usage. Also, the time that a vehicle spent in a street segment may be tracked for one or a combination of the following purposes: calculating parking charges, assessing fines associated with breaking rules of the roads (e.g., violating maximum speed limitation, city circulation restrictions, parking in unauthorized places or the like), detecting parking spot availability, and directing motorists to vacant parking spots. Parking time duration of a vehicle may be counted as starting at the moment the vehicle enters the street segment and ending when the vehicle leaves the street segment. Furthermore, a given grace period of free parking time may be subtracted from the total measured parking time. The estimation of parking availability may be communicated to the parking authorities, the motorists and/or the public in the form of occupied states (e.g., Full, Saturated, Lots of Spaces, Someone Just Left, Number of available places, etc.) of the parking places. This estimation may also be indicated in the form of exact number of vacant parking spots, traffic conditions and/or any circulation flow disruption. This may be done via a website and/or dedicated applications for handheld and mobile devices or for vehicles, through a digital assistant.

Exemplary embodiments described herein are illustrative, and many variations can be introduced without departing from the spirit of the disclosure or from the scope of the appended claims. For example, elements and/or features of different exemplary embodiments may be combined with each other and/or substituted for each other within the scope of this disclosure and appended claims.