Project topics and materials
Get Complete Project Material File(s) Now! »
Birth of the Web
The Web was created by Tim Berners-Lee at CERN in 1989 to connect researchers and allow them to share resources more easily. It was based on 3 technologies:
• HyperText Markup Language (HTML): a description language that presents infor-mation in a structured way,
• Uniform Resource Locator (URL): a string that identifies resources on the Web,
• HyperText Transfer Protocol (HTTP): a protocol for machines to communicate and transfer HTML documents.
The first browser developed to understand and interpret these technologies was WorldWideWeb only accessible on NeXT operating system [83]. The first cross-OS browser was launched in 1992 with the first line-mode browser [26]. The Mosaic browser was created at the National Center for Supercomputing Applica-tions (NCSA) while Netscape was created in 1994. Mosaic was licensed by Windows, and was used to create Internet Explorer in 1995. These 2 browsers were the 2 major ones at the end of the 90s and tried to become dominant. Known as the first browser war, this period was opportune to develop new technologies to become the best browser. Because of this, the innovative browsers were preferred by web developers, and many browsers tried to pretend to be each other to stay competitive. This instability is reflected in the history of the User-Agent string and is still the reason why User-Agent strings are formatted strangely [55]. The JavaScript language was created and released by Netscape. It allows the Web to become dynamic by providing APIs to interact with the user. In response, Microsoft created the CSS language (Cascade-Style Sheet) to add style to the HTML pages. As Microsoft installed Internet Explorer by default within its Windows OS, it allows Internet Explorer to be reached by many users as 2.1.1 Birth of the Web The Web was created by Tim Berners-Lee at CERN in 1989 to connect researchers and allow them to share resources more easily. It was based on 3 technologies:
• HyperText Markup Language (HTML): a description language that presents infor-mation in a structured way,
• Uniform Resource Locator (URL): a string that identifies resources on the Web,
• HyperText Transfer Protocol (HTTP): a protocol for machines to communicate and transfer HTML documents.
The first browser developed to understand and interpret these technologies was WorldWideWeb only accessible on NeXT operating system [83]. The first cross-OS browser was launched in 1992 with the first line-mode browser [26].
The Mosaic browser was created at the National Center for Supercomputing Applica-tions (NCSA) while Netscape was created in 1994. Mosaic was licensed by Windows, and was used to create Internet Explorer in 1995. These 2 browsers were the 2 major ones at the end of the 90s and tried to become dominant. Known as the first browser war, this period was opportune to develop new technologies to become the best browser. Because of this, the innovative browsers were preferred by web developers, and many browsers tried to pretend to be each other to stay competitive. This instability is reflected in the history of the User-Agent string and is still the reason why User-Agent strings are formatted strangely [55]. The JavaScript language was created and released by Netscape. It allows the Web to become dynamic by providing APIs to interact with the user. In response, Microsoft created the CSS language (Cascade-Style Sheet) to add style to the HTML pages. As Microsoft installed Internet Explorer by default within its Windows OS, it allows Internet Explorer to be reached by many users as a default choice. By 1999, Internet Explorer owned 99% of the browser market. In response, Netscape went into making its code open source and created the not-for-profit Mozilla organization, that created the Firefox browser in 2002 [63]. Apple launched Safari on its MacOS system in 2003 [82]. Chrome was released in 2008 [22] while Edge was launched in 2015 to replace the aging Internet Explorer browser.
Web evolution
Increasing diversity of devices. Originally built for desktop devices, the Web is now accessed by more and more diverse devices. Figure 2.1 present the evolution of the distribution of the device market share from 2009 to 2021. With the birth of smartphones in 2007, mobiles started to massively access the Web. Since 2017, they represent 45% to 55% of the devices accessing the Web. Nowadays, many other devices can browse the Web, such as connected watches, TVs and even cars. This increases the need for websites to adapt to users and their devices. Increasing diversity of APIs. JavaScript was developed to transfer a part of the logic treatment from the server-side to the client-side. It allows websites to increase the possible interactions with the user. The language keeps evolving along revisions to both adapt to the increasing diversity of devices connecting to the web and to introduce new APIs to develop new functionalities, such as accessing the network information of the connected device or connecting a VR headset to the device. While the standardization of JavaScript is ensured by Ecma International, browser vendors often develop non-standard APIs to test new functionalities on their users. For example, Chrome implemented the non-standard Keyboard API [58] to detect the keyboard layout of the user and get the best of it. This increases the diversity of APIs available in browsers.
Evolution of the browser market share. As we explained in Section 2.1.1, the first browser war lead to the birth of CSS and JavaScript, which are now omnipresent on the Web. More generally, it was the opportunity to develop new features to attract more users. The same situation happened at the end of the 2000s and during the 10s, during the second browser war. While Internet Explorer was declining, other browser vendors raced to attract more users and become dominant. The evolution of the browser market share from 2009 to 2021 is presented on Figure 2.2. Since a couple of years, the situation has stabilized. Chrome now represents 65% of the browser market share, followed by Safari with 15%, Firefox and Edge with 5% each. The remaining 10% are shared between less-popular browsers.
Protecting data access
Encryption. The first defenses concern the way data is sent on the Web. First, the HTTPS protocol intends to use the TLS/SSL encryption technology over the classic HTTP protocol [56]. It allows users to exchange data under an encryption layer that protects against cookie hijacking and other threats. Felt et al. [98] measured the current adoption of HTTPS on the Web. They collected data from Chrome and Firefox users from 2014 to 2017, and showed the proportion of pages loaded under HTTPS keeps growing, and reached 58 − 90% on Chrome depending on the OS used, and 50-57% on Firefox. They also measured disparities according to the region and country of the user. In addition to HTTPS, The HTTP Strict Transport Security (HSTS) header has been designed to use HTTPS by default. HSTS is an HTTP header a server adds to its response. It tells the client to always reach it with HTTPS for a certain period of time.
The browser receiving the response will store this information and will send the future requests to this domain directly with the HTTPS. Felt et al. [98] showed the HSTS header is only available on 3% of websites on the Alexa Top 1M.
Restricting cookies access. Browsers also implemented several defenses to protect cookies against interception and other malicious usages [57]. The Secure cookie response header allows websites to define cookies that must only be sent over HTTPS, preventing the interception of cookies via network monitoring. Websites can use the instruction HTTPOnly that will prevent the access of cookies via JavaScript, preventing them from being stolen via XSS attacks. Finally, websites can use the Domain, Path, and the experimental SameSite instruction to restrict the access of cookies and protect against CSRF attacks.
Table of contents :
1 Introduction
1.1 Background
1.2 Motivation and aim of the thesis
1.3 Thesis contribution
1.4 Thesis outline
2 Railway ecosystem
2.1 Introduction
2.2 Railway infrastructure
2.2.1 Railway line
2.2.2 Railway node
2.3 Railway signalling and control systems
2.3.1 Objective of railway signalling and control systems
2.3.1.1 Safety
2.3.1.2 Exploitation
2.3.2 Railway interlocking systems
2.3.2.1 Train detection equipments
2.3.2.2 Railway interlocking types
2.3.2.3 Interlocking of route
2.3.2.3.1 Train route
2.3.2.3.2 Train route table
2.3.2.3.3 Conclusion
2.3.3 The concept of block
2.3.4 Automatic Train Control system
2.3.5 Communication systems
2.3.5.1 Systems with spot transmission
2.3.5.2 Systems with continuous transmission
2.3.6 Communications-Based Train Control (CBTC) and moving block
2.3.7 European Rail Trac Management System (ERTMS) (https://www.ertms.net)
2.3.7.1 The incompatibility of railway signalling and control systems
2.3.7.2 ERTMS composition
2.3.7.3 ERTMS levels
2.4 Railway capacity
2.4.1 Notions of capacity
2.4.2 Methods to evaluate capacity
2.4.2.1 Analytical method for a railway line
2.4.2.2 Optimisation methods to evaluate a railway line capacity
2.4.3 Capacity of a railway station
2.4.4 Strategies to increase capacity
2.4.4.1 Building new infrastructure
2.4.4.2 Increase relatively homogeneous trac
2.4.4.3 Performance of rolling stocks
2.4.4.4 Railway trac management
2.5 Conclusion
3 Railway exploitation for trac uidication: steps, issues and approaches
3.1 Introduction
3.2 Railway trac management
3.2.1 Representation of railway network
3.2.2 Classication of problems
3.2.2.1 Network capacity assessment
3.2.2.2 Global pre-construction
3.2.2.3 Local scheduling
3.2.2.3.1 Routing and scheduling in railway station
3.2.2.3.2 Phase of adaptation
3.2.2.4 Disturbance management
3.3 Routing and scheduling in railway station
3.3.1 Denition of train routing and scheduling problem in railway station
3.3.2 Literature review
3.3.2.1 Conict graph approaches
3.3.2.2 Constraint programming approach
3.3.2.3 Heuristic approaches
3.3.3 Conclusion of the literature review
3.4 Railway disturbances management
3.4.1 Robustness in railway management
3.4.1.1 Denition
3.4.1.2 Literature review
3.4.2 Train rescheduling problems
3.4.2.1 Denition
3.4.2.2 Literature review
3.5 Conclusion
4 Problem formalization
4.1 Introduction
4.2 Topology of a railway station
4.2.1 Section
4.2.2 Connector
4.2.3 Principles of construction
4.3 Trains’ activities
4.3.1 Management
4.3.2 Trains and Circulations
4.3.2.1 Trains
4.3.2.2 Circulations
4.3.2.2.1 Commercial entering circulation
4.3.2.2.2 Commercial leaving circulation
4.3.2.2.3 Technical entering circulation
4.3.2.2.4 Technical leaving circulation
4.3.2.2.5 Crossing circulation
4.3.2.2.6 Management of circulations
4.3.2.2.7 Coupling and decoupling mechanism
4.4 Routing and Scheduling
4.4.1 Study hypotheses
4.4.2 Parameters
4.4.2.1 Parameters of given data
4.4.2.2 Safety
4.4.3 Eective Occupation Times
4.5 Conclusion
5 Mathematical models
5.1 Introduction
5.2 Decision Variables
5.3 Constraints
5.3.1 Routing constraints
5.3.2 Constraints of stopping platforms
5.3.3 Constraints of occupation times
5.3.4 Safety constraints
5.3.5 Constraints for the management of technical and commercial circulations
5.3.5.1 Deviation of technical circulations
5.3.5.2 Model with time relaxation
5.3.5.3 Model with cancellation of trains
5.4 Objective functions
5.4.1 Minimising of the totals of deviation time of technical circulations
5.4.2 Minimising of the number of interruptions
5.4.3 Minimising of the maximum number of occupation of sections
5.4.4 Minimising of the number of cancelled train
5.5 Mathematical models
5.6 Continuous-time model
5.7 Conclusion
6 Case study
6.1 Introduction
6.2 Topology
6.3 Data visualization
6.4 Numerical experiments
6.5 Subgroups partitioning strategies based on rolling horizon approach
6.5.1 Introduction
6.5.2 State of art in rolling horizon approach
6.5.3 Solving principles
6.6 Computational results
6.6.1 Results on full day timetable (model 1 )
6.6.2 Results of model with relaxation of commercial trains (model 2 )
6.6.3 Results of model with cancellation of trains (model 3 )
6.6.4 Results on robust timetables
6.7 Conclusion
7 Conclusions and future research
7.1 Conclusions
7.2 Future research
7.2.1 Train routing and scheduling support tool
7.2.2 Types of trains
7.2.3 Switches manipulation
7.2.4 Modalities for cutting of subgroups partitioning strategy
7.2.5 Resolution order of subgroups partitioning strategy
7.2.6 Improving robustness
7.2.7 Rescheduling in real time
Appendix
Bibliography
