A rail transit train driver control unit test system

Abstract

This invention discloses a testing system for a rail transit train driver control unit, relating to the field of controller testing, aiming to solve the problems of incomplete functional coverage, low accuracy, and low efficiency in existing systems. The system includes logic interaction, interaction index, type parsing, fault parsing, and level analysis modules, and can also include virtual parsing and level correction modules. The logic interaction module handles command response and feedback reception; the interaction index module retrieves commands through a comprehensive index; the type parsing module identifies the driver control unit type; the fault parsing module diagnoses faults; and the level analysis module detects level deviations. The virtual parsing module simulates test scenarios, and the level correction module optimizes driver control unit damping. The system comprehensively covers key indicators such as contact resistance, logic, and level voltage, improving testing accuracy and efficiency to meet the testing needs of modern rail transit.

Description

Technical Field

[0001] This invention relates to a controller testing system, and more specifically, to a testing system for a rail transit train driver control unit. Background Technology

[0002] With the continuous improvement of the intelligence and automation level of rail transit trains, the performance of the driver control unit, as one of the core control devices of the train, directly affects the safety and reliability of train operation. However, the existing driver control unit testing systems still have shortcomings in terms of functional coverage, testing accuracy, and intelligence level, making it difficult to fully meet the testing needs of new driver control units, especially in the areas of pulse width modulation (PWM) testing and control power supply testing, which are basically non-existent.

[0003] Patent CN113232698B discloses a static testing method and train for trains. This patent, after receiving a wake-up command through an onboard controller, powers on the train and initiates static tests, including air compressor testing, braking and traction testing, and broadcasting tests. This achieves remote automatic static testing and inspection before the departure of an unmanned train, improving the train's intelligence level. However, this technical solution mainly focuses on the overall static testing process of the train and does not specifically test the specific functions of the driver control unit, especially lacking support for testing the pulse width and control power supply of new driver controllers. Furthermore, its contact resistance and logic tests are relatively independent, and the self-learning function is limited to the logic level, unable to adapt to more complex testing needs. Patent CN113147842B discloses a dynamic testing method and train for trains. This patent, through the vehicle and vehicle control management system combined with an onboard controller, initiates dynamic testing commands after successful static testing, including jump tests, thereby completing remote automatic dynamic testing and inspection before train departure. While this technical solution excels in train dynamic testing, its focus is on verifying overall vehicle performance, neglecting core parameters of the driver control unit such as pulse width and control power supply. Furthermore, using transmitters for voltage range adjustment incurs additional accuracy losses, and the analog signal acquisition method, with its severely limited sampling range, further restricts the flexibility and accuracy of the testing system.

[0004] The aforementioned problems indicate that existing train testing systems have significant shortcomings in specialized testing of driver control units, particularly in areas such as pulse width testing, control power supply testing, and related high-precision measurements, where no effective solutions exist. Therefore, this invention provides a testing system for rail transit train driver control units, aiming to comprehensively cover multiple key indicators such as contact resistance, contact logic, voltage level, pulse width, and control power supply, optimizing testing accuracy and efficiency to meet the demands of modern rail transit for efficient and intelligent testing systems. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a test system for a rail transit train driver control unit.

[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is: a test system for a rail transit train driver control unit, including a logic interaction module, an interaction index module, a type parsing module, a fault parsing module, and a level analysis module; The logic interaction module responds to logic interaction commands and outputs corresponding logic interaction information, while receiving test feedback information. The interactive index module is configured with an interactive information table, which stores several logical interactive instructions. Each logical interactive instruction is indexed by comprehensive index data. The interactive index module retrieves the corresponding logical interactive instruction based on the generated comprehensive index data and sends it to the logical interactive module. The type parsing module is configured with several driver controller types, each driver controller type is configured with corresponding identification conditions, each identification condition includes several condition sub-items, the type parsing module is configured with a type parsing strategy, the type parsing strategy is used to determine whether the condition sub-items are activated based on test feedback information, when the activated condition sub-items meet the trigger constraints of the corresponding identification conditions, the corresponding driver controller type is output. The fault analysis module is configured with fault identification events, and the fault analysis module matches the corresponding fault identification events according to the test feedback information to generate fault diagnosis results. The level analysis module includes a level analysis algorithm, which calculates the level deviation based on the level test data in the test feedback information. When the level deviation is greater than a preset value, level abnormality information is output.

[0007] Furthermore, the logic interaction module includes a contact learning unit. This unit detects the controller contacts and retrieves corresponding contact distribution information from a preset controller contact library based on their conduction status. It then generates a test truth table based on this information. This configuration allows for the direct determination of the controller's interface count based on the conduction status and minute current responses. The number of interfaces enables preliminary screening of the train's matching type, thus generating initial test commands. This significantly reduces computational load and avoids the need for extensive testing due to difficulties in determining the matching type between the controller type and the train's actual control circuit.

[0008] Furthermore: the logic interaction module includes an impedance testing unit and a logic testing unit, wherein the impedance testing unit controls the corresponding impedance testing relay to operate according to the test truth table to obtain the contact impedance; The logic test unit is used to adjust the working state of the controller to the working state pointed to by the logic interaction command, and generate a status response result; The action types of the logical interaction instructions include learning sub-items, impedance test sub-items, and logic test sub-items. The learning sub-items correspond to contact learning units, the impedance test sub-items correspond to impedance test units, and the logic test sub-items correspond to logic test units. The comprehensive index data includes contact distribution information, status response results, and contact impedance of the driver controller in a certain operating state. Impedance testing is used to further identify the matching type. This serves two purposes: firstly, it allows analysis of any anomalies; secondly, it enables the collection of further contact information based on actual impedance feedback. Once the driver controller type is determined, further operational logic testing can be performed, reducing the number of testing tasks and improving efficiency.

[0009] Furthermore, the system also includes a virtual parsing module. This module is configured with several simulation interaction models, each corresponding to the controller type setting. The virtual parsing module is also configured with an event test set, which stores several virtual events indexed by train operation information. The virtual parsing module retrieves virtual events based on the train operation information and inputs them into the corresponding simulation interaction model to output new logical interaction instructions to the logical interaction module. By collecting train operation information, corresponding event scenarios can be output based on the actual train operation. By simulating continuous operations of the controller to handle these events, extreme conditions and adaptability tests can be performed, improving the controller's testing effectiveness. Furthermore, by converting the corresponding virtual events into the required logical interaction instructions through the simulation interaction model, verification can be performed through continuous high-frequency operations.

[0010] Furthermore: the virtual parsing module is configured with a triggering strategy to select the virtual events to be executed; The triggering strategy includes: Step A1: The virtual event is configured with a corresponding baseline trigger weight; Step A2: Calculate the baseline trigger value for each virtual event using a preset trigger weighting algorithm; Step A3: Configure the corresponding trigger range based on the baseline trigger value; Step A4: Select the corresponding virtual event output based on the trigger range into which the generated random trigger value falls. The baseline trigger weight configured for each virtual event varies according to the runtime information. Furthermore, the impact value of each test feedback message on the virtual event is generated based on the actual runtime and test conditions. The corresponding baseline trigger value can then be calculated using a weighted average. A larger baseline trigger value indicates that the virtual event is more likely to be selected.

[0011] Furthermore, the fault analysis module also includes an event evaluation unit. This unit acquires test feedback information obtained during the execution of virtual events and inputs it into a preset multi-dimensional evaluation model to obtain an event evaluation vector for each virtual event. It then matches other virtual events based on the event evaluation vector and adjusts the corresponding baseline trigger weights. Through event evaluation, the fault analysis module can evaluate the results of virtual events using test feedback information as a factor, thereby obtaining corresponding evaluation vectors. This influences the selection of the next virtual event; for example, if the abnormal component is large in the test, the weight of similar virtual events being selected is increased.

[0012] Furthermore, the system also includes a level correction module connected to the damper of the driver controller. This module is configured with a level correction strategy, which generates a level damping correction table based on level anomaly information and configures it in the damper. The level damping correction table stores several level damping instructions, each indexed by a force response condition. When the level controller meets the corresponding force response condition, the corresponding level damping instruction is executed to control the damper's operation. By increasing damping through the damper, the system improves directivity and corrects mechanical errors. Simultaneously, by analyzing user force habits, the system corrects the operability, smoothness, and control accuracy when using the level controller, meeting the actual needs of driver and passenger control.

[0013] Furthermore: the level correction strategy includes: Step S1: Obtain the level-level exception information corresponding to each type of logical interaction instruction for level-level testing; Step S2: Classify the level anomaly information using a preset inertial classifier to obtain level anomaly information of three types: habitual, directional, and mechanical. Step S3: Process the level position anomaly information using the inertial analysis algorithm, the directional analysis algorithm, and the mechanical analysis algorithm respectively to obtain the corresponding inertial anomaly component, directional anomaly component, and mechanical anomaly component. Step S4: Generate full-condition term limits through preset control precision constraints, and input the inertial anomaly component, directional anomaly component and mechanical anomaly component into the preset level response model to obtain the damping optimization value of each node in the full-condition term limits. Step S5: Generate the corresponding level damping command based on the damping optimization value, and generate the force response condition corresponding to the level damping command based on the coordinates under the full condition limit. Analyze different situations through configuration strategies. The control accuracy constraint characterizes the accuracy requirement during level control, which is the number of nodes in the full condition limit. Based on the test results, the level anomaly vector (composed of three components) corresponding to each node can be obtained. By substituting the level anomaly vector into the level response model, we can determine how the control anomaly damper at this node should be set to achieve the optimal anomaly correction effect, ensuring that anomalies caused by directional control, usage habits, and mechanical control errors can be optimized and corrected as much as possible during use.

[0014] The main technical advantages of this invention are reflected in the following aspects: Enhanced comprehensive functionality: Existing train testing systems primarily target the static or dynamic performance of the entire vehicle, lacking specific testing for driver control units, especially key indicators such as pulse width and control power supply. This system integrates five core modules: logical interaction, interactive indexing, type parsing, fault analysis, and level / position analysis. It can simultaneously achieve logical instruction interaction, driver / controller type identification, fault diagnosis, and level / position deviation detection, covering the core requirements of driver / controller testing and filling the functional gaps in existing technologies for driver / controller-specific testing. Optimized test accuracy: Through the identification conditions and trigger constraints of the type parsing module, the system can accurately match the driver / controller type, avoiding test deviations caused by type misjudgment; the fault analysis module matches fault identification events based on test feedback, reducing missed and false faults; the level / position analysis module calculates level / position deviations through algorithms, quantifying level / position anomalies. Compared to the fuzzy test judgment methods in existing technologies, this significantly improves the accuracy of test results, providing reliable data support for driver / controller performance evaluation. Enhanced testing efficiency and adaptability: The interactive index module retrieves logical interactive instructions using comprehensive index data, eliminating the need to poll all instructions, reducing redundant operations, and improving testing efficiency; the type parsing module can adapt to various types of controllers, eliminating the need to build separate test systems for different controllers, enhancing the system's adaptability to different controller models, reducing testing costs, and meeting the diverse testing needs of controllers in the rail transit field. Attached Figure Description

[0015] Figure 1 : This invention's test system architecture diagram; Figure 2 This invention tests contact learning and impedance testing. Figure 3 : Interaction principle diagram of the logic test module of the test system of this invention; Figure 4 : Schematic diagram of the interactive principle of the test system level of this invention; Figure 5 : Flowchart of the level correction process of the test system of this invention. Detailed Implementation

[0016] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, so that the technical solution of the present invention can be more easily understood and mastered.

[0017] A test system for a rail transit train driver control unit includes a logic interaction module, an interaction index module, a type parsing module, a fault parsing module, and a level analysis module.

[0018] The logic interaction module responds to logic interaction commands and outputs corresponding logic interaction information, while receiving test feedback information. The logic interaction module includes a contact learning unit, which is used to detect the driver controller contacts and obtain the corresponding contact distribution information from the preset driver controller contact library according to the conduction state, and generate a test truth table based on the contact distribution information.

[0019] The logic interaction module includes an impedance testing unit and a logic testing unit. The impedance testing unit controls the corresponding impedance testing relay to work according to the test truth table to obtain the contact impedance. The logic test unit is used to adjust the working state of the controller to the working state pointed to by the logic interaction command, and generate a status response result; The action types of the logical interaction instructions include learning sub-items, impedance test sub-items, and logic test sub-items. The learning sub-items correspond to contact learning units, the impedance test sub-items correspond to impedance test units, and the logic test sub-items correspond to logic test units. The comprehensive index data includes contact distribution information, status response results, and contact impedance of the controller in a certain operating state.

[0020] The logic interaction module is the core execution layer of the rail transit train driver control unit testing system. It is responsible for receiving logic interaction instructions from modules such as the interaction index module and the virtual parsing module, executing specific test operations, and collecting test feedback information and transmitting it to the lower-level analysis modules, such as the type parsing module and the fault parsing module. Its core functions revolve around the entire process of contact identification, impedance testing, logic verification, and data feedback. Specifically, it can be broken down into three main functional units and overall interaction functions: Contact learning unit: Enables automatic adaptation and truth table of driver controller contacts. Functions include: solving the problem of large differences in the number and function of contacts among different driver controller models, which requires manual configuration of test parameters; and achieving automatic identification of contact characteristics through micro-current detection and contact library matching.

[0021] Step 1: Contact Continuity Detection. A small current within a safe range is output to all contacts of the controller to detect the on / off state of each contact, eliminating physically damaged contacts. Step 2: Contact Distribution Matching. The detected continuity states are compared with a preset controller contact library to determine the functional associations of the controller's contacts. Step 3: Test Truth Table Generation. A test truth table containing contact types and on / off rules for different states is generated based on logical reasoning calculations, providing guidance for subsequent testing. Example: When testing a light rail controller, the contact learning unit detected 5 out of 8 contacts as on. After matching with the contact library, it was found that contacts 6-8 of this controller model are braking level contacts. Therefore, a test truth table containing the on / off rules of contacts 6-8 under braking levels 1-3 is generated, eliminating the need for manual labeling of contact functions.

[0022] Impedance Testing Unit: Enables accurate testing and redundancy elimination of contact impedance. Guided by the test truth table, it precisely tests the impedance of logically correct contacts, avoiding the inefficiency caused by polling all contacts. It also employs the Kelvin bridge method to ensure testing accuracy and solves the problem of interference from wire resistance in traditional impedance testing. Step 1: Relay Control. Based on logically correct contacts in the test truth table, the corresponding impedance test relay is closed, connecting the test circuit for that contact. Step 2: High-Precision Impedance Acquisition. Contact impedance is acquired using the Kelvin bridge method, and the data is recorded. Step 3: Test Result Feedback. The acquired contact impedance is used as part of the test feedback information and transmitted to the interactive index module and fault analysis module. Example: The test truth table shows that contacts 2, 5, and 7 are logically correct in the reverse-brake level 1 state. The impedance testing unit controls the corresponding relay to close. The Kelvin bridge measures the impedance of contact 2 as 22mΩ, contact 5 as 19mΩ, and contact 7 as 65mΩ. Immediately, the impedance of contact 7 is found to be abnormal, and the fault analysis module is notified.

[0023] Logic Test Unit: It realizes the adjustment and logic verification of the working state of the controller. The logic test sub-item that receives the logic interaction instruction actively adjusts the working state of the controller, verifies whether the contact logic in this state conforms to the test truth table, and generates a state response result. It is the core unit for judging whether the logic function of the controller is normal. The first step: State adjustment. According to the instruction of the logic test sub-item, the direction handle and gear position handle of the controller are controlled through electrical signals to simulate actual operations and switch to the target working state. The second step: Logic verification. Detect the on-off states of all contacts in the target state and compare them with the preset on-off rules of this state in the test truth table. The third step: Response result generation. Output the state response result of normal logic or abnormal logic and transmit it as test feedback information to the interaction index module and type analysis module. Example: When the instruction of the logic test sub-item is to adjust to the reverse-idle state, after the logic test unit controls the controller to switch, it is detected that contact 2 for reverse is closed and contacts 3-8 are all open, which is consistent with the test truth table, and a state response result of normal logic is generated; if it is detected that contact 4 is closed, a result of abnormal logic for contact 4 is generated. Overall interaction function of the module: Connect the upper and lower layer modules to achieve a closed-loop test process. The logic interaction module does not work independently, but as an instruction executor and data collector, it connects the entire test system process: Receive instructions: Receive the logic interaction instruction retrieved based on the comprehensive index data from the interaction index module and the new logic interaction instruction generated based on the virtual event from the virtual analysis module; Execute operations: Coordinate the three major units to execute the coherent operations of contact learning-impedance test-logic verification, such as first executing the learning sub-item to generate the truth table, then executing the impedance test sub-item to collect the impedance, and finally executing the logic test sub-item to verify the state; Feedback data: Synchronously transmit the test feedback information composed of contact distribution information, contact impedance, and state response result to the type analysis module, fault analysis module, and gear position analysis module to provide raw data for subsequent analysis; Process optimization: The mode of guiding the test through the test truth table reduces the number of operations of the controller, reduces the operation error rate, and at the same time adapts to various types of controllers, eliminating the need to build a separate test circuit for different models, improving the test efficiency and system adaptability.

[0024] The contact logic self-learning function is currently mainly set for quickly adapting to new types of controllers when testing different types of controllers on the test bench. Its quick adaptation is reflected in being able to confirm the action logic of this type of controller by detecting the logic of the controller that has been confirmed as a qualified product. This solution basically does not consider the time consumption of contact resistance testing during the entire test process, delaying the overall test progress, increasing the operation process during the entire test, and being not very user-friendly to the test personnel.

[0025] In order to organically combine the contact logic test and the contact resistance test and improve the overall test efficiency, the following adjustments are made to the current solution: First, self-learning of the contact logic is performed to ensure that the logic state of each test location is collected.

[0026] Then, a truth table is generated using software for the logic state at different test locations, and the truth table is used to guide the contact resistance test.

[0027] In the actual testing process, logic testing is performed first. The testing software guides the tester to operate the controller and enter different test positions. At each test position, the action logic, including open and closed points, is tested. When the logic at a certain position is correct, the truth table guides different impedance test relays to work. The Kelvin bridge method is used to perform impedance testing at the corresponding point, avoiding polling tests at all points and greatly saving testing time.

[0028] After the logic and impedance tests at this location are completed, switch to logic test mode. The test software guides the tester to operate the controller and enter the next test location for testing. Repeat the above process until all locations are tested. At the same time, obtain the contact logic test results and contact resistance test results.

[0029] This testing method can reduce the number of controller operations by at least half. Reducing the number of operations can reduce the possibility of operational errors and reduce the workload of operators, thus having a positive effect on error prevention and mitigation.

[0030] The interactive index module is configured with an interactive information table, which stores several logical interactive instructions. Each logical interactive instruction is indexed by comprehensive index data. The interactive index module retrieves the corresponding logical interactive instruction based on the generated comprehensive index data and sends it to the logical interactive module. All logical interactive instructions that may be used during the test are classified and associated according to the current test status of the driver controller using comprehensive index data, forming a one-to-one or many-to-one correspondence between status and instruction. This relationship needs to be filtered using auxiliary fields. The data structure contains at least three core fields: ① Index key: Standardized format of comprehensive index data, such as contact distribution information + status response result + contact impedance range; ② Instruction value: Logical interactive instruction containing action sub-item combination, such as impedance test sub-item + level data acquisition sub-item; ③ Auxiliary filtering field: Applicable driver controller type, such as metro type A car driver controller, light rail type B car driver controller, instruction priority, such as fault retest instruction priority > regular test instruction. This avoids the redundant operation of traversing all instructions to find the matching item in traditional test systems. Instructions are directly located through the index key, improving retrieval efficiency. The comprehensive index data is generated by the interactive index module receiving the raw test feedback information output by the logic interaction module and standardizing it according to preset rules: ① Contact distribution information: The contact ID + on / off state is converted into abbreviated codes, such as 1 closed - 2 forward closed - 3 pulled closed, representing contact 1 closed, directional contact 2 forward closed, and stage contact 3 pulled closed; ② Status response results: Only two types of results are retained: logic normal / logic abnormal (including abnormal contact ID), to avoid ambiguous descriptions; ③ Contact impedance: Continuous impedance values ​​are converted into range values, such as 19.2mΩ converted into 18-22mΩ, to accommodate minor fluctuations in test data; Matching logic: Only when the standardized comprehensive index data is completely consistent with the index key in the interactive information table or the impedance range and contact distribution abbreviated codes match, and the applicable driver controller type is consistent, can the corresponding logic interaction command be retrieved to ensure that the command is completely adapted to the current state of the driver controller. For ease of understanding, the interactive index module example is as follows: Step 1: Receive raw test feedback information: After the logic interaction module completes the initial test of reversing-braking level 1, it sends raw test feedback information to the interactive index module: contact 1 is activated and closed, contact 2 is closed in the direction of reversing, contact 6 is closed in the braking position, and the remaining contacts are open; after the logic test sub-item is executed, the contact continuity conforms to the test truth table, and the output logic is normal; the contact impedance is contact 1 (21.5mΩ), contact 2 (22.3mΩ), and contact 6 (20.8mΩ); the associated information is that the type parsing module synchronously outputs that the current driver controller type is light rail type B vehicle driver controller. Step 2: Generate standardized comprehensive index data. The interactive index module standardizes the original feedback information: the contact distribution abbreviation is 1 closed - 2 closed after closing - 6 closed; the status response result is: logic normal; the contact impedance range is 20-25mΩ; the driver controller type is: light rail B type car; the final comprehensive index data is: [1 closed - 2 closed after closing - 6 closed, logic normal, 20-25mΩ, light rail B type car].Step 3: Match instructions in the interaction information table. The interaction index module uses the generated comprehensive index data as a basis to perform bidirectional matching in the interaction information table: first, match the applicable driver controller type field to filter out all instruction records corresponding to the driver controllers of light rail type B vehicles; then match the comprehensive index data (index key) to find the index key that is completely consistent with 1 closed-2 closed-6 braking, logic normal, 20-25mΩ; confirm that the instruction corresponding to this index key has a high priority, and finally lock the instruction: execute the reverse-braking level 1 fault simulation including logic test sub-items + contact instantaneous power-off test sub-item, power-off duration 50ms. Step 4: Send the logic interaction instruction to the execution module: the interaction index module encapsulates the locked logic interaction instruction into a standardized signal, such as a CAN bus signal, and sends it to the logic interaction module; after receiving it, the logic interaction module executes the action sub-items in the order of the instruction: first trigger the logic test sub-item to confirm that the current state is stable, and then trigger the contact instantaneous power-off test sub-item to complete the fault simulation test.

[0031] The type parsing module is configured with several driver controller types, each with corresponding identification conditions. Each identification condition includes several sub-conditions. The type parsing module is configured with a type parsing strategy, which is used to determine whether the sub-conditions are activated based on test feedback information. When an activated sub-condition satisfies the triggering constraint of the corresponding identification condition, the corresponding driver controller type is output. The identification conditions are a set of feature judgment criteria specifically configured for each preset driver controller type. The core is to transform the key physical / logical characteristics of a driver controller type, such as the number of contacts, activation logic, and level association rules, into quantifiable and verifiable judgment criteria. Each driver controller type uniquely corresponds to a set of identification conditions. The principle is based on extracting the core features that distinguish this type from other types based on the design differences of different driver controllers, and decomposing them into a combination of several sub-conditions. Example: The identification conditions for the metro Type A car driver's controller include a total number of contacts ≥ 12, dual activation requiring both key insertion and alert button press, traction level ≥ 8 and braking level ≥ 5, and spare contacts ≥ 3. The identification conditions for the light rail Type B car driver's controller include a total number of contacts = 8-10, activation requiring only a single key insertion, traction level ≤ 5 and braking level ≤ 3, and spare contacts = 1-2. Each condition sub-item is the smallest indivisible judgment unit of the identification condition, corresponding to a specific feature that can be verified through test feedback information. The principle is that each sub-item must be measurable and verifiable. Physical attribute sub-items are numerical ranges / fixed values, while logical attribute sub-items are logical judgment rules. If the test feedback information matches the sub-item's judgment standard, it is activated; otherwise, it is not activated. Example: In the identification conditions of the subway Type A car driver controller, the criterion for the number of contact points is a total number of contact points ≥ 12. If the test feedback shows that the total number of contact points = 12, then this sub-item is activated. The criterion for the activation logic sub-item is that it requires dual key insertion + alert button pressing for dual activation. If the test feedback status response result meets the requirements, then this sub-item is activated. Trigger constraints are the final rule thresholds for determining whether a certain driver controller type is valid. They specify the number / type combination of conditional sub-items that must be activated to avoid misclassification due to the activation of a single sub-item. The principle is to set key sub-items that directly determine the core characteristics of the type based on the importance of the sub-items, such as activation logic sub-items and secondary characteristics of auxiliary sub-items, such as spare contact point sub-items. A rule is set that key sub-items must be fully activated + auxiliary sub-items must meet the quantity requirements. Example: The triggering constraints for the subway Type A car controller have three key sub-items: the number of contacts, activation logic, and hierarchical association must all be activated; for auxiliary sub-items, at least one spare contact must be activated. The triggering constraints for the light rail Type B car controller have two key sub-items: the number of contacts and activation logic must both be activated; for auxiliary sub-items, hierarchical association and at least one spare contact must be activated. The type resolution strategy is a standardized process and algorithm set for executing controller type identification. Its core is to receive test feedback information → determine whether each conditional sub-item is activated → verify whether the corresponding type's triggering constraints are met → output closed-loop logic with a unique matching type.The principle involves three steps: First, receiving test feedback information from the logic interaction module, including contact distribution information, status response results, and level test data; second, comparing the test feedback information with the conditional sub-items of each preset driver controller type, marking them as activated / inactive; third, checking whether the activated sub-items of each preset type meet the trigger constraints. If only one type meets the constraints, the output is provided; if multiple types meet the constraints, priority is given to the key sub-items with the higher number of activated sub-items; if none meet the constraints, the unidentified type is output. Example: Testing an unknown driver controller, the feedback information is: total number of contacts = 12, spare contacts = 4, requires double key insertion + alert button press for activation, traction level = 10 and braking level = 6. After comparison, the key sub-items of the Metro Type A car driver controller are all activated, and the auxiliary sub-items are activated, meeting the trigger constraints. The key sub-items of the Light Rail Type B car driver controller are not activated, and the final output is Metro Type A car driver controller.

[0032] Truth tables are key parameters for improving equipment efficiency. Their generation follows a specific algorithm, ensuring that all paths are reliably connected while corresponding open circuits are reliably disconnected, preventing logical inconsistencies caused by unresolved open circuits. Therefore, logical rationality calculations must be performed during truth table generation. The logical rationality calculation method is as follows: First, perform a logic check on the key activation contact and the alert button contact. Before activation, operate both handles to confirm that they are physically locked and cannot be operated. Then, using the logic in the default state as the benchmark, i.e., the logic in the directionless, coasting state, the logic is further processed separately based on the differences in the handles. That is, the logic of the direction of travel does not interfere with the traction and braking logic.

[0033] Under the aforementioned conditions, after the controller is installed and before the equipment performs self-learning, the locking function is confirmed. After confirmation, the activation, deactivation, and reactivation are performed sequentially to identify the activation logic contacts. Then, the alert button is pressed, released, and pressed again to identify the alert button. These two operations are necessary pre-operations to prevent logic recognition errors caused by subsequent changes in the alert button's logic. Simultaneously, all changed contacts are marked as 1 in the truth table type column. The truth table type column is encoded in 8421 BCD. All subsequent operations are performed under the activation condition.

[0034] After completing the aforementioned operations, perform directional handle operation. Mark all logic points that have switched states as directional contact points and mark them as 2 in the truth table type column. Since the direction includes three logical positions, namely forward, backward, middle value default value, and no operation position, its logical combination can be represented by three binary numbers, namely: forward closed / middle value closed / backward closed.

[0035] A value of 1 indicates that the contact is closed at that position, and a value of 0 indicates that the contact is open at that position. All contact values ​​that change during directional handle operation should be controlled by the directional handle. Marking the three position states effectively determines the contact status of the handle in different positions. After each position switch, pressing the alert button serves as an end-of-operation indicator, allowing the system to automatically proceed to the next action.

[0036] After completing the direction handle operation, proceed with the level handle operation. The level handle logic is more complex and has more marker bits, so its logic combination is represented by a six-bit binary number, namely: full traction closure / traction closure / intermediate value closure / braking closure / common full braking closure / rapid braking closure.

[0037] Similar to the directional handle, a 1 indicates that the contact is closed and a 0 indicates that the contact is open. Likewise, the contacts that change during the operation of the directional handle are marked as 4 in the truth table type flag, and the six-bit binary number of each position state is recorded.

[0038] The remaining contacts are all used as spare contacts, and the contact type flag is set to 0.

[0039] After counting all contacts, perform a logical XOR operation on the contact types and then perform a AND operation on the result. When the final logical result is 1, it indicates that the contact types in the truth table generated by the controller are valid and usable.

[0040] After determining the contact type, the contact position is determined. Since all contacts have a specific action after operation, the median value of both handles should be 0. First, perform a bitwise AND operation on all contacts with 2, listing the position states of all rows with a result of 1. Then, perform a bitwise OR operation on 5, and perform a bitwise AND operation on the result. When the final logical result is 0, it indicates that the median logical value of all contacts of type 2 on the controller is correct. Next, perform a bitwise AND operation on all contacts with 4, listing the position states of all rows with a result of 1. Then, perform a bitwise OR operation on 5, and perform a bitwise AND operation on the result. When the final logical result is 0, it indicates that the median logical value of all contacts of type 4 on the controller is correct.

[0041] The fault analysis module is configured with fault identification events. Based on test feedback information, the module matches corresponding fault identification events to generate fault diagnosis results. This refers to a preset set of fault characteristics and fault types, which transforms common controller faults, such as abnormal contact impedance and excessive level deviation, into matchable event rules. The principle is to extract fault characteristics from historical fault data and associate them with corresponding fault types. Example: A preset contact impedance > 50mΩ is a fault identification event. If the test feedback shows contact 1 impedance is 62mΩ, matching this event generates a diagnosis of poor contact for contact 1.

[0042] The fault analysis module also includes an event evaluation unit. This unit acquires test feedback information obtained during the execution of virtual events and inputs it into a preset multi-dimensional evaluation model to obtain an event evaluation vector for each virtual event. It then matches other virtual events based on the event evaluation vector and corrects the corresponding baseline trigger weights. This is a functional unit used for multi-dimensional evaluation of test feedback information during the execution of virtual events. The principle is to input the feedback information into a multi-dimensional evaluation model, including dimensions such as logical correctness and impedance stability, to generate an event evaluation vector and correct the baseline trigger weights of the virtual events. Example: After a virtual event is executed, if the feedback level deviation is 12%, the evaluation unit generates a vector indicating poor level stability, increases the baseline trigger weights of similar virtual events, and increases the frequency of retesting.

[0043] The level analysis module includes a level analysis algorithm, which calculates the level deviation based on the level test data in the test feedback information. When the level deviation is greater than a preset value, level abnormality information is output.

[0044] Improvements have also been made to the level voltage test. The output range of level voltage varies under different conditions and power supplies. To avoid exceeding the normal analog voltage range of 0-10V or ±10V, a voltage transmitter may be selected to adjust the voltage range. However, when using a transmitter, due to the characteristics of the transmitter itself, some accuracy of the voltage test will inevitably be lost. Direct connection to the analog quantity may exceed the analog quantity acquisition range. At the same time, the method of sampling the analog quantity by PLC is not convenient for metrological verification.

[0045] The power supply detection function is only required for testing a small number of driver controllers with PWM pulse width output. Since the driver controller needs a power supply to drive the internal circuitry to achieve pulse width modulation when outputting pulse width, its power supply status should also be detected when testing such driver controllers. The power supply status of the driver controller is indicated by a 110VDC signal output by its internal relay. After the voltage is transformed on the test equipment, the signal is converted into a readable logic signal and then acquired by the test equipment to determine whether the driver controller's power supply status output signal is normal.

[0046] The level analysis algorithm is designed as follows: Levels include traction level and braking level. The level values ​​of the controller should be continuous and linear to ensure stable hand feel, appropriate traction and braking force when the train driver controls the driver's handle, avoid vehicle jerking, and provide passengers with a more comfortable riding experience. Therefore, the designed function algorithm for level values ​​adds a linearity verification algorithm while normally detecting voltage and PWM pulse width. Linearity is based on the derivative theory. Through discrete analysis, the derivative function value at each position is obtained, and convergence and threshold ranges are set to determine whether the level output of the controller is correct and accurate. The specific algorithm is as follows: The device uses an encoder to obtain the angle. It uses AB phase pulses to sample the current angle. The software samples the output voltage or PWM pulse width at the current angle every 10 pulses, records the result value in array Y, and records the angle value in array X.

[0047] in Angle value corresponding The voltage or PWM pulse width, correspond ...until correspond .

[0048] In practical applications, the central difference method is used for calculation.

[0049] ; Using the above formula, discard... , , , These four values, and all other values, can be used for differentiation calculations. The range of values ​​for i is: ; Substituting into the above formula, we calculate and obtain the following sets: ; The mean of the derivative is obtained by performing the following calculation on the result of the above formula: ; Then, use the following two formulas to calculate the positive and negative deviations respectively: ; ; And calculate the deviation rate. and Applying the above formula, the complete formula is as follows: ; .

[0050] Based on experience, a threshold range is set. The two results above are compared with the threshold. Products within the threshold range are considered qualified. Assuming the threshold is 5%, the following formula is calculated, and its validity is determined: ; .

[0051] Substituting into the complete formula, we get: ; ; When both results of the above two formulas are true, then perform the difference optimization calculation: ; when When: If so, the level function of the subject's controller is relatively good.

[0052] The virtual parsing module is configured with several simulation interaction models, each corresponding to the driver controller type. The module also includes an event test set storing virtual events indexed by train operation information. The virtual parsing module retrieves these virtual events based on the train operation information and inputs them into the corresponding simulation interaction model to output new logical interaction commands to the logical interaction module. The simulation interaction model operates as follows: based on the driver controller type (e.g., a metro type A car driver controller)'s traction / braking characteristics and level response curves, combined with train load, track gradient, and other operating parameters, a model is constructed that simulates the linkage between driver controller operation and train operation status. Example: For the simulation interaction model of a metro type A car driver controller, a preset operating scenario parameter of full load (1800 people) + 3° uphill slope is used. When a traction level 5 command is input, the model can output standard data such as voltage and impedance that the driver controller should feedback under this scenario, for comparison with actual test feedback. The principle of the event test set is as follows: Based on historical rail transit operation data, typical operating conditions such as temporary braking before entering the station and encountering a 2° uphill slope upon exiting the station are extracted and transformed into virtual events containing triggering conditions such as a speed of 60 km / h and test targets such as level response delay. These are then stored according to train operation information, such as speed and gradient. Example: The virtual event of exiting the station and going uphill in the event test set has the index information of speed 0-30 km / h and gradient 2°, including the triggering condition of the driver switching from coasting to traction level 3 and the test target of whether the level voltage rise is stable. The triggering strategy includes: Step A1: The virtual event is configured with a corresponding baseline trigger weight; Step A2: Calculate the baseline trigger value for each virtual event using a preset trigger weighting algorithm; Step A3: Configure the corresponding trigger range based on the baseline trigger value; Step A4: Select the corresponding virtual event output based on the trigger range that the generated random trigger value falls into. The triggering strategy works as follows: First, a baseline trigger weight is configured for each virtual event (e.g., high-risk events have higher weights). Then, the weights are adjusted using a trigger weighting algorithm combined with historical test feedback to generate a baseline trigger value and divide the trigger range. Finally, a random trigger value is generated; if it falls into a certain range, the corresponding event is selected. For example, the baseline trigger weight for the emergency braking virtual event is 0.8. Due to the high anomaly rate of this event in historical tests, the weight is increased by 0.1, resulting in a baseline trigger value of 0.9, with a trigger range of 0.8-1.0. If a random trigger value of 0.85 is generated, falling into this range, the event is selected for testing.

[0053] A level correction module is connected to the damper of the driver controller. This module is configured with a level correction strategy, which generates a level damping correction table based on level anomaly information and configures it on the damper. The level damping correction table stores several level damping commands, each indexed by a force response condition. When the level controller meets the corresponding force response condition, the corresponding level damping command is executed to control the damper's operation. The level damping correction table generates corresponding damping commands based on optimized damping values, such as increasing traction damping by 0.2N at level 3. It also combines this with the driver controller's force data at different levels, such as handle operating force and displacement, to determine the force response conditions triggering the command, such as an operating force ≥ 5N and a displacement reaching 30mm, forming a structured table.

[0054] The level correction strategy includes: Step S1: Obtain the level-level exception information corresponding to each type of logical interaction instruction for level-level testing; Step S2: Classify the level anomaly information using a preset inertial classifier to obtain level anomaly information of three types: habitual, directional, and mechanical. The inertial classifier has a preset feature library for the three types of anomalies. For example, habitual anomalies often change with the frequency of operation, and mechanical anomalies worsen with the duration of use. The level anomaly information is compared with the feature library, and the one with the highest matching degree is the corresponding category.

[0055] Step S3: Process the level anomaly information using inertial analysis algorithm, directional analysis algorithm, and mechanical analysis algorithm respectively to obtain the corresponding inertial anomaly component, directional anomaly component, and mechanical anomaly component; Inertial analysis algorithm:

[0056] in, The inertial anomaly component refers to the torque deviation caused by operational habits, such as operating speed being too fast / too slow, resulting in deviations in level control. The actual operating force comes from the actual measured force when the controller handle is operated, as indicated by the level position anomaly information, and is collected by the logic interaction module through the force sensor; The effective length of the handle is the handle lever arm length of the corresponding model of the driver controller from the driver controller type standard parameter library, which is retrieved by the type parsing module after matching the driver controller type. The actual operating angular velocity is derived from the rate of change of the actual level angle in the level anomaly information, and is determined by the actual level angle. With operation time The calculation yields the following formula: ; The standard operating angular velocity is derived from the standard operating angular velocity of the corresponding level in the standard parameter library for the driver controller type.

[0057] Pointerability resolution algorithm: ; The abnormal directional component refers to the torque deviation caused by the deviation in the pointing accuracy of the handle, such as the deviation from the standard angle during operation, which leads to the deviation in the level control. The actual operating force is consistent with the definition in the inertial analysis algorithm and comes from the actual measured force of the handle in the level position anomaly information; The effective length of the handle is consistent with the definition in the inertial analysis algorithm and comes from the driver type standard parameter library; The level angle deviation is the difference between the actual level angle and the standard level angle from the level anomaly information. Compared with standard level angle The calculation yields the following formula: ,in From the driver controller type standard parameter library.

[0058] Mechanical analytical algorithm: ; in, The mechanical abnormal component refers to the torque deviation caused by mechanical structural errors, such as handle wear or damper clearance, resulting in stage control deviation. The mechanical stiffness coefficient is derived from the mechanical stiffness of the corresponding model of the controller handle in the standard parameter library for controller types: for example, the stiffness of a metal handle k=5000N / m; The effective length of the handle is consistent with the definition in the first two algorithms, and comes from the standard parameter library for driver controller types, with the dimension in meters; The handle displacement deviation is the difference between the actual handle displacement and the standard handle displacement from the level position anomaly information, derived from the actual displacement. Compared with standard displacement The calculation yields the following formula: ,in and All data are from displacement sensor test data in the logic interaction module.

[0059] Step S4: Generate full-condition limit by setting the control accuracy constraints, and input the inertial anomaly component, directional anomaly component and mechanical anomaly component into the preset level response model to obtain the damping optimization value of each node in the full-condition limit; according to the control accuracy requirements, the full-condition limit decomposes the operation process of the driver from the lowest level to the highest level into several continuous nodes, each node containing state parameters such as angle, force, voltage, etc., to form the full-condition limit.

[0060] Step S5: Generate the corresponding level damping command based on the damping optimization value, and generate the force response condition corresponding to the level damping command based on the coordinates under all condition limits.

[0061] Of course, the above are just typical examples of the present invention. In addition, the present invention may have many other specific embodiments. All technical solutions formed by equivalent substitution or equivalent transformation fall within the scope of protection claimed by the present invention.

Claims

1. A rail transit train driver control unit test system, characterized in that: It includes a logical interaction module, an interaction index module, a type parsing module, a fault parsing module, and a level analysis module; The logic interaction module responds to logic interaction commands and outputs corresponding logic interaction information, while receiving test feedback information. The interactive index module is configured with an interactive information table, which stores several logical interactive instructions. Each logical interactive instruction is indexed by comprehensive index data. The interactive index module retrieves the corresponding logical interactive instruction based on the generated comprehensive index data and sends it to the logical interactive module. The type parsing module is configured with several driver controller types, each driver controller type is configured with corresponding identification conditions, each identification condition includes several condition sub-items, the type parsing module is configured with a type parsing strategy, the type parsing strategy is used to determine whether the condition sub-items are activated based on test feedback information, when the activated condition sub-items meet the trigger constraints of the corresponding identification conditions, the corresponding driver controller type is output. The fault analysis module is configured with fault identification events, and the fault analysis module matches the corresponding fault identification events according to the test feedback information to generate fault diagnosis results. The level analysis module includes a level analysis algorithm, which calculates the level deviation based on the level test data in the test feedback information. When the level deviation is greater than a preset value, level abnormality information is output. The logic interaction module includes a contact learning unit, which is used to detect the driver controller contacts and obtain the corresponding contact distribution information from the preset driver controller contact library according to the conduction state, and generate a test truth table according to the contact distribution information. The logic interaction module includes an impedance testing unit and a logic testing unit. The impedance testing unit controls the corresponding impedance testing relay to work according to the test truth table to obtain the contact impedance. The logic test unit is used to adjust the working state of the controller to the working state pointed to by the logic interaction command, and generate a status response result; The action types of the logic interaction instructions include learning sub-items, impedance test sub-items, and logic test sub-items. The learning sub-items correspond to the contact learning unit, the impedance test sub-items correspond to the impedance test unit, and the logic test sub-items correspond to the logic test unit. The comprehensive index data includes contact distribution information, status response results, and contact impedance of the controller in a certain operating state.

2. The rail transit train driver control unit test system according to claim 1, wherein: It also includes a virtual parsing module, which is configured with several simulation interaction models. The simulation interaction models correspond to the driver controller type settings. The virtual parsing module is configured with an event test set, which stores several virtual events. The virtual events are indexed by train operation information. The virtual parsing module retrieves the virtual events according to the train operation information and brings the virtual events into the corresponding simulation interaction model to output new logical interaction instructions to the logical interaction module.

3. The rail transit train driver control unit testing system as described in claim 2, characterized in that: The virtual parsing module is configured with a triggering strategy to select the virtual events to be executed; The triggering strategy includes: Step A1: The virtual event is configured with a corresponding baseline trigger weight; Step A2: Calculate the baseline trigger value for each virtual event using a preset trigger weighting algorithm; Step A3: Configure the corresponding trigger range based on the baseline trigger value; Step A4: Select the corresponding virtual event output based on the trigger range into which the generated random trigger value falls.

4. The rail transit train driver control unit testing system as described in claim 3, characterized in that: The fault analysis module also includes an event evaluation unit. The event evaluation unit obtains test feedback information during the execution of virtual events, and inputs the test feedback information into a preset multi-dimensional evaluation model to obtain an event evaluation vector for each virtual event. It then matches other virtual events based on the event evaluation vector and corrects the corresponding baseline trigger weights.

5. The rail transit train driver control unit testing system as described in claim 1, characterized in that: It also includes a level correction module, which is connected to the damper of the controller. The level correction module is configured with a level correction strategy, which is used to generate a level damping correction table based on level anomaly information and configure it in the damper. The level damping correction table stores several level damping instructions, each level damping instruction being indexed by a force response condition. When the level sensor meets the corresponding force response condition, the corresponding level damping instruction is executed to control the operation of the damper.

6. The rail transit train driver control unit testing system as described in claim 5, characterized in that: The level correction strategy includes: Step S1: Obtain the level-level exception information corresponding to each type of logical interaction instruction for level-level testing; Step S2: Classify the level anomaly information using a preset inertial classifier to obtain level anomaly information of three types: habitual, directional, and mechanical. Step S3: Process the level position anomaly information using the inertial analysis algorithm, the directional analysis algorithm, and the mechanical analysis algorithm respectively to obtain the corresponding inertial anomaly component, directional anomaly component, and mechanical anomaly component. Step S4: Generate full-condition term limits through preset control precision constraints, and input the inertial anomaly component, directional anomaly component and mechanical anomaly component into the preset level response model to obtain the damping optimization value of each node in the full-condition term limits. Step S5: Generate the corresponding level damping command based on the damping optimization value, and generate the force response condition corresponding to the level damping command based on the coordinates under all condition limits.

Images