Modelling and implementing adequate controllers for urban road traffic control constitute a huge challenge nowadays because of the complexity of systems, as well as possible scenarios and configurations, in each road in a city. A series of issues related to modelling these behaviours are common to arise when using formalisms, tools, and computation machines to perform complex calculations and limitations. This paper presents a formal, flexible, and adaptable approach, with no limitations, from the scientific point of view. For this purpose, modelling formalisms (cellular automata and timed automata) and analysis techniques (simulation and formal verification) are proposed to reach the main goals of modelling complex and adaptable behaviours in urban road traffic with multiple over time changeable configurations. A case study is presented, in order to illustrate the approach and demonstrate in detail the unlimited application of the presented approach.
The continuous increasing of the number of vehicles in parallel with a slight possibility of building new roads and the corresponding infrastructure are only two of the main reasons that are permanently leading to the search for new solutions, capable of preventing congestion and improving road safety.
Numerous authors highlighted the necessity of a thorough analysis of various traffic conditions, having the role to reveal the most important specific characteristics. They found their expression in the three main categories of models, developed as a result of macro, meso, and micro approaches, which were modified, extended, and improved in a multitude of studies [
Based on different categories of information, these models are used in a lot of scenarios and for various purposes. While macroscopic model simulations determine the traffic flow or average velocities for different vehicle densities, where vehicles are considered moving entities in the traffic infrastructures, micromodels need a large amount of data to reproduce the dynamic behaviour of individual vehicles in different traffic conditions [
Practical reasons generated by inherent disadvantages of each category of the basic models, such as computational cost and some unsatisfactory evaluation results regarding the capabilities of different groups to adapt to real situations, lead to the necessity to consider appropriate hybrid approaches, respectively, the possibility of combining models to work together in a common framework [
Traffic simulation systems, as dedicated tools used for the analysis of traffic congestions, played a crucial role in the development of traffic models. In existing research directions, the event driven, or time driven, evolution of the traffic was considered along with the deterministic or stochastic nature of processes. Under particular conditions for many traffic models, two possible approaches were focused upon in an attempt to realize efficient models within a unified framework; the theory of traffic modelling focused on two major directions, attempting to realize efficient models and a unified framework.
A considerable number of road traffic simulators were proposed, and a particular importance has been given to microsimulation models [
Comparative aspects regarding the characteristics and capabilities of traffic simulators constituted standalone subjects of many studies, taking into account different criteria by the authors. While comparisons referring to traditional traffic [
Recent researches show that the potential of traffic simulators must be increased, in terms of pedestrian safety traffic [
Focusing especially on the necessity of validation and verification of microsimulation traffic models and based on the theory of timed automata [
The rest of the paper is organised as follows: Section
The key elements of the urban road traffic modelling approach to be considered are presented in this section. A careful choice of the theoretical and implementation support was needed to ensure a systematic, flexible, and adaptive solution (Section
Cellular automata were used for the first time in the 40s by Ulam and von Neumann in order to analyse possible behaviours of complex systems. Later, due to a considerable number of studies in the field, the theory of cellular automata was continuously developed, and many derived structures have been used to simulate a large variety of behaviours.
The basic components of cellular automata are cells that are organised in different configured n-dimensional grids. The system evolution can be described by a variety of sets of rules that are defined, taking into account the states of neighbouring cells, and are applied in a preestablished number of phases. A complete formal definition of this theoretical concept is presented in [
Cellular automaton
CA = <S, s0, G, d, F>;
CA(t) = (
The utility of cellular automata was proved in many categories of applications, with the urban road traffic being one of the most important [
Timed Automata were developed as a consequence of the need to model the timing behaviour of certain categories of systems that was not possible, using discrete automata. In order to include time variables [
Consequently, this formalism is well adapted for modelling processes in which the time must be taken into account such as in urban road traffic modelling. In this case, time is important in order to calculate the speed or the acceleration, or to model other various aspects.
A complete formal description of timed automata is presented in [
A timed automaton is a six-tuple
To define the semantics of a timed automaton, a clock valuation is a function
During a run of a timed automaton, all clock values increase with the same speed [
The clocks can be reset to zero (independently of each other) in the transition of the automaton, keeping the time elapsed since the last reset [
Based on the above considerations, the application presented in the paper was developed starting with a model based on cellular automata, which corresponds to the requirements to be a dynamic, discrete space and discrete time formalism and then translating the resulting cellular automata to a discrete automata [
It must be pointed out that even though a large number of formalisms could be used to model timed systems and in particular the proposed traffic system, timed automata were adopted here especially because the behavioural analysis of the considered models was realized using UPPAAL model-checker. This choice has the advantage that the necessity to convert models when the simulation and verification processes are performed is eliminated.
There are several tools used to analyse timed automata and extensions, including UPPAAL, Kronos, and TIMES. These are becoming more and more mature, but they are all exclusively academic research tools.
UPPAAL is a model-checker [
Besides the mentioned advantages, UPPAAL allows obtaining results for simulation and formal verification techniques, using the same environment [
Due to the above specified reasons, UPPAAL was chosen for simulation and formal verification purposes contributing to a more complete understanding of the presented application behaviour.
In order to formalize the desired behaviour of the system modelled with timed automata, it is important to choose a formal logic compatible with the verification tool. Consequently, this will be a timed version of Computational Tree Logic (CTL), a simplified version of Timed Computation Tree Logic (TCTL) [
CTL [
A state machine and its computation tree. adapted from [
This section is divided into two main parts: firstly, a series of issues are dealt with in relation to modelling urban road traffic; secondly, a flexible, adaptive, and systematic approach for solving these issues is presented.
In order to correctly represent urban road traffic, aspects to be considered include modelling the following: modelling different vehicles (cars, buses, trams, trucks, etc.) modelling the driver’s behaviour; modelling road and respective traffic-lanes, considering different sizes for road and lanes; modelling crossroads and upcoming road; modelling car parks, stops, and changing traffic-lanes for different kinds of vehicles (except trams); modelling the velocity and acceleration of vehicles; modelling the space occupied by each vehicle taking into account the size of the vehicle and the speed corresponding to each road (dynamic cell length).
When considering modelling tasks, there is also an interaction between the actors of the system.
The automobiles can come across the following implemented traffic-elements: pedestrian crossings for pedestrians; car parks placed transversely/alongside on the right side of the traffic-lane.
The buses can come across the following implemented traffic-elements: pedestrian crossings; bus-stops inside or outside the traffic-lane.
The trams can come across the following implemented traffic-elements: pedestrian crossings; tram-stops inside the traffic-lane.
For the purposes mentioned above, a modular modelling approach is adopted, using timed automata. This approach considers a modular model for each vehicle, road, lane, crossroad, upcoming road, and physical component.
In fact, this approach seems to be efficient, but it is neither flexible nor adaptive, despite being systematic. The reuse and readaptation of modules are not simple and when, for instance, the size of one road or one lane changes, the modules must be built again, with new specific conditions for each model, for each actor of the system. Another important issue is the fact that a huge number of models (composed of different modules) pose issues when it comes to extending the reachable state space of the overall system model.
In order to deal with this complexity, it was decided to create a model to representing accurately by a matrix the movement of the vehicles and the traffic-elements and being easily extendable allowing addition of more rows or columns. Matrices were used for modelling all parts of these complex systems.
This model is the first model with relevant traffic road rules included along with a significant level of detail. This methodology features the following main characteristics: The physical environment is a one-dimensional grid of rectangular cells, all equal in size (7.5 meters of length). It is a single cell model because each automobile will occupy only one road’s cell for each time iteration, and the cells can have only two possible states: occupied by an automobile or empty. The size of the neighbourhood is the same for each cell; the model is anisotropic because the automobiles only respond to stimuli in front of them. This model is a dynamic system with a limited number of automobiles, buses, trams, and roads that evolve and change in time and space depending on the same rules; only if the cell in front is free, can the different vehicles move along the lane. The time is a stochastic feature and its choice is completely nondeterministic. In an instant t the automobile can circulate in a cell at a velocity of 50 km/h, and in the instant t+1 it can move at 2 km/h. This model considers, for vehicles, the possibility of severe deceleration and acceleration even if the road is completely free in order to model the individual driver’s behaviour. This model can be easily extended. The number of roads and automobiles can be easily changed; the only requirements are to define in global declaration those variables and the matrix for extending the map, to define the inputs in terms of the traffic flow used in the simulation, to define the upcoming road, and to set up the variable for each automobile.
By using this approach, vehicles can circulate irrespectively of the different traffic-elements and interact with them. For example, a pedestrian crossing will influence the behaviour of the automobiles, buses, and trams when pedestrians cross the traffic-lane. If there is also a bus or a tram stop on the next lane, this will not affect an automobile on the road because it does not need to change its behaviour; rather buses and the trams will have to stop. These different behaviours are given by the functions and channels implemented in the road declarations explained in the next subsection.
Different structures are defined in order to represent the complexity of the urban road traffic. Two types of urban road traffic structures are taken into consideration: infrastructure (road, crossroads, traffic signs, parking lots, and pedestrian crossings) and moving vehicles (automobiles, trams, and buses). The formalism adopted to model the considered system is timed automata (TA). UPPAAL environment will be used for performing the simulation and formal verification analysis techniques.
To model and analyse the two types of structures, a two-layered model based on timed automata is considered; one represents the components of the infrastructure and the relations between them (Figure
First layer of the structure.
Second layer of the structure.
Several equations are considered to represent the evolution of each component. Arrays and matrices are built to memorize the components (as arrays) and their (current and future) behaviour and their interactions (as a matrix).
The circulation of the individual vehicles in a traffic flow is described by a set of rules that reflect the movements of cars and the lane-changing behaviour, evolving in time and space.
The characteristics of the defined structures include:
The automobiles can come across the following implemented road-elements: pedestrian crossings; car parks placed transversely on the right side of the traffic-lane; car parks placed on the right side of the traffic-lane; (fixed or mobile) obstacles that can be overtaken if the traffic allows it.
The buses can come across the following implemented road-elements: pedestrian crossings; bus-stops inside the traffic-lane; bus-stops outside the traffic-lane, on the right side of the traffic-lane; obstacles that can be overtaken if the traffic allows it.
The trams can come across the following implemented road-elements: pedestrian crossings; tram-stops inside the traffic-lane; overtaking obstacles is not possible.
Using this formalism to represent urban road traffic and the interactions within it allows us both a general representation and the ability to model complex structures. This way, the model allows any modification of the simulated map without changing the UPPAAL model, only by changing the initialization variables. Since the length of road is different and the matrix cannot be defined with variable number of columns, the value -1 is introduced.
Global declarations include the number of automobiles, buses, trams, and roads, using the function “typedef”. The maximum number of cells that can be defined for a road (the longest road) has been declared by using the variable “maxnoCells”. With this variable and the variable number of road (noS) the matrix “idexSC” was created. This matrix is a map of road cell coordinates. Each line corresponds to a road ID—the ID of the first line is 0 and the ID of the last line is the last road’s ID. The column number one corresponds to the number of cells that each road covers and the following columns are filled with -1 which means that a road’s cell is empty. The first column will be important as it allows the limitation of the road size.
Due to UPPAAL’s limitations it is not possible to create arrays with different sizes, and some of the values of “-1” present in the matrix have no significance. Therefore, it is easy to extend the map and to implement other features in subsequent models.
The choice of the next road in an intersection was implemented with a similar application. First, a new variable “maxNextRoad” (maximum next road) was declared. This variable is equal to three because a crossroad features a choice of no more than three roads usually. In case of a crossroad with more than three streets the problem is managed in a similar manner. Using the variable “maxNextRoad” and with the variable number of the road (“noS”), another matrix “indexMAP” was created. Each line corresponds to a road ID whose first line ID is 0 and whose last line ID is the last road’s ID. The first column contains the number of possible next road choices at the end of the current road, and the other columns have the road’s IDs of the next road.
To implement these road-elements it was necessary to instantiate the matrix “indexSC” for new negative numbers which will have a different meaning from an empty cell, affecting the behaviour of the vehicles. The elements present inside the road (pedestrian crossings, bus-stops inside the road, and tram-stops inside the road) were coded in the respective road ID with a negative number.
However, to create the road-elements outside the road, it was necessary to define adjacent roads to implement a turning movement that a vehicle will execute to go to an adjacent road where
In summary, the different negative digits that a matrix “indexSC” can have will give the instructions for an interaction between a vehicle and a road-element. The meaning (the road-element) of the negative digits is as in Table
Description of the matrix number of cells per different road (with different road-elements).
-1 | Empty cell |
| |
-2 | Bus station inside the traffic-lane |
| |
-3 | Tram station inside the traffic-lane |
| |
-4 | Pedestrian crossings |
| |
-5 | Possible parking lot alongside for automobiles on the right side of the road |
| |
-55 | Border of a parking lot alongside for automobiles on the right side of the road |
| |
-6 | Possible transversal parking lot for automobiles on the right side of the road (right place) |
| |
-66 | Border of a transversal parking lot for automobiles on the right side of the road (right place) |
| |
-7 | Possible transversal parking lot for automobiles on the right side of the road (left place) |
| |
-77 | Border of a transversal parking lot for automobiles on the right side of the road (left place) |
| |
-22 | Bus station outside the right side of the road |
| |
-222 | Border of a bus station outside the right side of the road |
| |
-8 | Road's end and cells with no meaning for the simulation |
With the “indexSC” variable and the variable number of the roads (noS), three matrices “indexMapAUTOMOBILE”, “indexMapBUS”, and “indexMapTRAM” are created. Each line of those matrices corresponds to a road ID, whose first line ID is 0 and whose last line ID is the last road’s ID.
To define the physical environment several variables were defined: “maxnoCells” (represents the maximum length of the road considered, maximum number of cells); “indexSC” matrix (size of noS x maxnoCell+1: this matrix is the description of the physical infrastructure; each line corresponds to a road ID, whose first line ID is 0 and whose last line ID is the last road’s ID and the column number one corresponds to the number of cells that each road has and the following columns are filled with -1 which means that a road’s cell is empty); “maxNextRoad” (maximum number of next roads); “indexMAP” matrix (each line corresponds to a road ID, whose first line ID is 0 and whose last line ID is the last road’s ID; the first column contains the number of possible next roads at the end of the road, and the other columns have the road’s IDs of the next road.); and “
Interactions between layers.
The average speed of the vehicles along a traffic-lane can be expressed by the following equation.
The traffic density is calculated as follows.
Based on these values, the traffic flow is:
The average speed of the vehicles that cross the lane section is expressed by:
Two types of traffic behaviours were implemented: the “car-by-car” model and the free traffic model (this involves that when a car is driving on the road with no constraints and an obstacle emerges, the traffic allows the driver to overtake it).
The “car-by-car” model used in this model is presented in Figure
Scheme of the car-by-car model [
In general, the “car-by-car” models are centred on the following relation.
The vehicle
The stimulus function,
where
Changing the traffic-lanes in order to overtake an obstacle or not is presented in Figure
Changing traffic-lanes model.
After presenting the developed and tested approach, we include a case study in order to allow illustrating the application of the approach and to allow the extrapolation of the obtained results for other similar systems.
One of the key aspects of creating good traffic road models is to define in a precise and unambiguous way the road that will be studied with all relevant information for a correct vehicular circulation.
In order to test and validate the proposed model a case study is considered, and the simulation involves a small group of roads in the city centre of Cluj-Napoca, containing the maximum road-elements that a road can have in order to test and verify the proposed model, as presented in Figure
Representation of the entire road network considered in this simulation.
This section details the physical environment of the simulation, describing the road (number, direction, and length of the traffic-lanes), the location of the pedestrian crossings, bus stations and tram stations, tram railways, the intersections between roads, and the way traffic-lights for road, rail, and pedestrian traffic operate.
The total network length (Figure
The simulated map contains the maximum number of elements that can be simultaneously simulated due to software constraints. Observing a large number of elements, tracking their status over time, is also costly.
In order to analyse some specific road traffic problems from the simulated network, some small parts are simulated and tested separately.
The image in Figure
Structured information for each modelled and simulated road.
| Length of the traffic lane (number of cells) | ||||
| |||||
| Number of traffic lanes - direction | ||||
| |||||
| Next road to follow | ||||
| |||||
| Possible next road to follow (directions) | ||||
| |||||
| Traffic-lane | Right | Left and central | Time | |
Red: | Time | Time | Time | seconds | |
Yellow: | Time | Time | Time | seconds | |
Green: | Time | Time | Time | seconds | |
| |||||
| Traffic-light: | ||||
Green: time [s] | |||||
Red: time [s] | |||||
| |||||
| Location | coordinates | |||
Length | Length of the bus station [m] | ||||
Buses | Buses no. lanes | ||||
| |||||
| Pedestrians’ desire | ||||
| |||||
| Max. speed allowed on this sector km/h | ||||
| |||||
|
The time measurements were taken at midday and at 6 pm, when roads are the busiest. The mode of operation of the traffic-lights taken into consideration in the simulation is the same at both times.
The model is based on templates for roads, traffic-lights, and vehicles (automobiles, buses, and trams, because three different types of vehicles are considered). In the global declaration, the numbers of automobiles, buses, trams, roads, and traffic-lights are first declared, using the function “typedef” according to the model described in Section
The automaton road was simplified because there are only three channels, which means ROAD_STARTS: when an automobile, a bus, or a tram was detected by a sensor at the beginning of a road and the road is free of any automobile; UPDATING_CELLS: when an automobile, bus, or tram or more than one vehicle on the road are moving; several functions were created in order to model the driving behaviour on the road; ROAD_ENDS: when an automobile, a bus, or a tram was detected by a sensor at the end of the road and it leaves the road.
The automaton road is the “brain” of the simulation, thus storing all the information regarding traffic conditions, the set of rules, and the subsequent transition rules.
The automaton automobile has three places: OUT_of_the_ROAD_START_MOVING: when an automobile is moving towards the beginning of the road; MOVING_INSIDE_the_ROAD: when an automobile was detected by a sensor and is moving on the road; OUT_of_the_MAP: when an automobile was detected by a sensor and there is no possible next road and it exits the considered map.
The bus and tram automatons have structures similar to that of an automobile, but they also feature a predefined path on the map.
The traffic light automaton has three states defining the three colours (red, green, and yellow). Yellow can be skipped, consequently reducing the loop to only two colours (red and green).
In the road considered in the case study, traffic behaviour is not exclusively influenced by the state of the road cells, as it was considered in the previous model. The vehicles interact with other road-elements present in the road such as pedestrian crossings, bus stations, tram stations, and traffic-lights. In the studied model, the interaction between vehicles and the road-elements contained in the group of the roads was taken into consideration.
The automobiles can come across the following implemented road-elements: pedestrian crossings; parking lots placed transversely on the right side of the traffic-lane; parking lots placed alongside the right side of the traffic-lane; traffic-lights.
The buses can come across the following implemented road-elements: pedestrian crossings; bus-stops inside the traffic-lane; bus-stops outside the traffic-lane, on the right side of the traffic-lane; traffic-lights.
The trams can come across the following implemented road-elements: pedestrian crossings; tram-stops inside the traffic-lane; traffic-lights.
To implement the considered map, 74 traffic-lanes, 480 automobiles, 30 buses, and 18 trams were declared. Afterwards, the traffic-elements and the predefined routes for buses and trams were implemented. Given the large volume of interactions between vehicles, road-elements, and roads, the entire map was divided into several small networks in order to simulate and analyse each modelled feature.
During the simulation and validation process, the authors faced several problems related to computational power that UPPAAL needed. The allocated memory that UPPAAL could use during the simulation was restricted and could not be extended. To overcome this problem, the authors defined several scenarios to validate all the considered traffic-elements. First the roads from the original case study were considered (74 traffic-lanes, 90 automobiles, 10 buses, and 1 tram) in order to verify and test all the already presented interactions. In that map, the road-elements were not considered because of the limitations of UPPAAL (e.g., pedestrians, car parking, drivers’ behaviour, and dynamic cell length). Another simulation was performed in order to study the interaction between traffic-elements. This simulation included a road which contained all the different road-elements (pedestrian crossing, bus stop, and tram stop cells within the road and dynamic cell length).
Figure
Time intervals needed for an automobile to go through a sequence of cells.
Figure
Time intervals needed for a bus to go through this sequence of cells.
Figure
Time intervals needed for a tram to go through this sequence of cells.
Formal verification is used in this work as a complementary technique to simulation. In fact, simulation considers some possible scenarios of evolution of the developed models, but formal verification checks all possible behaviours of those models. Due to this reason, the validation of the presented approach seems important by using this exhaustive technique.
For formal verification of the model it is enough to know that, in the UPPAAL version, A is the universal quantifier on paths (for any path. . .), E is the specific quantifier on paths (there is a path. . . .),
In UPPAAL, in the option Verifier, several queries to check the correct behaviour of this model were implemented. The initial values and variables taken into consideration for the formal verification of the map in Figure number of automobiles = 90; number of buses = 10; number of trams = 1; number of roads = 9; number of road cells per road = indexSC novis
Cellular automata: automobile (idA, time_per_road, time_per_cellA); bus(idB, time_per_road, time_per_cellB); tram(idT, time_per_road, time_per_cellT); road (idS, GLOBAL, novis); traffic-lights (idSem, tR, tY, tG).
A list of queries was generated in order to verify various properties. Some of the queries were built in order to double check some important traffic behaviours. The response of the query could be either “yes” or “no”. Based on this response, a report of a traffic simulation scenario can be generated.
The following properties can be verified and validated: Properties that need to be verified: greater than a minimum value E E<>forall (i : idA) automobile(i).time_per_road(idS) > 0.5 Properties that need to be verified: smaller than a maximum value E E<>forall (i : idA) automobile(i).time_per_road(idS) < 27 Properties that need to be verified: greater than a minimum value and smaller than a maximum value E E<> (forall (i : idA) automobile(i).time_per_road(idS) > 0.5 Properties that need to be verified: smaller than a maximum value, greater than a minimum value, greater than a minimum value, and smaller than a maximum value (automobile) E E<> automobile(idA).time_per_road(idS) > 0.5 E E<> automobile(idA).time_per_road(idS) < 27 E E<> (automobile(idA).time_per_road(idS) > 0.5 Properties that need to be verified: smaller than a maximum value, greater than a minimum value, greater than a minimum value, and smaller than a maximum value (bus) E E<> bus(idB).time_per_road(idS) > 0.5 E E<> bus(idB).time_per_road(idS) < 27 E E<> (bus(idB).time_per_road(idS) > 0.5 Properties that need to be verified: smaller than a maximum value, greater than a minimum value, greater than a minimum value, and smaller than a maximum value (tram) E E<> tram(idT).time_per_road(idS) > 0.5 E E<> tram(idT).time_per_road(idS) < 27 E E<> (tram(idT).time_per_road(idS) > 0.5 Properties that need to be verified: if the vehicles leave the road E<> forall (i : idA) automobile(i).response = -1 E<>forall (i : idB) bus(i).response = -1 E<> forall (i : idT) tram(i).response = -1 Properties that need to be verified: if the time needed to travel through a cell is small or greater than the predefined values, or if it is in a fixed interval E E E Properties that need to be verified: if the number of vehicles does not exceed the size of each road E E E E E E … Properties that need to be verified: determine the load of each road during the simulation process E<> ((GLOBAL > 0 && GLOBAL <=10) && ((novis E E<> ((GLOBAL > 0 && GLOBAL <=10) && ((novis E E<> ((GLOBAL > 0 && GLOBAL <=10) && ((novis E …
In these queries inserted in UPPAAL, maximum values for validation variables taken into consideration are the values presented at the beginning of the simulation scenario. The minimum time is the multiplication of 0.5 time units by the number of cells contained in the first column of the indexSC
This structuring modality of the presented simulation scenarios was chosen to prove the capacity of the system to simulate in detail the behaviour of each traffic component in a realistic context. During different verification processes, depending on the reachable states which are taken into account for investigation purposes, the element types of the simulation scenario have to be changed in a corresponding manner. At the same time, because not all the existing traffic-elements influence the considered evolution of the system on the interest state, the number of implied traffic components can decrease significantly, extending the urban area in which the verification process is applicable from the point of view of UPAAL limitations.
Cellular automata allow the observation of different phenomena, managing to break down components into individual variables. They allow the understanding of how local changes affect the whole grid of cells. The formalism of timed automata, due to their elementary structure, is appropriate for a modular approach, and the resolution (level of detail) and system size obtained (the network size that needs to be covered) are appropriate to the model proposed. In the context of urban traffic, cellular automata based on microscopic models have the capacity to simulate in detail all the elements presented in this environment. The quantity of traffic-elements implemented generates a model containing a large number of evolutionary rules and interactions.
This model has a high flexibility in accordance with the environment where it will be applied, due to the fact that it is implemented on a large group of road-elements and possible interactions. The stimuli created for each vehicle will depend on the road-elements contained in the road and the traffic conditions, due to the modular approach used.
In the context of formal verification, this model presents all the possible scenarios that can occur, even the ones that are physically impossible, and the presented results allow the maximum level flexibility.
It was demonstrated that UPPAAL software is capable of dealing with low/medium complexity models, but for the implementation of high complexity models it is limited, due to the computational power that UPPAAL can accesses and cannot be extended. Taking its limits into consideration, the application proved to be a success in this context.
The new road traffic simulation approach presented in this paper is based on the theory of timed automata and UPAAL model-checker. It was able to overcome the disadvantages regarding the lack of adaptability and flexibility of some previous urban road traffic models and to respond to the increasing necessity to verify the behaviour of traffic simulation models.
The behavioural characteristics of a representative and complex urban road traffic system are rendered in a realistic manner, considering the interactions between the infrastructure component and the moving vehicles. A two-layered timed automata based model was developed for this purpose. Unlike existing systems, this approach offers real extension possibilities, easily applied in practice due to the modular components based on matrix structures. They can be extended by adding a corresponding number of rows or columns. All the modifications of the simulated map could be performed simply by changing the initialization variables, without the necessity of modifying the UPAAL model. A case study highlighted some limitations of the UPAAL model-checker, more suitable for low/medium complexity models.
Features of this work can be developed and explored more deeply, providing room for new perspectives in this domain. Taking into consideration the scenario in which this approach will be implemented, some improvements could be made in terms of the specific problem and of the application itself.
The data used to support the findings of this study are included within the article.
The authors declare that there are no conflicts of interest.
This research was carried out under European funding, Structural Projects: POSDRU/89/1.5/S/52603-4D-POSTDOC.