Dio control system fusing train host and computing power node equipment
By introducing a conflict-free request execution sequence with global verification into the train control system, the problem of uncertain DIO channel output caused by multiple requests acting simultaneously is solved, and the timing reliability and security of DIO operation are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NANJING XINYUANTONG INTELLIGENT TECH CO LTD
- Filing Date
- 2026-04-24
- Publication Date
- 2026-05-29
- Estimated Expiration
- Not applicable · inactive patent
AI Technical Summary
In train control systems, when multiple control logic modules send operation requests to the same physical DIO channel, the lack of global consistency verification can lead to conflicting instructions being issued simultaneously, resulting in uncertain hardware output states and safety hazards.
A conflict-free request execution sequence with global verification is introduced. Through modules such as request reception, time grouping, legal filtering, conflict identification, arbitration, and centroid generation, a conflict-free request execution sequence is generated to ensure the timing reliability of DIO operations.
Ensure that each physical DIO channel always has a unique and definite expected state during operation, avoid abnormal behaviors such as output signal oscillation, and improve the functional safety level of the train control system.
Smart Images
Figure CN122120344A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to train control systems, specifically a DIO control system that integrates train host and computing node devices. Background Technology
[0002] In train control systems, physical DIO channels serve as crucial hardware interfaces for outputting control signals or reading status signals, and the timing consistency of their operations directly impacts train safety. In existing technologies, when multiple control logic modules concurrently request the same physical DIO channel, failure to coordinate the desired channel states specified in each request can lead to conflicting commands being issued simultaneously. For example, one request might require a channel to be set high, while another request simultaneously requires it to be set low, resulting in uncertain hardware output states and potentially causing malfunctions. Traditional methods typically rely on upper-level logic to avoid concurrency or employ simple priority override mechanisms. However, these methods lack global consistency checks on the desired channel states and cannot dynamically identify potential conflicts between requests. They struggle to guarantee the timing reliability of all DIO operations under complex conditions, potentially leading to abnormal behaviors such as output signal oscillations due to multiple simultaneous requests, posing safety hazards and affecting the functional safety level of the train control system. Summary of the Invention
[0003] To address the shortcomings of existing technologies, this invention provides a DIO control system that integrates train host and computing node devices, and solves the technical problems mentioned in the background by introducing a globally verified conflict-free request execution sequence.
[0004] To achieve the above objectives, the present invention provides the following technical solution: The DIO control system, which integrates the train host and computing node equipment, includes: The request receiving module is used to receive N operation requests from the host or node device within a processing window during train operation. The operation request must include at least: channel number, desired channel status, initiator, and request timestamp; Specifically, each operation request corresponds to a unique DIO channel, and the initiator is used to identify the source type of the operation request, the value of which includes: host identifier or node device ID; The time grouping module is used to group N operation requests by time based on the request timestamp to obtain K operation request groups; wherein each operation request group contains G operation requests, and G is a variable.
[0005] The validity filtering module is used to perform validity filtering on K operation request groups to obtain K valid request groups; The conflict identification module is used to identify conflicts in K legitimate request groups and extract the U first non-conflicting requests and M conflicting request subsets from each legitimate request group. The conflict arbitration module is used to perform deterministic arbitration on M subsets of conflicting requests to obtain M second conflict-free requests corresponding to the M subsets of conflicting requests. The request aggregation module is used to traverse K legitimate request groups, aggregate the U first conflict-free requests and M second conflict-free requests of each legitimate request group, and obtain K conflict-free request groups. The centroid acquisition module is used to obtain the K centroid timestamps of K conflict-free request groups; The sequence generation module is used to sort K conflict-free request groups according to K centroid timestamps and generate a global conflict-free request execution sequence. The request execution module is used to execute the DIO operations corresponding to each conflict-free request in the order of the conflict-free request execution sequence.
[0006] In some implementations, the grouping step of the inter-grouping module includes: S2-1. Randomly select K operation requests from N operation requests as the initial centroid; S2-2. Distribute the remaining NK operation requests one by one to the operation request group corresponding to the initial centroid with the smallest time distance from their request timestamps, where the time distance is the absolute value of the difference between the two request timestamps. S2-3. For each operation request group, extract the request timestamps of all operation requests within the group, and calculate the average timestamp of all request timestamps. S2-4. Calculate the time distance between the average timestamp and all request timestamps, and select the operation request corresponding to the smallest time distance as the new centroid; S2-5. Calculate the time deviation of the centroid timestamps of each operation request group before and after this round of update, and determine whether all time deviations are less than or equal to the preset deviation threshold. S2-6. If any time deviation is greater than the deviation threshold, the allocation is re-executed based on the new centroids of each group. S2-7. If all time deviations do not exceed the deviation threshold, stop the iteration and output the current K operation request groups.
[0007] In some implementations, the filtering steps of the legitimate filtering module include: S3-1. Select the current request group one by one from the K operation request groups; S3-2. Extract the G channel numbers corresponding to the G operation requests in the current request group; S3-3. Obtain the current train operation mode and extract the corresponding mode permission rules from the pre-built mode permission table based on the train operation mode. S3-4. Match the G channel numbers with the set of authorized operable channel numbers in the mode permission rules; S3-5. If any channel number is not present in the set of authorized operable channel numbers, the operation request containing that channel number is marked as an illegal request and removed; otherwise, it is marked as a legal request. S3-6. Traverse the G operation requests of the current request group, retain all G1 valid requests, until K valid request groups are obtained; where G1 is a variable.
[0008] In some implementations, the pre-construction step of the schema permission table includes: A1. Enumerate all possible operating modes of the train; A2. Define the set of DIO channel numbers that can be operated by the host or node devices in all possible operating modes; A3. Establish a mapping between the operating mode and the corresponding set of allowed DIO channel numbers to form a mode permission table and store it permanently.
[0009] In some implementations, the identification steps of the conflict identification module include: S4-1, Anchor the G1 legitimate requests contained in the legitimate request group and extract their channel numbers; S4-2. Arrange the G1 legitimate requests in order based on the channel number, and construct a sequence diagram of legitimate requests corresponding to the legitimate request group. S4-3. Along the ordered direction of the legal request sequence diagram, compare the channel numbers of two adjacent legal requests one by one; S4-4. If the channel numbers of two adjacent legitimate requests are different, the preceding legitimate request is marked as the first conflict-free request; otherwise, the two adjacent legitimate requests are both assigned to the same subset of conflicting requests. S4-5. Traverse the valid request sequence diagram and repeat the comparison until M conflicting request subsets are extracted from the valid request sequence diagram; wherein each conflicting request subset consists of consecutive valid requests with the same channel number.
[0010] In some implementations, the arbitration steps of the conflict arbitration module include: S5-1. Extract the initiator of each legitimate request from the subset of conflicting requests; S5-2. If the initiator in any subset of conflicting requests is a host identifier, then the operation request in which this initiator is located shall be the final request of the subset of conflicting requests, and operation requests initiated by a node device ID shall be removed. S5-3. If the initiators of the conflict request subset are all node devices, then query the node weight of each node device on the channel number in the pre-built DIO channel resource matrix, and retain the operation request with the highest node weight as the final request of the conflict request subset. S5-4. If the node weights are the same, compare the request timestamps of each request and take the operation request with the earlier timestamp as the final request of the subset of conflicting requests. S5-5. Traverse the M conflicting request subsets and repeatedly execute the arbitration until the M final requests of the legitimate request group are obtained, and mark them as the M second conflict-free requests.
[0011] In some implementations, the pre-construction step of the DIO channel resource matrix includes: B1. Enumerate all DIO channel numbers that can be operated by node devices; B2. For each DIO channel, list the node device IDs that are authorized to operate this DIO channel; B3. Obtain the device criticality level and physical topology distance based on the node device ID, and calculate the node weight corresponding to this node device ID based on the device criticality level and physical topology distance. B4. Concatenate the DIO channel number, node device ID, and node weight into a row index to form a DIO channel resource matrix and store it permanently.
[0012] In some implementations, the centroid acquisition module includes the following acquisition steps: S7-1. For each conflict-free request group, calculate the arithmetic mean of all request timestamps within the group to obtain the average timestamp of the group. S7-2. Calculate the absolute time difference between the average timestamp and each requested timestamp in the group; S7-3. Select the operation request corresponding to the request timestamp with the smallest absolute time difference, and mark its request timestamp as the centroid timestamp of the conflict-free request group. S7-4. Traverse the K conflict-free request groups and repeat the above marking until K centroid timestamps are obtained.
[0013] This invention provides a DIO control system that integrates train host and computing node equipment, which has the following beneficial effects: In this invention, when multiple operation requests may simultaneously specify the desired state of the same physical DIO channel, if any two requests specify different desired states for that channel, then there is a conflict between these requests. Before execution, the system performs a consistency check on all pending requests, eliminates request combinations that cause inconsistent states, and retains only a subset of requests that specify the same desired state for all physical DIO channels. This subset constitutes a conflict-free request execution sequence. When executed in this sequence, each physical DIO channel is always assigned a unique and definite desired state throughout the entire operation process, and will not produce abnormal behaviors such as output signal oscillation due to multiple requests acting simultaneously. Attached Figure Description
[0014] Figure 1 This is a structural block diagram of the DIO control system that integrates the train host and computing node equipment of the present invention; Figure 2 This is a schematic diagram of the processing flow of the DIO control system that integrates the train host and computing node equipment of the present invention; Figure 3 This is a schematic diagram of the marking process for the legitimate request group described in this invention; Figure 4 This is a schematic diagram of the process for extracting a subset of conflict requests as described in this invention. Detailed Implementation
[0015] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0016] Example 1: Please refer to Figures 1 to 2 This invention provides a DIO control system that integrates a train host and a computing node device, comprising the following modules: The request receiving module is used to receive N operation requests from the host or node device within a processing window during train operation. Specifically, the processing window is a time interval defined by the train control system within a unit scheduling cycle, used to process operation requests from the host and computing node devices. Its duration is preset to a fixed value or dynamically adjusted value according to the real-time requirements of train operation.
[0017] Each operation request corresponds to a unique DIO channel and includes at least the following fields arranged in sequence: channel number, channel expected status, initiator, and request timestamp; and the initiator is used to identify the source type of the operation request, and its value includes: host identifier or node device ID. Specifically, the operation request represents a control command to set, reset, or switch the state of the DIO channel.
[0018] The time grouping module is used to group N operation requests by time based on the request timestamp to obtain K operation request groups; wherein each operation request group contains G operation requests, and G is a variable.
[0019] Specifically, the time grouping refers to grouping operation requests that are close in time into the same operation request group based on the request timestamp of the operation request, so that the requests within the group have local density in the time dimension.
[0020] The validity filtering module is used to perform validity filtering on K operation request groups to obtain K valid request groups; The conflict identification module is used to identify conflicts in K legitimate request groups and extract the U first non-conflicting requests and M conflicting request subsets from each legitimate request group. The conflict arbitration module is used to perform deterministic arbitration on M subsets of conflicting requests to obtain M second conflict-free requests corresponding to the M subsets of conflicting requests. The request aggregation module is used to traverse K legitimate request groups, aggregate the U first conflict-free requests and M second conflict-free requests of each legitimate request group, and obtain K conflict-free request groups. The centroid acquisition module is used to obtain the K centroid timestamps of K conflict-free request groups; The sequence generation module is used to sort K conflict-free request groups according to K centroid timestamps and generate a global conflict-free request execution sequence. The request execution module is used to execute the DIO operations corresponding to each conflict-free request in the order of the conflict-free request execution sequence.
[0021] Specifically, each conflict-free request contains a channel number and a desired channel state that uniquely determine a DIO operation. The DIO operation is to drive the physical DIO channel corresponding to the specified channel number to the desired channel state. Here, the physical DIO channel is digital input / output hardware in the train control system used to output control signals or read status signals; the desired channel state is a binary state, such as the physical DIO channel being on / off, or a high / low level.
[0022] In this embodiment, the global conflict-free request execution sequence is a one-dimensional ordered list, whose elements are DIO operation requests from different conflict-free request groups, and the DIO channel numbers corresponding to any two adjacent elements are different or have been resolved by arbitration in time; so that the DIO controller does not need to perform runtime conflict detection during execution, avoiding output signal jitter or uncertainty caused by multiple operation requests being written to the same DIO channel concurrently.
[0023] Example 2: See Figures 3 to 4 The technical solution of this embodiment 2 differs from that of embodiment 1 in that it discloses the specific implementation steps of each module of embodiment 1.
[0024] Specifically, in this embodiment, the grouping steps of the inter-grouping module include: S2-1. Randomly select K operation requests from N operation requests as the initial centroid; S2-2. Distribute the remaining NK operation requests one by one to the operation request group corresponding to the initial centroid with the smallest time distance from their request timestamps, where the time distance is the absolute value of the difference between the two request timestamps. S2-3. For each operation request group, extract the request timestamps of all operation requests within the group, and calculate the average timestamp of all request timestamps. It should be noted that the timestamp mean is the arithmetic average of the timestamps (integer values in milliseconds) of all operation requests within a group. This value represents the center position of the request group on the timeline and is used to iteratively optimize the group centroid.
[0025] S2-4. Calculate the time distance between the average timestamp and all request timestamps, and select the operation request corresponding to the smallest time distance as the new centroid; S2-5. Calculate the time deviation of the centroid timestamps of each operation request group before and after this round of update, and determine whether all time deviations are less than or equal to the preset deviation threshold. Specifically, the deviation threshold is a preset time amount used to determine whether the time grouping has converged. Its value is set according to the response accuracy requirements of the train DIO control system, and the typical value range is 1 millisecond to 10 milliseconds.
[0026] S2-6. If any time deviation is greater than the deviation threshold, the allocation is re-executed based on the new centroids of each group. S2-7. If all time deviations do not exceed the deviation threshold, stop the iteration and output the current K operation request groups.
[0027] In this embodiment, the K operation request groups are request sets divided based on temporal local density. The operation requests within each operation request group are adjacent to each other in terms of timestamps, and there is a distinguishable interval between each group in the time dimension. This allows time-intensive operation requests within the same processing window to be effectively merged, reducing inter-group interference caused by time dispersion.
[0028] Specifically, in this embodiment, the filtering steps of the legality filtering module include: S3-1. Select the current request group one by one from the K operation request groups; S3-2. Extract the G channel numbers corresponding to the G operation requests in the current request group; S3-3. Obtain the current train operation mode and extract the corresponding mode permission rules from the pre-built mode permission table based on the train operation mode. Specifically, the train operation mode refers to the current working state of the train control system, including but not limited to normal operation mode, emergency braking mode, maintenance mode, and car wash mode, which are broadcast in real time by the train central control unit.
[0029] S3-4. Match the G channel numbers with the set of authorized operable channel numbers in the mode permission rules; The matching refers to checking whether each single channel number specified in each operation request exists in the set of channel numbers authorized in the current mode; if it exists, the request passes the permission verification, otherwise it is rejected.
[0030] S3-5. If any channel number is not present in the set of authorized operable channel numbers, the operation request containing that channel number is marked as an illegal request and removed; otherwise, it is marked as a legal request. S3-6. Traverse the G operation requests of the current request group, retain all G1 valid requests, until K valid request groups are obtained; where G1 is a variable.
[0031] In this embodiment, the K groups of legitimate requests are formed by filtering the original operation request groups through channel permissions. Each group contains only operation requests corresponding to the DIO channels that are authorized to operate under the current train operation mode, and illegal requests have been eliminated. This ensures that all requests entering the conflict identification stage meet the operation mode security constraints.
[0032] Furthermore, the pre-construction step of the pattern permission table includes: A1. Enumerate all possible operating modes of the train; A2. Define the set of DIO channel numbers that can be operated by the host or node devices in all possible operating modes; Specifically, the set of DIO channel numbers that are allowed to be operated refers to a list of channel numbers that, under a specific operating mode, are authorized only for the host or node device to issue control commands to a specified DIO channel for security or functional reasons.
[0033] A3. Establish a mapping between the operating mode and the corresponding set of allowed DIO channel numbers to form a mode permission table and store it permanently.
[0034] In this embodiment, the mode permission table is a static mapping structure, each of which consists of a train operation mode and a set of authorized operable channel numbers, used to quickly determine channel operation permissions during the legality filtering stage.
[0035] Specifically, in this embodiment, the identification steps of the conflict identification module include: S4-1, Anchor the G1 legitimate requests contained in the legitimate request group and extract their channel numbers; S4-2. Arrange the G1 legitimate requests in order based on the channel number, and construct a sequence diagram of legitimate requests corresponding to the legitimate request group. S4-3. Along the ordered direction of the legal request sequence diagram, compare the channel numbers of two adjacent legal requests one by one; S4-4. If the channel numbers of two adjacent legitimate requests are different, the preceding legitimate request is marked as the first conflict-free request; otherwise, the two adjacent legitimate requests are both assigned to the same subset of conflicting requests. Specifically, the conflicting request subset refers to a set of requests within the same legitimate request group that target the same DIO channel number and appear consecutively in time, making them impossible to execute simultaneously and requiring arbitration.
[0036] S4-5. Traverse the valid request sequence diagram and repeat the comparison until M conflicting request subsets are extracted from the valid request sequence diagram; wherein each conflicting request subset consists of consecutive valid requests with the same channel number.
[0037] In this embodiment, the M conflict request subsets are subsequences within the legitimate request group. Each conflict request subset contains two or more legitimate requests that are consecutively arranged in the legitimate request sequence diagram and have the same channel number. Arbitration is required to determine the unique execution request, thereby ensuring that the scope of the conflict is limited to the consecutive requests in the same channel and avoiding the incorrect inclusion of non-consecutive requests in the same conflict domain.
[0038] Specifically, in this embodiment, the arbitration steps of the conflict arbitration module include: S5-1. Extract the initiator of each legitimate request from the subset of conflicting requests; S5-2. If the initiator in any subset of conflicting requests is a host identifier, then the operation request in which this initiator is located shall be the final request of the subset of conflicting requests, and operation requests initiated by a node device ID shall be removed. S5-3. If the initiators of the conflict request subset are all node devices, then query the node weight of each node device on the channel number in the pre-built DIO channel resource matrix, and retain the operation request with the highest node weight as the final request of the conflict request subset. Specifically, the DIO channel resource matrix is a mapping structure with DIO channel number as the row, node device ID that has the right to operate the channel as the column, and DIO channel number and node device ID as a joint index to store the corresponding node weights, which is used to quickly query the arbitration basis.
[0039] The node weight is a priority value pre-assigned to each node device on a specific DIO channel, used to achieve deterministic arbitration in conflict scenarios without host involvement. Its value is set according to the functional criticality or physical location of the node device.
[0040] S5-4. If the node weights are the same, compare the request timestamps of each request and take the operation request with the earlier timestamp as the final request of the subset of conflicting requests. S5-5. Traverse the M conflicting request subsets and repeatedly execute the arbitration until the M final requests of the legitimate request group are obtained, and mark them as the M second conflict-free requests.
[0041] In this embodiment, the M second conflict-free requests are the winning requests output after performing deterministic arbitration on the M conflict request subsets respectively. Each second conflict-free request uniquely corresponds to a conflict request subset, and its initiator and channel number are inherited from a certain legitimate request in the original conflict subset. This ensures that each conflict subset ultimately generates only one executable instruction, eliminating the conflict of multiple sources writing concurrently to the same DIO channel.
[0042] Furthermore, the pre-construction step of the DIO channel resource matrix includes: B1. Enumerate all DIO channel numbers that can be operated by node devices; B2. For each DIO channel, list the node device IDs that are authorized to operate this DIO channel; B3. Obtain the device criticality level and physical topology distance based on the node device ID, and calculate the node weight corresponding to this node device ID based on the device criticality level and physical topology distance. The formula for calculating the node weight is: ; in: Indicates node weight; This indicates the criticality level of the equipment at this node. The value is a preset discrete integer, with a larger value indicating a more critical function of the equipment in the train control system. This indicates the physical topology distance between the node device and the target DIO channel, measured in communication hops or cable length. This represents the maximum physical topology distance from any node device to any DIO channel; This represents the normalized topological proximity, with a value range of [0,1]. This represents a key regulating factor, with a value range of [value range missing]. 0.5≤α<1 is used to emphasize the dominant role of the critical level of the equipment.
[0043] B4. Concatenate the DIO channel number, node device ID, and node weight into a row index to form a DIO channel resource matrix and store it permanently.
[0044] In this embodiment, the DIO channel resource matrix is a set of triples (DIO channel number, node device ID, node weight), which is used to quickly retrieve the corresponding node weight value based on the channel number and node device ID during the conflict arbitration phase, ensuring that the arbitration process is completed quickly.
[0045] Specifically, in this embodiment, the centroid acquisition module includes the following acquisition steps: S7-1. For each conflict-free request group, calculate the arithmetic mean of all request timestamps within the group to obtain the average timestamp of the group. S7-2. Calculate the absolute time difference between the average timestamp and each requested timestamp in the group; S7-3. Select the operation request corresponding to the request timestamp with the smallest absolute time difference, and mark its request timestamp as the centroid timestamp of the conflict-free request group. S7-4. Traverse the K conflict-free request groups and repeat the above marking until K centroid timestamps are obtained.
[0046] It should be noted that the centroid timestamp must be anchored to the timestamp of an actual operation request within the group, rather than directly using the arithmetic mean. The reason is that it is necessary to sort the conflict-free request groups based on the centroid timestamp to generate a global execution sequence, and the execution of DIO control instructions must strictly correspond to an actual initiated operation request. If a non-realistic average timestamp is used as the sorting basis, the execution sequence will not be able to map back to the specific operation request entity, thus compromising the traceability of control instructions.
[0047] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means.
[0048] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0049] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.
[0050] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.
Claims
1. A DIO control system integrating train host and computing node equipment, characterized in that, include: The request receiving module is used to receive N operation requests from the host or node device within a processing window during train operation. The operation request must include at least: channel number, desired channel status, initiator, and request timestamp; The time grouping module is used to group N operation requests by time based on the request timestamp to obtain K operation request groups; wherein each operation request group contains G operation requests, and G is a variable; The validity filtering module is used to perform validity filtering on K operation request groups to obtain K valid request groups; The conflict identification module is used to identify conflicts in K legitimate request groups and extract the U first non-conflicting requests and M conflicting request subsets from each legitimate request group. The conflict arbitration module is used to perform deterministic arbitration on M subsets of conflicting requests to obtain M second conflict-free requests corresponding to the M subsets of conflicting requests. The request aggregation module is used to traverse K legitimate request groups, aggregate the U first conflict-free requests and M second conflict-free requests of each legitimate request group, and obtain K conflict-free request groups. The centroid acquisition module is used to obtain the K centroid timestamps of K conflict-free request groups; The sequence generation module is used to sort K conflict-free request groups according to K centroid timestamps and generate a global conflict-free request execution sequence. The request execution module is used to execute the DIO operations corresponding to each conflict-free request in the order of the conflict-free request execution sequence.
2. The DIO control system integrating train host and computing node equipment according to claim 1, characterized in that, The grouping steps of the inter-grouping module include: S2-1. Randomly select K operation requests from N operation requests as the initial centroid; S2-2. Distribute the remaining NK operation requests one by one to the operation request group corresponding to the initial centroid with the smallest time distance from their request timestamps, where the time distance is the absolute value of the difference between the two request timestamps. S2-3. For each operation request group, extract the request timestamps of all operation requests within the group, and calculate the average timestamp of all request timestamps. S2-4. Calculate the time distance between the average timestamp and all request timestamps, and select the operation request corresponding to the smallest time distance as the new centroid; S2-5. Calculate the time deviation of the centroid timestamps of each operation request group before and after this round of update, and determine whether all time deviations are less than or equal to the preset deviation threshold. S2-6. If any time deviation is greater than the deviation threshold, the allocation is re-executed based on the new centroids of each group. S2-7. If all time deviations do not exceed the deviation threshold, stop the iteration and output the current K operation request groups.
3. The DIO control system integrating the train host and computing node equipment according to claim 2, characterized in that, The filtering steps of the legitimate filtering module include: S3-1. Select the current request group one by one from the K operation request groups; S3-2. Extract the G channel numbers corresponding to the G operation requests in the current request group; S3-3. Obtain the current train operation mode and extract the corresponding mode permission rules from the pre-built mode permission table based on the train operation mode. S3-4. Match the G channel numbers with the set of authorized operable channel numbers in the mode permission rules; S3-5. If any channel number is not present in the set of authorized operable channel numbers, the operation request containing that channel number is marked as an illegal request and removed; otherwise, it is marked as a legal request. S3-6. Traverse the G operation requests of the current request group, retain all G1 valid requests, until K valid request groups are obtained; where G1 is a variable.
4. The DIO control system integrating the train host and computing node equipment according to claim 3, characterized in that, The pre-construction steps of the schema permission table include: A1. Enumerate all possible operating modes of the train; A2. Define the set of DIO channel numbers that can be operated by the host or node devices in all possible operating modes; A3. Establish a mapping between the operating mode and the corresponding set of allowed DIO channel numbers to form a mode permission table and store it permanently.
5. The DIO control system integrating the train host and computing node equipment according to claim 1, characterized in that, The identification steps of the conflict identification module include: S4-1, Anchor the G1 legitimate requests contained in the legitimate request group and extract their channel numbers; S4-2. Arrange the G1 legitimate requests in order based on the channel number, and construct a sequence diagram of legitimate requests corresponding to the legitimate request group. S4-3. Along the ordered direction of the legal request sequence diagram, compare the channel numbers of two adjacent legal requests one by one; S4-4. If the channel numbers of two adjacent legitimate requests are different, the preceding legitimate request is marked as the first conflict-free request; otherwise, the two adjacent legitimate requests are both assigned to the same subset of conflicting requests. S4-5. Traverse the valid request sequence diagram and repeat the comparison until M conflicting request subsets are extracted from the valid request sequence diagram; wherein each conflicting request subset consists of consecutive valid requests with the same channel number.
6. The DIO control system for integrating train host and computing node equipment according to claim 1, characterized in that, The arbitration steps of the conflict arbitration module include: S5-1. Extract the initiator of each legitimate request from the subset of conflicting requests; S5-2. If the initiator in any subset of conflicting requests is a host identifier, then the operation request in which this initiator is located shall be the final request of the subset of conflicting requests, and operation requests initiated by a node device ID shall be removed. S5-3. If the initiators of the conflict request subset are all node devices, then query the node weight of each node device on the channel number in the pre-built DIO channel resource matrix, and retain the operation request with the highest node weight as the final request of the conflict request subset. S5-4. If the node weights are the same, compare the request timestamps of each request and take the operation request with the earlier timestamp as the final request of the subset of conflicting requests. S5-5. Traverse the M conflicting request subsets and repeatedly execute the arbitration until the M final requests of the legitimate request group are obtained, and mark them as the M second conflict-free requests.
7. The DIO control system for integrating train host and computing node equipment according to claim 6, characterized in that, The pre-construction steps of the DIO channel resource matrix include: B1. Enumerate all DIO channel numbers that can be operated by node devices; B2. For each DIO channel, list the node device IDs that are authorized to operate this DIO channel; B3. Obtain the device criticality level and physical topology distance based on the node device ID, and calculate the node weight corresponding to this node device ID based on the device criticality level and physical topology distance. B4. Concatenate the DIO channel number, node device ID, and node weight into a row index to form a DIO channel resource matrix and store it permanently.
8. The DIO control system integrating train host and computing node equipment according to claim 1, characterized in that, The centroid acquisition module includes the following acquisition steps: S7-1. For each conflict-free request group, calculate the arithmetic mean of all request timestamps within the group to obtain the average timestamp of the group. S7-2. Calculate the absolute time difference between the average timestamp and each requested timestamp in the group; S7-3. Select the operation request corresponding to the request timestamp with the smallest absolute time difference, and mark its request timestamp as the centroid timestamp of the conflict-free request group. S7-4. Traverse the K conflict-free request groups and repeat the above marking until K centroid timestamps are obtained.