A Locomotive Control System with a Dynamic Modular Architecture

Abstract

This invention discloses a locomotive control system with a dynamic modular architecture, including a configuration management layer, a visual debugging layer, a graphical hybrid programming layer, a drive management layer, a firmware generation layer, and a controller. The configuration management layer generates and manages XML configuration files and control system configuration files, and can update the configuration files based on debugging results. The graphical hybrid programming layer develops and generates control logic code. The drive management layer retrieves and matches driver files and constructs driver dependencies. The firmware generation layer combines the control logic code and driver dependency information to compile and generate binary firmware code. The controller receives configuration, firmware, and driver data from each layer, enabling hardware resource management, communication protocol adaptation, task scheduling, business logic control, and status feedback. The visual debugging layer performs system status monitoring, online debugging, and hot update control. This invention adopts a layered modular architecture, reducing system coupling, improving hardware compatibility and program development efficiency, adapting to complex locomotive control scenarios with mixed multi-protocols, ensuring real-time stability of the entire vehicle control, reducing maintenance difficulty, and possessing good versatility and scalability.

Description

Technical Field

[0001] This invention relates to the field of locomotive control technology, and in particular to a locomotive control system with a dynamic modular architecture. Background Technology

[0002] Current locomotive control systems generally adopt a static firmware architecture. Their operation revolves around a strong coupling between hardware drivers, protocol stacks, and control logic, forming a linear, closed process from initialization to execution. This architecture design results in a lack of dynamic adaptability in the control system, failing to meet the core requirements of modern locomotives for high reliability, high compatibility, and rapid iteration. In practical applications, it has exposed numerous technical defects, as follows: First, there is a tight coupling problem between hardware and protocol. Traditional locomotive control systems embed peripheral drivers and protocol stacks directly into the firmware. When hardware devices change or communication protocols need to be updated, the entire firmware must be recompiled and flashed. This not only significantly increases the maintenance difficulty of the locomotive system, but also leads to a lengthy system upgrade cycle and an inability to quickly respond to changes in field requirements.

[0003] Secondly, the hot-swap support capability is insufficient. Existing locomotive control system solutions cannot achieve hot-swap operations at the hardware layer or communication protocol. When unexpected situations such as sensor failure or extreme environmental changes occur, the system must be shut down for reconfiguration, which not only seriously affects the continuity of locomotive operation, but also incurs high operating costs due to downtime, making it particularly unsuitable for uninterrupted operation scenarios.

[0004] Secondly, the multi-protocol collaboration capability is weak. For heterogeneous communication protocols such as CAN and Modbus, the existing locomotive control system requires customized development, resulting in extremely low protocol compatibility and an inability to dynamically adapt to non-standard protocols. This greatly limits the compatibility of the locomotive control system with different peripherals and systems, making it difficult to meet the multi-device collaboration needs in complex industrial environments.

[0005] Finally, the development and debugging efficiency is low. The control logic of the control system relies on traditional code programming mode and lacks visual development tools. The debugging process requires physical breakpoints and manual variable monitoring, which not only prolongs the development cycle but also makes it easy to introduce faults due to human error, further increasing the cost of system development and maintenance.

[0006] The aforementioned technical deficiencies are particularly prominent in critical application scenarios such as long-distance trains and shunting on metallurgical and petrochemical railways, which operate 24 hours a day without interruption. In such scenarios, locomotive systems need to respond quickly to various sudden anomalies and environmental changes under the premise that the hardware is irreplaceable and there is zero downtime. Typical scenario requirements include: when a sensor suddenly fails (such as a short circuit in a temperature sensor), the faulty channel needs to be urgently disconnected and switched to a backup sensor or virtual value replacement to avoid false triggering of a fault shutdown; when extreme environmental changes occur (such as changes in high and low temperatures, sudden drops in air pressure on plateau railways, or strong electromagnetic interference), the range needs to be dynamically adjusted or the fault-tolerant communication protocol switched to ensure the reliability of data transmission and acquisition; when fault protection logic is adaptive (such as false alarms of high pressure caused by high external temperatures), the interlocking threshold needs to be modified in a timely manner or a compensation strategy needs to be executed to ensure that the system continues to operate within the safety boundary.

[0007] The common technical challenges in the aforementioned key scenarios are that the locomotive system hardware is not replaceable and the cost of downtime is extremely high. The existing static firmware architecture cannot achieve downtime-free repair and strategy optimization. There is an urgent need for a technical solution that can achieve minute-level fault repair, dynamic adaptation and strategy adjustment through pure software-layer hot updates, so as to solve many technical defects of the existing locomotive control system and meet the core requirement of uninterrupted operation of modern locomotives. Summary of the Invention

[0008] This invention provides a locomotive control system with a dynamic modular architecture to overcome the above-mentioned technical problems.

[0009] To achieve the above objectives, the technical solution of the present invention is as follows: A locomotive control system with a dynamic modular architecture includes: a configuration management layer, a visual debugging layer, a graphical hybrid programming layer, a drive management layer, a firmware generation layer, and a controller; The configuration management layer is used to generate and manage XML configuration files and control system configuration files. The XML configuration files contain engineering configuration data, hardware resource constraint data, driver configuration data, and protocol configuration data. The control system configuration files include hardware configuration data and hot-update configuration data. The configuration management layer is also used to receive verification and debugging results from the visual debugging layer to update the XML configuration file and the control system configuration file; The visualization debugging layer is used to receive hot update configuration data from the configuration management layer and running status data from the controller, output hot update instructions to the controller based on a preset method, and output verification and debugging results to the configuration management layer. The graphical hybrid programming layer is used to receive engineering configuration data and hardware resource constraint data from the configuration management layer, develop and generate control logic code, and output the control logic code to the firmware generation layer. The driver management layer is used to receive driver configuration data from the configuration management layer, retrieve matching driver files from local or external storage based on the driver configuration data, establish a dependency relationship between the driver file and the hardware interface and protocol type, i.e., driver dependency information, generate driver loading instructions based on the driver file, output the driver loading instructions to the dynamic protocol layer, and output the driver dependency information to the firmware generation layer. The firmware generation layer is used to receive control logic code from the graphical hybrid programming layer and driver dependency information from the driver management layer, compile it to generate binary firmware code, and output the binary firmware code to the controller. The controller is used to receive data from the configuration management layer, firmware generation layer, visual debugging layer and driver management layer, realize hardware resource management, communication protocol adaptation, system task scheduling and locomotive business logic control, and complete peripheral driver execution and operation status data feedback.

[0010] Furthermore, the controller includes a hardware abstraction layer, a dynamic protocol layer, a real-time operating system layer, and an application layer; The hardware abstraction layer is used to receive hardware configuration data from the configuration management layer, scan and identify physical peripheral hardware resources, output hardware initialization results and hardware acquisition data to the application layer, output raw communication data to the dynamic protocol layer, receive control commands from the application layer and drive external devices to execute, and receive hardware reconfiguration commands from the dynamic protocol layer and execute hardware parameter updates. The dynamic protocol layer is used to receive raw communication data from the hardware abstraction layer, extract key features by combining driver configuration data, maintain a protocol database containing features of various communication protocols, match the extracted key features to obtain the corresponding protocol features and protocol matching results; at the same time, it receives driver loading instructions from the driver management layer, outputs hardware reconfiguration instructions and sends them to the hardware abstraction layer, loads protocol processing logic corresponding to the protocol matching results, processes the raw communication data according to the protocol processing logic, obtains protocol parsing data and outputs it to the application layer; The real-time operating system layer is used to receive binary firmware code from the firmware generation layer and hot update instructions from the visual debugging layer, complete firmware image loading, task partition initialization and system resource scheduling configuration, execute tasks using preemptive scheduling, output task scheduling timing to the application layer, and output task suspension or resumption instructions to the dynamic protocol layer and hardware abstraction layer. The application layer is used to receive binary firmware code from the firmware generation layer, parse the binary firmware code and load it to obtain a control logic program; it is also used to receive hardware initialization results and hardware acquisition data from the hardware abstraction layer and protocol parsing data from the dynamic protocol layer, and execute locomotive business control logic based on the control logic program to perform logical operations, thereby outputting control commands to the hardware abstraction layer; it generates operating status data based on the hardware execution results, protocol communication status and control logic execution results, and outputs the operating status data to the visualization debugging layer.

[0011] Furthermore, the dynamic protocol layer includes a protocol feature analysis sublayer, a protocol library matching sublayer, and a dynamic protocol adaptation sublayer; The protocol feature analysis sublayer is used to receive raw communication data from the hardware abstraction layer, extract key features, namely hardware port configuration features, from the raw communication data based on driver configuration data, and output the hardware port configuration features to the protocol library matching sublayer. The protocol library matching sublayer is used to maintain a protocol database containing features of various communication protocols, receive hardware port configuration features from the protocol feature analysis sublayer, match the corresponding protocol features, and output the protocol matching results to the dynamic protocol adaptation sublayer. The dynamic protocol adaptation sublayer is used to receive protocol matching results from the protocol library matching sublayer and driver loading instructions from the driver management layer, thereby outputting hardware reconfiguration instructions and sending them to the hardware abstraction layer.

[0012] Furthermore, the dynamic protocol adaptation sublayer is also used to receive the protocol matching result from the protocol library matching sublayer, and according to the preset one-to-one mapping relationship between communication protocols and protocol processing logic, load the protocol processing logic corresponding to the protocol matching result, call the preset parsing function according to the protocol processing logic to unpack the original communication data, convert it into protocol parsing data that the application layer can recognize, and output the protocol parsing data to the application layer.

[0013] Furthermore, the driver management layer receives driver configuration data from the configuration management layer, retrieves matching driver files from local or external storage based on the driver configuration data, and establishes dependency relationships between the driver files and hardware interfaces and protocol types, i.e., driver dependency information. The specific steps for generating driver loading instructions based on the driver files include: The protocol type, hardware interface identifier, and feature hash value are extracted from the driver configuration data. The driver file is obtained by matching the feature hash value from local or external storage; the driver file includes a driver information structure. Establish the dependency relationships between the driver information structure and the protocol type and hardware interface identifier; The driver loading instruction is constructed based on the entry function address in the driver information structure and the current state of the target hardware interface.

[0014] Furthermore, the hardware abstraction layer receives hardware configuration data from the configuration management layer, scans and identifies physical peripheral hardware resources, specifically including: The hardware abstraction layer scans physical peripherals based on the hardware configuration data, collects hardware feature information and compares and matches it with preset hardware resource features, dynamically establishes the address mapping relationship between logical devices and physical hardware, completes the dynamic mapping and identification of hardware resources, and thus realizes plug-and-play peripherals.

[0015] Furthermore, the firmware generation layer is also used to calculate a hash check value based on the binary firmware code, and output it as check information along with the binary firmware code to the visual debugging layer so that the visual debugging layer can perform integrity verification.

[0016] Furthermore, the protocol database maintained by the protocol library matching sublayer includes feature data of CAN, Modbus, TRDP, MVB, and user-defined private protocols.

[0017] Furthermore, the dynamic protocol layer also includes a protocol dynamic hot-upgrading sublayer; The protocol dynamic hot-upgrade sublayer is used to monitor the current communication protocol type and hardware layer configuration status in real time. When it detects that a different communication protocol is being used or that the hardware layer configuration has changed, it works with the visualization debugging layer to obtain the driver file uploaded by the user and stores it in the non-volatile FLASH memory through the configuration management layer. At the same time, it sends a task pause command to the real-time operating system layer by layer to pause the associated communication tasks and hardware layer tasks, unload the old driver currently running, load the new driver file stored in FLASH, and link with the hardware abstraction layer to re-complete the hardware interface initialization configuration.

[0018] The present invention has the following beneficial effects: (1) The system adopts a layered modular architecture design, which divides the system into configuration management layer, visual debugging layer, graphical hybrid programming layer, drive management layer, firmware generation layer and controller. Each layer has clear responsibilities and clear interaction logic, which effectively reduces the coupling degree of the locomotive control system, facilitates system development, function iteration and later maintenance, and improves the versatility and scalability of the control system. (2) The control logic is developed by relying on the graphical hybrid programming layer. The firmware generation layer is combined with the driver dependency information to compile and generate binary firmware code, thereby realizing the automated compilation and solidification output of the control logic. The firmware code is distributed to the application layer and the real-time operating system layer respectively, providing a reliable program carrier for the operation of locomotive business logic and system task scheduling, reducing the development threshold of locomotive control program and improving the efficiency of program compilation and generation. (3) The driver management layer is set to search and match driver files and establish the dependency relationship between drivers, hardware interfaces and protocol types. It can accurately generate driver loading instructions and complete driver information distribution, realize intelligent matching and adaptation of protocol drivers, meet the adaptation needs of locomotives for diverse communication protocols and hardware interfaces, and improve system hardware compatibility. (4) The controller integrates hardware resource management, communication protocol adaptation, system task scheduling and locomotive business logic control functions. It can receive upper-level configuration, firmware and driver data, coordinate the execution of peripheral drivers and the feedback of running status, centrally realize the management and control of locomotive underlying hardware, protocol parsing, logic operation and status feedback, ensure the closed-loop operation of locomotive control process, and improve the real-time performance and stability of the whole vehicle control. (5) Configure a visual debugging layer, which relies on hot update configuration data and equipment operation status data to update the hot update command, and simultaneously feed back the verification debugging results to realize online system debugging, status monitoring and configuration iteration optimization. Debugging and maintenance can be completed without stopping the machine to disassemble the equipment, which greatly reduces the difficulty of locomotive operation and maintenance and improves the convenience of control system debugging and operation and maintenance efficiency.

[0019] In summary, this invention significantly improves the flexibility, maintainability, and development efficiency of locomotive control, and is suitable for complex industrial environments with high real-time requirements and mixed multi-protocols. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the structure of a locomotive control system with a dynamic modular architecture according to the present invention; Figure 2 This is a control timing diagram of a locomotive control system with a dynamic modular architecture according to the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] This embodiment provides a locomotive control system with a dynamic modular architecture, such as... Figure 1 and Figure 2 As shown, it includes: configuration management layer, visual debugging layer, graphical hybrid programming layer, driver management layer, firmware generation layer and controller; The configuration management layer is used to generate and manage XML configuration files and control system configuration files. The XML configuration files contain engineering configuration data, hardware resource constraint data, driver configuration data, and protocol configuration data. The control system configuration files include hardware configuration data and hot-update configuration data. Specifically, the configuration management layer outputs the engineering configuration data and hardware resource constraint data to the graphical hybrid programming layer, outputs the driver configuration data to the driver management layer, outputs the protocol configuration data to the dynamic protocol layer, outputs the hardware configuration data to the hardware abstraction layer, and outputs the hot update configuration data to the visual debugging layer; the configuration file is stored in the system's non-volatile memory FLASH, and the configuration file includes: the type, quantity, configuration parameters, communication type and protocol of the peripherals.

[0024] The configuration management layer is also used to receive verification and debugging results from the visual debugging layer to update the XML configuration file and the control system configuration file; Specifically, the configuration management layer provides the source of configuration parameters, the hardware abstraction layer completes the initialization configuration of physical peripheral communication parameters (such as the baud rate and sampling point setting of CAN communication), the driver management layer realizes intelligent retrieval and adaptation matching of protocol drivers, the dynamic protocol layer completes the loading and activation of non-standard protocols, and the real-time operating system layer completes the synchronous configuration of task time slices, priorities and timing constraints. The multi-level collaboration completes peripheral initialization, protocol driver matching and system task timing configuration at the same time as extracting configuration information.

[0025] The visualization debugging layer is used to receive hot update configuration data from the configuration management layer and running status data from the controller, output hot update instructions to the controller based on preset and existing waveform tracking, dynamic breakpoints and variable forced injection methods, and output verification and debugging results to the configuration management layer. Specifically, this embodiment supports runtime dynamic parsing. When a new peripheral or protocol is added, the system can parse and load the driver in real time simply by uploading the configuration file through the visual debugging layer, without needing to stop and restart.

[0026] The graphical hybrid programming layer is used to receive engineering configuration data and hardware resource constraint data from the configuration management layer, generate control logic code through a hybrid development of ladder diagrams, function block diagrams, and structured text, and output the control logic code to the firmware generation layer. Specifically, based on the graphical hybrid programming layer, users can construct control strategies by dragging and connecting graphical function blocks (ladder diagrams, FBDs) or writing structured text (ST), enabling program control of various devices in a train environment. The graphical hybrid programming layer, compiler, and real-time operating system (RTOS) layer work together to automatically compile this into binary code. The graphical hybrid programming layer first converts the user-designed logic (such as PID control and interlocking logic) into optimized intermediate code, and then, combined with hardware configuration and external interface mapping relationships (pointing to the APIs of the HAL and dynamic protocol layer), the compiler generates binary executable code for the target processor. The RTOS is responsible for loading this code into memory and scheduling its execution according to preset priorities, ensuring that the control logic can accurately and in real-time acquire input through the HAL, perform algorithmic calculations, and then drive the output through the HAL.

[0027] Specifically, the graphical hybrid programming layer lowers the development threshold, while the visual debugging layer integrates waveform tracking, dynamic breakpoints, and variable forced injection functions, shortening the debugging cycle by more than 50%.

[0028] The driver management layer is used to receive driver configuration data from the configuration management layer, retrieve matching driver files from local or external storage based on the driver configuration data, establish a dependency relationship between the driver file and the hardware interface and protocol type, i.e., driver dependency information, generate driver loading instructions based on the driver file, output the driver loading instructions to the dynamic protocol layer, and output the driver dependency information to the firmware generation layer. The firmware generation layer is used to receive control logic code from the graphical hybrid programming layer and driver dependency information from the driver management layer, compile it to generate binary firmware code, and output the binary firmware code to the application layer and the real-time operating system layer respectively. The controller is used to receive data from the configuration management layer, firmware generation layer, visual debugging layer and driver management layer, realize hardware resource management, communication protocol adaptation, system task scheduling and locomotive business logic control, and complete peripheral driver execution and operation status data feedback.

[0029] Specifically, the control system in this embodiment is developed using Visual Studio Code, and software development is completed within a Windows PC environment. The hardware configuration used is as follows: Processor: Cortex™-M4 CPU; Power supply: Input DC110V; Interfaces: CAN; Serial port; Ethernet (for debugging).

[0030] In a specific embodiment, the controller includes a hardware abstraction layer (HAL), a dynamic protocol layer, a real-time operating system layer, and an application layer; The hardware abstraction layer is used to receive hardware configuration data from the configuration management layer, scan and identify physical peripheral hardware resources, output hardware initialization results and hardware acquisition data to the application layer, output raw communication data to the dynamic protocol layer, receive control commands from the application layer and drive external devices to execute, and receive hardware reconfiguration commands from the dynamic protocol layer and execute hardware parameter updates. The dynamic protocol layer is used to receive raw communication data from the hardware abstraction layer, extract key features by combining driver configuration data, maintain a protocol database containing features of various communication protocols, match the extracted key features to obtain the corresponding protocol features and protocol matching results; at the same time, it receives driver loading instructions from the driver management layer, outputs hardware reconfiguration instructions and sends them to the hardware abstraction layer, loads protocol processing logic corresponding to the protocol matching results, processes the raw communication data according to the protocol processing logic, obtains protocol parsing data and outputs it to the application layer; Specifically, this embodiment separates hardware drivers and protocol parsing through a hardware abstraction layer and a dynamic protocol layer. The configuration file is stored independently in FLASH, supporting plug-and-play peripherals and hot protocol updates. It eliminates the need to recompile firmware, thus reducing maintenance costs.

[0031] The real-time operating system layer is used to receive binary firmware code from the firmware generation layer and hot update instructions from the visual debugging layer, complete firmware image loading, task partition initialization and system resource scheduling configuration, execute tasks using preemptive scheduling, output task scheduling timing to the application layer, and output task suspension or resumption instructions to the dynamic protocol layer and hardware abstraction layer. Specifically, the real-time operating system layer is also used to suspend only the communication and data acquisition tasks associated with the updated content during hot updates, while maintaining the continuous operation of the locomotive's traction, braking, and temperature closed-loop core control tasks. The preemptive scheduling mechanism ensures timely response for high-priority tasks (such as temperature closed-loop control), and combined with dynamic allocation of hardware resources, the system response latency is reduced to the microsecond level, guaranteeing the locomotive's control accuracy and safety.

[0032] The application layer is used to receive binary firmware code from the firmware generation layer, parse the binary firmware code and load it to obtain a control logic program; it is also used to receive hardware initialization results and hardware acquisition data from the hardware abstraction layer and protocol parsing data from the dynamic protocol layer, and execute locomotive business control logic based on the control logic program to perform logical operations, thereby outputting control commands to the hardware abstraction layer; it generates operating status data based on the hardware execution results, protocol communication status and control logic execution results, and outputs the operating status data to the visualization debugging layer.

[0033] Specifically, during system runtime, users can monitor variable waveforms in real time, set breakpoints to pause the program, and forcibly modify I / O values ​​through the visual debugging layer. The visual debugging layer connects to the controller via communication channels (Ethernet / CAN / serial port). When monitoring variables, the tool accesses application-layer memory data through the RTOS interface or reads real-time hardware register values ​​through the HAL interface; setting breakpoints utilizes the RTOS's debugging hook mechanism to insert interrupts at specific code locations; forcing I / O values ​​involves directly writing to physical ports or analog outputs through the HAL's debugging interface. Waveform tracing and viewing raw communication messages may also involve the debugging interface of the dynamic protocol layer. All these operations are performed in near real-time, providing users with convenient and intuitive debugging and troubleshooting methods.

[0034] Specifically, the locomotive control system's operation begins with the dynamic loading and parsing of configuration files. A visual debugging tool transmits the configuration file to the dynamic protocol layer for parsing. The hardware abstraction layer initializes physical peripheral resources and dynamically loads and configures the communication protocol stack based on the hardware interface parameters defined in the configuration file. Developers quickly construct control strategies in a graphical hybrid programming platform by dragging and dropping function blocks and connecting logic links. The graphical platform converts this control logic into intermediate code, embeds specific header data, and ultimately generates optimized binary machine code, which is then loaded into the controller. The real-time operating system layer employs a preemptive scheduling mechanism, dynamically allocating processor resources according to task priority to ensure timely execution of high real-time tasks such as temperature closed-loop control, while coordinating the timing synchronization of periodic tasks such as communication protocol parsing. The application layer executes the compiled control logic, acquires real-time input signals from the controlled device through the hardware abstraction layer, generates execution instructions through control algorithms, and outputs them to the drive interface, completing the closed-loop control link from data acquisition to execution response.

[0035] In a specific embodiment, the dynamic protocol layer includes a protocol feature analysis sublayer, a protocol library matching sublayer, and a dynamic protocol adaptation sublayer; The protocol feature analysis sublayer is used to receive raw communication data from the hardware abstraction layer, extract key features, namely hardware port configuration features, from the raw communication data based on driver configuration data, and output the hardware port configuration features to the protocol library matching sublayer. The protocol library matching sublayer is used to maintain a protocol database containing features of various communication protocols, receive hardware port configuration features from the protocol feature analysis sublayer, match the corresponding protocol features, and output the protocol matching results to the dynamic protocol adaptation sublayer. Specifically, the protocol library matches the protocol features of pre-stored standard protocols and non-standard custom protocols in the sublayer to form a protocol database. Subsequently, according to the configuration update instructions, it supports adding, modifying, and deleting protocol features during operation. The protocol database is maintained in real time, that is, updated and synchronized, to ensure that the protocol features can be used for feature extraction and protocol matching at any time.

[0036] The dynamic protocol adaptation sublayer is used to receive protocol matching results from the protocol library matching sublayer and driver loading instructions from the driver management layer, thereby outputting hardware reconfiguration instructions and sending them to the hardware abstraction layer.

[0037] Specifically, the dynamic protocol adaptation sublayer has a preset mapping relationship between communication protocols, driver types, and hardware interface parameters. After receiving the protocol matching result output by the protocol library matching sublayer and the driver loading instruction output by the driver management layer, it determines the communication protocol type and protocol parameters to be adapted based on the protocol matching result, determines the corresponding hardware interface configuration parameters and driver resource configuration requirements based on the driver loading instruction, performs parameter association matching in combination with the pre-stored mapping relationship, generates and outputs a hardware reconfiguration instruction that adapts to the current protocol and driver configuration, and sends it to the hardware abstraction layer.

[0038] The dynamic protocol adaptation sublayer matches the communication protocol, driver type, and hardware interface parameters based on the protocol matching result, generates hardware reconfiguration instructions to complete the underlying hardware link configuration, loads the protocol processing logic of the corresponding communication protocol, and outputs the protocol parsing and running status to the real-time operating system layer to realize system task timing synchronization and scheduling coordination.

[0039] In a specific embodiment, the dynamic protocol adaptation sublayer is further configured to receive protocol matching results from the protocol library matching sublayer, and, based on a preset one-to-one mapping relationship between communication protocols and protocol processing logic, load the protocol processing logic corresponding to the protocol matching result. It then calls a preset parsing function according to the protocol processing logic to unpack the original communication data, converting it into protocol parsing data recognizable by the application layer, and outputs the protocol parsing data to the application layer. Specifically, the dynamic protocol adaptation sublayer is also configured to send a task suspension request to the real-time operating system layer when the protocol type changes or the driver is updated, and to send a task resumption request after the protocol loading is complete.

[0040] In a specific embodiment, the driver management layer receives driver configuration data from the configuration management layer, retrieves matching driver files from local or external storage based on the driver configuration data, and establishes dependency relationships, i.e., driver dependency information, between the driver files and hardware interfaces and protocol types. The specific steps for generating driver loading instructions based on the driver files include: The protocol type, hardware interface identifier, and feature hash value are extracted from the driver configuration data. The driver file is obtained by matching the feature hash value from local or external storage; Specifically, in this embodiment, the preset driver description information is traversed in the fixed storage area of ​​the internal FLASH (by the driver symbol table or driver information structure array predefined by the linker script), and driver matching is achieved by feature hash comparison.

[0041] The driver file includes a driver information structure (stored at a fixed address in FLASH), which includes the hardware abstraction layer version required by the driver, the required peripheral resources (such as CAN channel number, GPIO pin), interrupt priority, and other dependent driver identifiers. Establish the dependency relationships between the driver information structure and the protocol type and hardware interface identifier; The driver loading instruction (including function pointer, hardware interface number, and execution timing) is constructed based on the entry function address (such as init_func, parse_func) in the driver information structure and the current state of the target hardware interface.

[0042] Specifically, the driver loading instruction is sent to the dynamic protocol layer for loading via inter-layer function callbacks or message queues.

[0043] In a specific embodiment, the hardware abstraction layer receives hardware configuration data from the configuration management layer, scans and identifies physical peripheral hardware resources, specifically including: The hardware abstraction layer scans physical peripherals based on the hardware configuration data, collects hardware feature information and compares and matches it with preset hardware resource features, dynamically establishes the address mapping relationship between logical devices and physical hardware, and completes the dynamic mapping and identification of hardware resources such as DI, DO, AI, AO, CAN, serial port and Ethernet, thereby realizing plug-and-play peripherals.

[0044] In a specific embodiment, the firmware generation layer is also used to calculate a hash check value based on the binary firmware code, and output it as check information along with the binary firmware code to the visual debugging layer so that the visual debugging layer can perform integrity verification.

[0045] In a specific embodiment, the protocol database maintained by the protocol library matching sublayer includes feature data of CAN, Modbus, TRDP, MVB, and user-defined private protocols.

[0046] Specifically, the visualization debugging layer is also used to send status synchronization instructions to the configuration management layer, dynamic protocol layer, and hardware abstraction layer after hot update is completed, so as to achieve data consistency across the entire system.

[0047] In a specific embodiment, the dynamic protocol layer further includes a protocol dynamic hot-upgrade sublayer; The protocol dynamic hot-upgrade sublayer is used to monitor the current communication protocol type and hardware layer configuration status in real time. When it detects that a different communication protocol is being used or that the hardware layer configuration has changed, it works with the visualization debugging layer to obtain the driver file uploaded by the user and stores it in the non-volatile FLASH memory through the configuration management layer. At the same time, it sends a task pause command to the real-time operating system layer by layer to pause the associated communication tasks and hardware layer tasks, unload the old driver currently running, load the new driver file stored in FLASH, and link with the hardware abstraction layer to re-complete the hardware interface initialization configuration.

[0048] Specifically, this embodiment incorporates multiple protocols into the program. By scanning the parameters in the configuration file in real time, the program determines which protocol to call. It features a built-in standard protocol stack and a dynamic driver loading mechanism. Standard protocols are processed by the built-in standard protocol stack, while non-standard protocols are parsed by dynamically loaded drivers. It supports parallel processing of industrial protocols such as CAN and Modbus with user-defined protocols, adapts to complex industrial scenarios, and has strong scalability.

[0049] In this embodiment, based on the locomotive control system, a hot update process for protocol parsing rules can be executed in the background during the normal online operation of the locomotive. Under the premise that the locomotive maintains its operating condition, without stopping, without powering down, and without interrupting the core control and interlocking operations of the entire vehicle, only the associated protocol communication subtasks are temporarily suspended. After unloading the old protocol parsing rules and drivers, loading the new protocol parsing rules and drivers, and reinitializing the hardware interfaces, the communication tasks are resumed and bus timing synchronization is completed. This process does not require the locomotive to be stopped and powered off, nor does it require restarting the control system, achieving seamless online hot updates of protocol parsing rules during locomotive operation. Simultaneously, this hot update process can also be executed during offline configuration upgrades while the locomotive is stopped and waiting in the locomotive depot or during maintenance and debugging phases. The specific steps for hot updating the protocol parsing rules include: (1) File upload and storage The visual debugging layer receives the driver file uploaded by the user, and the configuration management layer performs partitioned storage and generates file metadata (size, CRC16 check value, storage address). (2) Integrity verification The dynamic protocol layer performs CRC16 verification based on file metadata, extracts driver signatures such as protocol type and interface list. If the verification fails, an error code (ERR_DRV_SIGNATURE) is generated; if the verification passes, driver signatures (protocol type and dependent interface list) are generated. (3) Task context saving The real-time operating system layer is responsible for task location, task suspension, and context saving. (4) Release of old driving resources The driver management layer controls driver resources, releases driver code segments in the dynamic memory pool based on driver signatures, preserves static memory pool resources (data buffers such as DMA), and obtains a list of free memory block addresses to be released. (5) New driver loading and binding Based on the address of the free memory block and the driver file path, the dynamic linker loads the driver into the specified memory region and parses the specific content. According to the protocol content, it binds the HAL interface (such as HAL_UART_Init()) and outputs the driver function entry address table. (6) Hardware reconfiguration Based on the driver function entry address table, the driver initialization function (such as DRV_RS485_Init()) is called, and the hardware status word (success / failure) is output. (7) Task recovery and synchronization Based on the hardware status word and driver signature, the real-time operating system layer resumes the task, sends synchronization signals (such as CAN heartbeat frames) to the controlled device and monitors the response, and finally outputs a hot update status code (0 = success, non-0 = error code).

[0050] Specifically, when hardware modules or protocol drivers change, this control system can pause associated tasks, dynamically load the new driver, and reinitialize the interface, ensuring that core control tasks remain unaffected and achieving a "zero-downtime" upgrade, thus improving system availability. Through layered and coordinated operation, this control system ultimately outputs device control commands to drive locomotive peripherals to perform actions, outputs standardized protocol parsing data internally for control logic calculations, and simultaneously outputs operational status monitoring data and hot-update configuration commands, enabling automatic control of locomotive equipment, dynamic protocol adaptation, and non-stop debugging and optimization.

[0051] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A locomotive control system with a dynamic modular architecture, characterized in that, include: Configuration management layer, visual debugging layer, graphical hybrid programming layer, driver management layer, firmware generation layer, and controller; The configuration management layer is used to generate and manage XML configuration files and control system configuration files. The XML configuration files contain engineering configuration data, hardware resource constraint data, driver configuration data, and protocol configuration data. The control system configuration files include hardware configuration data and hot-update configuration data. The configuration management layer is also used to receive verification and debugging results from the visual debugging layer to update the XML configuration file and the control system configuration file; The visualization debugging layer is used to receive hot update configuration data from the configuration management layer and running status data from the controller, output hot update instructions to the controller based on a preset method, and output verification and debugging results to the configuration management layer. The graphical hybrid programming layer is used to receive engineering configuration data and hardware resource constraint data from the configuration management layer, develop and generate control logic code, and output the control logic code to the firmware generation layer. The driver management layer is used to receive driver configuration data from the configuration management layer, retrieve matching driver files from local or external storage based on the driver configuration data, establish a dependency relationship between the driver file and the hardware interface and protocol type, i.e., driver dependency information, generate driver loading instructions based on the driver file, output the driver loading instructions to the dynamic protocol layer, and output the driver dependency information to the firmware generation layer. The firmware generation layer is used to receive control logic code from the graphical hybrid programming layer and driver dependency information from the driver management layer, compile it to generate binary firmware code, and output the binary firmware code to the controller. The controller is used to receive data from the configuration management layer, firmware generation layer, visual debugging layer and driver management layer, realize hardware resource management, communication protocol adaptation, system task scheduling and locomotive business logic control, and complete peripheral driver execution and operation status data feedback.

2. The locomotive control system with a dynamic modular architecture according to claim 1, characterized in that, The controller includes a hardware abstraction layer, a dynamic protocol layer, a real-time operating system layer, and an application layer; The hardware abstraction layer is used to receive hardware configuration data from the configuration management layer, scan and identify physical peripheral hardware resources, output hardware initialization results and hardware acquisition data to the application layer, output raw communication data to the dynamic protocol layer, receive control commands from the application layer and drive external devices to execute, and receive hardware reconfiguration commands from the dynamic protocol layer and execute hardware parameter updates. The dynamic protocol layer is used to receive raw communication data from the hardware abstraction layer, extract key features by combining driver configuration data, maintain a protocol database containing features of various communication protocols, match the extracted key features to obtain the corresponding protocol features and protocol matching results; at the same time, it receives driver loading instructions from the driver management layer, outputs hardware reconfiguration instructions and sends them to the hardware abstraction layer, loads protocol processing logic corresponding to the protocol matching results, processes the raw communication data according to the protocol processing logic, obtains protocol parsing data and outputs it to the application layer; The real-time operating system layer is used to receive binary firmware code from the firmware generation layer and hot update instructions from the visual debugging layer, complete firmware image loading, task partition initialization and system resource scheduling configuration, execute tasks using preemptive scheduling, output task scheduling timing to the application layer, and output task suspension or resumption instructions to the dynamic protocol layer and hardware abstraction layer. The application layer is used to receive binary firmware code from the firmware generation layer, parse the binary firmware code and load it to obtain a control logic program; it is also used to receive hardware initialization results and hardware acquisition data from the hardware abstraction layer and protocol parsing data from the dynamic protocol layer, and run the locomotive business control logic to perform logical operations based on the control logic program, thereby outputting control commands to the hardware abstraction layer. Based on the hardware execution results, protocol communication status, and control logic execution results, runtime status data is generated and output to the visualization debugging layer.

3. The locomotive control system with a dynamic modular architecture according to claim 1, characterized in that, The dynamic protocol layer includes a protocol feature analysis sublayer, a protocol library matching sublayer, and a dynamic protocol adaptation sublayer; The protocol feature analysis sublayer is used to receive raw communication data from the hardware abstraction layer, extract key features, namely hardware port configuration features, from the raw communication data based on driver configuration data, and output the hardware port configuration features to the protocol library matching sublayer. The protocol library matching sublayer is used to maintain a protocol database containing features of various communication protocols, receive hardware port configuration features from the protocol feature analysis sublayer, match the corresponding protocol features, and output the protocol matching results to the dynamic protocol adaptation sublayer. The dynamic protocol adaptation sublayer is used to receive protocol matching results from the protocol library matching sublayer and driver loading instructions from the driver management layer, thereby outputting hardware reconfiguration instructions and sending them to the hardware abstraction layer.

4. The locomotive control system with a dynamic modular architecture according to claim 3, characterized in that, The dynamic protocol adaptation sublayer is also used to receive protocol matching results from the protocol library matching sublayer, and according to the preset one-to-one mapping relationship between communication protocols and protocol processing logic, load the protocol processing logic corresponding to the protocol matching result, call the preset parsing function according to the protocol processing logic to unpack the original communication data, convert it into protocol parsing data that the application layer can recognize, and output the protocol parsing data to the application layer.

5. The locomotive control system with a dynamic modular architecture according to claim 4, characterized in that, The driver management layer receives driver configuration data from the configuration management layer, retrieves matching driver files from local or external storage based on the driver configuration data, and establishes dependency relationships between the driver files and hardware interfaces and protocol types, i.e., driver dependency information. The specific steps for generating driver loading instructions based on the driver files include: The protocol type, hardware interface identifier, and feature hash value are extracted from the driver configuration data. The driver file is obtained by matching the feature hash value from local or external storage; the driver file includes a driver information structure. Establish the dependency relationships between the driver information structure and the protocol type and hardware interface identifier; The driver loading instruction is constructed based on the entry function address in the driver information structure and the current state of the target hardware interface.

6. The locomotive control system with a dynamic modular architecture according to claim 1, characterized in that, The hardware abstraction layer receives hardware configuration data from the configuration management layer, scans and identifies physical peripheral hardware resources, specifically including: The hardware abstraction layer scans physical peripherals based on the hardware configuration data, collects hardware feature information and compares and matches it with preset hardware resource features, dynamically establishes the address mapping relationship between logical devices and physical hardware, completes the dynamic mapping and identification of hardware resources, and thus realizes plug-and-play peripherals.

7. The locomotive control system with a dynamic modular architecture according to claim 4, characterized in that, The firmware generation layer is also used to calculate a hash check value based on the binary firmware code, and output it as check information along with the binary firmware code to the visual debugging layer so that the visual debugging layer can perform integrity verification.

8. The locomotive control system with a dynamic modular architecture according to claim 1, characterized in that, The protocol database maintained by the protocol library matching sublayer includes feature data for CAN, Modbus, TRDP, MVB, and user-defined private protocols.

9. The locomotive control system with a dynamic modular architecture according to claim 4, characterized in that, The dynamic protocol layer also includes a protocol dynamic hot-upgrading sublayer; The protocol dynamic hot-upgrade sublayer is used to monitor the current communication protocol type and hardware layer configuration status in real time. When it is detected that a non-original communication protocol is being used or the hardware layer configuration has changed, it works with the visualization debugging layer to obtain the driver file uploaded by the user and stores it in non-volatile FLASH memory through the configuration management layer. Simultaneously, task pause commands are sent to the real-time operating system layer by layer to pause associated communication tasks and hardware layer tasks, uninstall the currently running old driver, load the new driver file stored in FLASH, and coordinate with the hardware abstraction layer to re-complete the hardware interface initialization configuration.

Images