Traffic strategy system and method for implementing the same

Abstract

A traffic strategy and / or management system is adapted to generate and / or implement one or more strategy options to achieve user-defined objectives. The system includes an orchestration device connected to at least one data source device, at least one infrastructure device, and at least one management or control device. The orchestration device is also connected to a strategy generation device configured to create at least one traffic management strategy and / or a set of control instructions for all infrastructure devices associated with the strategy to achieve the user-defined objectives. The data source device includes modeling data and real-time data, which are provided and utilized by the strategy generation device and received by the orchestration device to create the traffic management strategy and / or the set of control instructions in real-time and / or near real-time.

Description

BACKGROUND

[0001] Transportation road networks are complex with many intersections between users of the network. The operator of the transportation road network attempts to keep the flow of people and goods around the network as efficient as possible.

[0002] Traditionally, road networks are managed using a variety of forms of traffic technology, i.e. traffic signals, message signs, traffic applications, pricing and incident management teams and systems.

[0003] These systems and methods work well when the demand for traffic is less than the capacity of the network to service the demand.

[0004] When the demand for traffic regularly approaches the capacity of the network, adaptive forms of control are introduced. In traffic control, the system manages the flow of traffic in the best way to minimize congestion and reduce delays. This operation is typically performed by a route base on transportation routes or in small geographical areas typically less than 4km 2 in length. These systems perform well if the capacity of the links of the network is not exceeded and if incidents do not occur that reduce the capacity of a particular link for more than a short period of time.

[0005] When incidents occur, the operator of the network intervenes to clear the incident with local incident management teams and to inform the traffic of potential disruptions to the network. Sometimes, control systems are used to create different flows around the incident, however, to perform this action, a similar incident needs to have occurred previously where a suitable plan has been developed (either during or at any time after the incident analysis) to deal with the incident.

[0006] Custom plans are often created to deal with major incidents, road works or major events in the plan. These plans are often built manually using modified versions of traffic models of typical road conditions. These plans take a significant amount of time to create and can need to be improved in real-time if the actual conditions are significantly different to those created in the traffic model. SUMMARY

[0007] The invention solves the above problems by using an automated method for creating management plans for road networks that can be generated and implemented in real-time or plans are generated offline and tested in a model before implementation.

[0008] The invention is a goal driven software that uses its understanding of how a ground transportation road network works to investigate all possible options on a route to find the option that achieves the goals set by the operator of the transportation.

[0009] The invention can solve the following problems in real-time:

[0010] • Event management - where a large event is planned to occur at a specific time, the invention combines the known information about the event (event time, event nature, likely traffic demand levels) with real-time knowledge of the state of the road network to produce a traffic plan to manage the event.

[0011] • Road works management - during road works, the invention takes knowledge of the capacity reduction caused by the road works and combines it with real-time and forecast demand over a time horizon of up to 60 minutes to produce a traffic management plan to reduce congestion in the road works area and to reduce the indirect effects of the road works caused bottlenecks.

[0012] • Accident management - this is similar to road works management, the invention takes knowledge of the capacity reduction caused by an accident (lane closure / road closure) and combines it with knowledge of current and forecast demand over a time horizon of up to one hour to produce a plan to reduce the congestion caused by the accident and the subsequent effects.

[0013] • Air quality management - the invention produces a traffic management plan in real-time to reduce emissions in places where air pollution levels are highest. The invention combines knowledge of current traffic demand with knowledge of road network capacity and the calculation of emissions per link. This knowledge is then used to reduce emissions in areas where air pollution is likely to be high, which are monitored or simulated.

[0014] • Bottleneck management - the invention uses its knowledge of demand and capacity pinch points in the road network to manage pinch points by upstream gating and local re-routing of routes to ensure that key road network bottlenecks operate at or below capacity. This ensures that subsequent delays caused by the bottlenecks do not cause traffic in the road network area to grind to a complete halt.

[0015] In a first aspect of the invention, there is provided a traffic strategy and / or management system adapted to generate and / or implement one or more strategy options that achieve user set targets, the system comprising an orchestration device connected to:

[0016] at least one data source device,

[0017] at least one base setting device; and

[0018] at least one management or control device,

[0019] In a preferred embodiment, the system includes one or more output data adapters. Typically, the output adapters process control instructions from the policy generation device and process them into a format for use and / or execution by the infrastructure devices. Further, the output data adapters typically perform any one or any combination of the following operations, including: translating, adapting, combining, completing, validating / verifying, or other forms of intermediate processing of the control instructions output from the policy generation device.

[0020] In one embodiment, the traffic is road-based traffic.

[0021] In one embodiment, the data source devices include any one or any combination of traffic management and control systems, data aggregation centers, databases, smart city data sources, and any kind of sensors, including connected vehicles and their sensors. Data from the data source devices can typically be provided manually and / or automatically. Further, the system typically uses multiple data input devices.

[0022] In a preferred embodiment, the system includes one or more input data adapters. Typically, the input adapters collect and / or process information from at least one data source device into the correct form for use by the policy generation device. Further, the input data adapters typically collect and / or extract information from the data source devices securely.

[0023] Typically, the system uses multiple input adapters to extract data from multiple data source devices.

[0024] In a preferred embodiment, the system includes one or more output data adapters. Typically, the output adapters process control instructions from the policy generation device and process them into a format for use and / or execution by the infrastructure devices. Further, the output data adapters typically perform any one or any combination of the following operations, including: translating, adapting, combining, completing, validating / verifying, or other forms of intermediate processing of the control instructions output from the policy generation device.

[0025] Typically, the system uses multiple output data adapters.

[0026] In one embodiment, the infrastructure devices include real-time traffic control products. Typically, the output data adapters convert and / or adapt the control instructions issued by the policy generation device into signal plans that can be loaded into the traffic control systems. Further, the signal plans are typically complete signal plans.

[0027] In preferred embodiments of the invention, the system includes one or more process control adapters. Generally, the process control adapters are adapted to control the flow of instructions and / or data into and / or out of the orchestration device. Further, generally the process control adapters include any one or any combination of the following functions, including: issuing the correct instructions to the correct infrastructure device in the correct manner, in the correct format, at the correct time, determining the effect of the instructions through data sources and measurements before, during, and after the instructions are issued, and determining that the instructions have been successful and in response to problems, including external problem reports.

[0028] Generally, the control adapters are used for both input and output. For example, input includes requests for real-time information about parking availability or traffic capacity. Output includes instructions for control signals, issuing routing directions to networked vehicles, etc.

[0029] In one embodiment, the control adapters have a user interface. In one embodiment, the control adapters can be part of another product and / or system. For example, in one embodiment, the traffic simulation control adapters are embedded in a third party's traffic modeling and simulation product, which has a user interface that allows configuration and control of the specific adapters.

[0030] In preferred embodiments, the orchestration device orchestrates the set of control instructions produced by the policy generation device across the components or devices of the system. Generally, the orchestration includes collecting, coordinating, and sending the instructions from the policy generation device to at least the infrastructure devices. Further, the orchestration is generally in real-time. Preferably, the control instructions are orchestrated across the system in real-time for a period of time until the policy is successful and / or replaced by a second or another policy.

[0031] In one embodiment, the orchestration device uses the input data adapters to continuously compare real-time data from the data source devices to expected traffic flow. Generally, the orchestration device uses the input data adapters and the output of the policy generator device to compare real-time traffic flow to expected traffic flow, such that when a discrepancy arises, implementation of a new policy or computation of a new policy can be triggered. Further generally, the orchestration device converts the signal instructions into a signal plan set.

[0032] In one embodiment, the signal plan is loaded, executed, and / or unloaded from the control adapters in the correct order. Generally, the orchestration device converts the signal instructions into a complete signal plan set, which can be loaded, executed, and unloaded from a single or multiple traffic controllers using a traffic control computer.

[0033] In one embodiment, the orchestration device provides accurate, timely information to a management or control device. Generally, the management or control device is in a supervisory control environment of a traffic control center.

[0034] Preferably, the system can be configured to operate independently and / or as an integrated component of another traffic management product. In this embodiment, the system provides a set of data and control interfaces that other systems can use to configure and control the system or to present options and information to the user.

[0035] In one embodiment, the system includes a control or management device in the form of a management console application. Typically, the control or management device provides any or any combination of configuration, management, control, visualization, and reporting functions. Therefore, it allows a policy generator to operate as a decision support tool via human-initiated control or as an autonomous traffic management product via system-initiated control.

[0036] In one embodiment, a user can use a traffic management console or application to set the goals of a policy generator. Typically, the console can then run the policy generator, visualize the resulting policy, execute the policy, evaluate its effectiveness in real time, stop the current policy, generate new policies, and / or report / evaluate their effectiveness upon completion. Furthermore, the console can typically configure operating parameters, adapter integration, data source / sink points, and / or security options.

[0037] In a preferred embodiment, the policy generation device is input to an initial state at a certain time (T), a target, a domain model, and a time delay (E). Typically, policy generation means that it outputs a traffic signal policy; if the policy achieves its initial state at time T+E, then the policy will achieve its target.

[0038] Typically, the initial state is a set of all data / knowledge about traffic scenarios within the spatial target area of ​​the region under consideration.

[0039] In one embodiment, only certain or predetermined initial states are allowed. Preferably, the initial states include two types of information: persistent data and real-time data. Typically, persistent data is collected or is known before policy generation. Furthermore, real-time data is typically data collected in real-time and / or near real-time from the target area.

[0040] In one embodiment, persistent data includes any one or any combination of the following, including all of the following: a unique identifier for each link, cross zone, and cross zone phase in the problem target area.

[0041] Typically, the set of all links consists of the disjoint union of the link sets, including: input links U, internal links U, and output links. Furthermore, input and output links are usually collectively referred to as boundary links, with one end located outside the area under consideration. Otherwise, the link is an internal link.

[0042] In one embodiment, persistent data includes the maximum storage capacity per PCU (vehicle-normalized unit) for each link. Typically, it is assumed that all boundary links have unlimited capacity.

[0043] In one embodiment, for each signalized intersection, persistent data includes any one or any combination of the following: phase sequence (a fixed order of signal phases), fixed green light interval timing between phases, and a suggested maximum intersection cycle time. Typically, pedestrian crossings are considered signalized intersections, which are modeled as having one phase (when traffic is flowing) and one green light interval (when pedestrians can cross).

[0044] In one embodiment, persistent data for each phase in a signalized crossover includes any one or any combination of the following: which turning movements (left, right, and straight) are shown as green light signals in that phase, the shortest duration of the phase, the longest duration of the phase, and / or, for each turn, an estimated maximum physical flow (in pcu / s), typically used for turning during that phase.

[0045] In one embodiment, persistent data includes a phase-average traffic flow estimate in pcu / s for each turn. Typically, based on the origin-destination of traffic entering the area, this estimate is used for planned time periods (morning peak, off-peak, afternoon peak, special incidents, etc.). Furthermore, this value is often used during preprocessing to extract vehicle intent from the simulation software.

[0046] In one embodiment, persistent data includes the maximum flow rate in pcu / s for each turn in a non-signalized crossover.

[0047] Typically, the presence of a "turn" at an intersection signifies the connection of two specified links, thus implicitly revealing the road network topology of the target area.

[0048] In one embodiment, persistent data for each input link includes the expected average flow rate into that link, in pcu / s. Typically, this can “step change” over a period of time (so for an input link, it might be expected to average 1 pcu / s over 120 seconds, then 0.5 pcu / s over the next 60 seconds, and so on). Furthermore, it is generally assumed that the output link acts as a sink, allowing traffic to flow unimpeded from the ends of links within the region into that output link.

[0049] In one embodiment, persistent data includes a fixed schedule that specifies for each cross zone how many seconds of green light time each phase will activate before entering the interval. Typically, the fixed schedule has a fixed cycle time and a fixed set of segment timings, and is assumed to be the schedule that is active in the target zone at time T when the policy generator is invoked.

[0050] In one embodiment, persistent data includes objectives that the generated strategy must achieve as efficiently or quickly as possible. Typically, objectives must be written in logical terms, and their components are data that the generated strategy can modify. More typically, possible objective components are those that can be defined based on the effects of processes, actions, or incidents in a domain model. An example objective could be reducing the occupancy of a set of links.

[0051] In one embodiment, real-time data includes the number of vehicles (in PCUs) in each link at time T.

[0052] In one embodiment, the real-time data for each signalized crossover includes an identifier of the current green light phase or the green light interval activated at time T, and the number of seconds that have elapsed since the start of that phase or green light interval.

[0053] In one embodiment, the strategy generation apparatus generates segmentation timing for crossover zones in the region of interest. Typically, these segments can vary with the planned time, compared to a fixed-time schedule, and the cycle time of the crossover zone can also vary within any given maximum cycle time limit. Further typically, this assumes that the signal phase at the crossover zone is defined as a continuous set of different signals displaying a green light.

[0054] Typically, each phase is followed by a fixed-length green light interval, 0 seconds or more. Further, there are some special cases: filter arrows require a 0-second green light interval (the next phase begins immediately). Pedestrian crossings consist of 1 phase and 1 green light interval. Crossings without signals consist of 1 phase.

[0055] In one embodiment for all intersections in the region, for each cycle over time, the strategy generation device will generate a segmented timing signal plan to achieve its given objective.

[0056] In one embodiment, the strategy generation apparatus operates in two phases: a preprocessing phase and a trial phase.

[0057] Typically, in order to generate strategies to achieve a goal and check whether the strategy will achieve the goal, the strategy generation device includes a simulator or a planning engine that includes a simulator.

[0058] Typically, simulators use the activation elements of the domain model to simulate the policy's operation in its initial state. More typically, simulators use the procedures, actions, and events defined within it to simulate the policy's operation.

[0059] The simulation of the traffic world is digital; therefore, in one embodiment, a unit (or "Δ") is typically required after which incremental changes will be simulated. In this case, an interval of Δ = 1 second is used. The key flow value required for the simulation is estimated as the number of vehicles (in pcu / s) traveling along the route from link X to link Y through the intersection. The actual flow rate (AFR) is calculated at each time T for the planning engine simulation of the policy generation device.

[0060] To calculate AFR[T], the maximum physical flow rate (PFR) is used as the root.

[0061] AFR[T] is calculated by applying the following function to PFR:

[0062] AFR[T] = PFR x G1 x G2 x G3 x G4 x G5

[0063] in:

[0064] G1 = The factor derived from the saturation of X at time T.

[0065] G2 = The factor derived from the saturation of Y at time T.

[0066] G3 = any factor derived from the flow rate from X to Y at time T (e.g., if X to Y is a right turn).

[0067] G4 = A factor derived from the driver's intention, extracted from the stage average turning rate.

[0068] G5 = The length of time that the phase has been activated at time T.

[0069] Since the AFR is calculated at time T in state S(T), and taking into account the generated (or predefined) policy P, the simulator can be specified by specifying which changes the simulator makes to the state at time T, as specified in the simulation routines in steps 1-5 below.

[0070] 1. Collect all actions from P that must be performed from state S(T) (i.e., periodically at T), and then execute these actions sequentially. The order in which each action is executed must be indistinguishable from the effect. Update state = S1(T) with the result.

[0071] 2. Run the program Events(S1(T),S2(T)).

[0072] 3. Collect all processes from the domain model that satisfy their preconditions in state S2, and then execute these processes sequentially for time Δ. The execution order of each process must be indistinguishable. Furthermore, during Δ, no event's precondition becomes true and then false again. Update the state as S3(T+Δ) with the result.

[0073] 4. Run the program Events(S3(T+Δ),S4(T+Δ)).

[0074] 5. End

[0075] The program Events(s,t) takes state s as input and outputs state t as output, as shown below:

[0076] 1. Collect all events from the domain model that satisfy the preconditions in state s, and then execute these events sequentially. The execution order of each event must be indistinguishable from the effect. Update state = s1 with the result.

[0077] 2. IF s is not equal to s1, THEN sets s := s1 and jumps to 1; ELSE sets t := s1.

[0078] 3. END

[0079] For a complete simulation, iterate through the entire simulation routine starting from T = 0. After each run, replace S with S4(T+Δ) and T with T +Δ until we reach P and end.

[0080] In one embodiment, policy generation implies the need for preprocessing the input. Typically, the preprocessing stage provides a form of static validation, which checks the integrity or other aspects of the input data. More typically, preprocessing optimizes the representation of the input, thereby making explicit the information that the policy generator may need to use multiple times within the problem; and / or transforms the input into a more efficient representation, thereby involving reducing the dimensionality of predicate arguments.

[0081] In one embodiment, the preprocessing stage has at least three steps.

[0082] Typically, step 1 includes checking whether all invariants are satisfied. If any are violated, the generated strategy may be unreliable.

[0083] Typically, step 2 involves calculating the following for each cross-section and link:

[0084] Let C be any set of allowed timings for stages in a signalized cross-section (i.e., the set of stage time lengths between the allowed maximum and minimum values); L, L1, L2 are links, and j is the cross-section. Then, the following is calculated using simulated traffic values ​​(where traffic is the estimated maximum traffic value for the time period being simulated):

[0085] F1 j (L1,C) = the average outflow from the end of link L1 via j on link C;

[0086] This is the average traffic volume leaving L1 over the entire specified cycle C.

[0087] F2 j (L2,C) = The average inflow into L2 through j over the entire period C;

[0088] F3 j (L1,L2,C) = The average inflow from the starting point of link L1 to L2 on period C;

[0089] Please note that there exists a relationship where the sum of F3 on all links L leading to L2 (i.e., F3 on all L) exists. j The sum of (L,L2,C) equals F2j(L2,C).

[0090] Then, the "average fill rate" of link L can be calculated as follows:

[0091] F2 j (L,C) - F1 k (L,C1)

[0092] Where L is the link from cross-section j to cross-section k, and C1 is any set of allowed timings for the stages in cross-section k.

[0093] Given these definitions, the main expected traffic corridor through the area from the input link to the output link can be calculated, in which most vehicles travel.

[0094] Step 2 typically produces the following three sets of outputs;

[0095] Output 1

[0096] The first step is to calculate, for any given cross section j, the stage timing that maximizes the outflow of a specific link L entering j. This set of timings is called Cmax(L). Note that it is not necessary to explicitly refer to "j" because it is assumed that each link flows into a unique cross section.

[0097] Given a maximum cycle time for each crossover zone (instead of using the maximum timing for each stage as in our previous work; the calculation of optimal stage timing is more detailed if both maximum timing and maximum cycle time exist for each stage), Cmax(L) is calculated by maximizing the stage time of the stage with the maximum outflow and minimizing the remaining stages.

[0098] To determine the phase times of s Cmax(L) Figure 1 :

[0099] IF s guarantees the maximum outflow of L, THEN

[0100] Phase time of s: = (Maximum cycle time) - (Sum of minimum timings for all other phases) - (Sum of green light interval times), ELSE

[0101] The stage time of s is equal to the minimum stage time of s.

[0102] Therefore, for example, if the maximum stage time is 120, each of the three stages s1, s2, and s3 has three green light intervals of 10 seconds and three minimum times of 10 seconds, and L has outflows of s1 = 1.0 pcu / s, s2 = 0.9 pcu / s, and s3 = 0.1 pcu / s, then Cmax(L) is: stage time of s1 = 70s, stage time of s2 = 10s, stage time of s3 = 10s, so the average outflow of L on the cycle under Cmax(L) will be 0.666 pcu / s.

[0103] The preprocessor calculates Cmax(L) for each link L.

[0104] Output 2

[0105] Considering link L1, the preprocessor uses the cross-section phase timing calculated in Output 1 above to give the maximum outflow of each link while calculating the “target corridor” from L1—this is a list of links that tracks the maximum expected flow from L1 through the road network to the output link (which is considered to act as a sink).

[0106] To calculate the target corridor from L1 flowing into intersection zone j1, the following procedure is used:

[0107] 1. When L1 is not an output link:

[0108] 2. Identify the next link L2 in the corridor, where F3 j 1. Maximize function F3 (L1, L2, Cmax(L1)) j 1(L1,LX,C), where LX covers all links flowing out of j1.

[0109] 3. Set L1 := L2

[0110] 4. End When

[0111] Therefore, each link is in the target corridor, since each link is the link that receives the highest average traffic on the loop from its predecessor.

[0112] Output 3

[0113] Taking links into account, the preprocessor calculates all bottlenecks along the target corridor, i.e., the set of links with a positive average fill rate (as defined above).

[0114] In one embodiment of step 3, the algorithm demonstrates how to execute the domain model D. o Reconstruct and execute the initial state and target representation I o In addition to the model to be reconstructed, the algorithm also requires a sparsity threshold s. t And the parameter is taken as input, the threshold s t This parameter is used to determine whether performing a refactoring is useful, and sets the maximum number of variables considered in the refactoring.

[0115] The output is a new domain (D) with reduced dimensionality. r ) and problems (I r This description makes the use of policy generation software more efficient.

[0116] Typically, if an instance of a predicate cannot be deleted or created during the planning process, the predicates of the domain model are considered static, except in the case of numeric predicates, whose values ​​can be changed. The sparsity of predicates (Boolean or numeric) with an atom greater than 2 is evaluated sequentially (line 3) to determine if they are suitable for the restructuring step. As a measure of sparsity, the set of propositions of the initial state is compared to the possible set of all propositions for that predicate.

[0117] Input: D o , I o , s t , a t

[0118] Output: D r I r

[0119] 1 SP = statics(D o P = predicates(D) o )∪functions(D o )

[0120] 2D r = Do I r = I o

[0121] 3 FOR P for all pj, where arithmetic(pj) > 2 DO

[0122] 4 IF sparsity(p j , I o )>st THEN

[0123] 5 p stat = findConstrainingStatic(p j ,SP)

[0124] 6 IF p stat Not equal to None THEN

[0125] 7 Tp stat = getSparseVariables(p stat ,I o ,a t )

[0126] 8 Cnew = makeConstants(Tp stat , s o )

[0127] 9D r = addAsConstants(D r (Cnew)

[0128] 10 D r = updateOpProEv(D r , Tp stat (Cnew)

[0129] 11 I r = updatePredsFuncs(D r ,I r ,Tp stat ,Cnew )

[0130] 12 END IF

[0131] 13 END IF

[0132] 14 END FOR

[0133] In the case of the sparse predicate pj, the program attempts (line 5) to find the static predicate p. stat , making p jOnly for use with p stat The transition pattern (i.e., action, process, or event pattern). If there is more than one constraint static predicate, a constraint static predicate is tentatively selected by choosing the predicate that appears most frequently in the transition pattern.

[0134] In one embodiment, the policy generation apparatus includes a trial phase. Typically, to generate policies efficiently and effectively in any large hybrid application, application-specific "trials" are generated and used to guide the search within that search space. Furthermore, trials generally help guide the search, but this is not a hard rule that the search will first try the states that give the lowest values, but if no solution is found, it will progressively try states with higher values ​​until a solution is found.

[0135] In one embodiment, any hybrid AI planner can be used in this method, as long as it allows the insertion of such domain-dependent probing into its search strategy. Typically, the input to an automated planning engine that implements this for hybrid (i.e., discrete and continuous) formulas is equivalent to a language called PDDL+ (Community Acceptable Syntax).

[0136] In a preferred embodiment, the strategy generation device employs corridor probing.

[0137] Typically, the general formula for corridor probing aims to generate strategies for the goal of reducing the occupancy of one or a group of links.

[0138] In one embodiment of link L1 in this target set, the first step of the process is to generate the target corridors of L1, as defined in the preprocessor section above, which consist of cross sections j1...jN and links L1...LN:

[0139] L1 - j1 - L2 - j2 - L3 - .... - LN – jN

[0140] In this approach, a cyclic Cmax(Lj) operation is performed for each crossover region j. However, this cyclic allocation will lead to a bottleneck, as some links will become saturated.

[0141] Therefore, the required trial and error will be equivalent to allocating the adjustment period C1, ... CN under constraints.

[0142] F2 j1 (L2,C1) - F1 j2 (L2,C2) <E1

[0143] F2 j2 (L3,C2) - F1 j3 (L3,C3) <E2

[0144] F2j3 (L4,C3) - F1 j4 (L4,C4) <E3 ...

[0146] F2j N-1 (LN,CN-1) - F1 jN (LN,CN) <EN

[0147] Where EI,l1 =

[0148] If there is a set of links in the target that are lower, the individual values ​​of the trial for each link in that set can be summed.

[0149] In one embodiment, a particular corridor probe is calculated as follows:

[0150] 1. Calculate the bottlenecks in the corridor. Note that there may be multiple bottlenecks, each affecting all links in the corridor that are closer to the target than the corresponding bottleneck. Assuming the first bottleneck is in link Lk, then:

[0151] L1 - j1 - L2 - j2 - L3 - .... Lk-1 - jk-1 - Lk – jk

[0152] 2. Adjust the cycle time in the target corridor for intersection zones j1 to jk-1 so that the maximum average flow never exceeds the bottleneck. This is achieved by reducing the maximizing stage time in the target intersection zone up to jk-1. This is achieved by reducing the time of the stage with the maximum average flow.

[0153] Typically, this is an approximation of the general formula above. The distance from the bottleneck to any "upstream" link is indeed important; for example, links that are direct neighbors should reduce their average traffic precisely to the PCU that the bottleneck can utilize.

[0154] Furthermore, if there is more than one link distance, traffic reduction should be adjusted to account for the fact that not all vehicles will actually reach the bottleneck.

[0155] For example, if there are corridor links L1, L2 and L3, with L3 being the bottleneck, and the path is L1->L2->L3, then the effect of L3 in reducing the corridor output flow of L1 is improved by the fact that cars leaving L1 to L2 can actually bypass L3 because they are leaving the corridor.

[0156] ​These corridor probes are constrained, meaning that the timing for maximizing each crossover zone can be chosen selectively. Therefore, these maximization times can be adjusted to account for other constraints in the region, such as the need to provide minimum crossover traffic on certain crossover zones, or the presence of more than one link in the target set.

[0157] In one embodiment, a penalty-based corridor probing is used. Typically, this is an extension of corridor probing. This adds a penalty to the probing calculation for any state where the target phase time exceeds the corridor probing adjustment value. In this way, the search will always test one or more first states whose target cross-section will not send more traffic than the bottleneck can handle on average.

[0158] In one embodiment, a penalty-based extended corridor probing is employed. Typically, this probing not only penalizes the state where the target cross-section phase exceeds the corridor probing time, but also penalizes any corridor whose cross-section phase exceeds its corresponding time value (just as the same corridor-based probing method used to evaluate the cross-section phase is applied to the target cross-section).

[0159] In one embodiment, the policy generated by the policy generation device is post-processed. Typically, post-processing favors a convenient format and outputs it to a file. Further, processes that require the generated policy will typically read the policy from that file.

[0160] Below is an example of the strategy format. In this example, the phase time variation for all signal crossings (excluding pedestrian crossings that are assumed to have fixed phase times) is specified, i.e., when to continue from the current phase.

[0161] In one embodiment, the syntax of the control policy is as follows. The file is a list of lines in the following form:

[0162] <Action ID><Time><Phase ID>

[0163] For example

[0164] 11140 s1202_s4

[0165] This means that at <Time> = T + E + 140 seconds (140 seconds from the start of the policy), the signal in phase <Phase id> = s1202_s4 will be moved to the next phase (the next phase will, of course, arrive after the specified green light interval). <Phase id> is unique for a specific crossover zone, so there is no need to include the crossover zone identifier here. The action number here is 11.

[0166] External simulators that input this strategy will only use these signal change actions in that region to advance their simulation (the strategy should guide each signal change). When the signal strategy ends, the simulator should revert to its default strategy.

[0167] For a short strategy for a region containing two crossover zones (N1202 and N1349, as specified below), which begins at the green light time for phase s0 = 0 at both crossover zones, the syntax is as follows:

[0168] 1 20 s1202_s0

[0169] 2 30 s1349_s0

[0170] 3 30 s1202_s1

[0171] 4 40 s1349_s1

[0172] 5 40 s1202_s2

[0173] 6 60 s1202_s3

[0174] At the end of this example policy, at 60 seconds, both cross zones revert to the default policy. Therefore, 1202 (starting phase s4 at the end of the policy) will persist through phase s4 until the default policy notifies it of a change.

[0175] At the end of the policy, since 1349 enters phase s2 after 15 seconds (considering the 5-second green light interval after s1), if the policy indicates that the green light time for this phase is greater than 15 seconds, it will continue to run until the default policy notifies it to change. If the default policy indicates that the green light time for this phase is less than or equal to 15 seconds, it will immediately switch N1349 to phase s3 when the policy ends.

[0176] The specifications for the intersection areas involved in the example are as follows:

[0177] (= (interlimit S1202_s0 ) 0)

[0178] (= (interlimit S1202_s1 ) 0)

[0179] (= (interlimit S1202_s2 ) 0)

[0180] (= (interlimit S1202_s3 ) 0)

[0181] (= (interlimit S1202_s4 ) 5)

[0182] (= (interlimit S1202_s5 ) 0)

[0183] (= (interlimit S1202_s6 ) 5)

[0184] (= (greentime N1202) 0)

[0185] (= (intertime N1202) 0)

[0186] (= (mingreentime S1202_s0) 5)

[0187] (= (mingreentime S1202_s1) 5)

[0188] (= (mingreentime S1202_s2) 0)

[0189] (= (mingreentime S1202_s3) 5)

[0190] (= (mingreentime S1202_s4) 5)

[0191] (= (mingreentime S1202_s5) 0)

[0192] (= (mingreentime S1202_s6) 5)

[0193] (= (maxgreentime S1202_s0) 40)

[0194] (= (maxgreentime S1202_s1) 20)

[0195] (= (maxgreentime S1202_s2)10)

[0196] (= (maxgreentime S1202_s3) 60)

[0197] (= (maxgreentime S1202_s4) 70)

[0198] (= (maxgreentime S1202_s5)15)

[0199] (= (maxgreentime S1202_s6) 50)

[0200] (active S1202_s0)

[0201] (= (interlimit S1349_s0 ) 5)

[0202] (= (interlimit S1349_s1 ) 5)

[0203] (= (interlimit S1349_s2 )10)

[0204] (= (interlimit S1349_s3 )10)

[0205] (= (greentime N1349) 0)

[0206] (= (intertime N1349) 0)

[0207] (= (mingreentime S1349_s0) 5)

[0208] (= (mingreentime S1349_s1) 5)

[0209] (= (mingreentime S1349_s2) 5)

[0210] (= (mingreentime S1349_s3)10)

[0211] (= (maxgreentime S1349_s0) 70)

[0212] (= (maxgreentime S1349_s1) 70)

[0213] (= (maxgreentime S1349_s2) 70)

[0214] (= (maxgreentime S1349_s3) 75)

[0215] (active S1349_s0)

[0216] The explanation for some of these facts is as follows:

[0217] (= (interlimit S1202_s6 ) 5) indicates that the green light interval after stage S1202_s6 lasts for 5 seconds.

[0218] (= (greentime N1202) 0)

[0219] (= (intertime N1202) 0) indicates that the next phase at the intersection N1202 has not yet started.

[0220] (active S1202_s0) indicates that phase S1202_s0 is active, but it has just started (its elapsed green light time is 0 seconds).

[0221] (= (mingreentime S1202_s0) 5) indicates that phase S1202_s0 must remain active for at least 5 seconds.

[0222] In a second aspect of the invention, a traffic strategy implementation system is provided, which generates instructions for transmitting road network infrastructure to achieve user-defined objectives, the system including an orchestration device connected to the following means;

[0223] At least one data source device,

[0224] At least one infrastructure device; and

[0225] At least one management or control device,

[0226] The orchestration device is characterized in that it is further connected to a strategy generation device, which is configured to create at least one traffic management strategy and / or a set of control instructions for all infrastructure devices related to the strategy to achieve a user-set objective.

[0227] Preferably, the data source device includes modeling data and real-time data, which are provided and utilized by the strategy generation device and received by the orchestration device to create at least one traffic management strategy and / or a set of control instructions. Attached Figure Description

[0228] A specific embodiment of the present invention is as follows, with reference to the following figures, wherein:

[0229] Figure 2 A schematic diagram showing a high-level view of the technical architecture;

[0230] Figure 3 A schematic diagram of an artificial intelligence (AI) core according to one aspect of the present invention is shown;

[0231] Figure 4 A diagram showing the cross-sections connected by links is displayed;

[0232] Figure 5 This shows an example of a signal cycle at a crossover region; and

[0233] Examples in the document A graph showing traffic flow during the phase. Detailed Implementation

[0234] This invention (hereinafter referred to as the Simplifai system) modifies and improves the steps of other road traffic management strategy generators in the following way:

[0235] • Scale of Operation – Simplifai can operate citywide. Other systems typically operate in corridors or small areas (usually less than 4km). 2 Optimize

[0236] • Speed ​​of Execution – Simplifai has found a strategy to achieve the goal in less than one traffic signal cycle time (>40 seconds). Current results show that a plan can be generated in less than 10 seconds. This means that the output can be used in real time, with a response time of less than 1 minute.

[0237] • Ability to achieve a range of objectives – Existing systems have fixed objectives such as reducing congestion in specific urban corridors or areas. Simplifai can achieve a range of different objectives through traffic management plans.

[0238] • Use of modeling and real-time data – Simplifai can combine and interpret data from a range of modeling and real-time sources, enabling the system to understand the current and future state of the road network.

[0239] • Output to a range of systems – Simplifai’s output can be directly linked to traffic models (for offline testing before implementation), central control systems, control devices that directly link to the road network, and routing engines for connected and autonomous vehicles.

[0240] • System Rescheduling – If the initial plan differs from its intended plan, Simplifai can generate a set of updated traffic management plans in real time. This can be done within a rescheduling refresh interval of 5 minutes or less.

[0241] 1.1 Technical architecture

[0242] The operational examples used in this document are intended to highlight the detailed operation of Simplifai in specific situations. Further details of the operation can be provided upon request.

[0243] 2 Strategy generator

[0244] 2.1 Strategy Generator

[0245] The purpose of Strategy Generator 2 is to create traffic management strategies and a set of control instructions for all infrastructure related to the strategy, which, when issued, will achieve the intended objectives. These objectives are pre-defined and can be anything, from managing congestion to evacuating the city in an emergency. The Strategy Generator is the main subject of this disclosure and is fully explained in Section 3.

[0246] The orchestration component 4 is responsible for launching the policy generator 2 and providing access to the necessary data and systems.

[0247] 2.2 Input Data Adapter

[0248] The system operates using a series of input adapters 6, driven by monitoring and control applications specific to the operating environment. These adapters 6 securely extract information from one or more data sources 8 and process it into the correct form for use by the policy generator 2. This typically requires translation, adaptation, combination, verification / validation, and other forms of intermediate processing. Data sources 8 include traffic management and control systems, data aggregation centers, databases, smart city data sources, and any type of sensor (including connected vehicles). Data can be manually provided (e.g., surveyed traffic counts). Instances of the system can utilize multiple input adapters 6.

[0249] For example, an adapter 6 uses surveyed traffic count data as a baseline for link occupancy. This data is collected manually and provided to the adapter as a CSV file. The adapter then uses real-time traffic data from the city's traffic monitoring system to adjust the link baseline up or down using a factorization algorithm. Occupancy on links not monitored in real time is inferred from measured link occupancy to provide approximate values ​​of possible real-time traffic, suitable for use by the policy generator 2.

[0250] 2.3 Output Data Adapter

[0251] The purpose of a strategy generator is to generate a set of control instructions for all infrastructure related to traffic management strategies, which, when issued, will achieve the intended objectives. These control instructions can be used in a variety of operating environments, including connected vehicles, signage, control room visualization, traffic modeling, traffic control, and traffic simulation products and infrastructure. The format and content of these instructions vary depending on the operating environment and, in some cases, on the products of each vendor within the operating context. For example, vendors A, B, and C may each provide traffic control systems, but the form and content of each vendor's set of input signal control instructions will differ. Customers can also customize the implementation of their products.

[0252] The purpose of Output Adaptor 10 is to generate control instructions in a suitable format for a specific product within a specific operational context, for use by a specific customer. It obtains control instructions from Strategy Generator 2 and combines them with other relevant information and systems to create control instructions that can be executed by the target product. This typically requires translation, adaptation, combination, completion, verification / validation, and other forms of intermediate processing. For example, for real-time traffic control products, it translates control instructions into a complete signal plan that can be loaded into the traffic control system.

[0253] A system instance can use multiple output adapters 10. For example, while the "Control Center Visualization" output adapter creates signal instructions for a traffic model or geographic information system displayed in the control room, the "Real-time Signal Control" output adapter will simultaneously create signal plans for the city traffic control system.

[0254] 2.4 Control Adapter

[0255] Coordination with external systems requires data and process control. While data adapter 10 provides data in an appropriate format for integration with external software and infrastructure, control adapter 12 provides process control facilities for use by a specific customer, tailored to the specific product in a specific operational context.

[0256] In this context, process control may include:

[0257] • Send the right instructions to the right system in the right way, in the right format, and at the right time—that is, use the appropriate protocol to communicate with the output product;

[0258] • Determine the effectiveness of the directives using instruments and measurements before, during, and after their issuance; and

[0259] • Determine if the instruction was successful and respond to problems, including external problem reports.

[0260] For example, when the request signal controller ends the current signal phase, the control adapter 12 can check the current signal phase, issue a command, and check the resulting signal phase. It will also record information such as how long the process took, whether there were any warnings or errors. If an error is found, it will determine whether action must be taken and take appropriate action.

[0261] Each external system may be proprietary, and therefore may have one or more proprietary control adapters 12. For a single product, such as a traffic control system, multiple control methods are typically permitted (e.g., Telnet / SSH interface, RESTful API, UTMC indirect control interface, etc.). In some cases, a common protocol exists (e.g., UG406 for urban traffic control), so many control adapters may share a "protocol" output control adapter. Similarly, when proprietary systems use the same data format, they can share data adapters.

[0262] The control adapter 12 can be used for inputs (e.g., requesting real-time information about parking availability or traffic capacity) and outputs (control signals, issuing route guidance to connected vehicles, etc.). The control adapter may also have a user interface and could even be part of another product. For example, a traffic simulation control adapter is embedded within a traffic modeling and simulation product and has a user interface that allows configuration and control of the adapter.

[0263] 2.5 Arrangement

[0264] Traffic management strategies are a set of coordinated interventions across multiple operational contexts and locations within a transportation network, which together allow a city to achieve its traffic management objectives within a specific timeframe. Therefore, when the strategy generator produces a set of control instructions, these instructions must be orchestrated in real-time across the system over a period of time until the strategy is successful. Orchestration component 4 performs this function.

[0265] For example, the orchestration unit continuously compares real-time traffic flow with expected traffic flow using the simulator output of input data adapter 6 and strategy generator 2, triggering new strategies when discrepancies arise. Simultaneously, the orchestration unit translates signal commands into a complete signal plan set, which it must load, execute, and unload from dozens of traffic controllers in the correct order using the traffic control computer. Furthermore, it must provide accurate and timely information to the monitoring environment of the traffic control center.

[0266] The orchestration component 4 contains its own logic, but relies heavily on the input 6 and output 10 data adapters and the control adapter 12 to integrate into a specific system and comply with a specific protocol.

[0267] As the complexity of objectives increases, as does the size and complexity of road networks and their domain models, the importance of orchestration and control also increases.

[0268] 2.6 Management Console

[0269] This system can operate as an integrated component of another management product, such as a city traffic management system 14 within a control center. In this case, it provides a set of data and control interfaces that other systems can use to configure and control the system or to present options and information to the user.

[0270] However, many traffic management departments lack such facilities or use rudimentary facilities that may not be suitable for city-wide autonomous control. Therefore, the system can include its own management console application.16 This architectural component is crucial for democratizing traffic management and facilitating widespread system deployment across customers, markets, and regions.

[0271] The management console application 16 provides configuration, management, control, visualization, and reporting facilities that allow the policy generator 2 to operate as a decision support tool (human-initiated control) or as an autonomous traffic management product (system-initiated control). For example, users can use this application to set goals for the policy generator 2, run the policy generator, visualize resulting policies, execute policies, evaluate their effectiveness in real time, stop the current policy, generate new policies, or report / evaluate their effectiveness upon completion. It can also configure operating parameters, adapter integration, data source / sink points, and security options.

[0272] 2.7 Data

[0273] The data required by the system depends on the system's traffic management objectives, operational context (e.g., traffic planning and real-time control), and operating environment (e.g., the presence or absence of a management console).

[0274] In many cases, data will be temporary. It will be extracted from the source data repository, processed, used, and then discarded (except where required for security, verification, and reporting). Data adapter 6 performs the role of managing data access, processing data, and then making it available to components within the system (such as control adapter 12). Temporary data can be temporarily stored and then removed from the system data store as needed. The discrete data management subcomponent of the orchestration component can be responsible for data management.

[0275] In some cases, especially where the data is used for a long period of time (such as the maximum and minimum green light times of traffic lights, intersection and link names / locations, etc.), it can be stored in the system data store and is usually updated regularly.

[0276] Reports and verification data can be permanently stored and archived according to the specific policies of clients, regions, and legislative bodies.

[0277] Sensitive data is typically not stored in the system.

[0278] Data access is typically protected through a multi-layered security and access management framework, which can be a sub-component of an orchestration component.

[0279] 2.8 Safety

[0280] Security is a critical component of the system, therefore a multi-layered security approach is typically employed. The system-related security measures for this system usually include:

[0281] • Application security – All endpoints, components, and interfaces require authentication and use user / service identity management.

[0282] • Access control – Access to all layers of the architecture is controlled using individual, group, role, and function permissions, with administrator permissions limited in number.

[0283] • Protocol Security – The system uses multiple protocols, particularly for accessing source data and infrastructure control environments. For example, access to traffic control systems is typically via Telnet or SSH, while access to city data centers is often via secure HTTP, file system protocols, or even SFTP. Where feasible, use secure variants of these protocols (e.g., SSH instead of Telnet, HTTPS instead of HTTP).

[0284] • Network security – Depending on the operational context, different levels of network security are deployed. At a minimum, firewalls and intrusion detection systems are deployed.

[0285] • Operating system security — Access to the operating system is limited to a limited number of designated and verifying personnel.

[0286] • Physical security — Access to the operating system is limited to a limited number of designated and auditing personnel and, where possible, is granted through a Tier 1 data center.

[0287] • Data security – Data is encrypted both at rest and in transit. Only the minimum data required by the operating system is stored, and even then, only for the shortest possible time. Sensitive data is not stored.

[0288] • Maintenance – All software is maintained with the latest patch level or version.

[0289] 3 Figure 2

[0290] 3.1 Data Requirements

[0291] Policy Generator 2 takes as input an initial state, objective, domain model, and time delay E at a given time T. Its output is a traffic signal policy that, if executed at time T+E, will achieve the objective. It is assumed that the initial state and domain model are accurate representations of the application.

[0292] The initial state is a set of all data / knowledge about the traffic scenario (within the spatial target area of ​​the considered urban area). The policy generator assumes that this set is true at the start of the problem and that this set is used to help generate a policy to solve the objective.

[0293] Typically, only specific initial states are allowed. Appendix B attempts to capture these initial states by illustrating the constraints on and between the components of the initial state.

[0294] This initial state consists of two types of information as defined in the following sections.

[0295] A key advantage of the method disclosed herein is that the strategy is automatically generated in response to a selected urban traffic control objective. This objective, along with its initial state, can be generated in real time to adapt to the type of problem being addressed. For example, if the problem is to reduce pollution in an area containing multiple road links, the resulting objective might be to reduce congestion on those road links.

[0296] If the internal world model of policy generator 2 is correct / accurate enough, then if it generates a policy, that policy is guaranteed to solve the objective when executed. If independent simulations show that it is incorrect, then its internal model or its internal simulator is incorrect or inaccurate.

[0297] Domain Model 20 ( Figure 2 Box 7) encodes the "physical" aspects of the traffic management scenario. In this example, it models vehicle flow, the actions and timing of signal changes, and the green light interval process. Domain model 20 must be designed a priori by a planning expert. This model represents the impact of traffic signal changes. Various other ways of altering traffic flow exist ("effectors"), such as VSL / VMS – these can be modularly added to the domain model of the policy generator, meaning that newly generated policies will contain instances of these effectors if they contribute to achieving the objectives.

[0298] 3.1.1 Persistent Data

[0299] Persistent data 22 (box 1, Figure 3 Collected or known before the policy generation time, including:

[0300] - Each link 40 in the problem area (e.g., the identifier marked with an arrow in Figure 3), and the intersection area (e.g., Figure 4 (circles in the middle) and the intersection phase 42 (part of the loop, in Figure 4 and 5 The labels indicate phases 1, 2, and 3. The set of all links consists of the disjoint union of the link sets:

[0301] - Input Link U Internal Link U Output Link

[0302] Input and output links are collectively referred to as boundary links, and one end of each link is located outside the area under consideration. Otherwise, the link is an internal link.

[0303] - Maximum storage capacity per link (in PCU). Assume all boundary links have unlimited capacity.

[0304] - For each signalized crossover region:

[0305] a. Stage sequence (a fixed order of stages, such as...) Figure 5 and Figure 4 (Clockwise order of stages 1-3)

[0306] b. Fixed green light interval time between stages 44 ( Figure 5 The orange section shows the loop duration, where the example timer is... Figure 5 (as given in the text)

[0307] Recommended maximum cycle time for the C-intersection ( Figure 4 The loop duration is 120 seconds.

[0308] Pedestrian crossings are considered signalized intersections and are modeled as having one phase (when traffic is flowing) and one green light interval (when pedestrians can cross).

[0309] - For each stage in the signalized crossover region:

[0310] a. During this phase, which turning movements (left, right, and straight) are indicated by a green light signal (e.g.) Figure 5 and Note that the presence of a "turn" in a cross-zone means that two specified links are connected together, thus implicitly giving the road network topology of the target zone. (The topology of the intersection area, with green arrows indicating which turning movements are valid for that phase)

[0311] Minimum time for phase b

[0312] c [Optional] Maximum time for the stage. A special case is when the stage time cannot be changed, so the maximum time can be set to the same as the minimum time.

[0313] d. For each turn, the estimated maximum physical flow (in pcu / s) for the turns during that phase.

[0314] - For each turn, an estimate (in pcu / s) of the phase average flow rate is typically used for a time period during which traffic entering the area is planned based on its source-destination (morning peak, off-peak, afternoon peak, special times, etc.). This value will be used during preprocessing to extract vehicle intent from the simulation software.

[0315] - Maximum flow rate (in pcu / s) for each turn in a non-signalized crossover (represented as a signalized crossover with a permanent phase).

[0316] Figure 5 Figure 2

[0317] - For each input link, the expected average flow rate entering that link is expressed in pcu / s. This can "step change" over time (so for an input link, it might be expected to average 1 pcu / s over 120 seconds, then 0.5 pcu / s over the next 60 seconds, and so on). Output links are assumed to be sinks, allowing traffic to flow unimpeded from the ends of links within the area into these output links.

[0318] - A fixed schedule is defined for each crossover zone, specifying how many seconds of green light time each phase activates before entering the interval. The fixed schedule has a fixed cycle time and a fixed set of split timings, and is assumed to be active in the target zone at time T when the policy generator is invoked. Figure 4 In this case, the values ​​might be as follows: Phase 1 = 50 seconds, Phase 2 = 30 seconds, Phase 3 = 18 seconds.

[0319] - The goal is to achieve the generated strategy as efficiently as possible. It must be written in logical terms, the components of which are the data that the generated strategy can modify. In other words, possible goal components are those that can be defined based on the effects of processes, actions, or time within the domain model. An example goal might be to reduce the occupancy of a set of links.

[0320] 3.1.2 Real-time data

[0321] Real-time data 24 ( Figure 5 Box 2) in the figure represents data from the target area, which is assumed to have been collected in real time or near real time.

[0322] - The number of vehicles on each link at time T (in PCUs).

[0323] - For each signalized crossover zone, the identifier of the current green light phase or the green light interval activated at time T, and the number of seconds that have elapsed since the start of that phase or green light interval.

[0324] 3.2 The operation of the strategy generator

[0325] The strategy generator generates segmentation timing for intersections in the region of interest (e.g., Figure 5 and Figure 2(The duration of each of the three green light arcs in the middle cycle). In contrast to a fixed-time schedule, these divisions may vary with the schedule duration within any given maximum cycle time limit, as may the cycle time of the crossover zone.

[0326] This example assumes that signal phases at an intersection are defined as a series of distinct signals continuously displaying a green light. Each phase is followed by a fixed-length green light interval, 0 seconds or more. There are some special cases: filter arrows require a 0-second green light interval (the next phase begins immediately). Pedestrian crossings consist of 1 phase and 1 green light interval. Intersections without signals consist of 1 phase.

[0327] Figure 2 A specific example of a cross-section cycle with sampling timing is shown. It also shows an example phase configuration, where the green light arrows represent the permitted traffic flow for that phase. It can be seen that changing the phase length strategy alters the total traffic volume of possible routes through that cross-section. For all cross-sections within the area, for each cycle in time, the strategy generator will produce a segmented timing signaling plan to achieve its given objective.

[0328] The policy generator operates in two phases, as described in Sections 3.2.2 and 3.2.3. It is based on the simulation method described in Section 3.2.1.

[0329] 3.2.1 Simulation

[0330] To generate strategies to achieve the goal and check whether the strategy will achieve the goal, the strategy generator's planning engine 26 ( To determine the phase times of s Box 6) in the table must implement a simulator. This uses the activation elements of the domain model; in other words, it uses the processes, actions, and times defined in the domain model to simulate the operation of the policy in its initial state.

[0331] The simulation of the traffic world is digital; therefore, a unit (or "Δ") is required after which incremental changes will be simulated. In this case, an interval of Δ = 1 second is used. The key flow values ​​required for the simulation are estimated as the number of vehicles (in pcu) traveling along the route from link X to link Y through the intersection. The Actual Flow Rate (AFR) used in the planning engine simulation is calculated at each time T. To calculate the AFR[T], the Maximum Physical Flow Rate (PFR) is used as the root.

[0332] AFR[T] is calculated by applying the following function to PFR:

[0333] AFR[T] = PFR x G1 x G2 x G3 x G4 x G5

[0334] in:

[0335] G1 = The factor derived from the saturation of X at time T.

[0336] G2 = The factor derived from the saturation of Y at time T.

[0337] G3 = any factor derived from the flow rate from X to Y at time T (e.g., if X to Y is a right turn).

[0338] G4 = A factor derived from the driver's intention, extracted from the stage average turning rate.

[0339] G5 = The length of time that the phase has been activated at time T.

[0340] Since the AFR is calculated at time T in state S(T), and considering the generated (or predefined) policy P, the simulator can be specified by specifying which changes the simulator makes to the state at time T.

[0341] Collect all actions from state S(T) that must be performed from state S(T) (i.e., periodically at T), and then execute these actions sequentially. The order in which each action is executed must be indistinguishable from the effect. Update state = S1(T) with the result.

[0342] Run the program Events(S1(T),S2(T)).

[0343] Collect all processes from the domain model that satisfy their preconditions in state S2, and then execute these processes sequentially for time Δ. The execution order of each process must be indistinguishable. Furthermore, during Δ, no event's precondition becomes true and then false again. Update the state as S3(T+Δ) with the result.

[0344] Run the program Events(S3(T+Δ),S4(T+Δ)).

[0345] Finish

[0346] The program Events(s,t) takes state s as input and outputs state t as output, as shown below:

[0347] Collect all events from the domain model that satisfy the preconditions in state s, and then execute these events sequentially. The execution order of each event must be indistinguishable from the effect. Update state = s1 with the result.

[0348] If s / = s1, then set s := s1 and jump to a; ELSE set t := s1.

[0349] Finish

[0350] For a complete simulation, iterate through the entire simulation routine starting from T = 0. After each run, replace S with S4(T+Δ) and T with T + Δ until we reach P and end the simulation.

[0351] 3.2.2 Preprocessing

[0352] The inputs to the policy generator (initial state, objective, and domain model) can be preprocessed.28 Figure 2 Box 3 in the middle, so that:

[0353] • Provides a form of static validation that checks the integrity of the input data or other aspects.

[0354] • Optimize its representation so that information that the in-problem policy generator may need to use multiple times is explicit; and

[0355] • Transforming the input into a more efficient representation involves reducing the dimensionality of predicate arguments.

[0356] 3.2.2.1 Step 1

[0357] This checks whether all the invariants given in Appendix B are satisfied. If any are violated, the generated strategy in this example may be unreliable.

[0358] 3.2.2.2 Step 2

[0359] For each cross zone and link, calculate the following;

[0360] Let C be any set of allowed timings for the phases in the signalized cross area (i.e., the set of phase time lengths between the allowed maximum and minimum values); L, L1, L2 are links, and j is the cross area. Then, the following is calculated from the above data 3.1.1-4(d) using simulated traffic values ​​(i.e., where traffic is the estimated maximum traffic value for the time period being simulated):

[0361] F1_j(L1,C) = the average outflow amount leaving the end of link L1 via j on link C;

[0362] This is the average traffic volume leaving L1 over the entire specified cycle C.

[0363] F2_j(L2,C) = The average inflow into the starting point of L2 via j over the entire period C;

[0364] F3_j(L1,L2,C) = the average inflow from the starting point of link L1 to L2 on period C;

[0365] Please note that there is a relationship where the sum of all links L leading to L2 (i.e., the sum of F3_j(L,L2,C) on all L) is equal to F2_j(L2,C).

[0366] Then, the "average fill rate" of link L can be calculated as follows:

[0367] F3_j(L,C) - F1_k(L,C1)

[0368] Where L is the link from cross-section j to cross-section k, and C1 is any set of allowed timings for the stages in cross-section k.

[0369] Given these definitions, the main expected traffic corridor through the area from the input link to the output link can be calculated, in which most vehicles travel.

[0370] Step 2 typically produces the following three sets of outputs;

[0371] Output 1

[0372] The first step is to calculate, for any given cross section j, the stage timing that maximizes the outflow of a specific link L entering j. This set of timings is called Cmax(L). Note that it is not necessary to explicitly refer to "j" because it is assumed that each link flows into a unique cross section.

[0373] With a maximum cycle time existing in each crossover zone (instead of using the maximum timing for each stage as in previous work; the calculation of optimal stage timing is more detailed if both maximum timing and maximum cycle time exist for each stage), Cmax(L) is calculated by maximizing the stage time of the stage with the maximum outflow and minimizing the remaining stages.

[0374] Figure 2 Cmax(L) Figure 2 :

[0375] IF s guarantees the maximum outflow of L, THEN

[0376] Phase time of s: = (Maximum cycle time) - (Sum of minimum timings for all other phases) - (Sum of green light interval times), ELSE

[0377] The stage time of s is equal to the minimum stage time of s.

[0378] Therefore, for example, if the maximum stage time is 120, each of the three stages s1, s2, and s3 has three green light intervals of 10 seconds and three minimum times of 10 seconds, and L has outflows of s1 = 1.0 pcu / s, s2 = 0.9 pcu / s, and s3 = 0.1 pcu / s, then Cmax(L) is: stage time of s1 = 70s, stage time of s2 = 10s, stage time of s3 = 10s, so the average outflow of L on the cycle under Cmax(L) will be 0.666 pcu / s.

[0379] The preprocessor calculates Cmax(L) for each link L.

[0380] Output 2

[0381] Considering link L1, the preprocessor uses the cross-section phase timing calculated in Output 1 above to give the maximum outflow of each link while calculating the “target corridor” from L1—this is a list of links that tracks the maximum expected flow from L1 through the road network to the output link (which is considered to act as a sink).

[0382] To calculate the target corridor from L1 flowing into intersection zone j1, the following procedure is used:

[0383] 1. When L1 is not an output link:

[0384] 2. Identify the next link L2 in the corridor, where F3_j1(L1,L2,Cmax(L1)) maximizes the function F3_j1(L1,LX,C), where LX covers all links flowing out of j1.

[0385] 3. Set L1 := L2

[0386] 4. End When

[0387] Therefore, each link is in the target corridor, since each link is the link that receives the highest average traffic on the loop from its predecessor.

[0388] Output 3

[0389] Taking links into account, the preprocessor calculates all bottlenecks along the target corridor, i.e., the set of links with a positive average fill rate (as defined above).

[0390] 3.2.2.3 Step 3

[0391] This algorithm demonstrates how to execute the domain model D. o Reconstruct and execute the initial state and target representation I o In addition to the model to be reconstructed, the algorithm also requires a sparsity threshold s. tAnd the parameter is taken as input, the threshold s t This parameter is used to determine whether performing a refactoring is useful, and sets the maximum number of variables considered in the refactoring.

[0392] The output is a new domain (D) with reduced dimensionality. r ) and problems (I r This description makes the use of policy generation software more efficient.

[0393] If an instance of a predicate cannot be deleted or created during the planning process, the predicates of the domain model are considered static, except in the case of numeric predicates, whose values ​​can be changed. The sparsity of predicates (Boolean or numeric) with an atom greater than 2 is evaluated sequentially to determine their suitability for the reconstruction step. As a measure of sparsity, the set of propositions of the initial state is compared to the possible set of all propositions for that predicate.

[0394] Input: Do, Io, st, at

[0395] Output: Dr, Ir

[0396] 1 SP = statics(Do ); P = predicates(Do )∪functions(Do)

[0397] 2 Dr = Do; Ir = Io

[0398] 3 FOR P for all pj, where arithmetic(pj) > 2 DO

[0399] 4 IF sparsity(pj , Io )>st THEN

[0400] 5 pstat = findConstrainingStatic(pj,SP)

[0401] 6. IF pstat not equal to None THEN

[0402] 7 Tpstat = getSparseVariables(pstat,Io,at)

[0403] 8 Cnew =makeConstants(Tpstat, so)

[0404] 9 Dr = addAsConstants(Dr , Cnew )

[0405] 10 Dr = updateOpProEv(Dr , Tpstat , Cnew )

[0406] 11 Ir = updatePredsFuncs(Dr,Ir,Tpstat,Cnew)

[0407] 12 END IF

[0408] 13 END IF

[0409] 14 END FOR

[0410] In the case of a sparse predicate pj, the program attempts (line 5) to find a static predicate pstat such that pj is used only for transition patterns (i.e., action, procedure, or event patterns) that have pstat. If there is more than one constraint static predicate, a constraint static predicate is tentatively selected by choosing the predicate that appears most frequently in the transition pattern.

[0411] 3.2.3 Exploration of Strategy Generation

[0412] The strategy generation process begins with an initial state and is based on a search space of future states of the world. Future states are generated using the simulator explained in Section 3.2.1. A number of "automatic planning engines" exist in the academic literature that implement this for hybrid (i.e., discrete and continuous) formulas. Figure 2 (See box 6 in the document). Most of these hybrid program engines input equivalents to a language called the community-received syntax known as DDL+.

[0413] However, in order to efficiently generate strategies in any large-scale hybrid application, it is necessary to provide application program 30 ( Appendix Box 5) generates "probes" to guide the search within the search space. Probes help guide the search, but are not a hard rule; the search will first try the states that give the lowest values, but if no solution is found, it will progressively try states with higher values ​​until a solution is found. For this purpose, any hybrid AI planner can be used in this approach, as long as it allows the insertion of such domain-dependent probes into its search strategy and is robust enough to take into account a domain model equivalent to PDDL+.

[0414] There are published explanations of domain-specific trial approaches for urban traffic control based on discrete-continuous planning. In particular, a queue-based trial approach is introduced in the AAAI paper “Efficient Macroscopic Urban Traffic Models for Congestion Reduction: A PDDL+ Planning Approach” (two of the co-authors are authors of this publication). This trial approach is based on a relaxed constraint that vehicles can only leave the link when the corresponding traffic light is green.

[0415] This disclosure defines a series of corridor probes to guide the search space for the policy generator. However, no published probe is as effective as this series of corridor probes.

[0416] 3.2.3.1 General Formula for Corridor Probing

[0417] Corridor probing aims to generate strategies for reducing the occupancy of one or a group of links. For link L1 in this target set, the first step of the process is to generate target corridors for L1, as defined in the preprocessor section above, which consist of cross sections j1 ... jN and links L1 ... LN:

[0418] L1 - j1 - L2 - j2 - L3 - .... - LN – jN

[0419] In this approach, for each crossover region j, the loop Cmax(Lj) is run. However, this cyclical allocation will lead to a bottleneck, as some links will become saturated.

[0420] Therefore, the required trial and error will be equivalent to allocating an adjusted period C1, ... CN under constraints.

[0421] F2_j1(L2,C1) - F1_j2(L2,C2) <E1

[0422] F2_j2(L3,C2) - F1_j3(L3,C3) <E2

[0423] F2_j3(L4,C3) - F1_j4(L4,C4) <E3 ...

[0425] F2_jN-1(LN,CN-1) - F1_jN(LN,CN) <EN

[0426] Where EI,l1 =

[0427] If there is a set of links in the target that need to be reduced, the trial values ​​for each link in that set can be summed.

[0428] 3.2.3.2 Exploration of a specific corridor

[0429] The trials that can be generated very efficiently can be calculated as follows:

[0430] Calculate the bottlenecks in the corridor. Note that there may be multiple bottlenecks, each affecting all links in the corridor that are closer to the target than the corresponding bottleneck. Assuming the first bottleneck is in link Lk, then:​

[0431] L1 - j1 - L2 - j2 - L3 - .... Lk-1 - jk-1 - Lk – jk

[0432] The cycle time in the target corridor is adjusted for intersection zones j1 to jk-1 so that the maximum average flow never exceeds the bottleneck. This is achieved by reducing the maximizing stage time in the target intersection zone up to jk-1. This is achieved by reducing the time of the stage with the maximum average flow.

[0433] This is an approximation of the general formula above. The distance from the bottleneck to any "upstream" link is indeed important; for example, a link that is a direct neighbor should reduce its average traffic precisely to the PCU that the bottleneck can take. However, if there are more than one link distance, the reduction in traffic should be adjusted to account for the fact that not all vehicles will actually reach the bottleneck. For example, if there are corridor links L1, L2, and L3, with L3 being the bottleneck, and the path is L1->L2->L3, then the effect of L3 in reducing the corridor output traffic of L1 is improved by the fact that vehicles leaving L1 to L2 can actually avoid reaching L3 because they are leaving the corridor.

[0434] These corridor probes are constrained, meaning that the maximum time for each crossover zone can be chosen selectively. Therefore, these maximization timings can be adjusted to account for other constraints in the region, such as the need to provide minimum crossover traffic at certain crossover zones, or the presence of more than one link in the target set.

[0435] 3.2.3.3 Specific Corridor Probing: Punishment-Based Corridor Probing

[0436] This is an extension of corridor probing. It adds a penalty to the probing calculation for any state where the target phase time exceeds the corridor probing adjustment value. Thus, the search will always test one or more first states whose target intersection will not send more traffic than the bottleneck can handle on average.

[0437] 3.2.3.4 Specific Corridor Exploration: Penalty-Based Extended Corridor Exploration

[0438] This is the current version of corridor probing. It not only penalizes the state where the target intersection phase exceeds the corridor probing time, but also penalizes any corridor intersection phase that exceeds its corresponding time value (just like the same corridor-based probing method used to evaluate intersection phases for the target intersection).

[0439] 3.3 Interface Specification for Output Strategy

[0440] The policies generated by the policy generator will be post-processed 32( Figure 2Box 8) is formatted for convenience and is output to file 34. ​ (See box 9 in the document). The process that requires this generated strategy will read it from the file. The strategy is given in the following format. In summary, it specifies the phase time changes for all signalized intersections (excluding pedestrian crossings that are assumed to have fixed phase times), i.e., when to continue from the current phase.

[0441] The syntax for the control policy is as follows. The file is a list of lines in the following form:

[0442] <Action ID><Time><Phase ID>

[0443] For example

[0444] 11140 s1202_s4

[0445] This means that at <Time> = T + E + 140 seconds (140 seconds from the start of the policy), the signal in phase <Phase id> = s1202_s4 will be moved to the next phase (the next phase will, of course, arrive after the specified green light interval). <Phase id> is unique for a specific crossover zone, so there is no need to include the crossover zone identifier here. The action number here is 11.

[0446] External simulators that input this strategy will only use these signal change actions in that region to advance their simulation (the strategy should guide each signal change). When the signal strategy ends, the simulator should revert to its default strategy.

[0447] For regions containing two intersection zones (N1202 and N1349, as specified below), a short strategy using this syntax begins at the green light time for stage s0 = 0 at both intersection zones, as follows:

[0448] 1 20 s1202_s0

[0449] 2 30 s1349_s0

[0450] 3 30 s1202_s1

[0451] 4 40 s1349_s1

[0452] 5 40 s1202_s2

[0453] 6 60 s1202_s3

[0454] At the end of this example policy, at 60 seconds, both cross zones revert to the default policy. Therefore, 1202 (starting phase s4 at the end of the policy) will run through phase s4 until the default policy notifies it of a change.

[0455] At the end of the policy, since 1349 enters phase s2 after 15 seconds (considering the 5-second green light interval after s1), if the policy indicates that the green light time for this phase is greater than 15 seconds, it will continue to run until the default policy notifies it to change. If the default policy indicates that the green light time for this phase is less than or equal to 15 seconds, it will immediately switch N1349 to phase s3 when the policy ends.

[0456] The connection point specifications involved in the example are as follows:

[0457] The specifications for the intersection areas involved in the example are as follows:

[0458] (= (interlimit S1202_s0 ) 0)

[0459] (= (interlimit S1202_s1 ) 0)

[0460] (= (interlimit S1202_s2 ) 0)

[0461] (= (interlimit S1202_s3 ) 0)

[0462] (= (interlimit S1202_s4 ) 5)

[0463] (= (interlimit S1202_s5 ) 0)

[0464] (= (interlimit S1202_s6 ) 5)

[0465] (= (greentime N1202) 0)

[0466] (= (intertime N1202) 0)

[0467] (= (mingreentime S1202_s0) 5)

[0468] (= (mingreentime S1202_s1) 5)

[0469] (= (mingreentime S1202_s2) 0)

[0470] (= (mingreentime S1202_s3) 5)

[0471] (= (mingreentime S1202_s4) 5)

[0472] (= (mingreentime S1202_s5) 0)

[0473] (= (mingreentime S1202_s6) 5)

[0474] (= (maxgreentime S1202_s0) 40)

[0475] (= (maxgreentime S1202_s1) 20)

[0476] (= (maxgreentime S1202_s2) 10)

[0477] (= (maxgreentime S1202_s3) 60)

[0478] (= (maxgreentime S1202_s4) 70)

[0479] (= (maxgreentime S1202_s5) 15)

[0480] (= (maxgreentime S1202_s6) 50)

[0481] (active S1202_s0)

[0482] (= (interlimit S1349_s0 ) 5)

[0483] (= (interlimit S1349_s1 ) 5)

[0484] (= (interlimit S1349_s2 ) 10)

[0485] (= (interlimit S1349_s3 ) 10)

[0486] (= (greentime N1349) 0)

[0487] (= (intertime N1349) 0)

[0488] (= (mingreentime S1349_s0) 5)

[0489] (= (mingreentime S1349_s1) 5)

[0490] (= (mingreentime S1349_s2) 5)

[0491] (= (mingreentime S1349_s3) 10)

[0492] (= (maxgreentime S1349_s0) 70)

[0493] (= (maxgreentime S1349_s1) 70)

[0494] (= (maxgreentime S1349_s2) 70)

[0495] (= (maxgreentime S1349_s3) 75)

[0496] (active S1349_s0)

[0497] The explanation for some of these facts is as follows:

[0498] (= (interlimit S1202_s6 ) 5) indicates that the green light interval after stage S1202_s6 lasts for 5 seconds.

[0499] (= (greentime N1202) 0)

[0500] (= (intertime N1202) 0) indicates that the next stage at the intersection N1202 has not yet started.

[0501] (active S1202_s0) indicates that phase S1202_s0 is active, but it has just started (its green light time is 0 seconds).

[0502] (= (mingreentime S1202_s0) 5) indicates that phase S1202_s0 must remain active for at least 5 seconds.

[0503] ​

[0504] A. Vocabulary

[0505]

[0506]

[0507] B. Invariants

[0508] These expressions must apply to any initial state file generated from information entering the AI ​​core. ​ ).

[0509] First, a link is formed by the disjoint union of sets of links:

[0510] Input link U, Internal link U, Output link

[0511] Each link has a occupancy value, and this value is always less than the maximum physical occupancy of that link:

[0512] x∈ Link, ∃! y∈ R ∃! z∈ R (= (occupancy rate x) y)&(= (maximum occupancy rate x)z)&y = <z

[0513] Each phase is followed by a green light interval of a certain length y:

[0514] x∈ stage, ∃! y∈ N ( = (interlimit x) y)

[0515] Each stage of the signalization crossover region has a stage before and after it:

[0516] The phase of x∈Signalized Crossover: ∃! y,z ∈s phase, (next yx)&(next xz)

[0517] Each stage belongs precisely to an intersection zone:

[0518] x ∈ stage, ∃! y ∈ intersection region (containing yx)

[0519] Each intersection zone has a green light interval – the number of seconds that the current phase has been active.

[0520] x∈ Intersection, ∃! y∈ N (= (green light time x) y)

[0521] Each intersection has a green light interval – the number of seconds the current green light interval has been active.

[0522] x∈ Intersection region, ∃! y∈ N (= (interval time x) y)

[0523] Each cross region has an activation phase:

[0524] x∈intersection∃! y∈phase, (activating y)&(containing xy)

[0525] Each inner link has at least one other link that allows inflow:

[0526] x∈ Internal link∃ y∈ Stage, ∃ z∈ Link, ∃ v ∈R (= (turning rate yzx)v).

Claims

1. A traffic strategy and management system for generating and implementing one or more strategy options to achieve user-defined objectives, the system including a orchestration device connected to; Data source devices include persistent data collected or known before policy generation, as well as real-time data. Infrastructure devices, including signals; and At least one management or control device; Its features are, The orchestration device is also connected to a strategy generation device configured to create at least one traffic management strategy and a set of control instructions for all infrastructure devices related to the strategy to achieve the objectives set by the user, wherein the strategy generation device uses: A simulator for modeling data of the domain and for simulating the operation of strategies on said persistent data using elements of the domain model. The objective is expressed as a logical term, and the components of the logical term are data that the generated policy options can change, including the effects of processes, actions, or events on the domain model, and The orchestration device continuously compares real-time data with simulator output to create control instructions, which include segmented timing signal plans for real-time and / or near-real-time signal changes for the infrastructure device.

2. The traffic strategy and management system according to claim 1, characterized in that, The traffic mentioned refers to road-based traffic.

3. The traffic strategy and management system according to claim 1, characterized in that, The data source device also includes any one or any combination of traffic management and control systems, data aggregation centers, databases, smart city data sources, and any type of sensor, including connected vehicles and their sensors.

4. The traffic strategy and management system according to claim 3, characterized in that, The system uses multiple data input devices.

5. The traffic strategy and management system according to claim 4, characterized in that, The system includes one or more input data adapters that collect and / or process information from the at least one data source device into a correct form for use by the policy generation device.

6. The traffic strategy and management system according to claim 1, characterized in that, The system includes one or more output data adapters that process control instructions from the policy generation device into a format used and / or executed by the infrastructure device.

7. The traffic strategy and management system according to claim 1, characterized in that, The infrastructure includes real-time traffic control products.

8. The traffic strategy and management system according to claim 1, characterized in that, The system includes one or more process control adapters adapted to control the flow of instructions and / or data into and / or out of the orchestration device.

9. The traffic strategy and management system according to claim 1, characterized in that, The orchestration includes collecting, coordinating, and / or sending instructions from the policy generation device to at least the infrastructure device.

10. The traffic strategy and management system according to claim 9, characterized in that, The orchestration device converts signal commands into a complete signal plan set, which can be loaded, executed, and unloaded from one or more traffic controllers using a traffic control computer.

11. The traffic strategy and management system according to claim 10, characterized in that, The orchestration device triggers a new strategy when a discrepancy arises between real-time traffic flow and the expected traffic output from the simulator of the strategy generation device.

12. The traffic strategy and management system according to any one of the preceding claims, characterized in that, The system can be configured to operate independently and / or as an integrated part of another traffic management product, and the system provides a set of data and control interfaces that can be used by other systems to configure and control the system or to provide options and information to users.

13. The traffic strategy and management system according to claim 1, characterized in that, The persistent data is collected or known before the strategy is generated, and the real-time data is real-time or near-real-time data collected from the target area.

14. The traffic strategy and management system according to claim 13, characterized in that, The persistent data includes any one or any combination of the following: a unique identifier for each link, cross zone, and cross zone phase in the problem target area.

15. The traffic strategy and management system according to claim 14, characterized in that, The persistent data includes the maximum storage capacity of each link in PCU (vehicle standardized unit).

16. The traffic strategy and management system according to claim 15, characterized in that, The persistent data includes the objectives that the generated strategy must achieve.

17. The traffic strategy and management system according to claim 1, characterized in that, The strategy generation device operates in two phases: a preprocessing phase and a trial phase.

18. The traffic strategy and management system according to claim 1, characterized in that, The simulator uses the activation elements of the domain model to simulate the operation of the strategy in the initial state, and the simulator uses the processes, actions and events defined therein to simulate the operation of the strategy.

19. The traffic strategy and management system according to claim 18, characterized in that, The input to the strategy generation device is preprocessed, and the preprocessing stage provides static verification to check the integrity of the input data or other aspects.

Images