RailTech : Deep Analytics on Security & Safety Sumit Chakraborty Fellow (IIM Calcutta), BEE(Jadavpur University), India Mobile : 91-9940433441, Email:
[email protected] Abstract : This work is focused on RailTech, an emerging technology in rail operation from the perspectives of intelligent management information systems. RailTech integrates intelligent Driver Advice System (DAS), traffic control centre (TCC) and real-time fault diagnostics (RTFD). The technology is analyzed through deep analytics along seven ‘S’ dimensions: scope (S1), system (S2), structure (S3), strategy (S4), security(S5), staff-resources (S6) and skill-style-support (S7). It highlights technology life-cycle analysis on S-Curve and also shows SWOT analysis on three different types of RailTech system architectures. Finally, this work outlines the basic building blocks of real–time fault diagnostics in terms of a set of system verification algorithms: System Verification Algorithm-Control [SVAC], System Verification Algorithm-Resources [SVA-R], System Verification Algorithm-Data [SVA-D], Fault Tree Analytics [SVA-FTA], FME analytics [SVAFMEA] and TFPG Analytics [SVA-TFPGA]. Keywords : RailTech, Driver Advice System, Real-time fault diagnostics, Fault tree analysis, FMEA, Time Propagation Failure Graph (TFPG), Control flow, Resource flow, Data flow
1. Introduction The ultimate goals of RailTech are to improve the performance of rail infrastructure and train services, minimize train delays which results decrease in capacity utilization, punctuality, reliability and safety. Increased infrastructure capacity also causes secondary delays and increase in route conflicts. Analysis on feedback of operational data is essential to improve planning and control in rail operations. It is essential to monitor train delays at stations using route conflicts, train and timetable data schema. This is a critical problem during natural disasters such as flood, cyclone, storm, fog, mist and snowfall in winter. Deep Analytics is essential to analyze chains of route conflicts, secondary delays, number of conflicts, time loss and delay jump. In this work, RailTech is analyzed based on literature reviews on block chain, rail safety, driver advice systems and real-time fault diagnostics from the perspectives of management information systems (MIS) [1-30] and also summer training experience at Railways as part of graduation programme in electrical engineering. The contributions and organization of the work are as follows. Section 1 explains the motivation of the problem. Section 2 analyzes rail safety and security through ‘7-S’ deep analytics : scope (S1), system (S2), structure (S3), strategy (S4), security(S5), staff-resources (S6) and skill-style-support (S7). Section 3 outlines the basic building blocks of real–time fault diagnostics in terms of a set of
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 1
system verification algorithms: System Verification Algorithm-Control [SVA-C], System Verification Algorithm-Resources [SVA-R], System Verification AlgorithmData [SVA-D], Fault Tree Analytics [SVA-FTA], FME analytics and TFPG Analytics [SVA-TFPGA]. Section 4 highlights technology life-cycle analysis on S-Curve and also shows SWOT analysis on three different types of RailTech system architectures. Section 5 concludes the work.
2. RailTech Evaluation : Deep Analytics The basic objective of this section is to analyze RailTech which integrates Driver Advice System (DAS), traffic control centre (TCC) and real-time fault diagnostics (RTFD). The technology is analyzed through deep analytics along seven ‘S’ dimensions: scope (S1), system (S2), structure (S3), strategy (S4), security(S5), staffresources (S6) and skill-style-support (S7). Scope [S1] : Agents : Driver of train, Traffic controller at TCC; Objectives : safe driving trading-off cost vs. comforts of the passengers through real-time fault diagnostics maintain schedule of train service approximately as far as possible improve energy efficiency of driving as per standard operating procedures optimal capacity utilization of limited rail infrastructure optimize train movements within limits and regulatory compliance ensure security, safety and comforts at optimal cost; System [S2]: Driver Advice System [DAS]; advise a train driver the target arrival time along a specific route to satisfy the timetable and avoid conflicts with other trains; monitor the train’s speed so that the advice is updated correctly and target time of the train is achieved; compute energy efficient speed/distance profile to achieve target time; advise a driver conflict free time target i.e. how far and fast a train can be driven safely within allocated and authorized movement hiding wider view of overall traffic management of Rail network. Computing schema : TCC computes o track train movement o predict future train movement o conflicts detection and resolution o new target train timings to avoid conflicts o speed profiles and choice of advice to the driver Networking schema 3G/4G/GRPS to DAS with built-in antenna 3G/4G/GRPS with external antenna
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 2
Data
3G/4G/GRPS to a communication gateway onboard SMS via GSM-R Data communication via ERTMS/ETCS schema Explicit driving instructions : current speed target, time series analysis of train speed profile, advice to speed up or slow down; Temporal information : train running status (early / delay), optimized speed profile to realize time table; Decision support information : gradient profile, energy usage, position of other trains, conflict, traffic congestion; Data mining : monitor a set of performance metrics. Delay (primary and secondary) Capacity utilization Route conflicts Traffic congestion Signalling errors Real-time train scheduling / time table; Application schema : Provide advice to the train driver for running the train in a safe and efficient manner Collect and recall from route knowledge the current and future speed targets such as infrastructure, regulation and operational factors. Select correct train speed to minimize delay and maximize safety; Monitor the speed of the train by collecting data from sensors, speedometer, noise and motion. Compare correct speed with train speed and compute speed gap. Speed control to minimize the difference between target required speed and actual train speed by changing the setting of the power or brake controller and considering train’s response, gradients, curves and professional driving policy. Assist the driver to continuously monitor the progress of a train against a series of scheduled stops and understand if the train runs early or late between two timing points. Advice for any temporary speed restrictions within a route to give a perception of progress and recovery time to the driver.
Structure [S3]: DAS at TCC (Traffic Control Centre) DAS Task shared between TCC and train DAS tasks mainly onboard Strategy [S4] : Real-time fault diagnostics using fault tree analytics, FMEA and TFPG Automated verification of security intelligence at multiple levels using deep analytics Distribution of intelligence
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 3
Processing unit integration Integration of driver’s interfaces, train positioning and communication schema Exchange of information between track and train
Security [S5] : Call real–time fault diagnostics System Verification Algorithm-Control [SVA-C] / * refer section 3.1 */ System Verification Algorithm-Resources [SVA-R] / * refer section 3.2 */ System Verification Algorithm-Data [SVA-D] / * refer section 3.3 */ Fault Tree Analytics [SVA-FTA] / * refer section 3.4 */ FMEA Analytics [ SVA-FMEA] / * refer section 3.5 */ Time Propagation Failure Graph Analytics [SVA-TFPGA] / * refer section 3.6 */ Call threat analytics assess risks of single or multiple threats on RailTech; analyze performance, sensitivity, trends, exception and alerts. what is corrupted or compromised: agents, communication schema, data schema, application schema, computing schema and RailTech System? time: what occurred? what is occuring? what will occur? assess probability of occurrence and impact. insights: how and why did it occur? do cause-effect analysis. recommend : what is the next best action? predict : what is the best or worst that can happen? Verify security intelligence of RailTech system at levels L1, L2, L3, L4 and L5; Level 1 (L1-access control): authentication, authorization, correct identification, privacy, audit; confidentiality, data integrity, non-repudiation; private view of data through role based access control assess the risk of privacy attack; Level 2 (L2-Computing and communication schema): fairness, correctness, transparency, accountability, trust, commitment, rationality; Level 3 (L3-system performance) : robustness, consistency, liveness, reliability, resiliency, deadlock freeness, lack of synchronization, safety and reachability; Level 4 (L4-malicious attacks) : detect the occurrence of any malicious attack on the RailTech system: rail network delay due to coremelt or network traffic congestion, blackhole, jellyfish, rushing and neighbor attack; sybil attack; false data injection attack; other attacks: data integrity attack, node deletion, flaws in workflows, poor QoS, information leakage. Level 5 (L5-business intelligence): audit the flaws in payment function computation.
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 4
Staff-resources [S6]: audit fairness in resource allocation (e.g. 5‘M’: man, machine, material, method, money), correctness in talent acquisition and retention. Skill-Style-Support [S7]: audit gap in skills (e.g. technical, management, system administration), style (e.g. leadership, shared vision, goal setting) and support (e.g. proactive, reactive, preventive).
3. Real-Time Fault Diagnostics [RTFD] The basic building blocks of RTFD are following six automated system verification algorithms; the output of these algorithms are fed to DAS. 3.1 System Verification Algorithm – Control [SVA-C] _____________________________________________________________________________________________ System : RailTech system (Mechanical, Electrical, Electronics, Information system: Driver Advice System [DAS], Communication system); Assess risks: Verify correctness, reliability, consistency, liveness, deadlock freeness, synchronization and reachability in control flow. Basic control flow : Sequential, Parallel split, Synchronization, Exclusive choice, Simple merge; Special branching and synchronization control flows: Multi choice, Synchronizing merge, Multi merge, Discriminator, m-out-of-n join; Structural control flows : Loop, Implicit / explicit termination, Multiple instances; State based control flows: Deferred choices, Interleaved parallel routing, Milestone, Cancel; Mitigate risks. Replace faulty components through proactive and reactive maintenance. Rectify circuit connectivity. Implement correct Boolean logic: AND / NAND/ Exclusive OR/ XOR/ XNOR/ NOT; _____________________________________________________________________________________________ 3.2 System Verification Algorithm – Resource [SVA-R] _____________________________________________________________________________________________ System : RailTech system (Mechanical, Electrical, Electronics, Information and Communication system), smart coaches; Assess risks: Verify correctness, and fairness of resource management. Resource planning – sense demand supply mismatch. Resource allocation : automatic / semi-automatic execution, direct allocation, role based allocation, deferred Allocation, authorization in allocation, separation of duties, case / exception handling, capability based allocation, history based allocation, organizational allocation, resource initiated allocation Resource distribution : Single / multiple resources distribution, early /
late distribution, priority queue, autonomous resource allocation; Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 5
Resource mobilization Resource sharing Resource delegation, escalation, deallocation, suspension, resumption, skip, redo, stateful / stateless reallocation, simultaneous / chained execution; Mitigate risks: Optimal resource allocation Sensor based on board condition monitoring system : o Monitor health of critical system components through sensors, CCTVs, Fire extinguishers, IoT and integrated information system. o Real-time fault detection: Detect defects and major causes for derailments and delays and deterioration in tracks, running trains and other rail infrastructure. o Trade-off cost vs. comforts / luxury; _____________________________________________________________________________________________ 3.3 System Verification Algorithm – Data [SVA-D] _____________________________________________________________________________________________ System : RailTech system (Information and Communication schema of DAS) Data elements: Single / multiple instance DAS operating environment data Atomic and block task data Boolean and numeric data Case and time series data Assess risks. Verify correctness, reliability and consistency of data schema: Data visibility Data interaction among various elements of DAS Data transfer between various components of networking, computing and application schema of DAS Data transformation Data based routing of various control flow patterns associated with DAS Data analysis / mining ETL (Extract, Transform, Load) mechanism Data cleaning and selection Knowledge discovery from data Data visualization Mitigate risks : Sense flaws in data flow, streamline data management. Detect noise, missing, imprecise sensor data; clean data before analysis. _____________________________________________________________________________________________ 3.4 System Verification Algorithm – Fault Tree Analytics [SVA-FTA] _____________________________________________________________________________________________ Call fault tree analytics; Objectives : identification and analysis of conditions and factors that cause the occurrence of faults;
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 6
Verify reliability and safety of RailTech system performance through top-bottom approach; Define fault tree structure based on system data, scope and applications related to RailTech System; Fault tree development, construction and evaluation; Compute failure rate from fault tree analysis; Output : Report /* FTA is a deductive reasoning that analyses an undesired top level event (TLE) and identifies fault configurations i.e. minimal cut sets; a cut set is a set of faults that represents a necessary, but not sufficient, condition that may cause an undesired state of a system */ Data visualization - error trail / error trace / fault propagation path; _____________________________________________________________________________________________ 3.5 System Verification Algorithm – Failure Mode Effect Analytics [SVA-FMEA] _____________________________________________________________________________________________ Call Failure Mode Effect Analysis (FMEA); Objectives : identification and analysis of conditions and factors that cause the occurrence of faults; Verify reliability and safety of RailTech system performance through bottom-up approach; Output : FMEA Table : it highlights causality relationship between faults and undesired states or properties. Data visualization -error trail / error trace / fault propagation path; _____________________________________________________________________________________________ 3.6 System Verification Algorithm – Time Failure Propagation Graph [SVA-TFPG] _____________________________________________________________________________________________ Call TFPG analytics; Verify robustness and consistency of RailTech system performance; Sense failure propagation in dynamic systems intermittent faults failure in alarms - spurious and missing alarms limited computational resources model reductions Detect, isolate and correct problems early and re-allocate resources as per demand. Output : Timed Failure Propagation Graph : TFPG = (F, D, E, M, ET, EM, DC, DS); /* causal models analyzing the behavior of dynamic system in presence of faults by capturing timing constraints and switching dynamics on the propagation of failures */ Data visualization - error trail / error trace / fault propagation path; _____________________________________________________________________________________________ Notations: TFPG = F, D, E, M, ET, EM, DC, DS;
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 7
F : failure nodes; D : discrepancy nodes; E : edges connecting all nodes; M : system modes; ET: E, a map that associates every edge with minimum and maximum time for the failure to propagate along the edge; EM: E, a map that associates every edge with a set of modes; DC: D, a map defining the class of each discrepancy either AND or OR node; DS: D, a map defining monitoring status of discrepancy node as either M (when discrepancy is monitored by alarm) or U (when the discrepancy is not monitored). Failure
Discrepancy
node
node
Edges
Figure 1: Time Failure Propagation Graph
4. SWOT & TLC Analysis
Real time fault diagnostics
Fault tree analytics FMEA analytics TFPG analytics SVA-C SVA-R SVA-D algorithms
Figure 2 : DAS at TCC (Traffic Control Centre)
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 8
Real time fault diagnostics
Fault tree analytics FMEA analytics TFPG analytics SVA-C SVA-R SVA-D algorithms
Figure 3 : DAS Task shared between TCC and train
Real time fault diagnostics
Fault tree analytics FMEA analytics TFPG analytics SVA-C SVA-R SVA-D algorithms
Figure 4 : DAS tasks mainly onboard It is rational to evaluate strength, weakness, opportunities and threats for a strategic option on technology innovation. There may be major and minor strengths and weaknesses. Strength indicates positive aspects, benefits and advantages of a strategic option. Weakness indicates negative aspects, limitations and disadvantages of that option. Opportunities indicate the areas of growth of market and industries from the perspective of profit. Threats are the risks or challenges posed by an unfavorable trend causing deterioration of profit or revenue and losses. Let us analyze three different types of system architectures in figures 2,3 and 4. In figure 2, DAS intelligence is deployed at TCC and onboard system only displays advice information to the driver. The system can be implemented using existing driver interface avoiding any additional equipment on the train. But, the
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 9
information content displayed to the driver is limited. Dynamic update of compensating feedback to the driver is limited. This alternative is a potential practical and economic solution for possible DAS rollout. In figure 3, DAS task is shared between TCC and train. DAS intelligence is distributed between TCC and train. TCC computed various critical parameters like previous architecture. Driver advice definitions and displays are done onboard. The solution optimizes the information exchange between TCC and onboard in real time. But, the advice can be poor if the real characteristics of the train differ from the characteristics known by TCC. Computation is done where it is easier to access the required data. In figure 4, DAS tasks are mainly onboard. DAS intelligence is implemented in the train. TCC computes a set of functions as mentioned previously. It can adjust speed / energy optimization and drive the development of advanced algorithms. The communication cost between TCC and train is reduced. But, there is risk of consistency of local optimization. In each system architecture, thee basic building blocks of RTFD are six automated system verification algorithms; the output of these algorithms are fed to DAS.
Strength
Opportunities
(High efficiency)
(Profit)
Weakness
Threats
(High Cost)
(Technological complexity)
Figure 5 : SWOT Analysis
4.1 Technological life-cycle analysis
RailTech
Figure 6 : S-Curve Technology life –cycle analysis Figure 6 indicates approximate position of RailTech (as considered in this work) on S-curve of technology life-cycle. No element in this universe exists eternally.
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 10
Similarly, each technology emerges, grows to some level of maturity and then declines and eventually expires. Some technologies may have relatively long technology life-cycle; others never reach a maturity stage. Emergence of new technologies follows a complex nonlinear process. It is hard to understand how technology life-cycles interact with other technologies, systems, cultures, enterprise activities and impacts on society. All technologies evolve from their parents; they interact with each other to form complex technological ecologies. The parents add their technological DNA which interacts to form the new development. A new technological development must be nurtured; many technologies perish before they are embedded in their environments. Next phase is growth; if a technology survives its early phases, it adapts and forwards to its intended environment with the emergence of competitors. This is a question of struggle for existence and survival for the fittest. Next phase is a stable maturity state with a set of incremental changes. At some point, all technologies reach a point of unstable maturity i.e. a strategic inflection point. The final stage is decline and phase out or expire; all technologies eventually decline and are phased out or expire at a substantial cost. TLC may have other different types of phases such as acquisition, utilization, and phase-out and disposal; preparation or initiation, implementation and operation; organization, directive, delegation, coordinate, collaborative, and dissolution; acquisition; emergence, diffusion, development, and maturity.
5. Conclusion How to manage evolution of technological innovation in RailTech security and safety? The nature of innovation shifts markedly after a dominant design emerges. The pace of performance improvement utilizing a particular technological approach is expected to follow an S-curve pattern. The evolution of innovation is determined by intersecting trajectories of performance demanded in the market vs. performance supplied by technologies. Diffusion of innovations indicates how new technologies spread through a population of potential adopters. It is controlled by characteristics of innovation, characteristics of the adopters (e.g. innovators, early adopters, early majority, late majority and laggards) and characteristics of the social environment. The present work considers only a specific area of RailTech with focus on DAS and real-time fault diagnostics from the perspectives of MIS. It is really an interesting and potential research agenda. It is possible to extend this study in various ways. Is it rational to imagine a train as a block chain? There are other various issues of RailTech safety and security such as consistency in train length, fire, food poisoning, anti-collision devices, modernization of rail signaling system, smart coaches, use of CCTV/Wi-Fi/Webcam, unmanned level crossing, passengers crossing railway tracks while talking on mobile phones, derailment of trains due to cracks in tracks or poor maintenance, rushing attacks, non-availability of overbridges, footbridges and skywalk and miscellaneous flaws in mechanical, electrical and civil schema. An intelligent rational rail budget is expected to address all these issues carefully and rationally.
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 11
References 1. Albrecht, T., 2005. Energy-efficient train control in suburban railways: experiences gained from onboard tests of a driver assistance system. In: 1st International Seminar on Railway Operations Modelling and Analysis, Delft, Netherlands. 2. Albrecht, T., 2009. The influence of anticipating train driving on the dispatching process in railway conflict situations. Netw. Spat. Econ. 9 (1), 85. 3. Albrecht, T., 2013. Human factor challenges in the development of a driver advisory system for regional passenger trains. In: Rail Human Factors: Supporting Reliability, Safety and Cost Reduction, pp. 129–138. 4. Dekker, S., 2008. Conflict detection and human-machine coordination. In:Hindsight, 4, January 2007. EUROCONTROL Directorate of ATM Programme –Security, Safety and Human Factors Business Division (DAP/SSH), pp 7–9. 5. DeltaRail Group, 2008a. Advisory speeds for drivers for energy management and regulation. In: RSSB Interim Report Milestone 2, Issue 01, 29th September 2008. 6. DeltaRail Group, 2008b. Advisory speeds for drivers for energy management and regulation. In: RSSB Interim Report Milestone 1, Issue 02, 22nd August 2008. 7. DeltaRail Group, 2009. Driver advisory information for energy management and regulation. In: Stage 1 Report, RSSB Research Programme, T724. 8. Hamilton, W., Clarke, T., 2005. Driver performance modelling and its practical application to railway safety. Appl. Ergon. 36 (6), 661–670. 9. Howlett, P.G., Milroy, I.P., Pudney, P.J., 1994. Energy-efficient train control. Control Eng. Pract. 2 (2), 193–200. 10. Liu, R., Golovitcher, I.M., 2003. Energy-efficient operation of rail vehicles. Transp.Res. A 37, 917–932. 11. Lukaszewicz, P., 2008. Methods for energy efficient driving – algorithms. RailEnergy, Document ID NRG-KTH-D2.3-005. 12. Mitchell, I. 2009: The sustainable railway: use of advisory systems for energy savings. IRSE News, No.151, pp. 2–7. 13. Rail Safety and Standards Board, 2008. The Rule Book. GE/RT8000, Issue 7. 14. Rail Safety and Standards Board, 2008. Good Practice Guide To Train Driver Training. RS/221, Issue 1. 15. Rail Safety and Standards Board, 2008. Train Movement – Staff Suitability and Fitness Requirements, GO/RT3451, Issue 01. 16. Tschirner, S., Andersson, A.W., Sandblad, B., 2013. Designing train driver advisory systems for situation awareness. In: Rail Human Factors: Supporting Reliability,Safety and Cost Reduction. pp.150–159. 17. Wardale, J., 2008. Advice on energy efficient driving. Presentation to drivers, CrossCountry Rail, 2008. 18. Conte, C., Schöbel, A., 2007. Identifying dependencies among delays. In: Proceedingsof the 2nd International Seminar on Railway Operations Research (RailHannover 2007), Hannover, March 28–30, 2007. 19. Daamen, W., Houben, T., Goverde, R.M.P., Hansen, I.A., Weeda, V.A., 2006. Monitoring system for reliability of rail transport chains. In: Proceedings of the 7th World Congress on Railway Research (WCRR 2006), Montreal, June 4–8, 2006. 20. De Fabris, S., Longo, G., Medeossi, G., 2008. Automated analysis of train event recorder data to improve microsimulation models. In: Allan, J., Arias, E., Brebbia, C.A., Goodman, C., Rumsey, A.F., Sciutto, G., Tomii, A. (Eds.), Computers in Railways XI. WIT Press, Southampton, pp. 575–583. 21. Exer, A., 1995. Rail traffic management. In: Bailey, C. (Ed.), European Railway Signalling. IRSE, A&C Black, London, pp. 311–342. 22. Flier, H., Gelashvili, R., Graffagnino, Th., Nunkesser, M., 2009. Mining railway delay dependencies in large-scale real-world delay data. In: Ahuja, R.K., Möhring, R.H., 23. Zaroliagis, C.D. (Eds.), Robust and Online Large-Scale Optimization: Models and Techniques for Transportation Systems, LNCS 5868. Springer, Berlin, pp. 354–368. 24. Goverde, R.M.P., 2005. Punctuality of railway operations and timetable stability analysis. PhD thesis, Delft University of Technology, Delft. 25. Goverde, R.M.P., 2011. A delay propagation algorithm for large-scale railway traffic networks. Transportation Research Part C 18 (3), 269–287. 26. Goverde, R.M.P., Daamen, W., Hansen, I.A., 2008. Automatic identification of route conflict occurrences and their consequences. In: Allan, J., Arias, E., Brebbia, C.A.,Goodman, C., Rumsey, A.F., Sciutto, G., Tomii, A. (Eds.), Computers in Railways XI. WIT Press, Southampton, pp. 473–482. 27. Hansen, I.A., Pachl, J. (Eds.), 2008. Railway Timetable & Traffic: Analysis, Modelling, Simulation. Eurailpress, Hamburg. 28. Ullius, M., 2004. Verwendung von Eisenbahnbetriebsdaten für die Schwachstellenund Risikoanalyse zur Verbesserung der Angebots- und Betriebsqualität. PhD thesis, Swiss Federal Institute of Technology, Zurich. 29. Van Oort, N., 2011. Service reliability and urban public transport design. PhD thesis,Delft University of Technology, Delft. 30. S.Chakraborty. 2018. Business analytics for top technology innovations. Researchgate.
Reference : EBOOK/ SCHAKRABORTY/ RailTech V1.0/ DATED 15082017 PRICE: RS. 5000 Page 12