Project Topics
Get Complete Project Material File(s) Now! »
Literature Related to ERTMS
To establish international standardization of automatic train control (ATC) systems, the European Rail Traffic Management System/European Train Control System (ERTMS/ETCS) development began in 1989 under the European Transport Minister. (Subset-026-1 System Requirements Specification: Introduction, 2014) In 1996, the EU decided that European Rail Traffic Management System (ERTMS) would become the standard for all high-speed lines. ETCS is developed as part of the ERTMS initiative. ERTMS comprises trackside and train borne systems and utilizes an in-cab signaling and ATP element called ETCS (European Train Control System). Unifying the multiple signaling systems will provide better interoperability of freight and passenger rail services, minimize technical and cultural problems of cross-border rail operations, reduce costs, improve the overall quality of rail transport and increase competitiveness. (Thomas & Davies, 2007) Compared with the traditional signaling systems, ERTMS is clearly more flexible and advanced about conveying information. It provides interoperability cross-border railway traffic.
During the past decades, more than 20 different train control systems have been developed and operated by individual European Railways according to their national requirements on technical standards and operating rules. The automatic train protection (ATP) systems in use are non-compatible with each other and hence a train must be equipped with different ATP systems as it travels along different lines across the country borders. Sometimes, it even requires changing locomotive or driver at frontiers as each country generally has its own signaling system for which the drivers must be trained. The additional ATP systems take up a lot of space on-board. It also adds to travel time, operational and maintenance costs. (Thomas & Davies, 2007) The ERTMS is gradually replacing the existing incompatible systems throughout Europe. It will boost international freight and passenger transport. The increasing implementation of ERTMS outside Europe such as Algeria, China, India, Mexico, Saudi Arabia, South Korea, Taiwan and Turkey also demonstrates its success. (Thomas & Davies, 2007).
Surveying the track ahead is a critical component of the train-driving task. However, all in-cab instruments require the driver to look away from the track, and in-cab signaling systems such as European Rail Traffic Management System (ERTMS) may increase the time that drivers spend ‘heads-down’. (Thomas & Davies, 2007) A clear and consistent definition of the ERTMS/ETCS DMI helps the driver to better understand the tasks he must perform. This increases the speed and the accuracy of interactions between the driver and the ERTMS/ETCS onboard equipment, hence reducing the probability of human errors in application of the operational rules. (ETCS Driver Machine Interface, 2014).
Due to the nature of the required functions, the ERTMS/ETCS system will have to be partly on the trackside and partly on board the trains. (System Requirements Specification: Basic System Description, 2014) The environment of ERTMS is composed of the train, the driver, other onboard interfaces and external trackside systems. The ERTMS/ETCS on-board equipment is a computer-based system that supervises the movement of the train to which it belongs, on basis of information exchanged with the trackside sub-system. The ERTMS/ETCS on-board equipment shall display the train speed, the permitted speed, the target distance and the target speed to the driver (ETCS Driver Machine Interface, 2014) The DMI is an interface that allows the direct exchange of information between the driver and the ERTMS/ETCS onboard equipment. The indirect exchange of information done via the train interface (e.g. a driver’s action on the service brake used for the service brake feedback, opening/closing the desk) is not part of the DMI. The ERTMS/ETCS DMI shall be able to display text in all languages pre-configured onboard. (ETCS Driver Machine Interface, 2014) A standard ERTMS DMI can be seen in Figure 5 and the main features of the speed and supervision area can be seen in Figure 6.
Literature Related to HUD
HUD is a secondary display that helps the driver locate potential hazards in the surrounding environment while keeping track of the vehicle’s current state. HUDs are widely used in both military and commercial aviation with gradual adaptation in general aviation and passenger cars but much less common in trains. A study that examined the usefulness of HUDs for locomotives concluded that they could help train drivers avoid accidents and improve their performance. (Liu, Andrew; Jones, Michael, 2017).
The HUD is used to project an image into the driver’s field of view by means of an optical system on a transparent display in front of the driver called the combiner. The most important vehicle or mission information can be displayed directly on the screen. The choice of information displayed on the screen can be adapted to the customers’ requirements. (Continental Engineering Services GmbH, 2018).
HUDs have a proven track record in the aviation and automobile sectors, allowing pilots and drivers to access information without diverting attention from the outside world. Similar benefits may be realized by the installation of HUDs in train cabs. (Thomas & Davies, 2007) The HUD is composed of a concave half mirror, known as a combiner, and a projector with Red Blue Green (RGB) semiconductor laser light as illustrated in Figure 7. (Tanaka, 2015) One important element of the HUD is the size of the display projected for the driver, the distance of the projection and the size of the headbox. The headbox is the cubic volume within which the driver’s eyes must present for the projections to be visible clearly without any distortion. The display in aircrafts cover the entire field of view and if projected at infinity whereas for an automotive, the display is small and is at 2-3 m from the driver where they are supposed to pay attention.
For a vehicle operator to look down at console instruments, they must perform several coordinated physical, cognitive and perceptual actions, some in parallel while others in series. As vision is a sense which is directed to a point in space (as opposed for instance to the sense of hearing), visual attention cannot be directed to the forward view while simultaneously fixating console instruments. Critically, some of the time taken to shift attention from the view ahead to console instruments is effectively lost time – neither the view ahead nor instruments are being attended while attention is being redirected. Contributions to the ‘time budget’ involved in an instrument scan are outlined in Figure 8. In aircraft, the pilot is trained to carry out a formal and structured instrument scan, which may take several seconds. Even a glance down to the dashboard in a car (where the instrument cluster tends to be located as close to the windscreen as possible) takes over a second, and where significant light adaptation is involved (for instance when driving into the sun), it may take considerably longer to read head-down instruments and redirect attention to the road. (Thomas & Davies, 2007).
Studies which have investigated eye movements of train drivers are directly relevant to this analysis. In a simulator-based study, the point of gaze was categorized as: Sky, Signs, cab, moving objects, track ahead, off track and signals. The study demonstrated that drivers spent most of the time looking either within the cab, at signs, at the track ahead or at signals. A proportionally smaller amount of time is spent looking at the sky, at moving objects or off-track (landscape). These findings are supported by who deployed eye movement recording equipment on trains. An extract from the study is given in Figure 9. As can be seen, drivers predominately attend to a relatively small area of the visual scene (labelled as ‘ahead’). Maximum value will be realized by installation of a HUD which overlays this area. Additional benefit may be gained if the requirement to view within the cab can be removed by installation of a HUD, effectively combining the ahead (yellow) and in-cab (blue) categories. (Thomas & Davies, 2007).
It is certain that HUDs could be installed to provide useful information to the driver in a manner which is readable across most (and possibly all) viewing conditions. The project indicated the following range of risk associated with the issues identified: (Thomas & Davies, 2007).
1. Issues related to night readability, display focus, refresh rate, sunshades, track curvature, combiner mechanism, integrity, and potential obscuration of external visual features are assessed to be low risk.
2. Issues related to vibration, daylight readability (especially when driving into the sun), legibility during transitions associated with tunnels, and interactions between the outside view and the field of view of the HUD are assessed as medium risk.
3. Issues related to readability of the display from the range of seating positions, and the long-term reliability of HUD displays in the demanding environment of the rail cab are assessed to be high risk.
In the study performed by Thomas & Davies, 2007, a trial was done with 16 participants, the difference in mean workload for the 16 trials involving HUD and the non-HUD condition. A negative difference implies that workload was reduced by the presence of a HUD. As can be seen in Figure10, in most of the cases (a total of 13 of the 16 drivers) workload was lower with a HUD. An analysis of the use of HUDs in other transport sectors and their demonstrated benefits has indicated that they can provide safety benefits if applied in the railway sector. It is judged that a suitably equipped HUD might help prevent up to 10% of incidents and 3% of accidents with a total potential annual value of £2M for the UK rail network. The results indicate that HUDs adapted to the railway environment will reduce workload on the drivers. Based on the known performance benefits in other applications, an assessment of the potential value of HUDs in contributing to performance suggests that a saving of up to £5M per annum might be made. This is derived from the improvement in punctuality arising from a reduction in driver workload. A net financial benefit to train operators was indicated. The engineering of an installation in a train cab requires innovative solutions, but the issues do not invalidate their use. Drivers responded positively to the experience of their use in the driving simulator. Drivers were positive about the potential for cueing the position of signals, a measure judged to be of assistance in reducing the probability of SPADs. (Thomas & Davies, 2007).
HUDs have various advantages. It takes only a couple of seconds to look down at the instruments but those few seconds could be the difference between seeing a conflict or avoiding it. Constantly the pilots have to look down at instruments to check various parameters during good weather, it can be challenging during bad weather conditions. (Ercoline, William Bill, 2000) It is very similar for train drivers with further challenges arriving due to crossings, bridges, tunnels and changes in tracks. One of the identified challenges of HUDs in aircrafts is reading the data during turbulent flights. (Ercoline, William Bill, 2000) Trains face similar situations all the time and hence the hardware must be robust and have good damping to prevent vibrations and distortions. Attentional or cognitive switching has been studied and identified although several studies have shown that it does not degrade performance in a global sense. Drivers should be trained and made aware of such possible issues arising. (Ercoline, William Bill, 2000).
One of the challenges of implementing HUDs in trains is that there is very limited literature available in the domain. Majority of the literature pertain to aircrafts and cars though they can be generalized to trains.
Design using Scenario Development
Design, as an activity of creation has been around since humans developed their creativity skills to solve problems. Besides making sure a good functioning of a product, users have a varying degree of concerns on the comfort of using the product (ergonomics), the ease of use, learn and maintain(usability), the appearance, the joyful experience of using the product and the price. Anggreeni & Voort, 2007 state that the design of a product can vary vastly but are constrained by certain criteria and is represented in Figure 11.
There are many existing methods and tools for dealing with interaction between user and product. However, they are, whether quantitative or qualitative in nature, essentially designed for analysis or evaluation according to Suri & Marsh, 1999. Some examples as given by Janhager & Hagman, 2007 are task analysis, user trials, performance tests and computer aided design such as 3-D representation of the human body. Traditional design models are too static for describing user-product interaction, and these models call for new dynamic techniques, such as scenarios for modelling user-product interactions. Janhager & Hagman, 2007 mention that carrying out investigation of concepts before the prototypes are built, could lead to reduction in product development costs. Rosson & Carroll, 2002 defines scenarios as work-oriented design objects. They describe the system in terms of the work that users will try to do when they use those systems, ensuring the design will remain focussed on the needs and concerns of the user. As per the authors, scenario-based design is a family of techniques in which the use of a future system is concretely described at an early point in the development process. According to Suri & Marsh, 1999 scenario building as an ergonomic method has its root in the more traditional techniques of user profiling, task analysis and system profiling. On a similar note, Anggreeni & Voort, 2007 marks scenarios as explicit descriptions of hypothetical events concerning a product during a certain phase of its life cycle. Hypothetical events could be intentional by the actor(s) in the scenario (for example, the use of a product) or unintentional (for example, the side effects of the interaction between an actor and a product).
According to Potts, 1995, a scenario is one that has a point and that helps people understand the exemplified system. The author also states that a collection of scenarios can never show the behaviour of the entire population but a major chunk of it is represented. Suri & Marsh, 1999 states that scenario building gives a possibility to explore and communicate the qualitative aspects of user experience early in the design process. The author states that scenarios serve as something concrete to base discussion, argument and resolution of issues. The characteristics of being engaging, digestible and compelling make scenarios ‘accessible’ to anyone, and thus support interdisciplinary design teams. Understanding the significant trends which might affect users and contexts of use in the future and the kind of technologies that are or will be available to support the design which can be used to extract and organize elements for developing scenarios.
Scenarios have become popular in the interactive system design because it enables rapid communication about usage possibilities and concerns among many different stake holders. Scenarios can also be enriched easily with rough sketches or story boards. Also, it is easy to make progress working through the idea, obtain quick feedback to refine these ideas. Scenarios are rough but support visible progress and they emphasize people and experience. Also, being evocative and incomplete by nature, scenarios promote empathy and raise usage questions at many levels as described by Rosson & Carroll, 2002 promoting fruitful and intricate discussions within the design team. Also, scenarios allow constraints to be put for designers as there are too many things that can be designed. Scenarios can be made more effective when users are directly involved in them, thus supporting a nature process of participatory design, where current users enact or recite relatable episodes of current activities, hence working iteratively with designers to transform and enrich the designs. Rosson & Carroll, 2002, illustrates an overview of scenario-based design framework as presented in Figure 12.
Potts, 1995 defines a scenario as a story or chronological events with a plot and its points. The author also believes that scenarios are highly constrained. Suri & Marsh, 1999 describes the first element of forming scenarios is to define specific individual users, detailed with respect to personal characteristics, lifestyle, motivations and circumstances. These characteristics are based upon real users like those observed and not typical of a population. The set should personify the range such as age, knowledge, user or buyer and include extremes rather than average. Next, these users are assigned issues, tasks and situations. The product features and functions are then defined keeping these users in mind. Janhager & Hagman, 2007 states that scenarios are based on technical processes to be able to connect the scenarios with the product function. Also, the authors suggest using a method that integrates user actions to the model of the technical process for scenario building and calls it User Technical Process(UTSP).
Rosson & Carroll, 2002 assumes that in Scenario Based development (SBD) system development begins with an initial vision or charter, even though it might be sketchy and non-binding. This vision motivates intense analysis of current situation for problems and opportunities that might be addressed by available technologies. The stakeholders are recognized for the project which is also suggested by Anggreeni & Voort. Both Anggreeni & Voort, 2007 and Rosson & Carroll, 2002 suggest the development of various scenarios- problem and interactive so that the product features can be based on these scenarios. While Anggreeni & Voort, 2007 recommends using the scenarios during all the stages of development from initial research to the final prototyping, Rosson & Carroll, 2002 recommends using the scenarios for the design activity and not so much in the prototyping and evaluation stage. The overview of relationships between scenarios can be seen in Figure 13 as illustrated by Anggreeni & Voort, 2007.
Potts, 1995 and Suri & Marsh, 1999 describes scenarios as very specific user stories that identifies something very specific about the product needs. This kind of scenario development can be useful to develop future versions of a product or a product that has already some users who have identified the problems. Also, this kind of scenarios seem more useful for consumer products that an individual purchase, rather than products to be fitted into trains and shared by multiple drivers. The process described in Anggreeni & Voort, 2007 and Rosson & Carroll, 2002 are more explorative in the sense that, interactive scenarios allow the designers to understand the user requirements and connect them to product specifications whereas the problem scenarios help identify the possible bottle necks that should be dealt with during the product development phase. With all the benefits associated to using scenarios, it is easy to identify loopholes as designers. Involving users in the scenario generation can lead to missing out on breakthrough ideas as users can often be comfortable with what they use and only suggest incremental changes. Also, in trying to define all kinds of users, scenarios might become too many or too complicated and act as an impediment to the whole design process. Keeping these loopholes in the hindsight, designers must use the scenario building technique to foster their designs, initiate quick feedback and promote good discussions while keeping their focus on the goals and targets of the project.
UTSP model consists of mental activities, user actions and technical functions. The interaction between the technical system and the user must be considered and therefore a suggestion is to draw a parallel between the user actions and the technical functions. Janhager & Hagman, 2007 states that users have feeling and thoughts, thus mental activities were introduced in the model as well. The user actions and mental activities constitute the user process while the technical process consists of technical function. Together they compose the UTSP.
UTSP also has a time axis extending along the processes, parallel to the actions activities and functions as shown in Figure 14.
By using UTSP, a structured scenario can be built. The foundation of the scenarios is the same as for ordinary scenarios, i.e., individual users with issues, tasks and situations are established, and the product concept is generated with help of the user-technical process. The advantage of UTSP for a scenario is that the concurrence between a user action and the corresponding technical function is clearly presented, i.e. the methods shows visibly the user and the technical system performs perform simultaneously. At the same time, it is possible to segregate a process and investigate it in isolation to see what either the user or the technical system does.
Janhager & Hagman, 2007 mentions that most design theories focus on the technical functions and the structure of the product and limit the product’s relation to the user. Also, Scenario building in technical processes brings in the user aspects in the synthesis part of the design work and supports he design team with creativity activities. Added to it, scenario building is a useful technique for forecasting the usability of a product design. It supports communication between different parties. Suri & Marsh, 1999 states that an important benefit, which is often not addressed by other design methods, is that scenario building explores the future possibilities of how the product will integrate into different physical and social context.
Table of contents :
1 INTRODUCTION
1.1 Background
1.2 Purpose
1.3 Objectives
1.4 Stakeholders
1.5 Delimitations
1.6 Method
2 FRAME OF REFERENCE
2.1 Definition of Terms Related to ERTMS
2.2 Literature Related to ERTMS
2.3 Literature Related to HUD
2.4 Design using Scenario Development
3 IMPLEMENTATION
3.1 Project Planning and Gantt Chart
3.2 Phases of Implementation
4 RESULTS
4.1 Major Findings from literature
4.2 Major Findings in the Workshop with Green Cargo
4.3 Scenarios
4.4 Design Objectives
4.5 Conceptual Design
5 DISCUSSION AND CONCLUSIONS
5.1 Discussion
5.2 Conclusions
6 RECOMMENDATIONS AND FUTURE WORK
6.1 Recommendations: HUD Hardware
6.2 Recommendations: Trams, Subway and Light Rail
6.3 Future work
7 REFERENCES
