EP3929892A1

EP3929892A1 - Traffic control system

Info

Publication number: EP3929892A1
Application number: EP20182410.9A
Authority: EP
Inventors: Takao Kojima; Yuji Oishi; Keiichi Katsuta; Takehito Ogata
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2020-06-26
Filing date: 2020-06-26
Publication date: 2021-12-29

Abstract

A Traffic control system 100 for managing the flow of vehicles within a predefined sector of a road, the predefined sector being divided into subsections and the traffic control system having a plurality of traffic control devices 1a-d connected to a network, each traffic control device is configured to control the flow of the traffic in a subsection of the predefined sector and comprises at least one communication unit 20 for receiving or transmitting data from a remotely located communication unit, wherein the communication unit 20 is configured to receive an entry request from a vehicle 10 approaching the subsection before entering said subsection, and transmit one token 2a-d with one entry permission flag 3a-d for said subsection to said vehicle 10 in response to said entry request, if at least one token 2a-d and at least one entry permission flag 3a-d is stored in a data storage space 13 linked to said subsection.

Description

The present disclosure relates to a traffic control system for managing the flow of vehicles within a predefined sector of a road, such as a crossing or a round-about, and it relates to a computer program product comprising computer-readable instructions that can be executed in a computer system including one or more computers. In particular, it is provided an automated traffic control for a controlled sector (without traffic lights) which requires reduced/minimal computational and data transmission resources. Preferably, even specific traffic situations can be controlled in which, e.g., emergency vehicles request priority for entering or passing the controlled sector of the road. The safety of the automated traffic control and automated driving is increased, too.

Background

Traffic flow management especially in urban areas with a high density of traffic is increasingly important for avoiding traffic jams and for ensuring a high level of safety. Automated solutions are known which however require high computational performance/power and which may not cover specific traffic situations (comprehensively) or which require additional high computing resources for handling specific traffic situations. For example, there are systems which predict the future travelling trajectories of all vehicles in a controlled sector or around a controlled sector and which perform a control based on the trajectories for avoiding collisions. Other systems inform autonomously driving vehicles about the presence of an emergency vehicle nearby. The control techniques are described by US 2019/130739A1 and US 2019/302781 A1 .
As mentioned above, the required computational resources are immense and specific traffic situations, such as the occurrence of an emergency vehicle or the like, are not reflected or require additional high computational effort.

Problem and Solution

It is an object of the herein described disclosure to provide a solution which, in particular, includes an automated traffic control system for safely managing the flow of vehicles within a predefined sector of a road and a computer program product which can safely and in an automated manner control the traffic, wherein the required computational resources and the required data transmission resources are minimized, preferably even when handling specific traffic situations. This is solved by the appended claims.
The following aspects may be provided in particular:
A Traffic control system for managing the flow of vehicles within a predefined sector of a road. The controlled sector may be a crossing, a round-about or any other part of a road at which lanes overlap with each other. Further, the sector may also be any part of a road if entry restrictions shall be applied thereto. The predefined sector may be divided into subsections.
The traffic control system may include one or more traffic control devices communicably connected to a network. The network may be any type of network, such as a local area network (LAN), a wide area network (WAN) such as the Internet, a cellular network, a satellite network, or a combination thereof, wired or wireless. The connection may be wireless and/or wire-based. Each of the one or more traffic control devices may be configured to control (manage) the traffic in one or more subsections of the predefined sector, wherein preferably each traffic control device is assigned to one predefined subsection which it controls. Further, each traffic control device may comprise at least one communication unit for receiving or transmitting data. Preferably, the data exchange is performed with a remotely located communication unit wireless. Preferably, the remotely located communication unit is installed in a vehicle, in another traffic control apparatus, or the like.
The communication unit may be configured to receive an entry request from a vehicle approaching the subsection that is controlled by the traffic control device including said communication unit which has received the request. Further, the communication unit may be configured to transmit (issue) one token combined (together with) one entry permission flag for said subsection to the vehicle in response to the entry request. The transmission/issuance is performed if at least one token and at least one entry permission flag is stored in a data storage space associated with (linked to, related to, assigned to, communicably connected to, included in) the traffic control device controlling the subsection for which entry was requested.
Further, the traffic control system may include or may be (communicably) connected to one or more data storage space(s) which may be configured to store one or more tokens and one or more entry permission flags for each subsection of the predefined sector of the road. The tokens may be stored in advance and/or tokens may be created within predefined rules by the traffic control device if needed. The tokens may be a data unit which is not different for different subsections, in other words the tokens are preferably identical or universally usable for the different subsections. The entry permission flag may be another data unit which includes specific information about its validity; specifically, each entry permission flag may be configured to be valid for a predefined (preferably single) subsection and this information may be included in the entry permission flag/data unit. The tokens and entry permission flags (entry permission or permission) may be data strings or data packages and preferably the tokens may be data units which are configured to carry information from a sender to a receiver (data transport vessel/unit) and the entry permission flags preferably may at least include information which indicate the subsection for which entry is granted. Modified tokens or modifications of tokens are envisaged and are explained further below.
The data storage space may be a physical memory or a database on a physical storage means and it may include databases, tables or the like for storing data, such as the tokens and the permission flags. Preferably, the storage space links each subsection of the sector of the road to a storage sub-space (physical or within a software database).
The traffic control device or the system itself may be configured to increase the number of tokens/entry permission flags (for the respective subsection) in the data storage space if a token/an entry permission flag was received (for the respective subsection). This applies also for the case that a token/entry permission flag was transmitted which results in a decrease of the number.
The token and entry permission system allows creating an entry permission/denial system for the controlled sector of the road including one or more subsections on an automated basis which ensures high safety especially in view of avoiding collisions between vehicles. The complexity and the required computational resources are reduced because there is no need for complex computing tasks, such as determining travelling trajectories or the like. Tokens and permissions are issued like returnable tickets based on which the traffic is managed safely. The system is also flexible with regard to its implementation because the system can be established based on software (except the physical storage and the network including computing resources) only, based on hardware (except the data exchange), or based on a flexibly adjustable combination of both. Data transmission between the communication units is also reduced due to the minimal data information that is required to be exchanged (in particular token and entry permission flag which both can be very small in regard of their data size). Small data size being transferred also increases the reaction times of the system advantageously (reduced latency) which increases the overall control safety even further.
In a further preferred aspect the predefined sector of the road may include overlapping lanes (like in a crossing, an intersection or a round-about), the sector may be divided into subsections and/or each traffic control device may be configured to control/manage the traffic within one predefined subsection of the plurality of subsections. A preferred scenario of application is a crossing or a round-about where preferably each part in which lanes overlap defines a subsection.
The data storage space may be configured to store information about which traffic control device is assigned to (linked to, associated with, related to) control the traffic within which subsection. This may be stored in a table, a database, or any other suitable data format. A vehicle, after it has entered a specific subsection within which the traffic is controlled by a designated traffic control device, may return the received token and the received entry permission flag to another traffic control device, i.e. a different/second traffic control device. Said other traffic control device (second/different) may be configured to return/transmit the entry permission flag returned from the vehicle to the traffic control device that issued the entry permission flag to the vehicle and to forward/transmit a token (any one in its storage or the specific token returned from the vehicle) to a further control device, i.e. a third one.
The above general configuration of the system in which the entry permission flag is returned to the issuing traffic control device while the token is passed on to a further (third) traffic control device allows balancing the number of tokens in each traffic control device (or the data storage space associated therewith) in a simple computer operation while a high safety of the traffic control is ensured. As an example, if the token would be returned to the issuing traffic control device immediately, the traffic within the controlled sector may not be safely controlled, e.g. if a plurality of vehicles request entry to different subsections of the controlled sector of the road.
Further, if considering a scenario in which each subsection of the sector may allow only a single vehicle at the same time, the disclosed system could be configured so that each traffic control device has a single token and entry permission flag. If the token (and the entry permission flag) is issued to a first vehicle, no further token is available so that any further request of a second vehicle will not be granted until the first vehicle has passed the subsection and until the entry permission flag was returned to the issuing traffic control device.
Neatly, the present disclosure allows that the initial/default token distribution can be restored without needing to know which traffic control device has issued a token. Hence, no further computational intelligence needs to be provided which would take care of a correct token distribution. The tokens are "simply" passed to another traffic control device until restoration of the initial/default distribution.
Data traffic can be reduced, computational complexity/resources is/are reduced and a safe handling of the traffic management is established.
In a further preferred aspect the tokens issued by the traffic control devices may be identical to each other, and the entry permission flags may be configured to be valid only for a specific subsection. This supports the above technical advantages, in particular it ensures that an initial configuration of the system can be restored without complex computer operations and without high data communication traffic.
In a further preferred aspect the data storage space may be configured to store information about which traffic control device is assigned to control the traffic within which subsection, wherein each subsection may be labelled (numbered/marked or otherwise characterized) according to a predefined order and each traffic control device may be labelled according to a predefined order. The data storage space may include information about which subsection with a specific label is linked to which traffic control device having a specific label. In other words, preferably, the linking between the control unit (traffic control device) and the control target (a specific subsection) is stored in the data storage space and preferably it may be stored in a central database or the like. The order of the subsections and traffic control devices may be exemplified by a crossing. Assuming that two streets each have two lanes which cross each other and assuming that the area in which the two streets cross each other is the controlled sector of the road. Then, as one possible example, the sector may be divided into four subsections, one subsection for each area in which two different lanes overlap each other. Each of the four subsections may be connected/assigned to one traffic control device and each subsection/traffic control device may be labelled according to an order, e.g. a numbering running counter-clockwise or clockwise. E.g., subsection and traffic control device labelled no. 1, subsection and traffic control device labelled no. 2, and so on.
The numbering is storable with low complexity, e.g. in a table connecting the numbers or letters with subsections and traffic control devices.
Preferably, the predefined order is circularly connected/arranged/numbered so that each subsection and each traffic control device of the sector of the road, respectively, is adjacent to one previous and one next subsection and traffic control device, respectively. In the above example, if N subsections/devices would be required in the controlled sector, the subsection/device no. 1 would be stored to be adjacent with the subsections/devices no. N and 2, respectively. The "circular connection/numbering" allows to realize a redistribution of tokens with low complexity and reduced computational efforts.
In a further preferred aspect a vehicle which has entered a subsection m within which the traffic subsection is controlled by a traffic control device N returns the received token and the received entry permission flag to a traffic control device m+1 which is next in the predefined order and which is configured to control the traffic in a next subsection m+1 into which the vehicle may enter. The traffic control device m+1 which has received the token and the entry permission flag of the subsection m may be configured to return/transmit the entry permission flag of subsection m to the traffic control device m that issued said entry permission flag of subsection m and to forward/transmit a token (any token from the storage can be passed on; it may be the same token that was returned from the vehicle) to a further next traffic control device m+2 according to the predefined order, and each further traffic control device may be configured to forward a token until a token is received by the traffic control device which issued a token to the vehicle.
The traffic control device that issued the token is easily identifiable because the connected data storage space includes one token less than it should/it included in the initial distribution setup. In other words, preferably, the traffic control device which issued the token to a vehicle may be identified by the number of tokens in the data storage space.
In a further preferred aspect each traffic control device may include an entry permission control unit configured to grant a vehicle entry into a predefined sector, if said vehicle holds a token combined with an entry permission flag for said sector. Vehicles which do not hold it may be refused to enter a subsection for which they do not have the permission. If the vehicle is an automated or self-driving vehicle, the entry permission control unit may issue a signal to the vehicle's controller including the stop or entry command. If the vehicle is driven by a human, the signal may be displayed to the driver acoustically, optically or the like. Safety is ensured effectively and without requiring high volumes of data transfer.
The entry permission control unit may not be necessary in the traffic control system/device if vehicles include a unit which prevents them from entering a subsection without holding the required entry permission. In automated vehicles the unit may stop the vehicle automatically, while human drivers may be stopped by a warning.
In a further preferred aspect a traffic control device may be configured to issue a token combined with one or more reservation options for one or more subsequent subsections and linked to a specific vehicle. Each traffic control device holding a token with reservation option may issue the token with reservation option only to the vehicle to which said token with reservation option is linked. This allows handling a traffic scenario in which a vehicle requests entry into the controlled sector indicating that not only a single subsection will be crossed, but two or more. The reservation option may be enabled, e.g., by adding an additional data part to the token which includes the information about the reservation and the vehicle for which it was issued.
For example, in the above example according to which a crossing has four subsections: A vehicle which intends to cross the crossing straightly, would have to travel through two subsections. The vehicle may hence request entering the first subsection (the first with regard to its travelling direction) and indicate that it will furthermore need to enter the next subsection (the next in the straight travelling direction) after having passed the first subsection. The request may be automatically transmitted from the vehicle to the traffic control system, e.g. based on the route set in the navigation system or based on a route set by a trajectory planner of an artificial intelligence driver. As a result of the reservation option, the vehicle may smoothly pass the crossing without interruption due to other vehicles or the like. Again, also such a specific driving scenario can be managed without a great increase of the complexity of the control system. The computational resources need not to be increased significantly and the data volume transferred can be kept low. Safety is ensured by the explained configuration at all times.
In a further preferred aspect each traffic control device may include an emergency vehicle priority mode and/or a unit which switches the modes. Alternatively or additionally, the overall system may include such a unit. The unit configured to be activated by an emergency/priority vehicle requesting entry into one or more subsections of the predefined sector of the road. If the emergency vehicle priority mode unit switches the operational mode of the traffic control device to an emergency vehicle priority mode, the traffic control device may be configured to create a temporary token and a temporary entry permission flag which may be issued to the emergency vehicle requesting entry. The temporary token and the temporary entry permission may be different to the tokens and the entry permission flags used in the normal operation mode, ie they may be distinguished, e.g. by adding/modifying the data forming the token/permission. The temporary token may be generated upon the request of the emergency vehicle in the system or the traffic control device to which the request was directed. At the same time, when the request is received from an emergency vehicle, the traffic control device may be configured to check whether it has already issued a (normal) token and an (normal) entry permission flag (e.g., by checking the number of tokens/permissions in the data storage compared to the default/initial number). If it is determined that another (normal, not emergency/priority) vehicle, ie other than the emergency vehicle, holds an entry permission flag for the subsection into which the emergency requires to enter, the traffic control device may be configured to force said vehicle (by issuing a return request) to return said token and the entry permission flag before the temporary token and the temporary entry permission flag is issued to the emergency vehicle. As soon as the token and the entry permission flag is returned to the traffic control device, the traffic control device is configured to issue the temporary token with the temporary entry permission request immediately to the emergency vehicle. The priority/emergency vehicle may be a police car, a fire vehicle, an ambulance vehicle, etc.
The temporary token and the temporary entry permission flag may be transmitted to the next traffic control device when the emergency vehicle has entered the (first) subsection and the next traffic control device may be configured to erase the temporary token and to return the temporary entry permission flag to the traffic control device which has issued the temporary entry permission flag. When the traffic control device which has issued the temporary entry permission flag has received the temporary entry permission flag, it may be configured to erase the temporary entry permission flag and to re-issue any token and any entry permission flag to a vehicle which forcibly returned the token and the entry permission flag before.
Also the specific driving scenario of an emergency or priority vehicle which wants to enter the controlled sector can be managed without a great increase of the complexity of the control system. The computational resources need not to be increased significantly and the data volume transferred can be kept low. Safety is ensured by the explained configuration at all times while the emergency vehicle can pass the sector with high priority.
In a further preferred aspect the temporary token may have a reservation option for one or more further subsections in order to enable a smooth passage of the emergency vehicle through all subsections of the sector which it need to pass on its target travelling route.
In a further preferred aspect the number of tokens and entry permission flags per subsection may be fixed. For example, the fixed predefined number may be set based on the maximum number of vehicles allowed in a subsection. The number may alternatively or additionally variably controlled based on time and density of traffic. In the latter case, it may be possible to increase the number of vehicles in the controlled sector during low traffic times, at sunny daylight conditions or the like while it may be decreased during peak traffic times, during rainy weather or the like.
In a further preferred aspect each traffic control device may include an emergency vehicle priority mode unit configured to be activated by an emergency vehicle requesting entry into one or more subsections of the predefined sector, and, if the emergency vehicle priority mode is activated, the traffic control system/device may be configured to control the occupancy within the predefined sector/subsection of the road. The occupancy may stand for the density of vehicles or the number of vehicles per area.
For occupancy control a maximum occupancy may be determined during the emergency vehicle priority mode. The maximum occupancy may be derived (determined, calculated) from the number of subsections of the predefined sector which will be crossed by the emergency vehicle. The latter may be determined based on the entry request of the emergency vehicle including, e.g. the intended travelling route, and based on the maximum capacity of vehicles inside the predefined sector of the road or a subsection at the same time.
The traffic control system may be configured to stop providing entry permission to a vehicle outside the sector of the road if an actual occupancy is higher than the maximum occupancy, and/or to set or adapt a delay time for the grant of an entry permission depending on the actual occupancy. The occupancy control may allow to manage the traffic situation alternatively or additionally to issuing temporary tokens and permission flags. The technical benefits explained before can be achieved with the occupancy control as well because it does not require complex computing resources, like for a trajectory-based control.
In a further preferred aspect, the above described control system may be realized by a computer program product comprising computer-readable instructions that, when executed in a computer system including one or more computers, cause the computer system to perform the control as described in relation with one or more of the aspects above.

Brief Description of Drawings

Fig. 1: schematically shows an example of a traffic control system;
Fig. 2: schematically shows a traffic control device;
Fig. 3: schematically shows a vehicle control device;
Figs. 4 to 8: schematically show a control procedure for a vehicle requesting entry into the controlled sector;
Figs. 9 to 14: schematically show a modified control procedure including a token having a reservation option;
Fig. 15: schematically shows a control method/control configuration performed within a traffic control device;
Fig. 16: shows a sub-process of step S200 performed in the traffic control device;
Fig. 17: shows the sub-procedure of step S400 performed in a traffic control device;
Fig. 18: schematically shows a sub-procedure of step S300 performed in a traffic control device;
Figs. 19 to 23: schematically show a procedure of a modification including an entry request of an emergency vehicle;
Fig. 24: schematically shows a modification of the procedure according to Fig. 16 in regard of an emergency control mode selection step (S500);
Fig. 25: shows a sub-procedure of step S500 (control mode selection performed in a traffic control device);
Fig. 26: shows a modification of step S400 including the emergency/priority mode performed in a traffic control device;
Fig. 27: schematically shows a sub-procedure of step S300 performed in a traffic control device;
Figs. 28 to 30: shows a process/configuration of a vehicle-based control device;
Figs. 31 and 32: schematically show the effect of the emergency mode on the controlled sector and normal vehicles being rejected/unable to enter;
Fig. 33: schematically shows a modified traffic control device including a traffic density monitoring unit;
Fig. 34: shows a procedure of controlling the traffic within the controlled sector based on the priority control mode and an acceptance delay of granting a permission to enter;
Figs. 35 to 38: schematically show a procedure in which an emergency vehicle is given priority access to the controlled sector based on an occupancy control;
Fig. 39: shows an example of calculating a maximum occupancy within a controlled sector;
Fig. 40: shows a table of an example for calculating the occupancy within a roundabout including proposed equations for calculating the occupancy.

Detailed Description of Exemplary Embodiments

In the following, preferred aspects and examples will be described in more detail with reference to the accompanying figures. Same or similar features in different drawings and examples are referred to by similar reference numerals. It is to be understood that the detailed description below relating to various preferred aspects and preferred examples are not to be meant as limiting the scope of the present disclosure.
Fig. 1 shows an example for a traffic control system 100 as disclosed herein according to which a plurality of traffic control devices 1a-d are connected to a network 12. In this example, one or more of the plurality of traffic control devices 1a-d being connected to the network 12 may be grouped to control one specific sector of a road. The sector being controlled may preferably be a crossing, a roundabout or any other sector of a road in which lanes are overlapping. The number of sectors being controlled by the traffic control system 100 is generally not limited, however, of course, a plurality of traffic control systems 100 can be provided. It is an advantage of the herein described disclosure that traffic lights are not necessary for the sectors being controlled.
Furthermore, one or more data storage spaces 13 are included or communicably connected to the traffic control system 100. Fig. 1 shows one data storage space 13 which may, however, be a plurality or which may be sub-divided into a plurality of sub-units of the data storage space 13. Furthermore, a computing apparatus/unit 14 may be connected to the network 12. The computing apparatus/unit 14 may be a single unit or may include/be a plurality of computing units or sub-units. The traffic control devices 1a-d being shown in Fig. 1 may be implemented by software and/or by hardware.
In the case the traffic control devices 1a-d are implemented by software, these devices 1 may be stored as computer program products within a data storage space such as indicated by reference sign 13 in Fig. 1.
If the traffic control devices 1 are implemented by hardware, they may be installed at the very sector of the road being controlled by the one or more traffic control devices 1a-d related/associated/assigned to said sector. A combination of a software and hardware implementation is as well possible; for example, a hardware device may be installed at the controlled sector, while a part of its functionality is provided as a computer program product installed at a physical memory of the traffic control device 1a-d or the data storage space 13 connected remotely to the network 12. The computing unit 14 may as well be implemented in each of the traffic control devices 1, especially when the hardware implementation is used. The (communication) connection between the hardware traffic control devices 1 and the network is either established by a wired connection and/or can be enabled via a wireless connection to the network.
Fig. 2 schematically shows one example for the configuration of a traffic control device 1 being implemented as a hardware or a software unit. One module/sub-unit of the traffic control device 1 is a communication unit 20 connected to a data receiving/transmission component 20a. Furthermore, an entry permission control unit 21 may be included in the traffic control device 1, as well. In case of a hardware implementation of the traffic control device, the units 20 and 21 may be implemented within a traffic control device internal memory, while the unit 20a/component 20a may be established by an antenna. In case of a software implementation, the units/ components 20, 20a and 21 may be composed of software modules. The functionality of the traffic control device 1 and its sub-units will be described in detail below.
Furthermore, a vehicle which is traveling on the road and which wants to enter a controlled sector, may also be equipped with a vehicle control device 30 which is exemplarily shown by Fig. 3. As it is usually implemented in a vehicle control device 30, it may be connected to sensing unit(s) 34 as well as actuation unit(s) 35 for controlling the driving of the vehicle. These units may be connected with can be a vehicle control unit 33 which is a sub-unit of the vehicle control device 30. Furthermore, in regard of the traffic control system 100 being disclosed herein, the vehicle control device 30 may also include a communication unit 31 as well as an entry permission control unit on the vehicle side 32 and a data receiving/transmitting unit 31a. The units 31, 31a, and 32 may be configured to communicate in a wireless manner with the before described traffic control devices 1a-d. If the traffic control devices 1a-d are not implemented by hardware, but as a software/computer program product, the communication unit 31 of the vehicle may be configured to directly communicate with the network 12 in which the traffic control devices 1a-d are implemented.
Now a control method/configuration being performed/enabled by the traffic control system 100 will be described. The method described may either be claimed by a method claim directly, a computer program product being enabled to perform said method and/or the traffic control system/apparatus being configured to perform the respective method steps.
Figs. 4 and 5 show a first step within a procedure included in the disclosure described herein. In this first step, a (first) vehicle 10a approaches a controlled sector of a road which is in this example a crossing of two roads each having two lanes, wherein the lanes and their driving directions are indicated by short arrows in the middle of each lane. The sector is shown by the virtual circle that is divided into four subsections in this example. The circle is divided by the virtual broken straight lines in the middle of the two roads which also divide the lanes from each other. Of course, other sectors of a road than a crossing may be controlled and of course more or less subsections may be provided for a controlled sector. Returning to the example of Fig. 5, each virtual sub-sector is virtually labeled, wherein the labels are stored in the storage space 13; here the Figures use the exemplary labels "area A", "area B", "area C", and "area D". In Figs. 4 and 5, the vehicle 10a approaching the controlled sector approaches the subsection labeled "area B" which it wants to pass (indicated by the broken arrow ahead of vehicle 10a in Fig. 5). Accordingly, an entry permission for area B needs to be granted to the first vehicle 10a by the traffic control system 100 which is responsible for the crossing shown by Fig. 5.
Figs. 4 and 5 further schematically show that four traffic control devices 1a to 1d are provided for controlling the subsections area A to area D of the controlled sector. In other words, in the traffic control system 100 controlling the depicted sector of a road, each subsection of the sector of the road is controlled by a single traffic control device 1a-1d. Each traffic control device 1a to 1d is assigned to/related to/associated with one specific subsection "area A" to "area D". Furthermore, it is schematically shown that in this example each traffic control device 1a to 1d holds one entry permission (in the following called entry permission flag) 3a to 3d and each traffic control device 1a to 1d holds on token 2a to 2d. This is the default/initial configuration of the exemplary traffic control system 100 when no vehicle is inside the controlled sector. This exemplary traffic control system 100 will be used to describe the present disclosure in more detail. Variations thereof are envisaged, such as providing more or less traffic control devices 1a-1d, providing more than one token or entry permission to each traffic control device 1, and the like.
As soon as the communication unit of the vehicle 31 has issued a request for an entry permission to the traffic control device 1b (Fig. 5 arrow pointing from the vehicle 10a to the device 1b) which is in charge of/assigned to controlling area B of the controlled sector, the traffic control device 1b will issue one token 2b combined with one entry permission flag 3b via the communication unit 20 to the communication unit of the vehicle 31. The transmission of the token with the entry permission flag 2b, 3b (shown as 2b') is shown in Fig. 6, wherein the arrow pointing from the traffic control device 1b to the vehicle 10a indicates the wireless transmission between these two communication units 20 and 31. As one can see from Fig. 6, the traffic control device 1b does not have any further token or entry permission flag after transmitting one of each to the vehicle 10a.
If the traffic control devices 1 are a hardware implementation, a data storage space/memory within each traffic control device 1 may hold the data relating to the token/entry permission flag. Alternatively, the token and the entry permission flag data/information may also be stored in a central memory/data storage space 13 connected to the network 12 and, more specifically, in a subsection of the data storage space 13 which is specifically linked/related to a traffic control device 1. The related data storage space of subsection "area B" and traffic control device 1b is empty after the transmission of the only token 2b and the only entry permission flag 3b to the vehicle 10a. It is noted that in this example, only a single token and only a single entry permission flag are stored in the data storage space linked to one specific traffic control device 1. However, more than one token and entry permission flag may be stored therein. The latter may be the case if, for example, the subsections, such as "area B", are large enough for taking up more than one vehicle at the same time.
Fig. 7 shows the next step in which the vehicle 10a is allowed to enter the subsection "area B" because it holds the entry permission flag combined with the token issued by the traffic control device 1b being in charge for "area B". Instead of returning the combined token with the entry permission flag 2b' to the traffic control device 1b which issued it to the vehicle 10a, the vehicle 10a transmits the combination of the token and the entry permission flag 2b' to the traffic control device 1c which is in charge of the next area in the predefined order/ in the itinerary/ possible itinerary of the vehicle 10a. The vehicle 10a returns/transmits the combined token and entry permission flag 2b' after it has entered into the area for which the entry permission flag is valid. In this example of Fig. 7, it is subsection "area B". As one can now see in Fig. 8 combined with Fig. 7, the next traffic control device 1c which has received the token 2b from the vehicle 10a temporarily holds two tokens 2b and 2c within its related data storage space/sub-space. Therefore, the traffic control device 1c holds one token more than in the default setup of the traffic control system 100. Therefore, the excess token 2c is transmitted to a next traffic control device in the order of the traffic control devices which is traffic control device 1d in the herein shown in example. Since the tokens 2 are identical to each other, it is only about the total number of tokens being stored in a data storage space 13 related to each traffic control device 1. After having received the token 2 from the traffic control device 1c, the traffic control device 1d would have one excess token and, therefore, transmits one token to the next traffic control device 1a in Fig. 8. The same holds for the traffic control device 1a and, therefore, it transmits the excess token being shown as token 2a in Fig. 8 to the next traffic control device which is the traffic control device 1b in Fig. 8. Since in this example, the traffic control device 1b has originally issued a token to the vehicle 10a, it is short of tokens by one and, therefore, stops circulating the tokens so that the default setup/distribution of tokens is reestablished. Further (preferably at the same time), instead of circulating it, the entry permission flag 3b, which is not identical to the other entry permission flags 3 of other subsections of the controlled sector, is returned to the originally issuing traffic control device 1b. In other words, the entry permission flag 3b being valid for the subsection "area B" having reference sign 3b in Fig. 8 is returned from the traffic control device 1c to the traffic control device 1b which has issued it. With this step, the default distribution/setup of tokens 2 and entry permission flags 3 is reestablished. Since the vehicle 10a has no further entry permission flag to any other subsection of the controlled sector, it either has to stop within the subsection "area B" or it has to leave the subsection "area B" exiting the controlled sector as it is shown in this example depicted by the arrow in Fig. 8.
If the vehicle 10a is an automatically driven vehicle, preferably the vehicle 10a will proceed according to its itinerary which in the depicted case of Figs. 4 to 8 would mean that it automatically leaves the crossing by turning right after having entered the subsection area B. Otherwise, if the vehicle 10a would have an itinerary according to which more than one sector has to be passed, the vehicle 10a will request to an entry permission into the next sector on its itinerary.
The above described control example assumes that the vehicle 10a does not need to pass more than one subsection of the controlled sector. In the following example, the control method is modified to allow the vehicle 10a to travel smoothly through more than one subsection which shall be subsections being labeled as "area B" and "area C" in Fig. 9.
Fig. 9 shows the situation that after having requested entry into the subsection "area B", a token combined with an entry permission flag 2b' was issued by the traffic control device 1b to the vehicle 10a. However, as a modification, the vehicle 10a has indicated to the traffic control device 1b that it needs to enter not only subsection "area B" but also subsection "area C". The indication may be conveniently performed by submitting the itinerary via a navigational system of the vehicle 10a to the communication unit 20 of the traffic control device 1 or it may be requested by a driver. Other options are of course possible, too. Having received the specific request for entering more than one subsection of the controlled sector, a reservation option being indicated by reference sign 6 is added to the data package of the token 2b and the entry permission flag 3b being summarized as 2b' in Fig. 9. The reservation option 6 may be additional data which may, for example, include the information about the specific vehicle (such as an identification number) and the areas for which entry is requested. However, it may also suffice for reducing data transmission/data traffic that only the vehicle ID is included in the reservation option 6.
After the vehicle 10a has entered the first subsection area B and after it has returned the data package including the combination of the token and the entry permission flag 2b' as well as the reservation option 6 to the next traffic control device 1c, Fig. 10 shows the next step(s) according to which the tokens are circulated as described before until each of the other traffic control devices 1d, 1a, and 1b have its original number of tokens. The entry permission flag 3b is returned from the traffic control device 1c to the issuing traffic control 1b as described before. However, the traffic control device 1c holds/maintains the token 2b which has the reservation option 6; i.e. it starts the circulation of tokens 2 based on the token 2c which does not have the reservation option 6. Then, the vehicle 10a, when it is inside the subsection "area B", requests entry into the subsection "area C" to the traffic control device 1c in charge for controlling the traffic within the subsection "area C" (its intended itinerary is shown by the broken arrow in Fig. 10).
In order to highlight the technical effect/benefit of this modified method, it is assumed that in the moment at which the first vehicle 10a requests entry, a second vehicle 10b approaches the area C subsection and requests entry into subsection "area C", too. This is depicted in Fig. 11. In this situation and this example in which only one vehicle can enter a subsection at the same time, the traffic control device 1c can only allow one of the two vehicles 10a, 10b to enter into subsection "area C".
According to the present disclosure, the traffic control device 1c holds the token 2c which is modified by a reservation option 6. The reservation option 6 includes data relating to the ID of the first vehicle 10a. Therefore, the traffic control device 1c easily determines that it may issue/transmit the token 2b including the reservation option 6 to the first vehicle 10a only; i.e. not to the second vehicle 10b. This is shown in Fig. 12 in which it is schematically indicated that the request of the second vehicle 10b is rejected temporarily while a package including the token 2b and the entry permission flag 3c for entering subsection "area C" is transmitted to the first vehicle 10a. In other words, a permission to enter area C is only granted to the vehicle 10a to which the reservation option 6 belongs while all other vehicles are rejected in their attempt to enter the same subsection of the controlled sector at this time.
With the permission granted, the vehicle 10a enters into the subsection "area C" and returns the package of a token including the entry permission flag indicated by 2b' according to the method described before. Fig. 13 shows an example in which the vehicle 10a returns the combination 2b' to the next traffic control device 1d. Then, since the vehicle 10a has requested entry only into the subsection area "area C", the reservation option attached to the token 2b is deleted and the vehicle 10a leaves the controlled sector after subsection "area C". Depending on the format of the request message (or signal), the vehicle may request entry into a plurality of areas at once - in this example, "area B" and "area C"; or one request message (or signal) includes one entry request only and a new request is issued for each area to be entered. The deletion of the reservation option 6 has the consequence that all tokens 2 included in the traffic control system 100 are rendered identical again. The recirculation of tokens 2 is then performed as described before and, as described before as well, the entry permission flag 3c for the subsection "area C" is returned by the traffic control device 1d to the issuing traffic control device 1c. Figure 14 shows: After, the vehicle 10a has left the controlled sector exiting subsection "area C" and after default setup of the traffic control device 1c was restored, the traffic control device 1c can grant the request of the second vehicle 10b by issuing a package of a token and an entry permission flag 2c' for the subsection "area C" so that the second vehicle 10b may enter. The arrows between the second vehicle 10b and the traffic control device 1c show the further request of the second vehicle 10b and the grant thereof.
The above described configuration of the traffic control system 100 allows an automation of vehicle traffic within intersections, roundabouts, etc. which can be used by vehicles driven by a human driver or a machine safely. The exchange of tokens and entry permission flags, which are (small) data strings or packages including the minimum information necessary for the above described procedures, does enable to reduce the size of the data transmission/bandwidth of the connections (and it also reduces the latency times), and to reduce the complexity of the computing operations needed, e.g. it is not necessary that the system 100 or any of the travel control devices 1a-d calculates trajectories of the vehicles or the like. A very safe, ultrafast, and low complex traffic control is enabled which has the options to control even specific traffic situations, which will be further explained below.
The flowcharts related to the before described configuration/method implemented with the traffic control system 100 are now described in connection with Figs. 15 to 18. The steps being described in the following may preferably be performed within the traffic control device 1 and its sub-units, the communication unit 20 and/or the entry permission management unit 21. Communication preferably takes place with the communication apparatus of the vehicle 30 and its sub-units.
Fig. 15 shows a high-level flowchart of steps related to receiving and analyzing a message which is, for example, the entry request received by the communication unit 20 and issued/transmitted from a vehicle's communication unit 31. This is shown as step S101 in Fig. 15.
Further, if it was analyzed that an entry permission is requested, this processed within step S200 and its sub-steps. After step S200, the step S300 (including sub-steps) is performed according to which a token 2 and a permission 3 is returned/issued to a traffic control device 1. Step S300 preferably includes the sub-steps for recirculating tokens 2 and for returning entry permission flags 3 to the respective traffic control devices 1a to 1d as discussed in connection with the before described Figures. A further step S102 may be added which includes the sending of messages; in this optional setup, when performing steps 200/300 et seq., a message/signal/request is not sent or transmitted. The sending/receiving of a message/signal/request between e.g. communication unit(s) 20 and/or 31 can be performed within/by step(s) S102. If step S102 is not provided, the sending/receiving of messages may also be integrated within the general control flow.
Fig. 16 shows the sub-steps of step S200, especially the analyzation whether entry to a subsection is requested. If this is decided to be positive ("yes" in step S201), the procedure according to the entry permission control related to step S400 and its sub-steps is performed. The sub-steps of step S400 are shown by Fig. 17.
Fig. 17 shows a first step of the entry permission control (step S401) which is to check whether the traffic control device 1 to which the request was transmitted holds an entry permission flag 3 in its related data storage space 13 or its internal memory. If step S401 is decided positively ("yes"), it is determined in step S402 whether a token 2 is stored for said traffic control device 1, too. If this is positively decided ("yes"), it is checked in step S403 whether the available token 2 has a reservation option 6 for a vehicle 10. If this is not the case ("no"), a permission is issued to the vehicle 10 which has requested entry into the specific subsection being controlled by the related traffic control device (in step S407). The permission is preferably granted by submitting a combination of a token 2 and an entry permission flag 3 for the subsection.
If, however, the token 2 is reserved, step S407 cannot be performed and step S404 is performed according to which it is checked whether the reservation option 6 of the token 2 matches with the ID of the vehicle requesting entry. If this is positively decided ("yes"), step S406 is performed which grants, analogously to step S407, a permission for entry to said vehicle. Otherwise, if the IDs do not match, step S405 is performed in which an entry permission request is rejected at least temporarily. The same step S405 is also performed if steps S401 and/or step S402 return a negative result ("no"). In the flowchart it is explained that step S406 returns a permission to the vehicle inside the controlled sector: This is the situation as depicted in Fig. 12 which shows that a traffic control device 1c holds the token 2b with reservation option 6 for the first vehicle 10a.
Furthermore, Fig. 18 shows the control procedure according to the distribution of tokens 2 and permission flags 3 which is used for returning the traffic control system 100 into its default setup after a token 2 and/or an entry permission flag 3 was issued to a vehicle. In a first step S301, the traffic control device 1 (or all traffic control devices 1a-1d of a controlled sector) performing said control checks the number of tokens 2 which it has in stored in its related data storage space 13 and it also verifies if any token 2 is in its possession/storage space which has a reservation option/status 6.
Then, in step S302, information is acquired about returned tokens 2, especially as to a possible reservation request for reserving a token 2 and/or with regard to an entry permission for a target management subsection/area.
In a subsequent step S303, the number of tokens without reservation option 6, i.e. which can be circulated to a next traffic control device 1 as described before, is counted. Based on the above acquired information of steps S301 to S303, it is determined, whether there is any token(s) 2 to be circulated. This is step S304. Should step S304 determine that there are tokens 2 which can be circulated, the step S305 is performed in which non-reserved tokens 2, i.e. tokens 2 without reservation option 6, are passed/transmitted to a next traffic control device 1. After step S305 or if step S304 should return a negative result ("no"), step S306 is performed. In step S306 it is checked whether the traffic control device 1 performing the procedure of steps S300 et seq.. holds an entry permission flag 3 which is not associated/valid for the subsection being linked to said traffic control device 1. If such a "foreign" entry permission flag 3 is detected in the storage related to said traffic control device 1, it is returned with step S307 to the traffic control device 1 to which it belongs (e.g. shown in Fig. 8: device 1c returns flag 3b to device 1b). Otherwise, if only entry permission flags 3 are detected which belong to the controlled subsection of said traffic control device 1, step S308 is performed in which the entry permission flags 3 are kept by said traffic control device 1. If every traffic control device 1 within the traffic control system 100 or at least related to a controlled sector of a road performs this flow of steps, the default/original distribution of tokens 2 and entry permission flags 3 can always be reestablished quickly and without complex computational operations.
Next, a further modification of the above method/control setup is provided in regard of Figs. 19 to 23.
Fig. 19 shows the situation in which a vehicle 10a, which is a normal vehicle such as a passenger car or the like, holds an entry permission flag 3b combined with a token 2b (the combination referenced as 2b') issued by the traffic control device 1b. Hence, said vehicle 10a has the permission to enter the subsection "area B" from its actual position which is inside subsection "area A". In the moment before the vehicle 10a can enter into the subsection "area B", as depicted in Fig. 19, a priority vehicle, such as an emergency vehicle 11, requests entry into the subsection "area B". The request is communicated to the traffic control device 1b as shown by the arrow from the emergency vehicle 11 to the traffic control device 1b. In a situation as described before or in case that the emergency vehicle 11 would not be an emergency vehicle 11, but a second vehicle 10b, the request would be denied by the traffic control device 1b because it does not have any further token or entry permission flag available (in Fig. 19 the traffic control device is schematically shown "empty"). The only entry permission flag 3b and token 2b combined (2b') is in possession of the vehicle 10a which is driving within subsection "area A". Therefore, it would not be possible to give priority to the emergency vehicle 11 which would result in adversary effects possibly to a person who needs quick medical assistance or the like.
Therefore, Fig. 20 depicts a modification relating to an emergency mode which may be activated by a not depicted emergency mode setting unit (which may be part of each traffic control device 1 or of the overall system 100). In the emergency mode, which is triggered by a request of an emergency vehicle 11, the following procedure is preferably followed. The traffic control device 1b to which the request of the emergency vehicle 11 was transmitted in this example issues a command/request to the vehicle 10a which possesses the permission for entering the controlled subsection. The request as indicated by the arrow between the control device 1b and the vehicle 10a in Fig. 20 includes the command to return the token 2b including the entry permission flag 3b to the issuing traffic control device 1, which is 1b in this example. In addition, in the emergency mode, the traffic control device 1b is enabled to temporarily create/generate a temporary token 4 including a temporary entry permission flag T being shown by reference sign 4b' in Fig. 20.
As shown in Fig. 21, as soon as the vehicle 10a has returned the entry permission flag including the token 2b' upon request of the traffic control device 1b (see arrow and reference sign 2b'), the temporary token including the temporary permission flag 4b' is transmitted to the emergency vehicle 11 (see the arrow and reference sign 4b'). As a consequence, the emergency vehicle 11 can immediately enter the subsection controlled by the traffic control device 1b which is subsection "area B", while the normal vehicle 10a has to stop and wait in the subsection "area A".
As previously described in the normal mode, the emergency vehicle 11 returns the package 4b' including the temporary token 4 and the temporary entry permission flag T to the next entry permission device 1c. This is depicted by the respective arrow in Fig. 22.
Fig. 23 displays the moment when the emergency vehicle 11 has returned the temporary token 4 including the temporary entry permission flag T to the traffic control device 1c which, upon receiving it, returns the temporary entry permission flag 5b to its issuing traffic control device 1b and deletes the temporary token 4b after it has received it.
As a further modification, if the temporary token 4b has a reservation option 6 (not shown), the token will not be deleted in accordance with the flow of steps as described before. The token 4b will only be deleted, if it has a reservation option 6, after the reservation option 6 is "consumed".
As further shown by Fig. 23, as soon as the temporary token T is received by its issuing traffic control device 1b, it is deleted within said traffic control device 1b and the traffic control device 1b can reissue a normal token 2b and entry permission flag 3b for the subsection "area B" to the normal vehicle 10a (see respective arrow).
With the above modification, it is possible that an emergency vehicle 11 is given priority without increasing the computational complexity/system complexity. The temporary token 4b may be issued with a reservation option analogously to the above described modification including the reservation option in case that the emergency vehicle 11 should request entering more than one subsection of the controlled sector.
The flowcharts of Figs. 24 to 27 illustrate the modifications to the method/control configuration if the emergency mode option is available. Specifically, Fig. 24 illustrates that a further step S500 including a control mode selection process is provided before entry permissions requests are checked in step S201.
The procedure of steps S500 following is illustrated by Fig. 25 which shows that in a step S501 it is determined whether the request was issued from a high priority vehicle, such as an emergency vehicle 11. If this is decided negatively ("no"), it is decided in step S503 whether there is already a temporary token 4 (that means that there is no emergency vehicle inside this section if the answer "no"; an 'in-use'flag is hence not set). If step S503 is decided with "no", the control mode is decided to be "normal" in step S504; i.e. no 'in-use' is flagged by the system. Otherwise, if in step S501, it is determined that a priority vehicle is requesting entry, step S502 is performed in which a temporary token 4 and a temporary entry permission flag T is added to the traffic control device 1 and its data storage space, respectively, and the control mode is switched to "emergency mode" in the next step S505. The same holds if in step S503 it is found positively that temporary tokens are existing (remaining) so that the emergency mode is activated in step S505.
Further, as a modification to the sub-steps including the steps S400 following, Fig. 26 shows modifications for enabling the emergency mode. Before the entry permission checking described in connection with the normal operation mode (step S401) is performed, steps S408 and S409 are processed according to which it is decided whether a priority vehicle requests entry (step S408). If this is not the case, it is decided as to whether temporary tokens 4 and entry permission flags T are already in use (step S409). If temporary tokens 4 and temporary entry permission flags T are already in use ("yes" in step S409), the request is rejected in step S405 because there is already an emergency/priority vehicle 11 inside the controlled sector; if it is defined that only one temporary token 4 and temporary entry permission flag T is allowed to be issued for the controlled sector.
Furthermore, as a difference to the before discussed control steps of step S400, step S410 is performed if in step S408 it was found that a priority vehicle has requested entry. Step S410 firstly asks/determines whether the traffic control device 1 has a normal entry permission 3 in its related storage (like S400 described above) and if this is answered with "yes", a temporary entry permission flag T including a temporary token 4 is sent to the emergency vehicle 11 in step S411. Further, a status of the system that generates a temporary token 4 and a temporary entry permission flag T is switched to "in use" in step S412 (which means that an 'in-use'-flag is set) in order to avoid that another (normal) vehicle 10a may receive a grant for entry as long as the emergency vehicle 11 is within the designated subsection.
Otherwise, if it is found in step S410 that the traffic control device 1 to which the request was issued by the priority vehicle /emergency vehicle 11 does not have any normal tokens 2/normal entry permission flags 3 in possession (stored in the memory/data storage space 13) (or less than it has in the default setting), which means that a normal vehicle 10a already holds a permission to drive into the subsection, step S413 is performed according to which the normal entry permission flag 3 and its token 2 are demanded to be returned from the normal vehicle 10a holding them, as described before. The request from the priority vehicle 11 to enter the respective subsection is rejected in S414 as long as the normal entry permission flag 3 and its token 2 are not returned by the normal vehicle 10a; in other words, as soon as (but not before) they are returned the grant can be issued to the emergency vehicle 11 in S411.
Furthermore, an emergency mode checking step S415 is added which takes place after step S403 if this step S403 delivers that no reserved token 2 is available. If no reserved token 2 is available ("no" in step S403), and if in step S415, it is found that an emergency mode is active, any request from a normal vehicle 10 is rejected in step S416 while, if the emergency mode is inactive ("no" in step S415), a permission to enter the controlled subsection is granted.
Furthermore, with regard to the redistribution/recirculating of tokens 2 and entry permission flags 3, a modification to the sub-steps of step S300 is shown in Fig. 27, if the emergency mode is included in the traffic control system 100. Specifically, in step S302, it is additionally asked which kind of token 2 is returned (normal or temporary). Further, before step S303 and after step S302, another decision is added by step S309 which checks whether the returned token is a temporary token 4. If this is not the case ("no"), the normal operation following step S303 as described before is processed. Otherwise, if step S309 returns "yes", step S310 is performed asking whether the returned temporary token 4 is reserved. If the temporary token 4 is reserved (i.e. it has a reservation option 6), step S312 is performed which means that the temporary token 4 and the related entry permission flag T are kept so that no circulation/redistribution for this token is performed. Otherwise, should step S310 find that the temporary token 4 is not reserved, step S311 performs erasing of the temporary token 4 and its permission /entry permission flag T (which also means that the 'in-use'-flag may be cleared/erased).
Figs. 28 to 30 show a procedure of the control included in the vehicle control device 30; the vehicle control device 30 may be included in the traffic control system 100. Fundamentally, the procedure as shown in Fig. 28 mirrors the procedure on the "infrastructure side" so that a step S601 receives messages which are analyzed by the communication unit 31. Then, vehicle and map information are acquired by and within step S602, e. g. from the sensing unit 35 or the like of the vehicle 10. Map information may relate to the information included or generated by a navigation device (not shown), e.g. it may include itineraries, positional data, and the like. In step S700, the request for an entry permission to a traffic control device 1 is issued and in step S800 a token 2 and an entry permission flag 3 are returned to a traffic control device. Messages may be sent as shown in step S603 in correspondence with the description of S102. The sub-steps of step S700 are explained in Fig. 29.
Fig. 29: In step S701 it is determined whether the vehicle 10 is inside a controlled sector, such as an intersection or a crossing. Should the answer be "no", it is determined, whether a distance to said controlled sector is smaller than a predefined distance D (step S702). Should the intersection be farer away than the predefined distance D, step S703 is performed according to which a request to enter a subsection is issued to the respective/responsible traffic control device 1 of said subsection (such as traffic control device 1b in Fig. 5). Furthermore, should step S701 find that the vehicle 10 is already inside the controlled sector or a subsection thereof, step S704 determines whether the vehicle 10 (or its driver) has the plan to proceed within the controlled sector or not. If this should be the case, step S705 is performed and a reservation right/option 6 for the next subsection is requested.
As a modification to Fig. 29 and its flowchart shown therein, step S701 is not necessarily included if a reservation option 6 is not used in the traffic control system 100.
Furthermore, the subs-steps of steps S800 are depicted in Fig. 30 which are performable within a vehicle control device 30. The process includes the returning of a token 2 and an entry permission flag 3 to a traffic control device 1. It is determined in step S801 whether the vehicle 10 is inside the controlled sector. If this is not the case, this procedure is stopped. If it is found that the vehicle 10 is inside the controlled sector, in step S802, it is checked whether a traffic control device 1 has issued a request to return an entry permission flag 3 as well as a token 2 which was already issued to said vehicle 10. This is the case, if an emergency vehicle 11 switched the traffic control system 100 to the emergency mode. If in step S802 the answer is "no", step S803 is performed in which it is determined whether the vehicle shall exit the subsection in which it is driving presently or not. If it is decided "yes", step S804 returns the entry permission 3 including the token 2 without a reservation option 6. Otherwise, if step S805 is performed, the entry permission flag 3 and token 2 with reservation option 6 is returned. If furthermore, in step S802, it is determined that there is a request present from a traffic control device 1 which demands the return of an entry permission flag 3 and a token 2, step S806 is performed. It is decided in step S806 whether it is possible to safely stop within the subsection in which the vehicle 10 is travelling at this moment. If this is the case, in step S807, the permission 3 is returned (with reservation option 6), while in step S808, the returning of the entry permission 3 and of the token 2 is rejected. In optional step 806 it may be found that the vehicle 10 has to perform an emergency braking or may not be able to stop in time, then the vehicle 10 may rather pass keep the entry permission; i.e. in this case the emergency vehicle 11 would have to wait and may pass the subsection briefly afterwards.
The effects achieved by the control including an emergency vehicle more are schematically depicted in Figs. 31 and 32. Both Figures show a virtual "stop sign" indicated by the filled black areas which cannot be passed by the normal vehicles 10a to 10d when the emergency vehicle 11 needs to enter the controlled sector. The emergency vehicle 11 has a "pass signal" indicated by the hatched area. Hence, for example, it is a technical advantage that the emergency vehicle 11 may quickly enter into the controlled sector, even though another normal vehicle 10a (see Fig. 31) holds an entry permission flag for the same subsection into which the emergency vehicle 11 needs to enter. This also applies for the case of many vehicles 10a to 10d which are inside or outside the controlled sector. They can be reliable prevented to enter the controlled sector or subsections thereof, through which the emergency vehicle 11 needs to pass. The technical implementation allows that the entire automated handling/coordination can be performed safely with minimum requirements in regard of communication bandwidth and computational resources. The control exhibits low latencies, inter alia, because of the small data packages which are exchanged.
A further modification option for prioritizing an emergency vehicle 11, i.e. giving it priority access to the controlled sector, is enabled by adding a traffic density monitoring unit 22 to the traffic control device 1. The traffic density monitoring unit 22 may be connected to a respective sensing unit 23 (Fig. 33). The sensing unit 23 may include a camera which monitors the traffic and it may be supported by an artificial intelligence that detects vehicles, roads, infrastructure and other traffic-relevant objects. Based on the modification of the traffic control device as shown by Fig. 33, instead of or in addition to the before described procedure including the generation of a temporary token 4 and a temporary entry permission flag T, an occupancy rate can be used to control the traffic within the controlled sector and for providing access priority to the emergency vehicle 11.
A first example is shown by Fig. 34 which shows possible timings for requesting and granting entry permissions to vehicles 10. Here, "[R]" indicates the timing of entry request and "[G]" indicates the timing of the grant of said request. The horizontal arrows indicate a time axis. In a normal traffic situation without an emergency vehicle 11 requesting entry to the controlled sector/a subsection thereof, a request is issued and after a very short communication caused delay, the request is granted if the token 2 and an entry permission flag 3 is available. This is depicted in the upper part of Fig. 34 and the communication caused delay is shown by the hatched areas. However, if it is switched to a priority/emergency control mode, as shown in the lower part of the schematic Figure 34, a request is not instantly granted and a delay time is added on purpose. The delay time (shown by the filled black areas) may be a predetermined delay time or a delay time being calculated for each situation depending on the present occupancy within the controlled sector. By delaying a grant to a normal vehicle 10 within or outside the controlled sector, the occupancy within the controlled sector can be reduced to such a degree that an emergency vehicle 11 can safely pass through the subsections of the controlled sector as requested.
Instead of or in addition to adapting the delay time, it may also be possible to force vehicles 10 inside the controlled sector to leave it on the shortest route and/orto stop issuing entry permissions to the controlled sector. Generally, the situation of an occupancy adjustment/control in an emergency case is depicted by Figs. 35 and following. Assuming that, as shown in Fig. 35, an emergency vehicle requests entry to the traffic control system 100, for example, if traffic control devices 1 are implemented only by software, the request is directly transmitted to the network 12. Then, as soon as the emergency mode is switched on, traffic density adjustment will be performed. One option of adjustment was described in connection with Figure 34 above. Another option is described as follows. The options may be combined.
Fig. 36 shows general considerations for an occupancy adjustment within a controlled sector. As shown in the left part of Fig. 36, an emergency vehicle 11 may need to pass the subsections "area C" and "area D" (indicated by the long unbroken arrow; the "areas A to D" are abbreviated as "A" to "D"). That means, it will have to pass two subsections of the controlled sector which has four subsections in this example. Then, it is assumed that a certain percentage of occupancy should not be exceeded so that the emergency vehicle 11 can smoothly and safely pass the controlled sector. This situation is further schematically explained by the right side part of Fig. 36. This part shows the subsections linearly aligned starting with the subsection which will be entered first by the emergency vehicle 11. In this example, subsection C would be first followed by subsections D, A, and B. Since it is a circular arrangement of subsections, the subsections B and C are shown again on the left and right side of this linear arrangement. Further, the filled black areas indicate the "stop signal" for entering this lane/subsection and the hatched areas indicate that passing is allowed. The areas with a quadratic black and white filling indicate that these subsections may be used for adjustment of occupancy if needed.
Since the emergency vehicle will pass through subsections C and D, these two subsections need to be free of other vehicles; it will not pass subsections A and B so that other vehicles may be inside the subsections A and B. In other words, the maximum occupancy can be calculated based on 100% minus the maximum occupancy X% of the subsections A and B. As an example, if six normal vehicles 10a to 10f are inside the controlled sector and its controlled subsections and, hence, 57.30% (see Fig. 38) are occupied according to a calculation which is described later, one can find that, if the vehicles 10a-f are evenly distributed over the subsections as shown in the right side of Fig. 37, the occupancy rate would need to be reduced in accordance with the scheme as shown in Fig. 38. In other words, it could be found that five vehicles 10a to 10e are allowable within the controlled sector (subsection A and B would be filled), while the sixth vehicle 10f in this example is exceeding the allowable/maximum occupancy rate in the controlled sector. Therefore, the occupancy rate in the situation depicted by Fig. 37 would have to be reduced so that the emergency vehicle 11 can smoothly pass areas C and D on its intended route indicated by the bold black arrows.
The occupancy rate may be calculated as shown in Fig. 39 by determining the vehicle body length LB, a safety margin L_M, and a vehicle breaking distance $d_{brk} = \frac{V^{2}}{2 a_{brk}}$
as well as the assumed radius of the controlled sector and the number of subsections. A maximum number of vehicles 10a to 10j may look like it is shown in the right side part of Fig. 39. Then, based on the equations and example shown in Fig. 40, the occupancy rate can be determined.
In the example with the example values of Fig. 40 (right column), a maximum of 10.472 vehicles is possible in the example sector which means a maximum of 2.618 vehicles per subsection. Now, assuming based on Fig. 36, that at least two free areas are required so that the emergency vehicle 11 can pass from area C to D safely, one can find that a maximum of five vehicles (47.7% occupancy rate) may be allowed inside the controlled sector for fulfilling the requirement. This is calculated based on the maximum number of vehicles within one subsection and the number of subsections in which vehicles are allowable. In this example, two areas of four need to be free and two areas can be occupied by other vehicles and each area may hold 2.618 vehicles per subsection.
In the example as shown in Fig. 38, the number of five vehicles within the controlled sector would result in an occupancy rate of 47.7 % which is admissible because two free subsections areas A and B are provided. However, with the sixth vehicle 10f within the controlled sector, an occupancy rate of 57.3 % is returned which is too high so that a specific procedure would have to be applied for reducing the occupancy rate. In other words, in the scenario as shown in Fig. 38, with six vehicles 10a to 10f inside the controlled sector, the vehicle no. 6 (10f) would block a part of subsection D, if all other vehicles 1 to 5 (10a- e) are adjusted to be driven inside subsections A and B which the emergency vehicle 11 does not need to pass or to leave the controlled sector.
In the above case the sixth vehicle 10f which is too much for the controlled sector and since it is inside the controlled sector already, it would be possible to force the sixth vehicle 10f to leave the controlled sector or to stop permitting other vehicles 10 to enter the controlled sector so that the number of vehicles 10 inside the controlled sector can decrease to an allowable occupancy rate before the emergency vehicle 11 enters the controlled sector.
If the number of vehicles 10 inside the controlled sector is below the maximum occupancy rate, two options are preferred which are also combinable and which are applicable within the traffic control system 100 for keeping the occupancy rate below the maximum occupancy rate for the safe passage of the emergency vehicle. A first possibility in this regard is that the occupancy rate is kept below the maximum occupancy rate /threshold by stopping each normal vehicle requesting to enter the controlled sector. The second option is as described in connection with Fig. 34 that a delay time is set or adjusted for the returning of a grant for an entry permission flag based on the occupancy rate so that the occupancy rate can be kept over the time below the maximum occupancy rate as long as the emergency mode is active.
The present disclosure allows to provide an automated traffic control for a controlled sector which needs reduced/minimal computational resources and data transmission resources. Even specific traffic situations can be controlled in which, e.g., emergency vehicles request priority for entering or passing the controlled sector of the road. The safety of the automated traffic control and automated driving is increased.
Aspects/Examples of the present disclosure may be a software entirely (including firmware, resident software, micro-code, etc.), or a combination of software and hardware aspects that may be referred to as a "system". Furthermore, the present disclosure may take the form of a computer program product on a computer-readable medium having computer-executable program code embodied in the medium.
It should be noted that arrows may be used in drawings to represent communication, transfer, or other activity involving two or more entities. Double-ended arrows generally indicate that activity may occur in both directions (e.g., a command/request in one direction with a corresponding reply back in the other direction, or peer-to-peer communications initiated by either entity), although in some situations, activity may not necessarily occur in both directions.
Single-ended arrows generally indicate activity exclusively or predominantly in one direction, although it should be noted that, in certain situations, such directional activity actually may involve activities in both directions (e.g., a message from a sender to a receiver and an acknowledgement back from the receiver to the sender, or establishment of a connection prior to a transfer and termination of the connection following the transfer). Thus, the type of arrow used in a particular drawing to represent a particular activity is exemplary and should not be seen as limiting.
The present disclosure may be described with reference to flowchart illustrations and/or block diagrams of methods and apparatuses, and with reference to a number of sample views of a graphical user interface generated by the methods and/or apparatuses. It will be understood that each block of the flowchart illustrations and/or block diagrams, and/or combinations of blocks in the flowchart illustrations and/or block diagrams, as well as the graphical user interface, can be implemented by computer-executable program code.
The computer-executable program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a particular machine, such that the program code, which executes via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts/outputs specified in the flowchart, block diagram block or blocks, figures, and/or written description.
The computer-executable program code may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the program code stored in the computer readable memory produce an article of manufacture including instruction means which implement the function/act/output specified in the flowchart, block diagram block(s), figures, and/or written description.
The computer-executable program code may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the program code which executes on the computer or other programmable apparatus provides steps for implementing the functions/acts/outputs specified in the flowchart, block diagram block(s), figures, and/or written description. Alternatively, computer program implemented steps or acts may be combined with operator or human implemented steps or acts in order to carry out an embodiment of the disclosure.
It should be noted that terms such as "server" and "processor" may be used herein to describe devices that may be used in certain aspects of the present disclosure and should not be construed to limit the present disclosure to any particular device type unless the context otherwise requires. Thus, a device may include, without limitation, a bridge, router, bridge-router (brouter), switch, node, server, computer, appliance, or other type of device. Such devices typically include one or more network interfaces for communicating over a communication network and a processor (e.g., a microprocessor with memory and other peripherals and/or application-specific hardware) configured accordingly to perform device functions.
Communication networks generally may include public and/or private networks; may include local-area, wide-area, metropolitan-area, storage, and/or other types of networks; and may employ communication technologies including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies (e.g., Bluetooth), networking technologies, and internetworking technologies.
It should also be noted that devices may use communication protocols and messages (e.g., messages created, transmitted, received, stored, and/or processed by the device), and such messages may be conveyed by a communication network or medium.
Unless the context otherwise requires, the present disclosure should not be construed as being limited to any particular communication message type, communication message format, or communication protocol. Thus, a communication message generally may include, without limitation, a frame, packet, datagram, user datagram, cell, or other type of communication message.
Unless the context requires otherwise, references to specific communication protocols are exemplary, and it should be understood that alternatives may, as appropriate, employ variations of such communication protocols (e.g., modifications or extensions of the protocol that may be made from time-to-time) or other protocols either known or developed in the future.
It should also be noted that logic flows may be described herein to demonstrate various aspects of the disclosure, and should not be construed to limit the present disclosure to any particular logic flow or logic implementation. The described logic may be partitioned into different logic blocks (e.g., programs, modules, functions, or subroutines) without changing the overall results or otherwise departing from the true scope of the disclosure.
Often, logic elements may be added, modified, omitted, performed in a different order, or implemented using different logic constructs (e.g., logic gates, looping primitives, conditional logic, and other logic constructs) without changing the overall results or otherwise departing from the scope of the disclosure.
The present disclosure may be embodied in many different forms, including, but in no way limited to, computer program logic for use with a processor (e.g., a microprocessor, microcontroller, digital signal processor, or general purpose computer), programmable logic for use with a programmable logic device (e.g., a Field Programmable Gate Array (FPGA) or other PLD), discrete components, integrated circuitry (e.g., an Application Specific Integrated Circuit (ASIC)), or any other means including any combination thereof Computer program logic implementing some or all of the described functionality is typically implemented as a set of computer program instructions that is converted into a computer executable form, stored as such in a computer readable medium, and executed by a microprocessor under the control of an operating system. Hardware-based logic implementing some or all of the described functionality may be implemented using one or more appropriately configured FPGAs.
Computer program logic implementing all or part of the functionality previously described herein may be embodied in various forms, including, but in no way limited to, a source code form, a computer executable form, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator).
Source code may include a series of computer program instructions implemented in any of various programming languages (e.g., an object code, an assembly language, or a high-level language such as Fortran, C, C++, JAVA, JavaScript or HTML) for use with various operating systems or operating environments. The source code may define and use various data structures and communication messages. The source code may be in a computer executable form (e.g., via an interpreter), or the source code maybe converted (e.g., via a translator, assembler, or compiler) into a computer executable form.
Computer-executable program code for carrying out operations of embodiments of the present disclosure may be written in an object oriented, scripted or unscripted programming language such as Java, Perl, Smalltalk, C++, or the like. However, the computer program code for carrying out operations of aspects of the present disclosure may also be written in conventional procedural programming languages, such as the "C" programming language or similar programming languages.
Computer program logic implementing all or part of the functionality previously described herein may be executed at different times on a single processor (e.g., concurrently) or may be executed at the same or different times on multiple processors and may run under a single operating system process/thread or under different operating system processes/threads.
Thus, the term "computer process" refers generally to the execution of a set of computer program instructions regardless of whether different computer processes are executed on the same or different processors and regardless of whether different computer processes run under the same operating system process/thread or different operating system processes/threads.
The computer program may be fixed in any form (e.g., source code form, computer executable form, or an intermediate form) either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory device (e.g., a CD-ROM), a PC card (e.g., PCMCIA card), or other memory device.
The computer program may be fixed in any form in a signal that is transmittable to a computer using any of various communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies (e.g., Bluetooth), networking technologies, and internetworking technologies.
The computer program may be distributed in any form as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the Internet or World Wide Web).
Hardware logic (including programmable logic for use with a programmable logic device) implementing all or part of the functionality previously described herein may be designed using traditional manual methods, or may be designed, captured, simulated, or documented electronically using various tools, such as Computer Aided Design (CAD), a hardware description language (e.g., VHDL or AHDL), or a PLD programming language (e.g., PALASM, ABEL, or CUPL).
Any suitable computer readable medium may be utilized. The computer readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or medium.
More specific examples of the computer readable medium include, but are not limited to, an electrical connection having one or more wires or other tangible storage medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), or other optical or magnetic storage device.
Programmable logic may be fixed either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory device (e.g., a CD-ROM), or other memory device.
The programmable logic may be fixed in a signal that is transmittable to a computer using any of various communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies (e.g., Bluetooth), networking technologies, and internetworking technologies.
The programmable logic may be distributed as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the Internet or World Wide Web). Of course, some embodiments of the disclosure may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other aspects of the present disclosure are implemented as entirely hardware, or entirely software.
While certain exemplary aspects have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and are not restrictive on the broad disclosure, and that the aspects of the present disclosure are not limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible.
Those skilled in the art will appreciate that various adaptations, modifications, and/or combination of the just described aspects and examples can be configured. Therefore, it is to be understood that, within the scope of the appended claims, the disclosure may be practiced other than as specifically described herein. For example, unless expressly stated otherwise, the steps of processes described herein may be performed in orders different from those described herein and one or more steps may be combined, split, or performed simultaneously.
Those skilled in the art will also appreciate, in view of this disclosure, that different aspects or examples of the disclosure described herein may be combined to form other aspects or examples of the disclosure.

Claims

A Traffic control system (100) for managing the flow of vehicles within a predefined sector of a road, the predefined sector being divided into subsections and the traffic control system having a plurality of traffic control devices (1a-d) connected to a network, each traffic control device is configured to control the flow of the traffic in a subsection of the predefined sector and comprises
at least one communication unit (20) for receiving or transmitting data from a remotely located communication unit, wherein the communication unit (20) is configured to
receive an entry request from a vehicle (10) approaching the subsection before entering said subsection, and

transmit one token (2a-d) with one entry permission flag (3a-d) for said subsection to said vehicle (10) in response to said entry request, if at least one token (2a-d) and at least one entry permission flag (3a-3d) is stored in a data storage space (13) linked to said subsection;
the traffic control system (100) further including said data storage space (13) configured to store one or more tokens (2a-2d) and one or more entry permission flags (3a-d), wherein receiving a token (2a-d) or an entry permission flag (3a-d) increases the number of tokens (2a-d) or entry permission flags (3a-d) in said data storage (13), respectively, and transmitting a token (2a-d) or an entry permission flag (3a-d) reduces the number of tokens (2a-d) or entry permission flags (3a-d) in said data storage (13), respectively.
The traffic control system according to claim 1, characterized in that the predefined sector of the road includes overlapping lanes, the sector is divided into subsections and each traffic control device (1a-d) is configured to control the traffic within one subsection of the plurality of subsections, and
the data storage space (13) is configured to store information about which traffic control device (1a-d) is assigned to control the traffic within which subsection; and
a vehicle (10) which has entered a subsection within which the traffic is controlled by a traffic control device (1a-d) returns the received token (2a-d) and the received entry permission flag (3a-3d) to another traffic control device (1a-d), wherein
said other traffic control device (1a-d) is configured to transmit the entry permission flag (3a-d) returned from the vehicle (10) to the traffic control device (1a-d) that had issued the entry permission flag (3a-d) and to forward a token (2a-d) to a further control device (1a-d).
The traffic control system according to at least one of claims 1 to 2, characterized in that the tokens (2a-d) issued by the traffic control devices (1a-d) are identical to each other, and the entry permission flags (3a-d) are configured to be valid for a specific subsection.
The traffic control system according to at least one of claims 1 to 3, characterized in that the data storage space (13) is configured to store information about which traffic control device (1a-d) is assigned to control the traffic within which subsection, wherein each subsection is labelled according to a predefined order and each traffic control device (1a-d) is labelled according to a predefined order, and
the data storage space (13) is configured to store information about which subsection with a specific label is linked to which traffic control device (1a-d) having a specific label.
The traffic control system according to claim 4, characterized in that the predefined order is circular so that each subsection and each traffic control device (1a-d) of the sector of the road, respectively, is connected to one previous and one next subsection and traffic control device (1a-d), respectively.
The traffic control system according to claim 4 and/or 5, characterized in that the predefined sector of the road includes overlapping lanes and the area of the sector in which roads or lanes are overlapping is divided into subsections and one subsection is defined for a part of the area within which two different lanes overlap, wherein
a vehicle (10) which has entered a subsection m within which the traffic is controlled by a traffic control device m (1a-d) returns the received token (2a-d) and the received entry permission flag (3a-d) to a traffic control device m+1 (1a-d) which is next in the predefined order and which is configured to control the traffic in a next subsection m+1, wherein
the traffic control device m+1 (1a-d) which has received the token (2a-d) and the entry permission flag (3a-d) of the subsection m is configured to transmit the entry permission flag of subsection m to the traffic control device m (1a-d) that issued said entry permission flag of subsection m and to forward a token (2a-d) to a further next traffic control device m+2 (1a-d) according to the predefined order, and each further traffic control device (1a-d) is configured to forward a token (2a-d) until a token (2a-d) is received by the traffic control device (1a-d) which issued a token to the vehicle (10).
The traffic control system according to claim 6, characterized in that the traffic control device which issued the token (2a-d) to the vehicle (10) is identified by the number of tokens (2a-d) in the data storage space (13).
The traffic control system according to at least one of the previous claims, characterized in that each traffic control device includes an entry permission control unit configured (21) to grant a vehicle (10) entry into a predefined sector, if said vehicle (10) holds an entry permission flag (3a-d) for said sector.
The traffic control system according to at least one of the previous claims, characterized in that the traffic control device (1a-d) is configured to issue a token (2a-d) combined with one or more reservation options (6) for one or more subsequent subsections and linked to a specific vehicle (10a), and each traffic control device (1a-d) holding a token (2a-d) with reservation option (6) is configured to issue said token with reservation option only to the vehicle (10a) to which said token with reservation option is linked.
The traffic control system according to at least one of the previous claims, characterized in that the traffic control device (1a-d) includes an emergency vehicle priority mode unit configured to be activated by an emergency vehicle (11) requesting entry into one or more subsections of the predefined sector, wherein,
if the emergency vehicle priority mode unit switches the operational mode of the traffic control device (1a-d) to an emergency vehicle priority mode, the traffic control device (1a-d) is configured to create a temporary token and a temporary entry permission flag to be issued to the emergency vehicle (11) requesting entry, and
each other vehicle (10), if holding a token (2a-d) and an entry permission flag (3a-d) of the subsection for which the emergency vehicle (11) requests entry, is forced by the traffic control device (1a-d) to return said token and the entry permission flag before the temporary token and the temporary entry permission flag is issued to the emergency vehicle (11).
The traffic control system according to claim 10, characterized in that the temporary token and the temporary entry permission flag are transmitted to the next traffic control device (1a-d) when the emergency vehicle (11) enters the subsection and the next traffic control device (1a-d) is configured to erase the temporary token and to return the temporary entry permission flag to the traffic control device (1a-d) which had issued the temporary entry permission flag; wherein when the traffic control device which has issued the temporary entry permission flag has received the temporary entry permission flag, said traffic control device is configured to erase the temporary entry permission flag and to re-issue a token and an entry permission flag to the vehicle (10) which forcibly returned a token and an entry permission flag before.
The traffic control system according to claim 10 or 11, characterized in that the temporary token has a reservation option (6) for one or more further subsections.
The traffic control system according to at least one of the previous claims, characterized in that the number of tokens (2a-d) and entry permission flags (3a-d) per subsection is either fixed based on the maximum number of vehicles (10) allowed in the subsection or is variably controlled based on time and density of traffic.
The traffic control system according to at least one of the previous claims, characterized in that each traffic control device (1a-d) includes an emergency vehicle priority mode unit configured to be activated by an emergency vehicle (11) requesting entry into one or more subsections of the predefined sector, wherein
if the emergency vehicle priority mode unit switches the operational mode of the traffic control device (1a-d) to an emergency vehicle priority mode, the traffic control device (1a-d) is configured to control the occupancy within the predefined sector of the road.
The traffic control system according to at least one of the previous claims, characterized in that the traffic control system (100) is configured to determine a maximum occupancy during the emergency vehicle priority mode which is derived from the number of subsections of the predefined sector which will be crossed by the emergency vehicle (11), the number being determined based on the entry request of the emergency vehicle (11), and based on the maximum capacity of vehicles (10) being inside the predefined sector of the road at the same time.
The traffic control system according to claim 15, characterized in that the traffic control system (100) stops providing entry permission to a vehicle (10) outside the sector of the road if an actual occupancy is higher than the maximum occupancy, and/or to set or adapt a delay time for the grant of an entry permission depending on the actual occupancy.
A computer program product comprising computer-readable instructions that, when executed in a computer system including one or more computers, cause the computer system to perform the control of the traffic control system according to at least one of the previous claims.