IN
DEGREE PROJECT ELECTRONICS AND COMPUTER ENGINEERING,
FIRST CYCLE, 15 CREDITS ,
STOCKHOLM SWEDEN 2019
Evaluating the Effects of using a
Fuzzy Controller in Timetable
Generation for Commuter Rail
Services
Prestandautvärdering av
tidtabeller genererade med
fuzzy control för
pendeltågstafik
Authors
Anna Söderberg Johan Wieslander
Electrical Engineering and Computer Science (EECS) KTH Royal Institute of Technology
Examiner
Örjan Ekeberg Stockholm
KTH Royal Institute of Technology
Supervisor
Jörg Conradt Stockholm
Abstract
Scheduling trains is a hard problem where current solutions typically create timetables that create undesirable amounts of delay for the trains that use them. This study considers the fact that conventional timetables, which only use fixed intervals to schedule trains, might not be optimal for minimising the delay and travel time of passengers. In this study, we compare this ”simple” timetable with timetables generated via a fuzzy controller which has access to information about the flow of passengers throughout the day. The hypothesis is that this fuzzy controller therefore becomes more ”intelligent”. We evaluate the performance using a custom-built simulator that measures the average delay and travel time of the passengers. We conclude that the fuzzy controller can generate timetables that quickly adapt to passenger demands and show favourable resource usage over the simple timetable. However, more research is needed on the input variables and their usage within the fuzzy controller to further optimise the performance.
Keywords
Sammanfattning
Schemaläggning av tåg är ett svårt problem och nuvarande lösningar skapar ofta tidtabeller med oönskade mängder förseningar. Den här rapporten behandlar faktumet att enkla tidtabeller, som enbart använder fasta intervaller för tågens avgång, kanske inte är optimala för att minimera antalet förseningar samt resenärers restid. Den här studien jämför enkla tidtabller, med fasta intervall, med tidtabeller som skapats av en fuzzy controller som har tillgång till information om passagerarflödet. Hypotesen är att fuzzy controllern på så sätt blir mer intelligent. Rapporten utvärderar hur bra tidtabellerna presterar med hjälp av en simulator som mäter genomsnittlig försening och restid för passagerarna i simulationen. Slutsatsen som dras är att en fuzzy controller kan generera tidtabeller som kan anpassa sig till passagerarflödet samt att denna uppvisar gynnsam resursanvändning i jämförelse med den enkla tidtabellen. Dock framhävs behovet av ytterligare forskning på indatavariabler och dess användning inom fuzzy controllern för att vidare kunna optimera dess prestanda.
Nyckelord
Contents
1 Introduction 1 1.1 Background . . . 1 1.2 Problem statement . . . 2 1.3 Scope . . . 3 2 Theoretical Background 5 2.1 Timetables . . . 5 2.2 Delays . . . 5 2.3 Fuzzy control . . . 6 2.4 Related work . . . 9 3 Method 12 3.1 Data generation . . . 12 3.2 Metrics . . . 17 3.3 Simulation . . . 18 3.4 Simple timetable . . . 22 3.5 Fuzzy control . . . 22 3.6 Normalisation . . . 26 3.7 Method discussion . . . 28 4 Result 34 4.1 Average delay . . . 34 4.2 Latent passengers . . . 354.3 Average travel time . . . 37
4.4 Additional rules . . . 40
5 Discussion 43 5.1 Travel time . . . 43
5.2 Delay . . . 43
5.3 Latent passengers . . . 45
5.4 Comparing different rule bases . . . 45
5.5 Lower passenger magnitudes . . . 46
1 Introduction
The global population is growing steadily which has implications for the population sizes of cities [17]. If cities are to continue to grow, as a consequence of an increased global population, then the demand on the local transport systems inside the cities will increase. Today, trains in Sweden are often late [5], which causes problems for society and for the everyday passenger [4]. By scheduling trains in a smarter way, some of these problems can be mitigated [5].
1.1 Background
Scheduling trains and controlling railway systems is a commonly researched problem in the literature [18]. The interest in making railway systems more efficient has many origins. Unlike traffic on roads, railway traffic is limited by the railway network’s capacity. Many vehicles share the same, limited, resources: freight transports, regional trains, and commuter trains. The costs of these methods of transportation can be measured in the amount of diesel or electricity used by the freight trains [7], or in time spent by the passengers of regional or commuter trains [18][2].
The most important problem in train scheduling is how to create the most effective schedule of trains so that no collisions occur and the capacity of the tracks is not violated. This problem is NP-hard [2] and there are many heuristics, strategies and algorithms developed to solve the problem [2][3][7][18].
However, the efficiency of timetables for passenger trains receives less attention in the literature. Many railway control systems are still dependent on competent train dispatchers - competent and experienced humans that create the timetables and manage traffic [18]. Yang, Li, and Gao [18] states that ”how to make train timetables scientific is still an important issue today”.
control over some system [9].
Fuzzy control is a form of intelligent control which employs the use of so-called
fuzzy rules. This type of control system mimics how a smart human would control
the system [9]. A fuzzy controller could, therefore, be seen as a reasonable first step when introducing intelligent control to a system that is traditionally controlled by a human.
The use of fuzzy control for timetable generation seems to be a new idea, based on the fact that currently the literature and research on the topic is limited or nonexistent. Passino [9] states that ”there is a definite need for experimental research (especially in comparative analysis and new non-traditional applications)”, in an overhaul of use cases for intelligent control, which is why exploring the use of a fuzzy controller for timetable generation is interesting.
1.2 Problem statement
This thesis presents a comparison of the simulated performance of timetables for local rail generated by two different methods. The first method is the traditional, ”simple”, method of generating timetables that uses fixed intervals. The second method employs a fuzzy controller in conjunction with data about when passengers arrive at their departure stations, to generate a timetable that more closely follows the flow of passengers. By using this data and an understanding of the data, a fuzzy controller might be able to generate timetables that achieve better performance on metrics such as delay and travel time. The following research questions are therefore posed.
1.2.1 Research questions
How do timetables generated by a fuzzy system, with the flow of travellers as input, perform compared to a simple timetable1? How do the rules of the fuzzy
controller impact performance?
1.3 Scope
In this paper, we will concern ourselves with timetables generated via two methods: a simple way with set intervals and a fuzzy controller. These timetables will be tested and evaluated on a simulator that simulates trains and passengers during the course of 24 hours. We will only consider 24 hours in this paper since trends in passenger flow can be expected to be repeated the next day in a similar manner.
1.3.1 Simulation environment considerations
When simulating, we use the same simulation environment as well as the same speed and capacity of the trains, for each simulation. This is to put more emphasis on the actual methods of timetabling since that is what we aim to measure. By keeping the environment the same it is easier to compare the methods.
Further, when creating timetables, no railway limitations or capacity constraints, are taken into consideration. Defining such limitations to our simulation environment would add bias to the result. It would then only surely apply to environments with such limitations.
The trains move at a fixed speed on these rails and we, therefore, do not simulate any switches, speed limits, accelerations or other trains trafficking the railway. This is since the most important thing for calculating delay and travel time is when the train actually arrives at a station and that is mostly dependent on when it departed from the previous station.
1.3.2 Trains
2 Theoretical Background
2.1 Timetables
Local traffic services typically employ the use of simple timetables for scheduling the traffic [13]. These timetables use a simple method of scheduling the traffic services by scheduling a fixed amount of traffic resources, such as buses or trains, interspersed at a fixed interval [6]. These are the timetables that most people are familiar with, e.g. if we want to have three trains in an hour then one train might depart at 14:15, another at 14:35 and the third at 14:55. This does not necessarily take into consideration the movement patterns of the travellers at each station nor does it take into consideration surges of people happening at a specific time, e.g. when people at a certain station might get off work or school.
These sudden peaks can cause a buildup of passengers at stations that are waiting for the next departure [6]. The buildup of passengers at a station will extend the total travel time for these passengers since they are simply awaiting the next departure. If there instead was a train exactly when most of the passengers arrive then the total travel time would be minimised for these passengers.
2.2 Delays
2.3 Fuzzy control
Fuzzy control is a technique in intelligent control. It uses so-called fuzzy rules to mimic how a competent human would control a certain system. The fuzzy rules form the rule base of the fuzzy controller. The inputs to the fuzzy controller are real, continuous values which cannot be handled by the rule base. Therefore the input needs to be fuzzified, using a fuzzification process that converts the continuous input to fuzzy values. The fuzzy values can then be manipulated by the fuzzy controller using a rule base. This results in fuzzy output which is then defuzzified to real values again via the defuzzification process [9].
In general, a control system uses rules to decide what to do with its input [9]. It uses traditional logic to compose these rules using statements like ”if the temperature is above 10 degrees then it is hot”. A regular control system uses ones and zeros as the inputs for deciding on whether the input is or isn’t, hot in this case. Temperature is therefore either hot or cold but never anything in between, when using a regular controller.
2.3.1 Fuzzy sets
Fuzzy control uses fuzzy sets. These are special sets with a membership function, that gives a degree to which an object is a member of the fuzzy set [19]. In contrast, in a normal set, an object is either in the set or not. In a fuzzy set, there is a ”continuum of grades of membership” [19].
Given an object and the task to decide whether the object belongs to the set or not, a traditional set would give the response ”yes” or ”no”. However, if using a fuzzy set the answer is instead a real value between 0 and 1, giving the grade to which the object belongs to the set [19]. An example of a membership function for hot temperatures can be seen in Figure 2.1. Since real world concepts rarely can be described using simple binary relations, fuzzy sets allow for more complex models that might more accurately represent the real world [19].
For example, if the task was to classify temperatures being either hot or cold,
Figure 2.1: Membership function for a fuzzy set defining hot temperatures belonging to the set cold. However, a fuzzy set could classify 18 degrees as being 80% hot (having a grade of 0.8) and 15% cold (a grade of 0.15). The fuzzy set in Figure 2.1 would classify 18 degrees as being 80% hot.
2.3.2 Fuzzy rules
(a) Membership function (b) Membership function after being capped
Figure 2.2: Membership function for a fuzzy set defining ”high” happiness
To evaluate a fuzzy rule, the first step is to get the grade to which the input belongs to the set. This step is called fuzzification since we are taking a concrete input and creating a fuzzy representation of it. Continuing the example, in this case, this would result in the temperature 18 being given the grade 0.8. That would then mean that the fuzzy set for high would get ”capped” at that maximal grade 0.8 [19]. The result of capping the set can be seen in Figure 2.2b.
The next step is to get a concrete output value from the fuzzy set of high for happiness. This process is called defuzzification since we are taking a fuzzy set and producing a value from it that we can use in our program [9]. In this example we will assume that a person’s happiness can be measured on a scale from one to ten, it is defuzzified according to the fuzzy set in Figure 2.2a. A common method of defuzzification is to use the ”center average” of the capped fuzzy set [9]. This would result in a happiness value of 9 in this case.
2.3.3 Fuzzy controller
Since fuzzy control can be classified as a heuristic [9], due to it not relying on a defined mathematical model, it can prove useful for problems where a mathematical model is difficult to form. Such a problem is generating a timetable from passenger data which is why we chose to use a fuzzy controller for this thesis.
2.4 Related work
2.4.1 Scheduling trains
There are many reports in the literature that address the problem of scheduling trains [18]. Many of them regard the problem of creating an optimal timetable where the capacity of the tracks should not be violated while creating the optimal schedule for the trains on the railway. Others focus more on the problem of re-scheduling the traffic after disturbances. For both problems there are multiple techniques developed to handle them [2][3][7][18]. The strategies developed are thoroughly described, but since this thesis will not address the same problem -scheduling trains without violating the track capacity, those algorithms will not be described here. The design choices made by these studies were the main focus when considering their work.
Dorfman and Medanic have researched strategies for scheduling trains on single
line railways [7] as well as on railway networks [3].
In the paper considering single line scheduling, Medanic and Dorfman [7] present a ”greedy travel advance strategy” for generating train schedules. The strategy is described with the advantages that it, apart for generating a complete schedule, also can modify the schedule if a train is late or there is some ”temporary speed restriction” or a new train needs to be added. When developing their strategy, they do discuss variable velocity of trains, however, they assume that the velocity
of the trains is constant on sections of the line, in their model. When evaluating
the performance of their algorithm, they also use a 24 hour period and ”numerous examples” with the metrics time to clear the line, total delay of all trains and
Regarding the generation of schedules for railway networks, Dorfman and Medanic [3] presents a ”local feedback-based travel advance strategy” as an extension of the greedy strategy presented in the previous report. This strategy makes it possible to schedule trains on railway networks with the same advantages as described for the single line strategy.
Yang, Li, and Gao [18] also present a strategy for the problem of scheduling trains on a single line railway, using a branch-and-bound algorithm. However, the passenger demand is not considered in absolute numbers but as fuzzy values since ”the number of passengers getting on/off the train at each station is actually uncertain during different periods”. The metrics for evaluating the result in this study are total time and total delay of the fuzzy passengers. The authors state that while there are many techniques developed to create timetables and train schedules, the experience and knowledge of the train dispatchers are still important in solving conflicts that occur in the network.
Caprara, Fischetti, and Toth [2] presents an approach to model the Train Timetabling Problem. The paper ”aims at determining a periodic timetable for a set of trains that do not violate track capacities and satisfies some operational constraints” [2]. The problem considers a single line railway that links two
major cities with multiple smaller stations in between. The authors present a
problem formulation using a multi-graph as well as a heuristic method to solve the problem. They also present proof that this particular problem is NP-hard.
2.4.2 Simulating railway systems
for the trains. These delays can both be in the form of planned delays, such as planned infrastructure-related work, and delays from the trains, either when arriving/departing from a station or during the actual travel itself [8].
According to the study from KTH [8], a drawback of using a complex simulation tool like RailSys is that it is very time consuming to build up the realistic model, due to the vast number of parameters, and can then also take several hours to complete one single run of the simulation [8]. A complex simulator like RailSys might therefore not be ideal for running multiple simulations in constantly changing environments. However, useful data can still be extracted from the test results and the study from KTH found that, using a simulation in RailSys, it is not feasible for the Swedish railway agency SJ to reach their punctuality goals [8].
3 Method
The method for this thesis consisted of generating timetables with two different strategies and using a simulator to evaluate how the timetables would perform.
3.1 Data generation
Two types of data were needed for the simulations: environment data and passenger data. The generation of these data is described in this section. The simulator is further described in section 3.3.1.
3.1.1 Environment data
The environment files used in the simulator consisted of a set of stations along with the distances between them and the speed and capacity of the trains used in the environment. Figure 3.1 shows how the environments were filled in by hand in the GUI of the simulator. Each environment was saved to a file and could be reused to create consistency in the simulations.
The main environment used to test the time tables is displayed in Figure 3.1. The working name of it was ”10x1000” because it consisted of 10 stations with 1000 meters between each station. The capacity of the trains was set to 500 passengers. The speed of the trains could be regulated but to simplify it was kept at 1 m/s, which is 3.6 km/h.
Figure 3.1: The environment file with 10 stations with 1000 m between each other, a train speed of 1 m/s and a train capacity of 500 passengers. View from the GUI of the simulator, described in section 3.3.1
Figure 3.2: ”Popular visiting hours” at Stockholms Östra on Tuesdays, from Google Maps (screen shot 2019-04-09) [12]
3.1.2 Passenger data
When evaluating the timetables a passenger distribution over 24 hours was used, presented in Table 3.1. The distribution state the percentage of the maximum amount of passengers that there can be in an hour, for each hour. In the simulator, the passenger distribution was used to generate the arrival time of each passenger to a station in the simulation, which is further described in section 3.3.1.
Figure 3.3: Spline points for a passenger distribution
3.1.3 Splines
The passenger data was then generated using a spline interpolation. By using a spline interpolation with points being defined with hours of the day on the x-axis and the number of passengers arriving at a station on the y-axis, generation of time tables was simple. This is because with a spline interpolation you can define a very intricate curve using only a few points. An example of such points can be seen in Figure 3.3.
These points can then be interpolated to create a smooth curve by fitting several cubic polynomials to these spline points [15]. We used a cubic Hermite spline [14] to generate the coefficients for these polynomials. To generate the final value for a given time, the algorithm finds the two closest spline points to the time point and evaluates the polynomial given by the two spline points at the given time [15]. The result is showed in Figure 3.4a.
Finally, the value outputted by this spline gets a randomly distributed Gaussian noise added to it to make it more random and therefore more representative of actual human behaviour. The maximum random noise value was set at 0.5. This produces a more ”jagged” curve which can be seen in Figure 3.4b.
(a) Smooth curve (b) Curve with added Gaussian noise
Figure 3.4: Curves generated from spline points
Table 3.2: Factors used to scale the ”height” of the passenger distribution of the stations, each value was randomly assigned to one of the 10 stations
0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95
number of stations (s) and the maximum passenger level (max) of the simulation, also called passenger magnitude, described in section 3.3.3.
v = max∗ p∗ factor 100 ∗ 1 s ∗ 1 60 (1) 3.1.4 Scaling
To create some variations in passenger flow between stations each station got its passenger distribution values, see Table 3.1, scaled with a random factor (factor) from Table 3.2. This was to keep the total passenger amount on the line consistent over simulations, while getting different distributions between stations.
3.2 Metrics
To measure how good a time table was, we used two main metrics: travel time and delay. These two metrics come in two varieties. One is the accumulated value for the entire system and one is the average of the value. The average is calculated by taking the total divided by the total number of passengers in the passenger distribution. We also used a third metric called latent passengers which is described and discussed in section 3.2.3.
Delay was chosen since delayed trains is generally a big concern in cities [4]. However, delay alone is not enough since if you only had one train on a rail service every day, the delay might be low but waiting time would be high. Additionally, if no trains are scheduled for a rail service then both delay and travel time is low which is why we introduce the concept of latent passengers. Together, these three give a comprehensive picture of how well a schedule is performing. We specifically choose to focus on these key metrics as they are the most relevant to our research question.
3.2.1 Travel time
The travel time is calculated from when a passenger arrives at a station to when the passenger disembarks from the train. If the passenger is still on a train when the simulation stops the travel time is calculated as the time from the passenger’s arrival to the end of the day (the current time at the end of the simulation).
3.2.2 Delay
amount of latent passengers, the effects of this will be negligible and the results still valid.
3.2.3 Latent passengers
The third metric used was latent passengers. This was the number of passengers that are standing at stations, awaiting the next train at the end of the simulation. Since we only simulated 24 hours, it might be that some passengers arrive at a station after the last train of the day has departed. This would mean that, in our simulation, those passengers would never embark on a train. However, in a real world scenario, they would just take the next train, on the next day.
Latent passengers as a metric might, therefore, seem redundant. However, in our testing we found it to be a valuable tool for validating a solution. This is because it is entirely possible to have no delay and no travel time if there are no passengers riding any trains. This solution might, therefore, seem good at first glance but upon inspecting the number of latent passengers one would find that
all passengers are latent passengers.
3.3 Simulation
The simulator evaluated the timetable by doing a 24-hour run and outputting the metrics described in section 3.2.
3.3.1 Simulator
The passenger distributions and environments that were used in the simulations were generated separately and saved to file. This made it possible to compare the results of the simulations by keeping the environment consistent and changing other variables.
Before each simulation, the data from the environment file and the passenger distribution were loaded into the simulator. The stations of the environment file were created and given the corresponding distance to each other. The passenger distribution seen in Table 3.1 was used to create a set of departing passengers for each station of the environment, described in section 3.1.3.
The simulation is run by performing small simulation steps of one second at a time. Each simulation step, the trains that are loaded into the simulator are updated as well as the passengers. If a passenger disembarks from a train, relevant metrics are measured and recorded to be reported at the end of the simulation run. Passengers that are yet to be loaded into the simulation are kept in a queue that is checked every simulation step.
3.3.2 Trains per hour
The trains per hour variable was used to create the simple timetable in the way that every rail line got that many trains for each hour. If there were 2 trains per hour then the trains departed at 30-minute intervals throughout the day, equalling a total of 48 trains over the course of the day. In the fuzzy system case, the trains per hour variable was instead used to calculate an upper limit to the number of trains to be used so that the number of trains was the same for both the fuzzy timetable and the simple timetable.
For every combination of the two variables, trains per hour and passenger amount, the program generated a passenger distribution. In the simple timetable case, the timetable stayed the same no matter the passenger distribution. However, in the fuzzy case, this passenger distribution was used to create a timetable using the fuzzy controller. The simulation was then run and the results stored. Since the passenger distribution generation has a random factor added to it this process was then repeated 100 times and the average value for all the dependent values for all 100 runs was the value that ultimately got plotted for that combination of the dependent variables.
The range of values tested, for the number of trains per hour, ranged from 1 to 8 with a step of one train as well as ranged from 1 to 37 with a step of eight trains.
3.3.3 Passenger magnitude
The passenger distribution used in the simulation, given in Table 3.1, gives a percentage of the maximum passenger magnitude. The passenger magnitude can be described as the maximum amount of passengers that can enter the stations in the simulation in an hour. It was designed so that the distribution inspired by Figure 3.2 could be used. The magnitude can be varied to test the system under different loads. In this study, the timetables were tested for different values: 25 000, 50 000, 75 000 and 10 0000, as well as lower magnitudes of 10 000, 15 000, 20 000 and 25 000.
Table 3.3: Passenger magnitudes and the resulting total amount of passengers in the simulation for each magnitude
Passenger magnitude Passengers in simulation
10 000 43 120 15 000 67 686 20 000 92 169 25 000 116 617 50 000 239 630 75 000 363 237 100 000 486 899 3.3.4 Environment
The environment used for all tests was an environment consisting of ten stations with equal distances between all stations, described in section 3.1.1. The distances were set to 1000 and the speed of the trains was set to one m/s. This meant that the travel time between stations was fixed at 1000 seconds or 16 minutes and 40 seconds. The holding time for each station was set to one minute. There were two rail lines generated, one for each end station going to the other end station. The boarding time of a passenger was set to one second.
3.3.5 Passenger boarding
In the simulation, each passenger took a certain amount of time to board a train. This time was the same for each passenger. The boarding process started right after the train had arrived at a station. If a new passenger would arrive while the train was being held up by other boarding passengers, the new passenger would also get a chance to board the train.
3.3.6 Train holding time
If the train accumulates delay so that the train arrives after the scheduled arrival time plus holding time then the train will leave as soon as possible. That is, the holding time is baked into the schedule. This means that the holding time is not added on to the arrival time of the train, but rather added onto the
expected/scheduled arrival time of the train.
3.4 Simple timetable
The simple time table was used as a reference for how a common time table performed in the simulation. The time table consists of some fixed number of trains per hour, evenly spaced, during the entire 24-hour interval. Each train departs from one of the end stations, through all stations in the environment, to the other end station. The time table takes into consideration the speed and capacity of the trains stated in the environment as well as the distance between stations.
For example: if the number of trains per hour is 4 in a simulation there will be
4∗ 24 = 96 trains going in each direction each ”day”, each 24-hour interval, which gives a total of 2∗4∗24 = 192 trains in a simulation. In this simulation, there will be a train departing in each direction every 15 minutes from each station. Likewise, if the number of trains per hour is 2 there will be 48 trains in each direction, 96 trains in total and the trains will depart every 30 minutes during the ”day”.
3.5 Fuzzy control
To create a time table using a fuzzy controller the passenger distribution over the course of 24 hours, see Table 3.1, was used as input. This data is what made the fuzzy controller ”intelligent” and gave it the advantage over the simple time table.
considered it most important that a train arrived. An example of such a heatmap can be seen in Figure 3.5.
Figure 3.5: A heatmap for station 1 generated from passenger data
This heatmap was then used to create a timetable using a normalisation method, described in section 3.6. This normalisation method made sure that the number of trains did not exceed the amount of the simple time table. That way the two methods were comparable in terms of how effective the time tables were since they both had the same train usage.
3.5.1 Fuzzyfication
The fuzzy controller used two distinct input variables for the rules in the rule base, described below.
• passengers_prev_15 - total amount of passengers at the station in the
previous 15 minutes
• passengers_next_15 - total amount of passengers at the station in the
next 15 minutes
Since the complete passenger distribution over the course of the entire 24 hours was accessible, these variables could easily be extracted from the data.
3.5.2 Rule base
• IF passengers_prev_15 IS high THEN num_trains IS high
• IF passengers_prev_15 IS low AND IF passengers_next_15 IS low THEN num_trains IS low
3.5.3 Fuzzy sets
As described in section 2.3.1, fuzzy sets are used for fuzzyfication of the input to the fuzzy controller, and for defuzzyfication of the output from the fuzzy controller. The fuzzy sets used for the rule base of the fuzzy controller are shown in Figure 3.6 and 3.7.
(a) Fuzzy set for ”low” values (b) Fuzzy set for ”high” values
Figure 3.6: Fuzzy sets for low/high values of accumulated passengers in the last 15 minutes
(a) Fuzzy set for ”low” heat (b) Fuzzy set for ”high” heat
Figure 3.7: Fuzzy sets for low/high values of heat
Figures 3.7a and 3.7b show representations of the fuzzy sets used for defuzzifying the output into a heatmap. We define values for what high and low heat are which will become the output of the fuzzy controller which, in turn, will go through the normalisation process.
3.5.4 Additional rules
We also decided on testing what would happen if we were to introduce another rule into the controller. This rule will use another input variable, called passenger
count, which is just the passenger count for just the current minute (not
accumulated over several minutes) as input. This input variable is fuzzyfied using the set in Figure 3.8. This new rule base, consisting of the standard rule base and the additional rule, will be referred to as the ”comparison rule base” in section 4.4.
This set is composed to have a different shape (a peak rather than a ramp) to test different behaviours. Since this has the form of a peak it also has an end where it will stop being effective. The peak of the membership function is at 50 since the peak of the ramp in Figure 3.6b is at 800 and 800
15 ≈ 50. The rule we introduce and test with this fuzzy set is going to be the following:
Figure 3.8: Fuzzy set for high current passenger value
The new rule will be used with the new set shown in Figure 3.8 for fuzzyfying and will use a set similar to that in Figure 3.7b for defuzzyfying only that this new set, called extra high, goes all the way to 30 on the x-axis, meaning that it will have the ability to influence the heatmap more.
The reasoning behind this additional rule is to see if it would be wise to add a rule which can create small spikes in the heatmap when there are a lot of passengers. Since it only takes the current passenger count into account it might be more reactive to changes as it does not consider what has happened in the last 15 minutes or upcoming 15 minutes. It might create a more spontaneous behaviour and with this rule, we want to evaluate if that can result in better performance.
These rules will be evaluated on the lower passenger magnitudes since any small differences will be easier to spot there since the outliers might have more influence over the data. To observe any longer trends we will also evaluate these rules using the extended range of train values, from 1 to 37.
3.6 Normalisation
to as normalisation since it takes the heatmap and schedules trains thereafter and ensures that the total number of trains don’t exceed the total number of trains used in the simple time table.
The normalisation process is done in two steps. The first step looks at the heatmap and determines how many trains need to be scheduled for each hour. This gives a limit to how many trains may be scheduled for each hour of the day. This ensures that there still are some trains on the hours of the day when traffic is not so high. As long as those hours have an area in the heatmap graph they will receive trains.
Figure 3.9: Heatmap for station 1 after the normalisation process
3.7 Method discussion
Here we discuss some of the design choices that have been made in the process of making this project.
3.7.1 Timetable generator selection
The two methods of generating timetables used in this paper are the simple timetable, outlined in section 3.4, and fuzzy control, outlined in section 3.5. We use the simple timetable model since it is most closely related to the traditional method of scheduling trains using fixed time intervals seen for example on Svealandsbanan [6]. According to Lindfeldt [6] this rigidness of the timetables is a major contributing factor for the delays caused on the Svealandsbanan. This makes this model viable for comparison since it is realistic and also create problems with delay, which is a current problem in society [4].
When selecting fuzzy control as a method to compare to we looked for methods of intelligent control since intelligent control systems can be useful in situations where humans traditionally have been involved [9]. Since the simple timetables are traditionally generated by humans, intelligent control might help in construction or even replace the need for human involvement.
made by humans [10] it combines intelligent data-based knowledge with human expertise regarding passenger flow and timetable construction with regards to this passenger flow.
Fuzzy control also has the advantage of employing fuzzy logic [9]. Fuzzy logic has the advantage of being able to use a spectrum of membership grades for input values instead of regular logic where an input simply is something or isn’t [19]. As Zadeh [19] explains ”classes of objects encountered in the real physical world do not have precisely defined criteria of membership” which makes it easier to describe complex real world systems, which timetable schedules can be considered as.
3.7.2 Simulator
As described in section 2.4.2 there are existing simulators for railway systems, where RailSys is an example, used by the Swedish railway company SJ. However, we decided on not using such an existing simulator and instead developed our own, for cost and time reasons.
First of all, RailSys was not an alternative since it was not for free and was too complicated and expensive to license to be able to use in this study. Along with that, a study from KTH, presented in section 2.4.2, stated that simulations in RailSys take extensive amounts of time to run as well as setting up which is not ideal in our scenario as we want to be able to change a lot of parameters and to do so quickly and often.
Second of all, using a free train simulator would require finding a simulator which suits our exact requirements. This would require finding a simulator that can take input in the form of a time table as well as giving us access to useful data about the simulations. If we were to find such a simulator, the time for setup, reading the documentation and tweaking it to fit our needs would still require a lot of time and effort. This time was estimated to take more time than developing our own simulator, custom for the needs of this project, with the bonus of being sure to have access to the right data.
existing one. The main drawback is the lack of realism in the simulation. A simulator like RailSys is used for performing advanced simulations of real world scenarios [1]. It is therefore very complex and has a high degree of realism which makes it suitable for real world implementations. However, this is not something we need to concern ourselves with since we are only interested in the overall characteristics of passenger flow and train usage. Therefore, the results from our simulator are still relevant and applicable and can lay the groundwork for further research in the area.
Another drawback is, of course, the time requirement. The time spent working on the simulator was significant in comparison to the amount of time spent getting the results and writing the report. However, since this report is using new methods for timetable generation, our demands are quite different from ordinary simulator requirements. Therefore, it was argued that constructing a new simulator for this project would probably take less time than trying to get an existing simulator working to our specifications.
3.7.3 Data generation
To evaluate the performance of the different timetables we generated our own data both for the environment and the passengers, based on observations of data from the real world, described in section 3.1.2. The reason that we did not use existing data is that real data is difficult to get and difficult to get in the correct format. For the scope of this thesis, generated data could give us good approximations of how the real world data would look and allowed us to quickly and easily evaluate how the timetables performed.
3.7.4 Delay accumulation
malevolent timetables would always accumulate delay, regardless of the number of passengers at the station. Since we are interested in how the flow of passengers affects the delay, we choose to not include such timetables. They are also not realistic since if a rail service provider wants to minimise the overall delay, they would completely counteract that goal.
3.7.5 Normalisation process
The output from the fuzzy controller was a heatmap that indicated where trains were needed for each station, over the course of 24 hours. This output needed to be converted to a time table, which was done with a normalising process, as described in section 3.6.
The reason for the normalisation process is that the output format of a fuzzy controller is not, by default, compliant with the format of a timetable. This is since a timetable is a sequence of time points connected to a station and the output of a fuzzy controller is just a value.
Since the output of a fuzzy controller is a value we need to evaluate the fuzzy controller at multiple points throughout the day. This creates the heatmap that is translated, as outlined in section 3.6. This heatmap will be a good representation of how the fuzzy controller evaluates the needs of trains at different times throughout the day.
However, this still is not usable as a timetable and therefore there is a need for conversion. This conversion must not add any information or alter the output of the fuzzy controller. Otherwise, the scheduling method would not be considered as strictly fuzzy but might include other information. To avoid this we have come up with the normalisation process which does not alter the distribution of trains from the heatmap.
(a) Heatmap (b) Timetable train distribution
Figure 3.10: Comparing output from the heatmap with the output from the normalisation process
Figure 3.10. It is quite evident from the figure that both graphs belong to the same fuzzy controller output. Small discrepancies might occur due to the fact that other stations that come after this station will also schedule trains according to their heatmap. This will then influence the schedule of the stations that come before it.
3.7.6 Evaluation
The evaluation of how well a timetable generated by a fuzzy controller performed, was done using the timetable in a simulation with the same passenger distribution that the fuzzy controller used as input for generating the timetable. This was possible due to the aim being to research how well the fuzzy controller adapted to the passenger distribution and evaluate its usability to create timetables. Using the same passenger distribution shows how the timetable performs on an expected passenger load and since the aim was not to evaluate how it performs on unexpected passenger loads this is not a problem.
3.7.7 Extended rule base
4 Result
In this section results of the different time tables are presented and visualised. The independent variables are the trains per hour and the magnitude of passengers
in the simulation, described in section 3.3.2 and 3.3.3. The dependent variables
are average and total travel time, average and total delay and the percentage of latent passengers, in relation to the magnitude of passengers in the simulation. All values in the result are averages over 100 runs.
4.1 Average delay
Firstly we present the results of the different methods of timetable generation on the average delay of the trains. These results are presented in Figure 4.1.
(a) Average delay with the simple method (b) Average delay with the fuzzy method
Figure 4.1: Average delay, measured in minutes (m), for passengers on trains with timetables generated via either the simple method or the fuzzy controller. Performed on four different passenger magnitudes (series)
(a) Average delay with the simple method (b) Average delay with the fuzzy method
Figure 4.2: Average delay, measured in minutes (m), for passengers on trains with timetables generated via either the simple method or the fuzzy controller. Performed on four different passenger, lower, magnitudes (series)
To observe any longer trends we also extend the range of trains tested and plot the result in Figure 4.3.
(a) Average delay with the simple method (b) Average delay with the fuzzy method
Figure 4.3: Average delay, measured in minutes (m), for passengers on trains with timetables generated via either the simple method or the fuzzy controller over an extended range of trains
4.2 Latent passengers
is taken after the 24 hours have been simulated.
(a) Percentage of latent passengers with the simple method
(b) Percentage of latent passengers with the fuzzy method
Figure 4.4: Percentage of latent passengers after simulating 24 hours on timetables generated via either the simple method or the fuzzy controller. Performed on four different passenger magnitudes (series)
The same data was also gathered from running the simulation on the lower passenger magnitudes, the results of which can be seen in Figure 4.5.
(a) Percentage of latent passengers with the simple method
(b) Percentage of latent passengers with the fuzzy method
Figure 4.5: Percentage of latent passengers after simulating 24 hours on timetables generated via either the simple method or the fuzzy controller. Performed on the four lower passenger magnitudes (series)
(a) Percentage of latent passengers with the simple method
(b) Percentage of latent passengers with the fuzzy method
Figure 4.6: Percentage of latent passengers after simulating 24 hours on timetables generated via either the simple method or the fuzzy controller. Plotted over an extend range of train values
4.3 Average travel time
Lastly, we also present a comparison of the average travel time for the same test runs. These results are presented in Figure 4.7.
(a) Average travel time for passengers with the simple method
(b) Average travel time for passengers with the fuzzy method
Figure 4.7: Average travel time for passengers on trains with timetables generated via either the simple method or the fuzzy controller. Performed on four different passenger magnitudes (series)
the result from these runs are presented in Figure 4.8.
(a) Average travel time for passengers with the simple method
(b) Average travel time for passengers with the fuzzy method
Figure 4.8: Average travel time for passengers on trains with timetables generated via either the simple method or the fuzzy controller. Performed on the four lower passenger magnitudes (series)
Finally, we again present plots over extended ranges of train values. These plots can be seen in Figure 4.9.
(a) Average travel time for passengers with the simple method
(b) Average travel time for passengers with the fuzzy method
4.3.1 Generated timetables
Figures 4.10 and 4.11 show an overview of how the generated timetables look. We present a view of when each train is scheduled to arrive at what station as well as a representation of the total amount of trains departing from a particular station. The station considered is the first station in the environment. For all pictures the passenger magnitude was fixed at 25000 and the number of trains fixed at 4 trains per hour.
The graphs in Figure 4.10b and Figure 4.11b show a representation of how the trains are laid out over the course of the day. Each line and color represents the schedule for one particular train. It is possible to see how some trains start at station 10 and some start at station 1. Then the graph shows at what station the train is scheduled to arrive at for any given time of the day.
(a) Simple timetable train distribution (b) Simple timetable graph
Figure 4.10: Visualisation of timetables generated via the simple method
(a) Train distribution from the fuzzy controller (b) Timetable graph from the fuzzy controller
Figure 4.11: Visualisation of timetables generated via the fuzzy controller
In Figure 4.11b and Figure 4.11a it is possible to see how the trains are distributed over the course of 24 hours when generated with the fuzzy controller.
4.4 Additional rules
Here we compare the results of using the rule base consisting of just two rules, as seen in the results above, against the rule base of the same rules with the added additional rule described in section 3.5.4. The results presented here were also produced by taking the average of 100 runs for each performance metric. The additional rules were evaluated with the lower passenger magnitudes and from 1 train per hour to 37 trains per hour.
4.4.1 Average delay
(a) Standard rule base (b) Comparison rule base
Figure 4.12: Comparing delay between the standard rule base (left) and the comparison rule base (right), measured in minutes (m)
4.4.2 Latent passengers
Figure 4.13 presents a comparison of the percentage of latent passengers when introducing a new rule (the comparison rule base).
(a) Standard rule base (b) Comparison rule base
Figure 4.13: Comparing the percentage of latent passengers between the standard rule base (left) and the comparison rule base (right)
4.4.3 Travel time
(a) Standard rule base (b) Comparison rule base
5 Discussion
5.1 Travel time
Looking at the resulting travel times of the simple timetable in Figure 4.7a it is evident that having more trains per hour will lower the travel time. This is most certainly due to the period between the departure of each train becoming shorter when there are more trains, as described in section 3.4. The travel time of a passenger does not only consist of the time the passenger actually goes by train, but also the ”wait”, the time it takes from the arrival of the passenger to the station to the departure of the train that the passenger aims to take, as described in section 3.2.1. When the interval in which trains are departing gets shorter the wait for the average passenger also gets shorter which leads to shorter travel time.
When comparing the results for the simple timetable and the fuzzy control generated timetable (FCT) over 1-37 trains we can see the overall trend for travel time. For 24 trains per day (1 train per hour), the timetables perform identical travel time. Both timetables also stabilize at the same travel time for many trains, 37 trains per hour ( 37 ∗ 24 = 888 trains per day for the FCT), around 1.5 hours, which can be interpreted as the optimal travel time of the line. The things worth mentioning happened in between. The travel time of the FCT is around half an hour better than it from the simple timetable for 9, 17 and 25 trains. This indicates that the FCT has adapted to the passenger distribution and could mean that the waiting time of each passenger is lowered since the distances between stations as well as the speed of the trains have not changed.
5.2 Delay
concept of delay and its causes is described in section 2.2.
The fuzzy control generated timetable (FCT) has a lower maximum delay than the simple timetable, which can be seen in Figure 4.3. It also reaches its maximum and starts decreasing for fewer trains per day than the simple timetable, which can be clearly seen in Figure 4.1.
These results indicate that the FCT has the ability to adapt to the passenger flow. The difference between timetables is however not that large. The largest difference in delay appears for the larger passenger magnitudes where the FCT has a considerably lower delay than the simple timetable. This indicates that the FCT can adapt to larger passenger magnitudes than the simple timetable.
The improvement in delay with the FCT is larger for larger passenger magnitudes. For example, the peak in delay for 25 000 passengers occurs for
about 2 trains less than for the simple timetable. With a magnitude of 50 000 passengers, this improvement is at least 2 trains less. The improvement for 75 000 passengers is approximately 5 trains less.
5.2.1 Maximum delay
5.3 Latent passengers
The same way as for travel time, the proportion of latent passengers begin and end at the same values for both types of timetables, which can be seen in Figure 4.4. The proportion for the fuzzy control generated timetable (FCT) stabilises more quickly than for the simple timetable. The proportion is zero at 17∗24 = 408 trains per day for the FCT (17 trains per hour). For the simple timetable the proportion is zero for the three lowest passenger magnitudes but not for 100 000 passengers, at 17 trains per hour. All magnitudes have zero proportion at 25 trains per hour for the simple timetable. The timetable generated with fuzzy control reach
a proportion of about zero latent passengers for fewer trains per day than the simple timetable does.
The decrease in latent passengers is expected by the same mechanisms that the decrease in the delay is for simple timetables. When the number of trains per hour is increased the periods between departing trains is shortened. This means that the period between the last train of the day and the end of the measuring period (the 24 hours) is shortened, which means that fewer passengers arrive after the last train departs.
In a well functioning timetable, the latent passengers metric does not really indicate anything more than the capability of the timetable to pick up all passengers during the last hour of the day. However, it is a useful metric to use
to check whether a decrease in delay or travel time is caused by an increase in latent passengers or not. If almost all passengers are latent then the timetable
does not work as supposed.
5.4 Comparing different rule bases
latent passengers, depicted in Figure 4.13, as well as the average travel time, which can be seen in Figure 4.14.
This indicates that we have utilised the information that can be gained from the passenger count to a high degree. This is since any additional rules that solely include the passenger count, would be some variation of the rules that we have already tested. However, since a fuzzy system can define intricate sets for fuzzyfying and defuzzyfying it is possible that different sets and parameters might achieve better results still.
There is also the possibility of using other input variables and other fuzzy sets fuzzyfying these inputs. This added information has the potential to further improve the performance of the fuzzy controller timetables. Additional information could be time variables such as time of day or information about other the current state of stations down the line. Any and all information that improves performance is interesting.
Furthermore, information that can give information about constraints of the system can be useful, such as limits on the number of active trains or desire to not schedule as many trains during the certain hours when it can be hard to find train personnel. These constraints can be used as ”penalties” by adding in as conditions in the rule base, for example:
• IF num_passengers IS high AND time_of_day IS day THEN ...
It can be seen that the fuzzy controller’s rule base can be adapted and expanded with whatever information might be available. The ability to expand or limit the number of rules also makes it versatile. At the same time, comparable results to the simple timetable can be achieved by only using two rules regarding the passenger information.
5.5 Lower passenger magnitudes
indicates that the trains in this simulation never reach their maximum capacity. Therefore it is interesting to look at what happens with the metrics if we simulate with lower magnitudes.
Simulations with lower passenger magnitudes were done and the resulting metrics from both timetables can be seen in Figure 4.2 (delay), 4.8 (travel time) and 4.5 (latent passengers). The magnitudes used were 10 000, 15 000, 20 000 as well as 25 000. 25 000 was used to act as a reference in the plots. Note that the colors have the same order as previous plots, where blue is the lowest magnitude and green the highest, but that 25 000 has changed color because of this.
The plots look similar but have some small differences. The average delay beginning at one train per hour is slightly lower for the fuzzy control generated timetable (FCT) than for the simple timetable. The lowest passenger magnitudes are not as affected by the FCT, meaning the differences between the timetables are small. However, the higher the passenger magnitude the higher the
improvement in delay, using the timetable generated with the fuzzy method.
This effectively means that a intelligently controlled railway system could make do with fewer trains than one using a simple timetable.
5.6 Converting fuzzy output to a timetable
The timetable generated from the fuzzy controller is heavily dependant on the normalisation process, outlined in section 3.6. As discussed in section 3.7.5 this process is necessary to be able to generate a timetable using a fuzzy controller. When developing this process we have been careful not to add any outside bias to the resulting timetable.
In a real world scenario, however, these conditions might not apply. If a fuzzy controller was to be used in a real scenario the time frame might have to be extended to an entire week, month or year to accommodate the fluctuations that might occur in passenger flow when considering a larger time frame. This would be advantageous or even necessary to do in a real implementation. By taking a larger perspective and integrating more variables and information into the controller it is possible to achieve even lower delays and shorter travel times. Performance might also be improved by using another normalisation process. It is possible that by adding bias in the normalisation process in the form of additional information the generated timetable could be constrained to certain limitations that might occur in a real world implementation. It is reasonable to assume that there is only a finite number of trains available, instead of a finite total number of trains over the 24 hours, as assumed in this thesis. Such considerations would add bias to the normalisation process and are therefore outside the scope of this thesis. However, they are necessary constraints in the real world implementation and could potentially boost or harm the performance of the system.
5.7 Conclusions
Based on the results of this thesis, it can be stated that the answer to the research question2 is that timetables generated by the fuzzy controller
performed better in simulations than the simple timetables. The improvement
can be measured with all metrics defined: average travel time, average delay and proportion of latent passengers.
The results show that the fuzzy control generated timetable adapts better to larger passenger amounts and does it with the use of fewer trains than the simple timetable. The improvement of using a fuzzy control generated timetable is larger for higher passenger amounts and not as significant for smaller passenger amounts. Furthermore, the fuzzy controller shows the potential of generating efficient timetables given the right input variables and settings.
2Research question: How do timetables generated by a fuzzy system, with the flow of
It should be noted, however, that this comparison is against a relatively simple timetable which does not adapt at all. The fuzzy control generated timetable did show that it can adapt and that it has the capability of increasing performance. It is therefore interesting to further investigate what can be gained in performance by tweaking or extending the rule base with different parameters or new inputs.
5.8 Future Work
Our results of comparing different rule bases showed no real improvement on adding additional rules for the passenger count. Therefore, it would be interesting to see further research on using additional rules that utilise other input variables. There are many different variables that can be used as input, some outlined in section 5.4.
In this study, we have limited ourselves to only comparing the simple timetable with a timetable generated with fuzzy control. Using fuzzy control it is possible to use more data about the passengers to create a timetable and there is potential to further develop this idea by using other, intelligent systems and machine learning systems. Since these systems also learn using data about the environment it is possible that these systems can outperform the simple timetable. It would therefore also be of interest to compare a timetable generated via fuzzy control against a somewhat smarter timetable. Such a timetable could, for example, have a higher number of trains in the morning and evening but not give any more bias to any particular time of day.
If a similar study was to be conducted it could be of interest to introduce a fourth performance metric called ”wait” which measures how long each passenger has to wait at each station before embarking on a train. This study uses the metric ”travel time” which is an aggregation of the wait time and the time spent on the train, actually travelling. The time each passenger has to wait indicates how well adapted the system is to the flow of passengers and is, therefore, an important metric to consider, instead of only using the aggregate metric of total travel time.
References
[1] Bendfeldt, JP, Mohr, U, and Muller, L. “RailSys, a system to plan future railway needs”. In: WIT Transactions on The Built Environment 50 (2000). [2] Caprara, Alberto, Fischetti, Matteo, and Toth, Paolo. “Modeling and solving the train timetabling problem”. In: Operations research 50.5 (2002), pp. 851–861.
[3] Dorfman, MJ and Medanic, J. “Scheduling trains on a railway network using a discrete event model of railway traffic”. In: Transportation
Research Part B: Methodological 38.1 (2004), pp. 81–98.
[4] Eliasson, Jonas and Transek, AB. “Förseningar, restidsosäkerhet och trängsel i samhällsekonomiska kalkyler”. In: Transek AB (2002).
[5] Lindfeldt, Anders. Kapacitetsanalys
av järnvägsnätet i Sverige: Delrapport 2, Bearbetning av databas över infrastruktur, trafik, tidtabell och förseningar. 2009.
[6] Lindfeldt, Olov. “Tidtabellskonstruktion, trafikledning och tättidighet på Svealandsbanan”. In: Kungl Tekniska Högskolan, Institutionen för
infrastruktur och samhälsplanering, Examensarbete 01-57 (2001).
[7] Medanic, J and Dorfman, MJ. “Time efficient greedy strategy for scheduling trains on a line”. In: IFAC Proceedings Volumes 35.1 (2002), pp. 469–474. [8] Nelldal, Bo-Lennart et al. Förbättrad punktlighet på X2000: analys med
hjälp av simulering. KTH Royal Institute of Technology, 2008.
[9] Passino, Kevin M. Intelligent control: An overview of techniques. 2001. [10] Ponce-Cruz, Pedro and Ramirez-Figueroa, Fernando D. Intelligent Control
Systems with LabVIEWTM. Springer Science & Business Media, 2009.
[11] Roslagsban, Region Stockholm. Accessed: 2019-04-09. URL: .
[12] Stockholms Östra, Google Maps. Accessed: 2019-04-10. URL:
[13] Storstockholms Lokaltrafik. URL: .
[14] Wikipedia. Cubic Hermite spline — Wikipedia, The Free Encyclopedia. . [Online; accessed 24-April-2019]. 2019. [15] Wikipedia. Spline interpolation — Wikipedia, The Free Encyclopedia.
. [Online; accessed 24-April-2019]. 2019.
[16] Williams, Michael K. “Using simulation to understand bottlenecks, delay accumulation, and rail network flow”. In: Proceedings of the Annual
AREMA Conference. 2011.
[17] World Population, total. 2017. URL: .
[18] Yang, Lixing, Li, Keping, and Gao, Ziyou. “Train timetable problem on a single-line railway with fuzzy passenger demand”. In: IEEE Transactions
on fuzzy systems 17.3 (2009), pp. 617–629.
Appendices
Appendix - Contents
A Simulator 52
