Domain controller-oriented configuration deployment and monitoring apparatus, method, and vehicle
Patent Information
- Application Number
- CN202611163292.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-03
- Publication Date
- 2026-10-30
AI Technical Summary
[0003]目前,列车软件配置部署主要依赖传统车载物理机部署方式,且受车载环境(例如,空间有限、资源紧张、振动强烈、电磁干扰强、温度范围宽)的限制,部署方案存在明显的短板
通过用户界面层获取待部署应用的应用需求和域控制器的配置需求,能够将分散的应用配置、资源配置和平台配置统一形成配置部署任务。业务逻辑层能够根据配置部署任务及待部署应用的运行特征,建立待部署应用、虚拟化资源和平台配置之间的关联关系,进而能够按照该关联关系生成包括目标程序、虚拟化运行环境和平台配置的部署对象。通信与数据交互层进一步将部署对象下发至域控制器,并将部署执行结果和运行数据反馈至业务逻辑层,以生成供用户界面层呈现的监视信息。采用上述方案,能够将应用需求获取、虚拟化资源规划、程序及配置生成、文件部署和运行监视组织为连续的闭环处理过程,从而降低应用软件与特定物理控制器之间的耦合程度,提高域控制器的配置部署效率和资源利用效率,并提高配置部署过程的一致性及可追溯性。
Smart Images

Figure CN123011303A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of rail transit technology, and more specifically, to a configuration, deployment, and monitoring device, method, and vehicle for domain controllers. Background Technology
[0002] With the rapid development of rail transit technology, the scale of train software systems is constantly expanding and their architecture is becoming increasingly complex. Onboard software has become the core of ensuring the safe and efficient operation of trains. Onboard software encompasses multiple categories, including train control systems (ATP / ATO), traction control systems, diagnostic and health management systems (PHM), onboard communication network software, and passenger information systems. Among these, the train control system is a critical safety software, with extremely high requirements for real-time performance and reliability.
[0003] Currently, the deployment of train software configuration mainly relies on the traditional on-board physical machine deployment method, and is limited by the on-board environment (e.g., limited space, scarce resources, strong vibration, strong electromagnetic interference, wide temperature range), resulting in obvious shortcomings in the deployment scheme.
[0004] In traditional vehicle-mounted physical unit deployment methods, different control systems are maintained by their own configuration and deployment software. Furthermore, the deployment process requires maintenance personnel to manually complete a series of operations on-site, such as hardware debugging of the vehicle controller, operating system installation, software environment configuration, dependency package adaptation, and permission settings, resulting in low deployment efficiency.
[0005] The information disclosed in the background section is only intended to enhance the understanding of the background of this application, and therefore may contain information that is not part of the prior art known to those skilled in the art. Summary of the Invention
[0006] This application provides a configuration deployment and monitoring device, method, and vehicle for domain controllers, which can improve configuration deployment efficiency and resource utilization efficiency.
[0007] According to a first aspect of the embodiments of this application, a configuration, deployment, and monitoring apparatus for a domain controller is provided, comprising: The user interface layer is used to obtain the application requirements of the application to be deployed and the configuration requirements for the domain controller, form a configuration deployment task, and present the execution results and monitoring information of the configuration deployment task; The business logic layer, connected to the user interface layer, is used to establish the association between the application to be deployed, the virtualization resources of the domain controller, and the platform configuration based on the configuration deployment task and the running characteristics of the application to be deployed, and to generate a deployment object for the domain controller to load based on the association. The deployment object includes the target program, virtualization runtime environment, and platform configuration corresponding to the application to be deployed. A communication and data interaction layer is set between the business logic layer and the domain controller. It is used to provide remote control interaction, file interaction and runtime data interaction for the business logic layer, so as to send the deployment object to the domain controller and obtain the deployment execution results and runtime data returned by the domain controller. The business logic layer is further configured to generate the monitoring information based on the deployment execution results and the running data, and provide the monitoring information to the user interface layer.
[0008] Optionally, the user interface layer includes at least one of the following: partition configuration interface, resource configuration interface, board configuration interface, application configuration interface, variable configuration interface, file configuration interface, configuration monitoring interface, and topology monitoring interface. At least one of the partition configuration interface and the resource configuration interface is used to obtain the application requirements of the application to be deployed and the virtualization resource configuration requirements of the domain controller. At least one of the board configuration interface, the application configuration interface, the variable configuration interface, and the file configuration interface is used to obtain the platform configuration requirements for the domain controller. The configuration monitoring interface is used to present at least one of the following: the execution result of the configuration deployment task, the running status of the application to be deployed, and the resource running status of the domain controller; The topology monitoring interface is used to display the train network topology, as well as the status of network nodes and communication links in the train network topology.
[0009] Optionally, the business logic layer includes a planning and scheduling module, which includes an algorithm planning submodule and a virtualization configuration submodule. The algorithm planning submodule is used to obtain the hardware resource parameters of the domain controller and the application requirement parameters of the application to be deployed from the configuration deployment task; control the application to be deployed to run in the test environment provided by the domain controller through the communication and data interaction layer, and obtain the execution time and resource consumption of the application to be deployed; determine the processor core configuration of the virtualization partition used to host the application to be deployed based on the comparison result between the execution time and the maximum allowed execution time in the application requirement parameters; limit the time interval between the start time of two consecutive executions of the application to be deployed based on the execution cycle and the maximum allowed jitter time; and determine the processor core configuration of the virtualization partition used to host the application to be deployed based on the execution cycle of the application to be deployed. The system defines the start and end times of each execution of the application to be deployed, based on the period, execution time, and deadline, and defines the sequential relationship between two adjacent executions based on their start and end times. It also determines candidate partition deployment relationships that meet the operational requirements of the application to be deployed based on the hardware resource parameters, processor core configuration, resource usage, and the limitations on the start time, end time, and sequential relationship. Finally, it determines a target partition deployment relationship from the candidate partition deployment relationships based on the execution time span of multiple applications to be deployed within the same supercycle and the differences in task execution load between different virtualization partitions. Finally, it determines the association relationship based on the target partition deployment relationship. The virtualization configuration submodule is used to generate the virtualization runtime environment based on the association relationship.
[0010] Optionally, the algorithm planning submodule is further configured to convert the hardware resource parameters, the processor core configuration, the resource occupancy, and the constraints on the start time, the end time, and the sequence relationship into satisfiability modular theory constraint expressions; The satisfiability of the satisfiability modulo theoretical constraint expression is determined to obtain the candidate partition deployment relationship that satisfies the running requirements of the application to be deployed and the hardware resource limitations of the domain controller. A comprehensive objective function is constructed based on the execution time span and the differences in task execution load; and an extreme value search is performed on the comprehensive objective function within the feasible domain formed by the candidate partition deployment relationship through iterative search to determine the target partition deployment relationship.
[0011] Optionally, the test environment is a single-partition, single-core test environment in which a virtualization partition and a processor core are independently allocated to each of the applications to be deployed; The algorithm planning submodule is also used to transmit the application to be deployed to the single-partition single-core test environment through the communication and data interaction layer; control the application to be deployed to run in the single-partition single-core test environment; acquire at least one of the test data generated during the operation of the application to be deployed, including application execution time, processor usage, memory usage, and execution jitter; and determine the running characteristics of the application to be deployed based on the test data.
[0012] Optionally, the business logic layer further includes a configuration management module and an application development module, wherein: The planning and scheduling module is also used to generate virtualization runtime environment files that constitute the virtualization runtime environment based on the association relationship; The application development module is used to generate the target program corresponding to the application to be deployed. The configuration management module is used to generate a platform configuration file based on the platform configuration. The business logic layer is also used to organize the target program, the virtualization runtime environment file, and the platform configuration file into the deployment object according to the association between the application to be deployed and the virtualization partition.
[0013] Optionally, the virtualization configuration submodule is used to determine the processor resources, memory resources, and device resources corresponding to each virtualization partition according to the association relationship; remotely log in to the preset cross-compilation environment through the communication and data interaction layer; generate at least one of a device tree file, resource configuration file, kernel image, and file system corresponding to each virtualization partition according to the processor resources, the memory resources, and the device resources; and use at least one of the device tree file, the resource configuration file, the kernel image, and the file system as the virtualization runtime environment file.
[0014] Optionally, the application development module is used to obtain the source code of the application to be deployed; perform at least one of syntax rule checking, variable reference legality verification, and logical conflict detection on the source code; cross-compile the verified source code according to the target device architecture of the domain controller, and link system libraries and user-defined libraries to generate the target program; generate integrity verification information of the target program, and associate the integrity verification information with the target program in the deployment object; The source program includes at least one of a control program conforming to the IEC 61131-3 standard and a C language application.
[0015] Optionally, the configuration management module is used to manage at least one of the following configuration information according to a unified configuration data structure: application operation configuration, variable configuration, variable list configuration, message storage configuration, log storage configuration, message function configuration, log function configuration, network configuration, and board configuration; and to verify the configuration information and save the verified configuration information as the platform configuration file in XML format, or read the configuration information from the platform configuration file.
[0016] Optionally, the communication and data interaction layer includes an SSH client, an FTP client, and a TCP client, wherein: The SSH client is used to remotely log in to the virtual machine, cross-compilation environment, or domain controller, and to perform at least one of the following operations: application compilation, virtualization runtime environment construction, and remote control. The FTP client is used to transfer files between the configuration deployment and monitoring device and the domain controller; The TCP client is used to transmit control commands and operational data between the configuration deployment and monitoring device and the domain controller.
[0017] Optionally, the business logic layer further includes a file transfer module; The file transfer module is used to invoke the FTP client to establish or disconnect a file transfer connection between the configuration deployment and monitoring device and the domain controller, and to perform at least one of the following operations on remote files in the domain controller: refresh, upload, and download; the remote files include at least one of the following: application dynamic library files, platform configuration files, log files, and virtualization runtime environment files; The file transfer module and the communication and data interaction layer are used to transfer the deployment object to the domain controller through the FTP client; and to perform integrity verification on the target program according to the integrity verification information associated with the target program. Specifically, after the integrity verification is passed, a loading command is sent to the domain controller via the SSH client or the TCP client, so that the domain controller establishes the corresponding virtualization runtime environment according to the association relationship, and loads the target program and the platform configuration into the corresponding virtualization runtime environment; and the loading result returned by the domain controller is obtained through the TCP client, and the loading result is provided to the business logic layer as the deployment execution result.
[0018] Optionally, the business logic layer includes a monitoring and management module, which is used to obtain the running data returned by the domain controller through the communication and data interaction layer. The running data includes at least one of application running status, processor load, memory usage, device temperature, key variable data, and train network topology data. The system determines at least one of the following based on the operational data: the operational status of the application to be deployed, the system resource usage of the domain controller, the status of key variables, and the status of the train network; and generates the monitoring information based on the determined operational status, system resource usage, status of key variables, or status of the train network, and provides the monitoring information to the user interface layer.
[0019] Optionally, the user interface layer is used to obtain variable selection information for the variable to be observed; The monitoring and management module is also used to determine the application to be deployed corresponding to the variable to be observed based on the variable selection information and the platform configuration; send a variable data request corresponding to the variable to be observed to the domain controller through the communication and data interaction layer; and generate monitoring information corresponding to the variable to be observed based on the variable data returned by the domain controller in response to the variable data request.
[0020] Optionally, the platform configuration file includes board configuration data corresponding to the CPU board and at least one other board of the domain controller, respectively; The communication and data interaction layer is used to transmit the platform configuration file to the CPU board, so that the CPU board can send a configuration update instruction to the at least one other board via Ethernet User Datagram Protocol (UDP) messages. The at least one other board is used to respond to the configuration update command, parse the corresponding board configuration data in the platform configuration file, and return the configuration update result to the CPU board; The CPU board is used to summarize the configuration update results returned by at least one other board; and the communication and data interaction layer is used to obtain the configuration update results summarized by the CPU board and provide the configuration update results to the business logic layer to generate the deployment execution results corresponding to the platform configuration file.
[0021] According to a second aspect of the embodiments of this application, a configuration, deployment, and monitoring method for domain controllers is provided, including: The application requirements of the application to be deployed and the configuration requirements for the domain controller are obtained through the user interface layer, and a configuration deployment task is formed. The business logic layer establishes the association between the application to be deployed, the virtualization resources of the domain controller, and the platform configuration based on the configuration deployment task and the running characteristics of the application to be deployed. The business logic layer generates a deployment object for the domain controller to load based on the association relationship. The deployment object includes the target program, virtualization runtime environment, and platform configuration corresponding to the application to be deployed. The deployment object is sent to the domain controller through remote control interaction, file interaction and runtime data interaction provided by the communication and data interaction layer, and the deployment execution results and runtime data returned by the domain controller are obtained. The business logic layer generates monitoring information based on the deployment execution results and the running data, and the user interface layer presents the execution results of the configuration deployment task and the monitoring information.
[0022] According to a third aspect of the embodiments of this application, a vehicle is provided, including: a configuration deployment and monitoring device for a domain controller as described in any of the foregoing embodiments.
[0023] The embodiments of this application, by adopting the above technical solutions, have the following technical effects: By acquiring the application requirements of the application to be deployed and the configuration requirements of the domain controller through the user interface layer, the dispersed application configuration, resource configuration, and platform configuration can be unified into a configuration deployment task. The business logic layer can establish the association between the application to be deployed, virtualization resources, and platform configuration based on the configuration deployment task and the operational characteristics of the application to be deployed. It can then generate a deployment object, including the target program, virtualization runtime environment, and platform configuration, according to this association. The communication and data interaction layer further distributes the deployment object to the domain controller and feeds back the deployment execution results and operational data to the business logic layer to generate monitoring information for presentation by the user interface layer. This approach organizes application requirement acquisition, virtualization resource planning, program and configuration generation, file deployment, and operational monitoring into a continuous closed-loop process. This reduces the coupling between application software and specific physical controllers, improves the configuration deployment efficiency and resource utilization efficiency of domain controllers, and enhances the consistency and traceability of the configuration deployment process. Attached Figure Description
[0024] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of an application scenario in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a configuration, deployment, and monitoring device for a domain controller according to an embodiment of this application; Figure 3This is a schematic diagram of the specific structure of a configuration, deployment, and monitoring device for a domain controller according to an embodiment of this application; Figure 4 This is a schematic diagram of a partition configuration interface in an embodiment of this application; Figure 5 This is a schematic diagram of a resource configuration interface in an embodiment of this application; Figure 6 This is a schematic diagram of a board configuration interface in an embodiment of this application; Figure 7 This is a schematic diagram of an application configuration interface in an embodiment of this application; Figure 8 This is a schematic diagram of a variable configuration interface in an embodiment of this application; Figure 9 This is a schematic diagram of a configuration monitoring interface in an embodiment of this application; Figure 10 This is a schematic diagram of a file configuration interface in an embodiment of this application; Figure 11 This is a schematic diagram of a topology monitoring interface in an embodiment of this application; Figure 12 This is a schematic diagram illustrating the working principle of a planning and scheduling module in an embodiment of this application; Figure 13 This is a flowchart of a configuration, deployment, and monitoring method for a domain controller, as described in an embodiment of this application. Detailed Implementation
[0025] To make the technical solutions and advantages of the embodiments of this application clearer, the exemplary embodiments of this application will be described in further detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not an exhaustive list of all embodiments. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.
[0026] As described in the background section, in traditional vehicle-mounted physical machine deployment methods, different control systems are maintained by their respective configuration and deployment software.
[0027] For example, each control host of the network system is maintained by maintenance software A, each control unit of the braking system is maintained by maintenance software B, and each control unit of the traction system is maintained by maintenance software C. That is, each type of train software requires its own dedicated onboard controller (physical machine).
[0028] Because different control systems are maintained by their own configuration and deployment software, and there are many types of maintenance and deployment software, the maintenance and deployment work is complicated and difficult to adapt to different types and architectures of train software. The entire process relies on the professional skills and industry experience of the operation and maintenance personnel, and must strictly follow the safety regulations of the rail transit industry. The deployment process is cumbersome and time-consuming, which also increases the on-site workload and training costs of the operation and maintenance personnel.
[0029] Therefore, in the face of the demands of large-scale and dynamic application operation, achieving flexible deployment of train software functions and rational allocation of computing resources has become a technical problem that urgently needs to be solved by those skilled in the art.
[0030] Based on this, this application provides a configuration deployment and monitoring scheme for domain controllers. By standardizing configuration, intelligent scheduling, integrated management and control, on-board environment adaptation and security protection mechanisms, it solves the above-mentioned technical defects, realizes the automation, efficiency, precision, security and scalability of train software configuration deployment, reduces on-site operation and maintenance costs, improves the real-time performance, stability and reliability of train software operation, and meets the operation and maintenance requirements of the long life cycle of train software.
[0031] To enable those skilled in the art to better understand and implement this solution, the following detailed description of the specific solution, principles, advantages, and effects of this application is provided with reference to the accompanying drawings and specific embodiments.
[0032] See Figure 1 , Figure 1 This is a schematic diagram of an application scenario in an embodiment of this application.
[0033] By employing a multi-core processor and virtualization partition architecture, applications are deployed to different partitions according to their real-time requirements, computing power, memory, and device resource requirements.
[0034] Each partition can run operating systems such as RT-Linux and FreeRTOS independently, and the Hypervisor uniformly manages the allocation and isolation of processor cores, memory, and peripheral resources.
[0035] Data interaction between partitions is achieved through shared memory, ensuring real-time performance, reliability, and fault isolation while enabling collaborative operation of multiple applications, load balancing, and efficient utilization of hardware resources.
[0036] Specifically, partition 1 is the root partition, which runs on the RT-Linux system and deploys APP1 and APP2. It occupies Core0, root partition memory, and hardware resources such as UART, SATA, physical network port and debug serial port. At the same time, it interacts with other partitions through Hypervisor and shared memory.
[0037] Similarly, partition 2 is a secondary partition (Inmate), running on the RT-Linux system and deploying APP3 and APP4. It occupies Core1, corresponding independent memory, virtual network port and debug serial port and other resources, and exchanges data with other partitions through shared memory.
[0038] Partition 3 is a secondary partition (Inmate), running on the FreeRTOS system and deploying APP5. It occupies Core2, corresponding independent memory, virtual network port and debugging serial port and other resources. It is mainly used to carry out control tasks with high real-time requirements and communicates with other partitions through shared memory.
[0039] See Figure 2 , Figure 2 This is a schematic diagram of a configuration, deployment, and monitoring device for domain controllers according to an embodiment of this application. The configuration, deployment, and monitoring device for domain controllers includes: The user interface layer 210 is used to obtain the application requirements of the application to be deployed and the configuration requirements for the domain controller 240, form a configuration deployment task, and present the execution results and monitoring information of the configuration deployment task. The business logic layer 220, connected to the user interface layer 210, is used to establish the association between the application to be deployed, the virtualization resources of the domain controller 240, and the platform configuration according to the configuration deployment task and the running characteristics of the application to be deployed, and to generate a deployment object for the domain controller 240 to load based on the association. The deployment object includes the target program, virtualization runtime environment, and platform configuration corresponding to the application to be deployed. The communication and data interaction layer 230, located between the business logic layer 220 and the domain controller 240, is used to provide remote control interaction, file interaction, and runtime data interaction for the business logic layer, so as to send the deployment object to the domain controller 240 and obtain the deployment execution results and runtime data returned by the domain controller 240; wherein, the business logic layer 220 is also used to generate the monitoring information based on the deployment execution results and the runtime data, and provide the monitoring information to the user interface layer 210.
[0040] In some embodiments, the user interface layer 210 is mainly responsible for direct interaction with the user, the business logic layer 220 is used to implement functions such as planning and scheduling, configuration management, application development, file transfer, and monitoring management, and the communication and data interaction layer 230 is used to implement communication between the software and the domain controller 240.
[0041] In this embodiment, the configuration deployment and monitoring device is used to uniformly manage the virtualization partitions, applications, middleware configurations, and board configurations in the domain controller.
[0042] The user interface layer receives user input such as application name, application execution cycle, application priority, maximum allowed execution time, maximum allowed jitter time, processor core requirements, memory requirements, variable information, network information, and board configuration information, and organizes this data into configuration and deployment tasks.
[0043] The business logic layer associates the application to be deployed, virtualization partitions, processor resources, memory resources, and platform configurations with the user-input requirement data and the running characteristics of the application to be deployed in the test environment, such as execution time, processor usage, and memory usage, to obtain the deployment relationship between the application and the partition, as well as the resource allocation relationship between the partition and hardware resources.
[0044] Based on this, the business logic layer generates deployment objects including application target programs, device tree files, resource configuration files, kernel images, file systems, and XML configuration files.
[0045] The communication and data interaction layer sends the deployed objects to the domain controller through remote login, file transfer and data communication, and controls the domain controller to establish a virtualized operating environment and load the corresponding applications.
[0046] After the domain controller is running, it returns application status, processor load, memory usage, device temperature, key variables, and train topology data to the configuration, deployment, and monitoring device. The business logic layer processes the returned data to form monitoring information, which is then displayed by the user interface layer. This forms an integrated closed loop of requirement configuration, resource planning, application building, file deployment, and operation monitoring.
[0047] See Figure 3 , Figure 3 This is a schematic diagram of the specific structure of a configuration, deployment, and monitoring device for a domain controller according to an embodiment of this application.
[0048] Combination Figure 2 and Figure 3 The user interface layer 210 includes at least one of the following: partition configuration interface 211, resource configuration interface 212, board configuration interface 213, application configuration interface 214, variable configuration interface 215, file configuration interface 216, configuration monitoring interface 217, and topology monitoring interface 218.
[0049] At least one of the partition configuration interface 211 and the resource configuration interface 212 is used to obtain the application requirements of the application to be deployed and the virtualization resource configuration requirements of the domain controller 240.
[0050] In this embodiment, the partition configuration interface 211 is used to create a QTableWidget object to display application running configuration information, including the application name, execution cycle, application priority, number of cores used, execution time, and whether function migration occurs in case of failure in different partitions.
[0051] See Figure 4 , Figure 4 This is a schematic diagram of a partition configuration interface in an embodiment of this application.
[0052] A QComboBox object is created to provide a dropdown list of preset application options; and six QPushButton buttons are created to serve as buttons for adding, deleting selected items, configuring network parameters, reading configuration, saving configuration, and confirming. Reading and saving configurations call the `readXmlCfgFile()` and `saveXmlCfgFile()` methods of `CfgFileManager`, respectively, to implement the functionality of reading and saving configurations. The confirm button triggers a signal to switch to the next page.
[0053] In this embodiment, the partition configuration interface displays two partitions (e.g., partition 1 and partition 2), and each partition displays information such as application name, execution cycle, priority, number of cores used, whether it is a real-time APP, execution time, fault migration, and migration partition.
[0054] For example, partition 1 contains a central control unit (CCU1), which has an execution cycle of 50, a priority of 1, a core usage of 1, is a real-time application, has an execution time of 24 hours, is fault migration enabled, and has an empty migration partition.
[0055] The resource configuration interface 212 is used to configure user application requirements and virtualization partition resource information.
[0056] See Figure 5 , Figure 5 This is a schematic diagram of a resource configuration interface in an embodiment of this application.
[0057] When automatic configuration is selected, the resource scheduling configuration interface is used to configure user application requirements and virtualization partition resource information. The application test button is used to test the computing power requirements of a specified application. After the test, any number of applications that meet the user's requirements can be selected. The application configuration interface generates an XML configuration file based on the user's application requirements. This file is used by the algorithm planning module to plan partition resources, kernel resources, and applications, generating resource and application configuration XML files. The virtualization configuration interface parses the XML file generated by the algorithm planning. Simultaneously, the user allocates memory and operating system information to each partition based on the planning results, generating a partition configuration XML file for subsequent generation of partition configuration files and kernel images. At least one of the board configuration interface 213, the application configuration interface 214, the variable configuration interface 215, and the file configuration interface 216 is used to obtain the platform configuration requirements for the domain controller.
[0058] Among them, the board configuration interface 213 is mainly used to configure the required board configuration information, generate an overall XML format configuration file, and transfer it to the CPU board using FTP. The CPU board sends a configuration update command via Ethernet UDP message to notify other boards to update their configuration information. Other boards parse the XML file and reply to the CPU board with the configuration update result.
[0059] See Figure 6 , Figure 6 This is a schematic diagram of a board configuration interface in an embodiment of this application.
[0060] The board configuration interface can display the configurations of TSN board, CPU1 board, IO board, CPU2 board, energy storage board, Ethernet switching board, PCIE switching board, wireless board, power supply 1 board, and power supply 2 board.
[0061] The configuration functions of the application configuration interface should cover the following core configuration items: (1) Application running information: application name, priority, execution cycle; (2) Variable configuration: application name, variable name, type, default value, belonging application name, input / output type; (3) Message configuration: message name, variable name; (4) Log configuration: log name, maximum number of entries, file name; (5) Message function configuration: message function name, message name, function category (combination or parsing); (6) Network function configuration: network function name, protocol type, communication mode, send / receive type, remote IP, remote Port, message name; (7) Log function configuration: log function name, log name, message name, trigger variable, repetition cycle, variable list.
[0062] See Figure 7 , Figure 7 This is a schematic diagram of an application configuration interface in an embodiment of this application.
[0063] Create a QGroupBox object through the feature development module to hold application development components, and create three QPushButton buttons as SDM configuration, range variable adaptation, and confirmation buttons, respectively.
[0064] The variable configuration interface 215 is used to display application configuration, variable configuration, message configuration, log configuration, and network function configuration.
[0065] See Figure 8 , Figure 8 This is a schematic diagram of a variable configuration interface in an embodiment of this application. It displays the variable configuration, which includes: variable name (var_name1), variable type (bool), default value (false), concurrency (false), application name (CCU1), and I / O type.
[0066] Furthermore, message configuration includes message name, user message format, variable name, byte offset, and bit offset; message function configuration includes message function name, function, message name, enabled protocol, data flow direction, source board type, source board slot, destination board slot, MAC address, IP address, data subsystem, and COMID; log configuration includes log name, maximum number of entries, and file name; network function configuration includes network function name, protocol type, communication mode, send / receive type, remote IP, remote port, multiple messages, and message name.
[0067] The configuration monitoring interface 217 is used to present at least one of the following: the execution result of the configuration deployment task, the running status of the application to be deployed, and the resource running status of the domain controller.
[0068] See Figure 9 , Figure 9 This is a schematic diagram of a configuration monitoring interface in an embodiment of this application.
[0069] The runtime monitoring function is used to monitor application operation status, system resource usage, and key variable data in real time. This includes real-time monitoring of application operation status, displaying the application name, running status, CPU load, temperature, and memory usage of remote devices, dynamically presented in a line graph format to intuitively reflect resource usage trends; and real-time observation of key variable data, providing a variable selection window to allow users to dynamically adjust the observed variables.
[0070] For example, see Figure 9 , Figure 9 The diagram illustrates the status of each application in partition 1 and partition 2. Specifically, for partition 1, CCU1 is in an unconnected state, with 0KB of RAM usage and 0% CPU utilization.
[0071] The file configuration interface 216 is used to manage application dynamic library files, configuration files, log files, etc. in remote devices, and mainly includes core functions such as refresh, upload, and download.
[0072] Specifically, this includes: (1) Refresh: Obtaining a list of files in a specified directory on a remote device and displaying it through the interface. (2) Upload: Users can select local files through a file selection dialog box, and the software automatically transfers them to a specified path on the remote device. After the transfer is completed, the file list is updated in real time to reflect the latest status. (3) Download: Users select the target file in the file display area and click the "Download" button. The system pops up a local path selection dialog box. After confirming the storage location, the file is transferred to the specified local path.
[0073] See Figure 10 , Figure 10 This is a schematic diagram of a file configuration interface in an embodiment of this application.
[0074] In the file configuration interface, a QGroupBox is created to display the file component. This component contains two QLabels, one displaying the file icon and the other the file name. The `mousePressEvent()` function is overridden to implement the icon selection effect. The interface also includes five QPushButtons, corresponding to refresh, upload, download, one-click refresh, and next page functions.
[0075] The topology monitoring interface 218 is used to display the train network topology and the status of network nodes and communication links in the train network topology.
[0076] See Figure 11 , Figure 11 This is a schematic diagram of a topology monitoring interface in an embodiment of this application.
[0077] Among them, based on the IEC 61375-2-3 (TCN communication protocol) and IEC 61375-2-5 (Ethernet TrainBackbone) standards, an intuitive train topology information visualization interface was developed, which aims to help maintenance personnel and engineers quickly understand the key information in the Train Topology Database (TTDB) and Train Network Directory, and realize real-time monitoring of train network status and rapid fault location.
[0078] The main interface (train topology information) is centered on the linear sequence diagram of the entire train, horizontally displaying the complete composition of the train from the leading end to the tail end.
[0079] Each Consist (group) is represented by an independent square, labeled with the Consist UUID, ETBN IP address, and node status (blue for normal, red for abnormal).
[0080] The ETB backbone uses a dual-line connection, clearly distinguishing Line A / B redundancy.
[0081] The lower layer displays a simplified diagram of the ECN (Ethernet Consist Network) for each Consist, with example devices (such as HMI, LCD Display, IP Camera) visually representing the hierarchical structure.
[0082] The top highlights the train direction, total number of train sets, total number of ETBNs, and faulty nodes, allowing for a clear overview of the overall topology health status.
[0083] Refer to Table 1, which shows the configuration of the user interface layer in this embodiment.
[0084] It should be noted that, Figures 4 to 11 The interface diagrams shown are for illustrative purposes only and should not be used to limit this application.
[0085] In some embodiments, see Figure 2 The business logic layer 220 may include a planning and scheduling module 221.
[0086] The planning and scheduling module 221 is used to provide resource scheduling and configuration related functions. This module includes two sub-modules: algorithm planning and virtualization configuration.
[0087] The algorithm planning process includes steps such as planning objectives, planning constraints, algorithm construction, and feasible domain solution. It is used to plan the number of domain controller partitions and application deployment based on user application requirements and application computing power requirements, and outputs domain controller application deployment and partition information configuration files. The virtualization configuration allocates hardware resources based on the XML file generated by the virtualization configuration interface. By calling the SSH client, it remotely logs into the virtual machine and generates the device tree file, resource configuration file, kernel image, and file system required for partition boot in the specified cross-compilation environment. It then uses an FTP client to download all files to the lower-level machine.
[0088] See Figure 12 , Figure 12 This is a schematic diagram illustrating the working principle of a planning and scheduling module in an embodiment of this application.
[0089] First, the user submits the application requirements. The scheduling strategy configuration tool downloads the specified application to the domain controller for application testing. The test parameters and application requirements are used as inputs to the planning algorithm. The algorithm planning module performs partition planning based on the test results and application requirements, and generates an XML configuration file.
[0090] Further virtualization configuration is performed, the generated partition image and partition configuration file are downloaded to the domain controller, the specified application is deployed after the partition is started, and the application process is monitored in real time, and the results are sent back to the application monitoring interface for real-time monitoring.
[0091] Specifically, in this embodiment, the planning and scheduling module includes an algorithm planning submodule and a virtualization configuration submodule.
[0092] The algorithm planning submodule is used to obtain the hardware resource parameters of the domain controller and the application requirement parameters of the application to be deployed from the configuration deployment task; control the application to be deployed to run in the test environment provided by the domain controller through the communication and data interaction layer, and obtain the execution time and resource consumption of the application to be deployed; determine the processor core configuration of the virtualization partition used to host the application to be deployed based on the comparison result between the execution time and the maximum allowed execution time in the application requirement parameters; limit the time interval between the start time of two consecutive executions of the application to be deployed based on the execution cycle and the maximum allowed jitter time; and limit the execution cycle, execution time and deadline of the application to be deployed. The start and end times of each execution of the application to be deployed are determined, and the order of execution between two adjacent executions is defined based on the start and end times of two adjacent executions. Based on the hardware resource parameters, processor core configuration, resource usage, and the limitations on the start time, end time, and order of execution, candidate partition deployment relationships that meet the operational requirements of the application to be deployed are determined. Based on the execution time span of multiple applications to be deployed within the same supercycle and the differences in task execution load between different virtualization partitions, a target partition deployment relationship is determined from the candidate partition deployment relationships. The association relationship is determined based on the target partition deployment relationship. The virtualization configuration submodule is used to generate the virtualization runtime environment based on the association relationship.
[0093] Specifically, the planning and scheduling module is used to plan the number of virtualization partitions, processor cores, memory, and application deployment locations based on the actual operating characteristics of the application to be deployed and the hardware resource capabilities of the domain controller.
[0094] The algorithm planning submodule first extracts the total number of processor cores, available memory, device resources, and the execution cycle, maximum allowed execution time, allowable jitter, priority, and memory requirements of each application from the configuration and deployment task. Then, through the communication and data interaction layer, the application to be deployed is sent to the test environment of the domain controller for execution, obtaining the application's single-execution time, processor utilization, and memory usage. If the application's execution time under single-core conditions does not exceed the maximum allowed execution time, the application can be configured in a single-core partition; if the single-core execution time exceeds the maximum allowed execution time, and the application has parallel execution capabilities, the number of cores in the partition hosting the application is increased.
[0095] For periodic applications, the algorithm planning submodule limits the start time difference between two adjacent executions based on the application cycle and allowable jitter. It also limits the start and end times of each application instance based on the release time, execution time, and deadline, ensuring that adjacent instances of the same application execute in chronological order. After obtaining multiple candidate partition deployment relationships based on the above resource and time conditions, the execution time span of each candidate scheme within the same supercycle and the task load differences between partitions are further compared to select the target partition deployment relationship. The target partition deployment relationship includes at least the mapping relationship between the application and the virtualization partition, the allocation relationship between the virtualization partition and the processor core, and the allocation relationship between the virtualization partition and memory resources. The virtualization configuration submodule then converts the above relationships into a virtualization runtime environment usable by the domain controller.
[0096] In one embodiment, for the first The application to be deployed is in the first The execution status within a virtualized partition can be used to determine whether a single-core configuration meets the application's running requirements, based on the following core partition conditions: .
[0097] in, Indicates the first The application to be deployed is in the first Execution time when a virtualized partition is configured with a single core. Indicates the first The maximum allowed execution time for each application to be deployed.
[0098] when When the algorithm planning submodule is in use, it can configure the corresponding virtualization partition as a single-core partition; when If the application to be deployed supports parallel execution, the number of processor cores in the corresponding virtualization partition is increased, and the execution time under multi-core conditions is regained; if the application to be deployed does not support parallel execution, the deployment relationship of the candidate partition is determined to not meet the application's running requirements.
[0099] In one embodiment, the first The number of processor cores required for each application to be deployed can be expressed as: .
[0100] in, Indicates the first The number of processor cores required for each application to be deployed. Indicates the first The application to be deployed is in the first Virtual partition allocation The execution time per processor core. For applications that only support single-threaded execution, it can be... Set to 1.
[0101] To limit the startup time fluctuation between adjacent execution instances of the application to be deployed, the algorithm planning submodule limits the start time of two consecutive executions according to the following jitter conditions: .
[0102] in, Indicates the first The application to be deployed is in the first The first virtual partition The next execution start time, Indicates its first The next execution start time, Indicates the first The execution cycle of each application to be deployed. Indicates the first The maximum allowed jitter time for each application to be deployed, used to keep the interval between two adjacent launches within a certain range. to Within the range.
[0103] When the scheduling range of the application to be deployed spans two adjacent supercycles, a jitter condition across supercycles can also be set: .
[0104] in, Indicates the first The time-to-deployment cycle of all applications in each virtualized partition. Indicates the first The start time of the first execution of each application to be deployed within the current supercycle. This indicates the start time of the last execution within the previous supercycle. Indicates the first The number of times an application to be deployed is executed within a supercycle.
[0105] For cases where the period is divisible by the extraperiod, we can set: .
[0106] To ensure that each application instance to be deployed completes within its corresponding period, the algorithm planning submodule can limit the start time according to the following conditions: .
[0107] in, Indicates the first The application to be deployed is in the first Execution time in each virtual partition Indicates its first The above formula is used to determine the waiting time corresponding to the first execution. This application example is in the first The cycle begins after the release of the first cycle and ends before the next cycle begins.
[0108] In another embodiment, the release time and relative cutoff time can also be used as equivalent representations: , .
[0109] in, Indicates the first The application to be deployed The release time of the next execution This represents the relative deadline. When the relative deadline equals the execution cycle, let... .
[0110] To ensure that adjacent execution instances of the same application to be deployed are executed sequentially and without overlap, the algorithm planning submodule sets continuous execution conditions: .
[0111] Alternatively, without setting a separate wait time variable, the following can be used: .
[0112] The algorithm planning submodule determines the processor core configuration, the allowed start and end times of application instances, and the sequential relationship between adjacent execution instances based on the above formula. It also generates candidate partition deployment relationships that meet the application's running requirements by combining the total number of processor cores, available memory capacity, and device resource conditions of the domain controller.
[0113] After the candidate partition deployment relationship satisfies all constraints, the algorithm planning submodule takes shortening the execution time span of multiple applications to be deployed within the same supercycle as its primary planning objective.
[0114] The planning objective can be expressed as: .
[0115] in, This indicates the time when the first application instance starts execution within the same supercycle. This indicates the time when the last application instance within the same supercycle ends execution. This represents the execution time span of all application instances within the same supercycle.
[0116] The algorithm planning submodule also sets a second planning objective: reducing the difference in task execution load between different virtualization partitions. This objective can be expressed as: .
[0117] in, Indicates the first The total execution time of a virtualized partition's tasks within a single supercycle. Indicates the total number of virtualized partitions. This represents the average total execution time of tasks across all virtualization partitions. Among them, The smaller the value, the more balanced the task execution load is among the virtualization partitions.
[0118] In other words, the algorithm planning submodule determines the target partition deployment relationship from the candidate partition deployment relationships based on the first and second planning objectives, and establishes the association relationship between the application to be deployed, virtualization resources, and platform configuration based on the target partition deployment relationship. The association relationship may include the mapping relationship between the application to be deployed and the virtualization partition, the allocation relationship between the virtualization partition and the processor core, the allocation relationship between the virtualization partition and memory resources, and the correspondence between application running parameters and platform configuration parameters. The virtualization configuration submodule generates the virtualization runtime environment, such as device tree files, resource configuration files, kernel images, and file systems, based on the association relationship.
[0119] By adopting the above solution, we can simultaneously consider application real-time performance, resource capacity, and partition load balancing, reducing resource waste or timeout issues caused by relying solely on experience to allocate processor cores and memory, thereby improving the executability, determinism, and resource utilization efficiency of the application deployment solution and the domain controller.
[0120] In some embodiments, the algorithm planning submodule can also convert hardware resource parameters, processor core configuration, resource consumption, and application execution time relationships into satisfiability modular theory constraint expressions, and can formally describe domain controller resource constraints and application real-time operation requirements.
[0121] Specifically, the algorithm planning submodule is further configured to convert the hardware resource parameters, the processor core configuration, the resource occupancy, and the constraints on the start time, the end time, and the sequence relationship into a satisfiability modular theory constraint expression; perform satisfiability determination on the satisfiability modular theory constraint expression to obtain the candidate partition deployment relationship that satisfies the operational requirements of the application to be deployed and the hardware resource limitations of the domain controller; construct a comprehensive objective function based on the execution time span and the difference in task execution load; and perform an extreme value search on the comprehensive objective function within the feasible domain formed by the candidate partition deployment relationship through iterative search to determine the target partition deployment relationship.
[0122] In this embodiment, the algorithm planning submodule transforms the application deployment and resource allocation problem into a satisfiability model. Variables in the model may include the partition to which the application belongs, the number of processor cores occupied by the partition, the amount of memory allocated to the partition, and the start and end times of the Kth execution of the application. Constraints in the model ensure that the application execution time does not exceed the maximum allowed execution time, the start interval between adjacent execution instances satisfies the allowable jitter, each application instance completes before the deadline, and adjacent execution instances of the same application do not overlap in time.
[0123] The algorithm planning submodule calls the SMT solver to perform SAT judgment on the constraint expressions. When the judgment result is satisfactory, it obtains candidate partition deployment relationships that satisfy all constraints. These candidate deployment relationships constitute the feasible region of the planning problem. In the feasible region, the time span from the start of execution of the first application to the end of execution of the last application within the same supercycle is used as the first optimization quantity, and the difference between the total task execution time of each virtualization partition and the average task execution time of each partition is used as the second optimization quantity.
[0124] The comprehensive objective function can be constructed using a weighted sum approach, or the objectives can be optimized sequentially according to priority. The algorithm planning submodule continuously adjusts the number of partitions, application mappings, and resource configurations through iterative search until a target partition deployment relationship that satisfies all constraints and achieves the optimal comprehensive objective value or meets preset convergence conditions is obtained.
[0125] In one embodiment, the decision variable may include at least: representing the first Should the applications awaiting deployment be deployed to the first...? Application allocation variables for each virtual partition 、 indicates the first The variable of the number of processor cores allocated to each virtualization partition. 、 indicates the first Variables of memory capacity allocated to each virtualization partition , and indicate the first The application to be deployed The variable of the start time of the next execution. .
[0126] Among them, the application of the allocation variable can satisfy: Each application to be deployed is assigned to a virtualization partition based on the following conditions: .
[0127] Among them, when When, it indicates the first The application to be deployed was deployed to the first... A virtual partition; when When, it indicates the first One application awaiting deployment has not been deployed to the first stage. A virtualized partition.
[0128] For processor core resources, the following settings can be configured: .in, This indicates the total number of processor cores that the domain controller can provide.
[0129] For memory resources, you can set: ,as well as: .
[0130] in, Indicates the first The memory requirements of the application to be deployed. Indicates the first The memory occupied by the operating system, middleware, and runtime environment in each virtualization partition. Indicates assignment to the first The memory capacity of each virtual partition. This indicates the total amount of available memory for the domain controller.
[0131] For the The processor load of each virtualized partition can be configured as follows: And limited to: .
[0132] in, Indicates the first The task processor load of each virtualized partition. Indicates the first Each virtualized partition has a preset maximum core utilization rate, and By Setting it to a value less than 1 can reserve processor resources for interrupt handling, virtualization overhead, communication processing, and execution time fluctuations.
[0133] At the same time, the algorithm planning submodule also converts the kernel partitioning condition, jitter condition, deadline condition and continuous execution condition in the aforementioned embodiments into SMT constraint expressions.
[0134] To avoid the absolute value expression affecting the solution process, it can be... Convert to: .
[0135] The condition for jitter across supercycles can be converted to: .
[0136] When two different application instances running on the same processor core cannot execute simultaneously, it is also possible to target application instances. and application examples Set mutual exclusion execution conditions: .
[0137] in, and These represent the start times of the two application instances, and These represent the execution times of the two application instances. This prevents overlapping execution times between different application instances mapped to the same processor core.
[0138] After the constraint expressions are constructed, the algorithm planning submodule calls the SMT solver to determine satisfiability. When the solver outputs an unsatisfiable result, it indicates a conflict between the current application requirements, domain controller resources, or time parameters; when the solver outputs a satisfiable result, it outputs the application allocation variables, resource allocation variables, and start time variables that satisfy the above constraints, forming candidate partition deployment relationships.
[0139] For the first and second planning objectives, a weighted sum can be used to construct a comprehensive objective function: .in , The weights represent the objectives for the execution time span. This indicates the weight of the target for the difference in task load between partitions.
[0140] In one specific embodiment, .
[0141] Therefore, the overall objective function is:
[0142] Furthermore, considering that the execution time span and the difference in task execution load may have different dimensions, the two planning objectives can be normalized first.
[0143] The normalized primary programming objective can be expressed as: .
[0144] The normalized second programming objective can be expressed as: .
[0145] In this case .in, and These represent the lower and upper bounds of the execution time span within the preset search range, respectively. and These represent the lower and upper bounds of the difference in task execution load, respectively.
[0146] The algorithm planning submodule can directly search for the minimum value of the comprehensive objective function within the feasible region that satisfies the constraints using optimization module theory, or it can use an iterative search method to gradually tighten the upper bound of the objective function.
[0147] For example, when obtaining the objective function value corresponding to a candidate solution Then, add the following constraints: The solver is then invoked again. If a feasible solution cannot be obtained, the previous candidate solution is used as the target partition deployment relationship.
[0148] By adopting the above approach, the feasibility assessment of the deployment plan can be separated from performance optimization. This ensures that the final plan first meets the requirements of hardware resources and real-time performance, and then optimizes the task completion time and load balancing within the feasible plan. This reduces the number of manual trials and errors and improves the reliability and optimization of the partitioning planning results.
[0149] In some embodiments, the test runtime environment is a single-partition, single-core test runtime environment in which a virtualization partition and a processor core are independently allocated to an application to be deployed.
[0150] In this case, the algorithm planning submodule is also used to transmit the application to be deployed to the single-partition single-core test environment through the communication and data interaction layer; control the application to be deployed to run in the single-partition single-core test environment; acquire at least one of the test data generated during the operation of the application to be deployed, including application execution time, processor usage, memory usage, and execution jitter; and determine the running characteristics of the application to be deployed based on the test data.
[0151] In one embodiment, to reduce the interference of other applications running concurrently on the test results, a single-partition, single-core test environment is set up in the domain controller.
[0152] The test environment loads only one application to be deployed and allocates a processor core, a preset memory region, and middleware and device access permissions required for the application to run.
[0153] The algorithm planning submodule uses an FTP client to transfer the application's program files and test configuration files to the test runtime environment, and sends a start command via an SSH client or TCP client.
[0154] Assume the first A total of [number] applications awaiting deployment have executed [number] times. sequence The start time of this test is The end time is Then the first The application execution time for this test is: .
[0155] Based on the results of multiple tests, the average execution time can be calculated: .
[0156] The maximum observation execution time is: .
[0157] In one embodiment, the execution time for algorithm planning can be determined based on the maximum observation execution time and a preset margin coefficient: .in, Indicates the first zoning plan. The execution time of each application to be deployed This represents the execution time margin coefficient, and .
[0158] By setting an execution time margin, the impact of virtualization overhead, system interruptions, cache contention, and changes in the runtime environment on the actual execution time can be compensated.
[0159] Assume the first During the second test, the first The time each application to be deployed occupies on the processor is The test interval length is The processor utilization rate can then be expressed as: .
[0160] No. The average processor utilization of each application to be deployed can be expressed as: .
[0161] Peak processor utilization can be expressed as: .
[0162] Assume the first The first data collected during the test The memory usage of each application to be deployed is The average memory usage is: .
[0163] Peak memory usage is: .
[0164] When planning the memory capacity of virtualization partitions, the following can be used: .
[0165] in, Indicates the first The planned memory requirements of an application to be deployed. This represents the memory margin coefficient, and .
[0166] For applications that are periodically awaiting deployment, the first Second and third The startup jitter between executions can be represented as: .
[0167] No. The maximum observed jitter for each application to be deployed is: .
[0168] The algorithm planning submodule can handle the maximum observation jitter. The maximum allowable jitter time set by the user Comparison. When When the application meets the jitter requirements in the current test environment, it indicates that the application to be deployed meets the jitter requirements; when If necessary, you can adjust the application priority, processor core binding relationship, scheduling parameters, or test environment configuration and then retest.
[0169] In this embodiment, the runtime characteristics of the application to be deployed can be represented by the following set of parameters: .
[0170] in, Indicates the first The algorithm planning submodule takes the set of runtime characteristics of the application to be deployed, along with the application cycle, maximum allowed execution time, maximum allowed jitter time, and domain controller hardware resource parameters input by the user, as input for partition planning.
[0171] In one implementation, when the planned execution time of the application to be deployed under single-core testing conditions meets the requirements... When the initial processor core requirement for the application to be deployed is set to 1, then... When the algorithm planning submodule determines that the single-core configuration does not meet the application's maximum execution time requirement, it will decide whether to perform multi-core testing or output the result that the current configuration is not feasible based on the parallel execution capability of the application to be deployed.
[0172] In some embodiments, see next. Figure 3The business logic layer 220 also includes a configuration management module 222 and an application development module 223.
[0173] The planning and scheduling module 221 is further configured to generate virtualization runtime environment files constituting the virtualization runtime environment based on the association relationship; the application development module 223 is configured to generate the target program corresponding to the application to be deployed; the configuration management module 222 is configured to generate a platform configuration file based on the platform configuration; and the business logic layer is further configured to organize the target program, the virtualization runtime environment files, and the platform configuration file into the deployment object according to the association relationship between the application to be deployed and the virtualization partition.
[0174] Specifically, the deployment object is not a single file, but a collection of files required by the domain controller to create virtualized partitions and run applications in the corresponding partitions.
[0175] The virtualization configuration submodule generates virtualization runtime environment files such as device tree files, resource configuration files, kernel images, and file systems for each virtualization partition based on the association relationships generated by the algorithm planning submodule. The application development module converts user-written source programs into target programs suitable for the domain controller's target architecture. The configuration management module converts application runtime parameters, middleware parameters, variable parameters, log parameters, message parameters, network parameters, and board parameters into platform configuration files. The business logic layer, according to the target partition deployment relationships, associates the target program with the virtualization partition hosting that target program, and combines the corresponding virtualization runtime environment files and platform configuration files into deployment objects. Deployment objects can be organized using directory structures, file lists, or compressed packages, as long as they can represent the correspondence between the target program, virtualization runtime environment files, platform configuration files, and target virtualization partitions.
[0176] In one embodiment, the virtualization configuration submodule is used to determine the processor resources, memory resources, and device resources corresponding to each virtualization partition according to the association relationship; remotely log in to a preset cross-compilation environment through the communication and data interaction layer; generate at least one of a device tree file, resource configuration file, kernel image, and file system corresponding to each virtualization partition according to the processor resources, the memory resources, and the device resources; and use at least one of the device tree file, the resource configuration file, the kernel image, and the file system as the virtualization runtime environment file.
[0177] In this embodiment, the virtualization configuration submodule reads the processor core number, memory start address, memory capacity, network interface, storage device and other peripheral mapping relationships recorded in the target partition deployment relationship, and converts these contents into the build parameters required by the cross-compilation environment.
[0178] The virtualization configuration submodule logs into the default virtual machine or build server via an SSH client and invokes the device tree generation script, resource configuration generation script, kernel compilation tools, and file system packaging tools within the specified cross-compilation environment. The device tree file describes the processor, memory, and device resources accessible to the partition; the resource configuration file describes the processor cores, memory regions, and scheduling parameters for each virtualization partition; the kernel image provides the operating system kernel required for partition operation; and the file system stores middleware, runtime libraries, applications, and startup scripts. After generation, the virtualization configuration submodule verifies the existence and format of the generated files and adds them to the deployment object of the corresponding virtualization partition.
[0179] Using the above solution, operations and maintenance personnel do not need to configure processor, memory and device mappings item by item on the domain controller, nor do they need to manually build the kernel and file system separately. This reduces repetitive operations and configuration differences in the virtualization runtime environment construction process, and improves the generation efficiency of partitioned runtime environments and the consistency of resource configuration.
[0180] In some embodiments, the application development module is used to obtain the source program of the application to be deployed; perform at least one of syntax rule checking, variable reference legality verification, and logical conflict detection on the source program; cross-compile the verified source program according to the target device architecture of the domain controller, and link system libraries and user-defined libraries to generate the target program; generate integrity verification information of the target program, and associate the integrity verification information with the target program in the deployment object; wherein, the source program includes at least one of a control program conforming to the IEC61131-3 standard and a C language application.
[0181] Specifically, the application development module supports IEC 61131-3 control programs and C language applications developed based on CODESYS.
[0182] For IEC 61131-3 control programs, the application development module performs syntax checks, variable reference checks, and logic conflict detection on ladder diagrams, structured text, or other programs conforming to IEC 61131-3, and returns the error location and reason to the user interface layer when an error is found.
[0183] For C language applications, the application development module can log in to a virtual machine with the target cross-compilation toolchain via an SSH client to compile the source code.
[0184] After successful verification, the application development module selects the appropriate instruction set and cross-compiler based on the domain controller's processor architecture, links system libraries and user-defined libraries, and generates an executable binary program or dynamic library file. For large projects, the application development module can also use incremental compilation, compiling only the changed source files. After the target program is generated, the application development module calculates the target program's hash value or other integrity verification information and adds the target program and its verification information to the deployment object for consistency verification before and after file transfer.
[0185] In some embodiments, the configuration management module is used to manage at least one of the following configuration information according to a unified configuration data structure: application runtime configuration, variable configuration, variable list configuration, message storage configuration, log storage configuration, message function configuration, log function configuration, network configuration, and board configuration; and to verify the configuration information and save the verified configuration information as the platform configuration file in XML format, or read the configuration information from the platform configuration file.
[0186] In this embodiment, the configuration management module uses a unified data management approach to process different types of platform configuration information.
[0187] Specifically, the configuration management module can build a unified interface based on the templated abstract base class IConfigBase, so that objects such as application runtime configuration, variable configuration, message configuration, log configuration, network configuration and board configuration can be processed through a unified interface for adding, deleting, modifying, querying, verifying, serializing and deserializing.
[0188] Application runtime configuration can include application name, execution cycle, priority, and partition number; variable configuration can include variable name, type, address, and application; message configuration can include message identifier, sending cycle, and storage location; log configuration can include log level, storage path, and storage capacity; network configuration can include IP address, port, and communication parameters; board configuration can include board type, board number, and board function parameters. Before saving the configuration, the file operation submodule verifies required fields, data range, identifier uniqueness, and the reference relationships between different configuration items. After successful verification, it generates an XML-formatted platform configuration file. When reading the configuration, it parses the XML nodes and restores the corresponding configuration objects for display and editing by the user interface layer.
[0189] See next Figure 3 The communication and data interaction layer 230 may include SSH clients, FTP clients, and TCP clients, wherein: The SSH client is used to remotely log in to the virtual machine, cross-compilation environment, or domain controller, and to perform at least one of the following operations: application compilation, virtualization runtime environment construction, and remote control. The FTP client is used to transfer files between the configuration deployment and monitoring device and the domain controller; The TCP client is used to transmit control commands and operational data between the configuration deployment and monitoring device and the domain controller.
[0190] Specifically, the communication and data interaction layer completes different types of communication operations through different clients.
[0191] The SSH client stores the remote host address, login account, authentication information, and remote working directory, and is used to log in to build virtual machines or domain controllers, executing commands such as cross-compilation, device tree generation, image building, partition booting, and application startup. The FTP client is used to transfer large target programs, dynamic libraries, device tree files, kernel images, file systems, XML configuration files, and log files between the host computer and the domain controller. The TCP client establishes persistent data communication connections, sends control commands such as start, stop, load, status query, and variable subscription, and receives application running status, CPU load, memory usage, device temperature, variable data, and train topology data. Each client can maintain its own connection status, timeout parameters, and error messages, and return the communication results to the corresponding business logic module.
[0192] By using appropriate communication clients based on the different communication characteristics of commands, files, and runtime data, we can avoid interface coupling and reduced transmission efficiency caused by using a single communication channel to process multiple types of data, thereby improving the communication efficiency and stability of remote building, file deployment, and runtime monitoring.
[0193] Among them, the SSH client (Secure Shell) is used for remote login and server management via encrypted connections. The FTP client (File Transfer Protocol) is used for uploading, downloading, and managing files between the local computer and the server. The TCP client (Transmission Control Protocol) is used for this purpose.
[0194] In some embodiments, see Figure 3 The business logic layer 220 may also include a file transfer module 224.
[0195] The file transfer module 224 is used to invoke the FTP client to establish or disconnect a file transfer connection between the configuration deployment and monitoring device and the domain controller, and to perform at least one of the following operations on remote files in the domain controller: refresh, upload, and download. The remote files include at least one of the following: application dynamic library files, platform configuration files, log files, and virtualization runtime environment files. The file transfer module 224 and the communication and data interaction layer 230 are used to transfer the deployment object to the domain controller via the FTP client; to perform integrity verification on the target program according to the integrity verification information associated with the target program; and, after the integrity verification is passed, to send a loading command to the domain controller via the SSH client or the TCP client, so that the domain controller establishes the corresponding virtualization runtime environment according to the association relationship and loads the target program and the platform configuration into the corresponding virtualization runtime environment; and to obtain the loading result returned by the domain controller via the TCP client and provide the loading result as the deployment execution result to the business logic layer 220.
[0196] Specifically, the file transfer module implements the FileTransfer class based on the FTPClient interface and provides a unified file operation interface to the file configuration interface.
[0197] When a user triggers a connection operation in the file configuration interface, the file transfer module calls the FTP client to establish a connection with the domain controller; when a refresh operation is triggered, the remote directory is read and the remote file name, size, modification time, and storage path are returned to the file configuration interface; when an upload operation is triggered, the local target program, dynamic library, XML configuration file, or virtualization runtime environment file is sent to the specified directory of the domain controller; when a download operation is triggered, the log file, configuration file, or other target file in the domain controller is saved to the local directory of the host computer.
[0198] In the event of a transmission interruption, the file transfer module can record the file offset that has been transmitted, resume transmission from the interrupted position after the connection is restored, and generate log information including file name, transmission duration, file size, and transmission result after the transmission is completed.
[0199] By setting up a file transfer module, users can view the remote directory of the domain controller, distribute deployment files, and obtain operation logs without having to use file tools provided by different vendors or systems. This simplifies the file management process, improves the efficiency of transferring application files, configuration files, and log files, and facilitates the tracing and analysis of deployment failures.
[0200] Furthermore, the business logic layer includes a monitoring and management module 225, which is used to obtain the operating data returned by the domain controller through the communication and data interaction layer. The operating data includes at least one of application running status, processor load, memory usage, device temperature, key variable data, and train network topology data; determine the running status of the application to be deployed, the system resource usage of the domain controller, the status of key variables, and the status of the train network based on the operating data; and generate the monitoring information based on the determined running status, system resource usage, key variable status, or train network status, and provide the monitoring information to the user interface layer.
[0201] Specifically, the monitoring and management module periodically sends status query requests to the domain controller via a TCP client, or receives operational data proactively reported by the domain controller. Application operational status can include states such as not started, starting, running, abnormally exited, stopped, and migrating; system resource data can include overall processor load, core load, total memory, used memory, remaining memory, and device temperature; key variable data can include variable identifiers, sampling time, variable values, and quality status; train network topology data can include vehicle identifiers, node identifiers, link identifiers, and corresponding operational statuses. The monitoring and management module parses, classifies, and caches the received data, and generates application-level, partition-level, and device-level monitoring information. The user interface layer can display application names and operational status in tables, CPU load, memory usage, and device temperature in numerical or line graphs, key variables in variable lists or trend curves, and train network status in a topology diagram.
[0202] It should be noted that, in Figure 3 In the illustrated architecture, a communication protocol also needs to be configured between the monitoring and management module 225 and the TCP client.
[0203] Furthermore, the user interface layer is used to obtain variable selection information for the variable to be observed; the monitoring and management module is also used to determine the application to be deployed corresponding to the variable to be observed based on the variable selection information and the platform configuration; send a variable data request corresponding to the variable to be observed to the domain controller through the communication and data interaction layer; and generate monitoring information corresponding to the variable to be observed based on the variable data returned by the domain controller in response to the variable data request.
[0204] The variable configuration interface displays a list of variables that have been registered in the platform configuration. Users can select one or more variables to be observed by variable name, application, data type, or variable group.
[0205] The monitoring and management module reads the variable selection information and queries the application, variable address, and data type of the variable to be observed from the variable configuration and application runtime configuration in the platform configuration file. Subsequently, the monitoring and management module sends a variable subscription request or a single variable read request to the domain controller via a TCP client. The domain controller retrieves the variable value from the corresponding application or middleware data area and returns the variable identifier, timestamp, and variable value. The monitoring and management module parses the variable value according to the data type to generate monitoring information such as the variable's current value, trend, and abnormal status. Users can also add or remove variables to be observed during operation, and the monitoring and management module updates the variable subscription request accordingly.
[0206] In some embodiments, the platform configuration file includes board configuration data corresponding to the CPU board and at least one other board of the domain controller, respectively; the communication and data interaction layer is used to transmit the platform configuration file to the CPU board, so that the CPU board sends a configuration update instruction to the at least one other board via Ethernet User Datagram Protocol (UDP) messages; the at least one other board is used to respond to the configuration update instruction, parse the corresponding board configuration data in the platform configuration file, and return a configuration update result to the CPU board; the CPU board is used to summarize the configuration update results returned by the at least one other board; and the communication and data interaction layer is used to obtain the configuration update result summarized by the CPU board and provide the configuration update result to the business logic layer to generate the deployment execution result corresponding to the platform configuration file.
[0207] Specifically, the board configuration interface receives configuration parameters from the CPU board and other functional boards. The configuration management module writes the configuration data of each board into the same XML platform configuration file according to the board identifier. The file transfer module calls an FTP client to send the XML platform configuration file to the CPU board's preset directory. After receiving the configuration file, the CPU board sends a configuration update command to other boards via Ethernet UDP packets. The configuration update command can carry the configuration file version, configuration file path, or configuration update identifier. After receiving the configuration update command, other boards read the configuration node matching their own board identifier from the configuration file, parse, verify, and update the corresponding configuration parameters, and return a successful, failed, or partially successful configuration update result to the CPU board. The CPU board collects the results returned by each board and summarizes them, then returns the summarized result through data communication with the host computer. The business logic layer determines the configuration update status of each board based on the summarized result and generates the deployment execution result corresponding to the platform configuration file. The configuration monitoring interface displays the successfully configured boards, the boards that failed to configure, and the corresponding error reasons.
[0208] In summary, this invention proposes a three-layer architecture (user interface layer - business logic layer - communication and data interaction layer) suitable for the configuration and deployment of train virtualization control system software, as well as a standardized implementation mechanism for data and functional linkage between each layer; modular decomposition of functions in each layer and standardized definition of interfaces, including multiple configuration / monitoring interfaces in the interface layer, design of five major functional modules in the business layer, and dedicated division of labor mechanism for SSH / FTP / TCP protocols in the communication layer.
[0209] Furthermore, the planning and scheduling module includes a two-level resource scheduling mechanism of algorithm planning + virtualization configuration, and an implementation method of the four steps of algorithm planning (planning objectives / constraints / construction / feasible region solution). It also features an automatic planning mechanism for the number of partitions and application deployment based on application computing power test parameters and user requirements as input, a multi-dimensional real-time monitoring mechanism for application running status, system resources (CPU load / temperature / memory), and key variables, as well as dynamic display of resource trends and dynamic selection and observation functions for variables.
[0210] Thus, through the dynamic matching mechanism of onboard physical resources and virtual resources based on the above embodiments, and the flexible adjustment mechanism of deployment strategy and resource configuration according to the train software safety level / type / operating conditions, it is possible to achieve resource-differentiated deployment of functional safety / non-functional safety software.
[0211] This application also provides a configuration, deployment, and monitoring method for domain controllers. This configuration, deployment, and monitoring method for domain controllers can be applied to the configuration, deployment, and monitoring apparatus for domain controllers described in any of the foregoing embodiments.
[0212] See Figure 13 , Figure 13 This is a flowchart illustrating a configuration, deployment, and monitoring method for a domain controller, as described in an embodiment of this application, including: S131 obtains the application requirements of the application to be deployed and the configuration requirements for the domain controller through the user interface layer, forming a configuration deployment task.
[0213] S132, the business logic layer establishes the association between the application to be deployed, the virtualization resources of the domain controller, and the platform configuration based on the configuration deployment task and the running characteristics of the application to be deployed.
[0214] S133, the business logic layer generates a deployment object for the domain controller to load based on the association relationship. The deployment object includes the target program, virtualization runtime environment and platform configuration corresponding to the application to be deployed.
[0215] S134, through the remote control interaction, file interaction and runtime data interaction provided by the communication and data interaction layer, the deployment object is sent to the domain controller, and the deployment execution result and runtime data returned by the domain controller are obtained.
[0216] S135, the business logic layer generates monitoring information based on the deployment execution result and the running data, and presents the execution result of the configuration deployment task and the monitoring information through the user interface layer.
[0217] For a more detailed description of the configuration, deployment, and monitoring methods for domain controllers, please refer to the aforementioned example.
[0218] Furthermore, embodiments of this application also provide a vehicle, the vehicle including: a configuration deployment and monitoring device for a domain controller as described in any of the foregoing embodiments.
[0219] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.
[0220] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.
[0221] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. A configuration, deployment, and monitoring device for domain controllers, characterized in that, include: The user interface layer is used to obtain the application requirements of the application to be deployed and the configuration requirements for the domain controller, form a configuration deployment task, and present the execution results and monitoring information of the configuration deployment task. The business logic layer, connected to the user interface layer, is used to establish the association between the application to be deployed, the virtualization resources of the domain controller, and the platform configuration based on the configuration deployment task and the running characteristics of the application to be deployed, and to generate a deployment object for the domain controller to load based on the association. The deployment object includes the target program, virtualization runtime environment, and platform configuration corresponding to the application to be deployed. A communication and data interaction layer is set between the business logic layer and the domain controller. It is used to provide remote control interaction, file interaction and runtime data interaction for the business logic layer, so as to send the deployment object to the domain controller and obtain the deployment execution results and runtime data returned by the domain controller. The business logic layer is further configured to generate the monitoring information based on the deployment execution results and the running data, and provide the monitoring information to the user interface layer.
2. The configuration, deployment, and monitoring device according to claim 1, characterized in that, The user interface layer includes at least one of the following: partition configuration interface, resource configuration interface, board configuration interface, application configuration interface, variable configuration interface, file configuration interface, configuration monitoring interface, and topology monitoring interface. At least one of the partition configuration interface and the resource configuration interface is used to obtain the application requirements of the application to be deployed and the virtualization resource configuration requirements of the domain controller. At least one of the board configuration interface, the application configuration interface, the variable configuration interface, and the file configuration interface is used to obtain the platform configuration requirements for the domain controller. The configuration monitoring interface is used to present at least one of the following: the execution result of the configuration deployment task, the running status of the application to be deployed, and the resource running status of the domain controller; The topology monitoring interface is used to display the train network topology, as well as the status of network nodes and communication links in the train network topology.
3. The configuration, deployment, and monitoring device according to claim 1, characterized in that, The business logic layer includes a planning and scheduling module, which includes an algorithm planning submodule and a virtualization configuration submodule. The algorithm planning submodule is used to obtain the hardware resource parameters of the domain controller and the application requirement parameters of the application to be deployed from the configuration deployment task; control the application to be deployed to run in the test environment provided by the domain controller through the communication and data interaction layer, and obtain the execution time and resource consumption of the application to be deployed; and determine the processor core configuration of the virtualization partition used to host the application to be deployed based on the comparison result between the execution time and the maximum allowed execution time in the application requirement parameters. Based on the execution cycle of the application to be deployed and the maximum allowable jitter time, the time interval between the start times of two consecutive executions of the application to be deployed is limited; Based on the execution cycle, execution time, and deadline of the application to be deployed, the start and end times of each execution of the application to be deployed are defined, and the order of execution between two adjacent executions is defined based on the start and end times of two adjacent executions; based on the hardware resource parameters, the processor core configuration, the resource usage, and the limitations on the start time, the end time, and the order of execution, candidate partition deployment relationships that meet the running requirements of the application to be deployed are determined; based on the execution time span of multiple applications to be deployed within the same supercycle and the differences in task execution load between different virtualization partitions, the target partition deployment relationship is determined from the candidate partition deployment relationships; And determine the association relationship based on the target partition deployment relationship; The virtualization configuration submodule is used to generate the virtualization runtime environment based on the association relationship.
4. The configuration, deployment, and monitoring device according to claim 3, characterized in that, The algorithm planning submodule is also used to convert the hardware resource parameters, the processor core configuration, the resource usage, and the constraints on the start time, the end time, and the sequence relationship into satisfiability modular theory constraint expressions; The satisfiability of the satisfiability modulo theoretical constraint expression is determined to obtain the candidate partition deployment relationship that satisfies the running requirements of the application to be deployed and the hardware resource limitations of the domain controller. A comprehensive objective function is constructed based on the execution time span and the differences in task execution load; and an extreme value search is performed on the comprehensive objective function within the feasible domain formed by the candidate partition deployment relationship through iterative search to determine the target partition deployment relationship.
5. The configuration deployment and monitoring device according to claim 3 or 4, characterized in that, The test environment is a single-partition, single-core test environment in which a virtualization partition and a processor core are independently allocated to each application to be deployed. The algorithm planning submodule is also used to transmit the application to be deployed to the single-partition single-core test environment through the communication and data interaction layer; control the application to be deployed to run in the single-partition single-core test environment; and acquire at least one of the following test data generated during the operation of the application to be deployed: application execution time, processor usage, memory usage, and execution jitter. And determine the operational characteristics of the application to be deployed based on the test data.
6. The configuration, deployment, and monitoring device according to claim 3, characterized in that, The business logic layer also includes a configuration management module and an application development module, wherein: The planning and scheduling module is also used to generate virtualization runtime environment files that constitute the virtualization runtime environment based on the association relationship; The application development module is used to generate the target program corresponding to the application to be deployed. The configuration management module is used to generate a platform configuration file based on the platform configuration. The business logic layer is also used to organize the target program, the virtualization runtime environment file, and the platform configuration file into the deployment object according to the association between the application to be deployed and the virtualization partition.
7. The configuration, deployment, and monitoring device according to claim 6, characterized in that, The virtualization configuration submodule is used to determine the processor resources, memory resources, and device resources corresponding to each virtualization partition according to the association relationship; remotely log in to the preset cross-compilation environment through the communication and data interaction layer; generate at least one of the device tree file, resource configuration file, kernel image, and file system corresponding to each virtualization partition according to the processor resources, memory resources, and device resources; and use at least one of the device tree file, resource configuration file, kernel image, and file system as the virtualization runtime environment file.
8. The configuration, deployment, and monitoring device according to claim 6, characterized in that, The application development module is used to obtain the source program of the application to be deployed; perform at least one of the following on the source program: syntax rule checking, variable reference legality verification, and logical conflict detection; cross-compile the verified source program according to the target device architecture of the domain controller, and link the system library and user-defined library to generate the target program; generate integrity verification information of the target program, and associate the integrity verification information with the target program in the deployment object; The source program includes at least one of a control program conforming to the IEC 61131-3 standard and a C language application.
9. The configuration, deployment, and monitoring device according to claim 6, characterized in that, The configuration management module is used to manage at least one of the following configuration information according to a unified configuration data structure: application operation configuration, variable configuration, variable list configuration, message storage configuration, log storage configuration, message function configuration, log function configuration, network configuration, and board configuration; and to verify the configuration information and save the verified configuration information as the platform configuration file in XML format, or read the configuration information from the platform configuration file.
10. The configuration, deployment, and monitoring device according to claim 1, characterized in that, The communication and data interaction layer includes SSH clients, FTP clients, and TCP clients, wherein: The SSH client is used to remotely log in to the virtual machine, cross-compilation environment, or domain controller, and to perform at least one of the following operations: application compilation, virtualization runtime environment construction, and remote control. The FTP client is used to transfer files between the configuration deployment and monitoring device and the domain controller; The TCP client is used to transmit control commands and operational data between the configuration deployment and monitoring device and the domain controller.
11. The configuration deployment and monitoring device according to claim 10, characterized in that, The business logic layer also includes a file transfer module; The file transfer module is used to invoke the FTP client to establish or disconnect a file transfer connection between the configuration deployment and monitoring device and the domain controller, and to perform at least one of the following operations on remote files in the domain controller: refresh, upload, and download; the remote files include at least one of the following: application dynamic library files, platform configuration files, log files, and virtualization runtime environment files; The file transfer module and the communication and data interaction layer are used to transfer the deployment object to the domain controller through the FTP client; and to perform integrity verification on the target program according to the integrity verification information associated with the target program. Specifically, after the integrity verification is passed, a loading command is sent to the domain controller via the SSH client or the TCP client, so that the domain controller establishes the corresponding virtualization runtime environment according to the association relationship, and loads the target program and the platform configuration into the corresponding virtualization runtime environment; and the loading result returned by the domain controller is obtained through the TCP client, and the loading result is provided to the business logic layer as the deployment execution result.
12. The configuration, deployment, and monitoring device according to claim 1, characterized in that, The business logic layer includes a monitoring and management module, which is used to obtain the running data returned by the domain controller through the communication and data interaction layer. The running data includes at least one of the following: application running status, processor load, memory usage, device temperature, key variable data, and train network topology data. The system determines at least one of the following based on the operational data: the operational status of the application to be deployed, the system resource usage of the domain controller, the status of key variables, and the status of the train network; and generates the monitoring information based on the determined operational status, system resource usage, status of key variables, or status of the train network, and provides the monitoring information to the user interface layer.
13. The configuration, deployment, and monitoring device according to claim 12, characterized in that, The user interface layer is used to obtain variable selection information for the variable to be observed; The monitoring and management module is also used to determine the application to be deployed corresponding to the variable to be observed based on the variable selection information and the platform configuration; send a variable data request corresponding to the variable to be observed to the domain controller through the communication and data interaction layer; and generate monitoring information corresponding to the variable to be observed based on the variable data returned by the domain controller in response to the variable data request.
14. The configuration, deployment, and monitoring device according to claim 9, characterized in that, The platform configuration file includes board configuration data corresponding to the CPU board and at least one other board of the domain controller, respectively; The communication and data interaction layer is used to transmit the platform configuration file to the CPU board, so that the CPU board can send a configuration update instruction to the at least one other board via Ethernet User Datagram Protocol (UDP) messages. The at least one other board is used to respond to the configuration update command, parse the corresponding board configuration data in the platform configuration file, and return the configuration update result to the CPU board; The CPU board is used to summarize the configuration update results returned by at least one other board; The communication and data interaction layer is used to obtain the configuration update results summarized by the CPU board and provide the configuration update results to the business logic layer to generate the deployment execution results corresponding to the platform configuration file.
15. A configuration, deployment, and monitoring method for domain controllers, characterized in that, include: The application requirements of the application to be deployed and the configuration requirements for the domain controller are obtained through the user interface layer, and a configuration deployment task is formed. The business logic layer establishes the association between the application to be deployed, the virtualization resources of the domain controller, and the platform configuration based on the configuration deployment task and the running characteristics of the application to be deployed. The business logic layer generates a deployment object for the domain controller to load based on the association relationship. The deployment object includes the target program, virtualization runtime environment, and platform configuration corresponding to the application to be deployed. The deployment object is sent to the domain controller through remote control interaction, file interaction and runtime data interaction provided by the communication and data interaction layer, and the deployment execution results and runtime data returned by the domain controller are obtained. The business logic layer generates monitoring information based on the deployment execution results and the running data, and the user interface layer presents the execution results of the configuration deployment task and the monitoring information.
16. A vehicle, characterized in that, include: The configuration, deployment, and monitoring apparatus for domain controllers as described in any one of claims 1 to 14.
