Introduction Train control systems are a general term for various devices that automatically control train speed. Based on the degree of speed control, they are generally divided into: Automatic Train Stop (ATS) system, Automatic Train Overspeed Protection (ATP) system, Automatic Train Control System, Automatic Train Control (ATC) system, and Automatic Train Operation (ATO) system. The onboard human-machine interface (HMI) of the train control system is a platform for information interaction between onboard equipment and the driver, and is an important component of the train control system. Through the HMI, the driver can set relevant train parameters, obtain real-time information on the train and track status and data, and respond promptly to commands and warnings issued by onboard equipment. In recent years, with the continuous development of science and technology, railway equipment technology has reached a new level, and the rise and development of high-speed railways has brought vitality to the revitalization of railways worldwide. As one of the key pieces of equipment in high-speed railways, the Automatic Train Control System has the following three main characteristics: 1. Onboard displays serve as the basis for train operation; 2. Speed ​​commands replace the meaning of color lights; 3. Signals directly control train braking. It is precisely because of these characteristics that the HMI plays a greater role in the entire system. A well-designed interface can clearly display more information, helping drivers better understand the tasks at hand, improving speed and accuracy, reducing the possibility of human error, and maximizing train safety. For general interactive software systems, GUI design and implementation are an important part of software system development. The human-machine interface (HMI) refers to the interaction between the software system and the user. It provides users with various forms of input, converts the user's input information, transmits it to the core module for processing, and provides the processing results back to the user in an understandable way. It sits between the user and the core application. The design must be user-friendly while also being adapted to the core module. The quality of the user interface design directly affects users' evaluation of the software product and ultimately its competitiveness and lifespan. In fact, in many software design phases, due to the lack of effective user interface design methods, the interface design is directly coded by the implementers, leading to a gap between the implementation and user needs. This paper analyzes the design principles that the onboard HMI of a train operation control system must meet and designs a suitable GUI model for this type of HMI. UML is used to describe the functional requirements, overall design, and detailed design process of the HMI and to model it, and Rational Rose is used for a rigorously defined graphical language description. Finally, the development was carried out using Microsoft's Visual C++ development tools. 1. Principles of Human-Computer Interface Design 1.1 Principles of Human-Computer Interface Design Human-computer interface design should emphasize both artistry and science, utilizing the insights of graphic artists and the findings of researchers on human factors, while also considering the user's intuitive feelings. Based on existing user interface design experience, and considering the characteristics of the onboard human-computer interface for train operation control systems, the following design principles were summarized: 1) Understand the operations the driver needs to perform. Typical user interface designs require task analysis to understand the nature of the user's task. 2) The driver should be able to maintain control of the operation during interaction with the system. Any operation initiated by the user should be able to be cancelled at any time. 3) Provide multiple ways to complete each interface-related action (e.g., closing a display window). 4) When the driver performs an incorrect operation, a timely and prominent prompt should be provided. 5) Emphasize readability and comprehensibility. Prompt information should be concise and clear, and all graphic information should be easily understood by the machine. Use different colors to indicate information priority. 6) Try to keep the dimensions of interface components the same. Make full use of spatial relationships. The distance between graphic components on the screen should not be too far; if necessary, they can be enclosed in a box. 1.2 Advantages of Using UML in Design UML is a graphical representation, a visual graphical modeling language. UML defines the grammar of the modeling language, using meta-models to provide unified and relatively rigorous definitions and explanations of the basic concepts, terms, and representations in the language, giving the precise meanings of these concepts. UML provides a standard method for observing and displaying various characteristics of a system from different perspectives. In UML, any abstraction of the system from any perspective may require several model diagrams to describe it, and these model diagrams from different perspectives ultimately form the complete picture of the system. The UML language provides a model management view to describe the relationships between various models of the system. Through the mechanism provided by the model management view, system designers can organically decompose various model elements into packages at different levels, thereby describing the relationships between system models at different levels of granularity, greatly improving the readability and maintainability of the system design. This hierarchical and modular management mechanism of UML is very suitable for modeling the onboard human-machine interface of a train operation control system. However, manually drawing these diagrams by developers is not only extremely tedious but also makes it difficult to ensure consistency between different views. Therefore, a UML support environment is indispensable in actual software development. Rational's Rose is currently the most widely used and powerful UML case tool internationally, useful in several stages of the software development process. At the project initiation stage, Rose can generate use case models; in the refinement and construction stages, Rose can develop activity diagrams to show event flows; sequence diagrams and collaboration diagrams show the objects to be developed and their interactions; class diagrams developed by Rose show the relationships between objects; and component diagrams show the dependencies between system components. Furthermore, one of Rational Rose's most powerful features is its ability to generate code representing the model and reverse engineer the project code, ensuring the synchronization of code and object model. 2. Using UML to analyze and model the onboard human-machine interface of the train operation control system. 2.1 Introduction to common GUI models. Generally, a GUI model is abstracted into three parts: the interface presentation model, that is, the interface with the user; the dialogue process of the interface components, that is, the interaction between the user interface and the components to complete the user task; and the core application, that is, the functional modules that complete the application business logic. Several major GUI models, such as the Seeheim model, the MVC (Model-View-Controller) model, and the PAC (Presentation-Abstraction-Controller) model, are all based on this fundamental idea. Let's briefly explain the most basic Seeheim model. The Seeheim model divides the software architecture into four parts: Functional Core, Functional Core Adapter, Dialogue Controller, and Presentation Component. The Functional Core models the domain application. The Functional Core Adapter establishes a buffer between the user interface and the core application to reduce coupling between them. It provides synchronous or asynchronous data exchange between the user interface and the core application through some interaction protocols. The Dialogue Controller is the core part of the Seeheim model. It receives various input requests from the user through the interface component, transforms them, and exchanges data with the core module using the core application interface, ensuring consistency among multiple views to complete specific user tasks. Seeheim sub-models can be nested within the Dialogue Controller. This allows for modeling of the GUI system at different granularities. Component designs the specific interactive actions and input/output of the interface components. 2.2 Modeling of the vehicle-mounted human-machine interface (1) System requirements analysis Requirements analysis is to clarify what functions the vehicle-mounted human-machine interface is required to provide from the perspective of the peripheral system. In the past requirements analysis, there has never been a suitable tool to ensure the complete expression of system requirements, which directly led to the system being found to be slightly different from the actual situation during the post-completion testing. From the analysis stage, we introduce Rational Rose, an effective formal tool that fully supports UML, to express requirements in a complete and unambiguous language, simplifying communication during the development process. The vehicle-mounted human-machine interface of the train operation control system is a platform for information interaction between the vehicle-mounted equipment and the driver. The vehicle-mounted human-machine interface must ensure that the driver can set the relevant parameters of the train, obtain relevant status and data of the train and the line in real time, and respond to the commands and warnings issued by the vehicle-mounted equipment in a timely manner. The above requirements can be clearly represented by the use case diagram of UML. Figure 1 The following is a formal description of the use cases of the vehicle-mounted human-machine interface model. When the driver operates, he can first adjust the background color, resolution and other parameters of the interface as needed. At this time, the interface setting use case is executed. When the driver needs to configure parameters such as train length, the data operation use case is used. The initialization information of the train can also be displayed in the data use case. Considering that the driver needs to respond to the instructions issued by the vehicle-mounted equipment and make manual interventions, the command operation use case is also essential. The process of the driver operating the human-machine interface is described using a UML activity diagram. Figure 2 Activity diagram of the vehicle-mounted human-machine interface model (2) GUI model framework According to the principles of human-machine interface design. Considering the actual application background, this paper proposes a GUI model suitable for the vehicle-mounted human-machine interface of the train operation control system based on the Seeheim model, as shown in Figure 3. The model consists of three parts: the view module (View Mode1), the view controller (View Controller) and the core application interface (Core Interface). It is an object-oriented GUI design model. View module (View Mode1) The View Model describes the visual part of the user interface. It accepts driver input and provides visual information, and is the only part of the GUI model that directly interacts with the driver. Its design employs a multi-level hierarchical design approach, logically decomposing it into various views, each of which can be further decomposed into multiple sub-views. Sub-views are further decompositions and refinements of the parent view. The static characteristics of a view can include attributes related to its own presentation, such as size, position, and visibility. Its dynamic behavior includes actions within the view, collaboration with other views, and interactions with the driver. The modeling of the view module is centered on message responses, handling user events through message response processes. For example, responding to commands from in-vehicle devices or changing interface styles. When a View interacts with other views, it sends user messages to the View Controller for scheduling. The View Controller handles the transitions between different views. When a user completes a task involving several views, the View Controller is responsible for scheduling the switching between them. It receives messages from the View Model, and message response functions control the relevant views. Compared to the View Model, the View... The Controller is a coarse-grained user interaction model. It is responsible for decomposing the tasks that the user needs to complete and then mapping them to the various views of the user interface. The user interaction actions inside the view are described by the View Model. The Core Interface provides an interface for the view in the user interface to interact with the on-board equipment. The on-board equipment transmits train-related information to the user interface through this interface and displays it to the driver; when the driver needs to perform operations, it also sends information to the on-board equipment through this interface. The Core Interface establishes a buffer between the user interface and the on-board equipment, reducing the mutual coupling between the two and improving the maintainability and reusability of the code. Figure 3 On-board human-machine interface design model As can be seen from Figure 3, the View Controller is responsible for the switching and scheduling between various views. It receives events from various views. The View Controller is not visible in the system; it is only responsible for coordinating the calls between various views. The scheduling process can be described using a UML sequence diagram (Figure 4). Figure 4 Scheduling sequence diagram of View Controller (3) After the division and processing of packages and classes provide a detailed description of use cases, the functional model of the system and the in-vehicle human-machine interface model can be further defined and described. UML provides a tool for describing the overall framework of objects in the early stages of design—the package. A package is a group of objects. With the help of package diagrams, the relationships between groups of objects in the system can be described, and the hierarchy and structure between sets of system objects can be determined. Package diagrams are the result of the classification and summarization of use case diagrams, and they can often be directly derived from use case diagrams. As the only part of the GUI model that directly interacts with the driver, the view module package consists of three parts: the configuration interface, the data interface, and the operation interface (Figure 5). Figure 5 The view module package diagram, when further analyzed, yields a class diagram. To facilitate driver operation, relevant information is displayed together in the user interface, divided into five different classes. The speed class provides the driver with information on the train's target speed, permissible speed, mitigation speed, and current speed. The planning information class provides the driver with prompts within a selected distance area, such as station location, gradient information, starting position information, speed curve information, and geographical information, and can display the maximum limit curve. When the train brakes, the monitoring distance information class provides the predicted distance to the target stopping point and the predicted intervention time. Commands issued to the driver by the onboard equipment and manual interventions by the driver are implemented through the auxiliary driving information class and the monitoring information class. Each class is responsible for displaying relevant information, divided into five relatively concentrated parts in the human-machine interface. Their distribution is shown in Figure 6. Figure 6: Distribution of functional modules in the user interface. For each class, we should also identify attributes and operations. Some attribute and method definitions of the user interface class and the Core Interface class are shown in Figure 7. UML possesses powerful descriptive capabilities for object-oriented design, effectively describing various levels of the vehicle-mounted human-machine interface (HMI) model. UML use case diagrams clearly derive the View Model, View Controller, and Core Interface. Package diagrams and class diagrams in UML are used to decompose and refine the model. Sequence diagrams and activity diagrams are created to describe the collaborative relationships between modules and the state transition order within modules. The hierarchical and modular structure of the vehicle-mounted HMI can be well integrated with UML design tools at various granularities, seamlessly incorporating it into the overall software design process. 3. Implementation of the Vehicle-Mounted HMI for the Train Operation Control System. Rose creates components based on object design during the construction phase. Component diagrams show the compilation dependencies between components; selecting the language for each component generates framework code. Here, we use C++, an object-oriented programming language, and Microsoft's Visual C++ tool for software development. Based on the established GUI model, a dialog-based program architecture in Visual C++ is used to develop the software system. The entire software system consists of multiple dialog boxes. The View Model consists of multiple dialog boxes, each representing a different View. Transitions between Dialogues are handled by the View... The Controller controls the interface, using message mapping to achieve this functionality. During development, the various views in the interface are first implemented based on the package diagram and class diagram. Among the views of the human-computer interface, the operation interface is the most important and complex. The following uses the operation interface as an example to illustrate the development process. First, using Rational Rose's ability to automatically generate representation model code, the framework code for the operation interface is generated. The operation interface class described in Figure 7 is transformed into C++ code. The base class and various subclasses of the operation interface are well encapsulated, ensuring the synchronization between the code and the object model. With the framework code of the interface, we only need to add the code to implement the specific functions in the function body. This method avoids misunderstandings between designers and implementers, improving the overall integrity of the software. Figure 7: Operation Interface and Core The Interface class diagram will then detail the implementation of the five subclasses in the operation interface. During implementation, the human-computer interface principles discussed above should be fully considered. For example, in the assisted driving information class, when displaying current commands, prompts, and system status, if the driver is required to perform an operation, it will be displayed in yellow with a flashing yellow border. The flashing will stop when the operation is correct. After a situation occurs (such as leaving a tunnel) or begins (when the front of the train passes the location indicated by the command or prompt, such as lowering the pantograph), the command or prompt symbol is removed from this area. When the operation is incorrect, the symbol is displayed in red with a non-flashing red border until the command is correctly responded to. This allows the driver to observe the prompts promptly and take appropriate measures. Considering the need for comprehensibility and aesthetics, specific graphic symbols are used in the planning information class to represent command and prompt information and speed curve information. The driver can also activate these graphic symbols to obtain a second layer of information. When representing distances, logarithms are used to represent the distance range. Because pure logarithms cannot display distance values ​​close to zero, linear interpolation is used between 0 and 100. Figure 8 shows the driving operation interface. Figure 8 The actions within the driving operation interface View and the interactions with the driver are based on message responses, which process user events. For example, after receiving a braking message from the onboard equipment, the interface triggers the display of braking information in the upper left corner. The interference warning time is displayed in a square area in the upper left corner of the screen. The size of the square dynamically changes according to the time of the interference. Vertical rectangles indicate the warning distance to the train's impending stop (see Figure 9). Figure 9: The operation interface during braking. Following the same method, other Views in the View Model can be developed. Based on the View Model, to achieve interaction between different Views, the View Controller is implemented according to the descriptions in the activity diagram and scheduling sequence diagram. The View Controller's scheduling of different Views is shown in Figure 10. The driver first sets the parameters on the interface, then configures the initial train data through the data input interface. After configuration, confirmation is performed, and the driver enters the driving operation interface. When the driver needs to view or reconfigure the initial data, they can also switch between different Views according to the description in the state diagram. For the Core of the GUI model... The interface is implemented using a dedicated buffer within the program. Different containers (Vectors) are set up in the buffer to store data exchanged between the View and the onboard equipment. The onboard equipment stores train-related information in the Vector, from which the user interface can retrieve and display the corresponding data. Due to space limitations, some information cannot be fully represented in the interface. For example, the detection information area may not be able to fully display the information in the detection information class. The Core Interface allows users to select the corresponding information from the Vector using function keys, preventing important information from being ignored or overwritten, and improving code integrity. Figure 10 Initial Data Input Interface 4. Conclusion This paper deeply analyzes the functions to be implemented by the onboard human-machine interface of the train operation control system and designs a GUI model that can effectively fulfill the requirements. This model provides a progressively refined design framework for the requirements analysis, interface structuring and hierarchical design, and dynamic interaction task design of the onboard human-machine interface. During the modeling process, UML and its tool Rational were used. Rose established various views of the static and dynamic models, describing the system's functional requirements, functional flow, class structure and relationships, and interactions between objects. It provided a holistic plan and design for the software, effectively bridging the gap between interface design and core applications, improving the quality and efficiency of software design, reducing misunderstandings between designers regarding requirements, between designers themselves, and between designers and implementers, thus enhancing the consistency, completeness, and maintainability of the design. The advantages of this approach were fully demonstrated in the implementation of the onboard human-machine interface for the train operation control system.