A semi-physical simulation multi-core task balancing method

Abstract

The present application relates to the technical field of semi-physical simulation and real-time simulation task scheduling, and particularly relates to a semi-physical simulation multi-core task balancing method, which establishes multi-core tasks, output fields and release dependency in semi-physical simulation, periodically collects multi-domain states and generates candidate storage tokens, combines closed-loop timestamp counterfactual residual error to evaluate and correct old state silence risk value, checks tokens to execute release restriction or multi-core task rebalancing, and ensures that the external release state is consistent with the same version. By establishing a release associated task set, a strongly coupled output field set and a release task dependency graph, combining candidate state storage tokens, closed-loop timestamp counterfactual residual error and correction of old state silence risk value to control release and scheduling, identifying old state silence risk and ensuring consistent state release.

Description

Technical Field

[0001] This invention relates to the field of hardware-in-the-loop (HIL) simulation and real-time simulation task scheduling technology, and more specifically, to a method for balancing multi-core tasks in hardware-in-the-loop simulation. Background Technology

[0002] Hardware-in-the-loop (HIL) simulation is widely used in motor control, power electronics, vehicle dynamics, aerospace control, and industrial process control. Its basic process involves running a simulation model of the controlled object in a real-time computing environment and interacting with the real controller through input / output interfaces in a closed loop. As the level of detail in the simulation model of the controlled object continues to increase, a single processing core often struggles to complete all state calculations within a fixed simulation cycle. Multi-core parallel computing has gradually become an important way to improve real-time simulation capabilities. In this type of computing, the simulation model of the controlled object is typically divided into multiple multi-core model calculation tasks. Different processing cores calculate output fields such as current, voltage, speed, temperature, protection status, and mechanical load, and these are aggregated near the boundary of the simulation cycle to form an input / output data packet.

[0003] Existing hardware-in-the-loop (HIL) simulation methods typically focus on whether the simulation cycle times out, whether the computation task is completed, whether the input / output link is transmitting normally, and whether the load on each processing core is roughly balanced. This approach can meet the operational requirements of general real-time simulations. However, when multi-core model computation tasks and input / output publishing processes are highly intertwined, relying solely on task completion markers or average load status to determine publishing conditions can easily overlook the consistency of publishing versions between different output fields. For example, the stator current field may have been updated to the version corresponding to the current simulation cycle by the electromagnetic calculation task, while the rotational speed field may remain in the previous simulation cycle version due to a later submission of the mechanical rotation calculation task, and the bus voltage field may have already completed direct storage access and transmission. In this situation, the input / output publishing data packet may superficially possess complete fields, but it internally contains the controlled object states generated by different simulation cycles. Upon receiving this data, the real controller will generate control commands based on the cross-version states, affecting the reliability of the closed-loop simulation.

[0004] Furthermore, state inconsistencies in multi-core parallel computing do not necessarily manifest as obvious computational failures or communication interruptions. In some scenarios, older version output fields may be silently mixed into the data packets to be released, while the input / output transmission links remain normal, and the simulation cycle may not show significant timeouts. Only slight drifts occur in the actual controller response time, response order, or return interval. Without a joint assessment of the multi-domain operating state, the target release version sequence value, the release buffer archiving state, and the closed-loop response timing, relying solely on fixed scheduling strategies or pre-release integrity checks makes it difficult to promptly identify the aforementioned risk of silent mixing of older states.

[0005] Furthermore, existing multi-core task balancing methods typically focus on computational load distribution, such as adjusting task positions based on task duration, processing core utilization, or cycle execution time. However, in a semi-physical simulation closed-loop deployment scenario, task balancing involves not only processing core load but also is closely related to whether strongly coupled output fields are deployed in the same version, whether deployment-related tasks arrive synchronously, and whether input and output deployment data packets have consistent sealing conditions. If only tasks with longer computational times are migrated to idle processing cores without considering the deployment dependencies between the task's output fields and other strongly coupled output fields, it may still result in some fields being deployed ahead of schedule, critical fields being deployed behind schedule, or misalignment of deployment buffer sealing references.

[0006] Therefore, this application proposes a hardware-in-the-loop simulation method for balancing multi-core tasks. Summary of the Invention

[0007] To address the shortcomings of existing technologies, the present invention aims to provide a hardware-in-the-loop simulation method for balancing multi-core tasks.

[0008] To achieve the above objectives, the present invention provides the following technical solution: A hardware-in-the-loop simulation method for balancing multi-core tasks includes: Step 1: In the hardware-in-the-loop simulation system, based on the multi-core partitioning results of the simulation model of the controlled object, determine the set of deployment related tasks consisting of multi-core model computation tasks, the set of strongly coupled output fields consisting of output fields, and the deployment task dependency graph. Step 2: Collect multi-domain running status in each simulation cycle, determine the target release version sequence value corresponding to the current simulation cycle, and generate candidate state sealing tokens for the input and output release data packets to be released in the calculation buffer; Step 3: Based on the multi-domain operating status and time-series version baseline model, determine the closed-loop timestamp to prove the residual; Step 4: Based on the multi-domain running status, target release version sequence value, and closed-loop timestamp inverse evidence residual, generate a silent injection evidence vector and a dynamic evidence weight matrix, and determine the corrected old-state silent risk value based on the silent injection evidence vector and the dynamic evidence weight matrix. Step 5: Verify the validity of the candidate state sealed tokens, generate the token validity verification result, and based on the token validity verification result, the same version release consistency condition, and the correction of the old state silent risk value, determine the valid state sealed token, the token release restricted state, or the multi-core task rebalancing state. Step Six: Based on the token validity verification result, perform task control on the input / output release process and the multi-core task scheduling process to ensure that the simulation state of the controlled object released externally meets the same release conditions.

[0009] In one embodiment, the hardware-in-the-loop simulation system includes a real controller, a multi-core real-time simulator, and input / output devices; the multi-core real-time simulator runs a simulation model of the controlled object and sets up a calculation buffer and a release buffer; the input / output devices establish a closed-loop signal path between the simulation model of the controlled object and the real controller.

[0010] In one embodiment, in step one, the multi-core model calculation tasks that participate in the generation of the same input-output publishing data packet are determined as the publishing associated task set, the output fields corresponding to the control quantity, feedback quantity or protection quantity in the closed-loop signal path are determined as the strongly coupled output field set, and a publishing task dependency graph is generated according to the dependency relationship between the publishing associated task set and the strongly coupled output field set.

[0011] In one embodiment, the multi-domain operating state includes a consistency order value state, a proof-of-contrast delay state, a window selection delay state, and a closed-loop response state.

[0012] In one embodiment, the consistency sequence value state is the version sequence value state related to input / output publishing, direct storage access transmission, multi-core model computation task submission, output field state, and publishing buffer archiving; the proof-of-contrast delay state is the delay state used to explain the timing deviation of the closed-loop response; the window selection delay state is the delay state used to select the security task control window; and the closed-loop response state is the timing response state of the real controller to the simulation state of the controlled object in the publishing buffer.

[0013] In one embodiment, the closed-loop timestamp rebuttal residual is determined as follows: the closed-loop response prediction window is determined based on the consistency sequence value state and the time-series version baseline model, and the closed-loop timestamp rebuttal residual is determined based on the degree of deviation of the closed-loop response state from the closed-loop response prediction window, the degree of continuous period drift, and the interpretable delay compensation amount corresponding to the rebuttal delay state.

[0014] In one embodiment, determining the correction of the old state silent risk value specifically includes: determining silent evidence components based on the multi-domain operating status, the target release version sequence value, and the closed-loop timestamp rebuttal residual, and generating a silent injection evidence vector based on the silent evidence components; generating a dynamic evidence weight matrix based on the release task dependency graph, the changing trend of the silent injection evidence vector over multiple consecutive simulation cycles, and the closed-loop timestamp rebuttal residual; and determining the correction of the old state silent risk value based on the silent injection evidence vector and the dynamic evidence weight matrix.

[0015] In one embodiment, the silent evidence component includes the input-output phase lead determined by the consistency order value state, the state submission water level gap, the output field tear spectrum value and the transmission state mapping residual, as well as the closed-loop timestamp reciprocal evidence residual.

[0016] In one embodiment, the generation of the dynamic evidence weight matrix includes: determining the association weights between the silent evidence component and the set of associated release tasks and the set of strongly coupled output fields based on the release task dependency graph; and correcting the association weights based on the changing trend of the silent injection evidence vector over multiple consecutive simulation cycles and the closed-loop timestamp rebuttal residuals to form a dynamic evidence weight matrix.

[0017] In one embodiment, task control includes: performing release restriction control on the input / output release process under a token release restricted state; and determining the task abnormality contribution value based on the silent injection evidence vector, the dynamic evidence weight matrix, and the token validity verification result under a multi-core task rebalancing state, and performing multi-core task rebalancing control based on the task abnormality contribution value.

[0018] Compared with the prior art, the present invention has the following beneficial effects: This invention determines the set of related release tasks, the set of strongly coupled output fields, and the release task dependency graph based on the multi-core partitioning results of the controlled object simulation model in a semi-physical simulation system. It imposes corresponding constraints on the multi-core model's computational tasks, output fields, and input-output release relationships, so that multi-core task balancing no longer depends solely on the processing core load state, but further combines the release coupling relationships between output fields, thereby improving the consistency recognition accuracy of the controlled object's simulation state before release. In each simulation cycle, the multi-domain running status is collected, the target release version sequence value is determined and the candidate state sealing token is generated. The closed-loop timestamp counter-evidence residual is further determined by combining the time-series version benchmark model, and the corrected old state silent risk value is determined by the silent injection evidence vector and the dynamic evidence weight matrix. It can quantitatively judge the old state silent mixing risk that does not show obvious computation timeout or transmission interruption, and improve the anomaly detection capability in the closed-loop operation process of the semi-physical simulation. Based on the valid token verification results, consistent release conditions, and correction of old state quiescent risk values, the system distinguishes between valid state token sealing, token release restricted state, and multi-core task rebalancing state. Based on this, task regulation is performed on the input / output release process and multi-core task scheduling process to ensure that the simulation state of the controlled object released to the outside world is consistent with the same version release, reducing the risk of the real controller receiving cross-version simulation states and improving the stability and reliability of the hardware-in-the-loop simulation results. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a hardware-in-the-loop simulation method for balancing multi-core tasks according to the present invention. Figure 2 This is a schematic diagram of the hardware-in-the-loop simulation system of the present invention; Figure 3This is a schematic diagram of the process for collecting multi-domain running status, determining the target release version sequence value, and generating candidate status sealing tokens in this invention. Figure 4 This is a schematic diagram of the process of the present invention to verify the validity of candidate state sealed tokens and determine the valid state sealed token, the token issuance restricted state, or the multi-core task rebalancing state. Figure 5 This is a schematic diagram illustrating the process of performing multi-core task rebalancing control under the multi-core task rebalancing state of the present invention. Detailed Implementation

[0020] Reference Figures 1 to 2 A hardware-in-the-loop simulation method for balancing multi-core tasks includes: Step 1: In the hardware-in-the-loop simulation system, based on the multi-core partitioning results of the controlled object simulation model, determine the set of related deployment tasks composed of multi-core model computation tasks, the set of strongly coupled output fields composed of output fields, and the deployment task dependency graph. After multi-core partitioning of the controlled object simulation model, the computation tasks of different multi-core models are not isolated from each other. Some multi-core model computation tasks jointly affect the same input / output deployment data packet, and some output fields are closely related to the control, feedback, or protection quantities in the closed-loop interaction of the real controller. By publishing associated task sets, strongly coupled output field sets, and published task dependency graphs, the relationships between multi-core model computation tasks, output fields, and input / output published data packets can be solidified into the basis for subsequent judgment and control, avoiding mechanical balancing based solely on core load levels.

[0021] In a semi-physical simulation environment, a real controller, a multi-real-time simulator, and input / output devices are arranged. The multi-real-time simulator runs the simulation model of the controlled object and divides the calculation buffer and the release buffer in its running storage area. The input / output devices receive the simulation state of the controlled object output by the multi-real-time simulator and transmit it to the real controller. At the same time, they receive the control commands fed back by the real controller and send them back to the simulation model of the controlled object, forming a closed-loop signal path. Taking the hardware-in-the-loop simulation of three-phase motor drive control as an example, the simulation model of the controlled object is divided into different processing cores according to electromagnetic calculation, mechanical rotation calculation, inverter switching calculation and protection logic calculation. The electromagnetic calculation task outputs the stator current field, the mechanical rotation calculation task outputs the speed field, the inverter switching calculation task outputs the bus voltage field, and the protection logic calculation task outputs the overcurrent protection field. The above multiple output fields jointly participate in the formation of the same input-output data packet. Based on the multi-core partitioning results of the simulation model of the controlled object, the multi-core model calculation tasks that participate in the generation of the same input-output data packet are associated and organized. The electromagnetic calculation task, mechanical rotation calculation task, inverter switching calculation task, and protection logic calculation task are identified as the set of associated tasks. The stator current field, speed field, bus voltage field, and overcurrent protection field that are directly related to the control decision of the real controller in the closed-loop signal path are identified as the set of strongly coupled output fields. Based on the contribution relationship of each multi-core model computation task to the strongly coupled output field, the relationship of the output field being encapsulated by the same input-output release data packet, and the synchronization requirements of the real controller for different output fields, a release task dependency graph is established. The release task dependency graph records the correspondence between multi-core model computation tasks, strongly coupled output fields and input-output release data packets, providing a structured basis for determining whether cross-core computation results belong to the same release version.

[0022] Reference Figure 3 Step 2: Within each simulation cycle, multi-domain runtime status is collected to determine the target release version sequence value corresponding to the current simulation cycle, and candidate state sealing tokens are generated for the input / output release data packets to be released in the computation buffer. The multi-domain runtime status reflects the operational status of input / output release, task submission, data transmission, state sealing, and closed-loop response within the current simulation cycle; the target release version sequence value defines the version baseline that should be released in this cycle; and the candidate state sealing tokens correspond to the input / output release data packets to be released in the computation buffer. Through this processing, the content to be released is no longer merely represented as ordinary data packets, but is assigned a sealing identifier associated with the simulation cycle, version sequence value, and runtime status, facilitating the determination of whether it meets the same-version release consistency conditions.

[0023] At the end of each simulation cycle, the timing of input / output release, direct memory access transmission, multi-core model computation task submission, output field status, release buffer sealing, and real controller response are synchronously collected to form a multi-domain operating status. Among them, the consistency sequence value status records the correspondence between input / output release version number, direct memory access transmission batch number, multi-core model computation task submission sequence number, output field version number, and release buffer sealing sequence number; the inverse delay status records the interpretable delay portion of the direct memory access transmission waiting time, input / output device transmission time, and real controller response return time; the window selection delay status records the time boundary suitable for executing release restriction control or multi-core task rebalancing control within the current simulation cycle; and the closed-loop response status records the receiving time, return time, and response order of the real controller's response to the simulation status of the controlled object in the release buffer. For example, in the hardware-in-the-loop simulation of motor control, the stator current field, speed field and bus voltage field are calculated by different processing cores. If the stator current field has entered the release buffer while the speed field is still in the calculation buffer, the consistency sequence value status will record the difference between the two version sequence values. Based on the current simulation cycle number, the most recent archive number of the release buffer, and the version number of each output field, determine the target release version number corresponding to the current simulation cycle, and write the candidate state archive token to the input and output release data packets to be released in the calculation buffer. The candidate state sealing token contains the target release version sequence value, input / output release data packet identifier, associated output field version sequence value, generation time, calculation buffer location identifier, and release buffer sealing reference number. The token content corresponds one-to-one with the multi-domain running status, which facilitates the identification of whether the input / output release data packet to be released has cross-cycle old state mixing, field version tearing, or closed-loop response timing offset under the condition of consistent release of the same version.

[0024] Candidate state sealing token is denoted as Let the current simulation period be... The target release version number is The input / output published data packet identifier is The strongly coupled output field set is , The number of strongly coupled output fields shall be no less than one. For strongly coupled output field sequence numbers and .

[0025] In this embodiment, the baseline, threshold, gain coefficient and protection value not obtained by real-time calculation by formula are all taken from the historical records or operation configuration files under normal closed-loop operation; when historical records are missing, the corresponding configuration values ​​given in the operation configuration file are taken.

[0026] The release buffer sealing reference number is denoted as follows: Token It also includes field version mapping. Task submission sequence number mapping and direct access transport batch mapping .

[0027] in, For output fields The version sequence value of the field. For output fields The submission sequence number corresponding to the multi-core model computation task. For output fields The corresponding direct storage access transmission batch number. and All are serial numbers converted based on the target release version sequence value benchmark; original task submission serial numbers and original direct storage access transmission batch numbers that have not completed this benchmark conversion are not included in the same version release consistency condition determination and silent injection evidence component calculation.

[0028] Let the current input / output published data packet identifier be... The current archive sequence number in the release buffer is The condition for consistent release of the same version is determined by the following criteria: .when And any All meet hour, Choose one; in the rest, Take zero.

[0029] Step 3: Based on the multi-domain operating state and timing version baseline model, determine the closed-loop timestamp inverse verification residual to reverse-examine whether there is a risk of silent injection of old state from the perspective of closed-loop timing. The timing version baseline model gives the timing range that the actual controller's closed-loop response should fall into after the controlled object's simulation state is released under normal circumstances; the multi-domain operating state reflects version changes, transmission delays, window selection delays, and closed-loop response states in actual operation. The closed-loop timestamp inverse verification residual reflects the deviation between the actual closed-loop response and the baseline timing that is difficult to explain by normal delays, and can supplement hidden anomalies that are difficult to detect by simple version sequence value verification.

[0030] Within each simulation cycle, the consistency sequence value state, the counter-proof delay state, and the closed-loop response state in the multi-domain operating state are read, and the benchmark timing record that matches the current target release version sequence value in the timing version benchmark model is retrieved. The consistency sequence value state includes the input and output release version number, the direct storage access transmission batch number, the multi-core model calculation task submission sequence number, the output field status sequence number, and the release buffer sealing sequence number. This determines the time boundary that the current controlled object simulation state should cause the real controller to respond under normal closed-loop interaction, forming a closed-loop response prediction window. The time-series version baseline model is denoted as It is formed by historical time-series records or operation configuration files under normal closed-loop operation. Includes version sequence value, release time, real controller receive time, real controller return time, response order, direct storage access transmission wait time, input / output device transmission time, and allowable jitter boundary.

[0031] Let the publication time of the current input / output publication data packet entering the publication buffer be . ,and The matched baseline closed-loop response delay is The permissible jitter boundary is The closed-loop response prediction window is , To predict the lower boundary of the window, This is for predicting the upper boundary of the window.

[0032] The lower boundary of the prediction window is obtained by the following formula.

[0033] The upper boundary of the prediction window is obtained by the following formula.

[0034] For example, in the hardware-in-the-loop simulation of motor control, when the target release version sequence value is version 126, the timing version baseline model gives the receiving time range in which the real controller feedback control command should fall after the stator current field, speed field and bus voltage field of this version enter the release buffer. This receiving time range is used as the closed-loop response prediction window. The actual reception time, return time, and response sequence in the closed-loop response state are compared with the closed-loop response prediction window to obtain the degree of deviation of the closed-loop response state relative to the closed-loop response prediction window. Combined with the direction of change and cumulative magnitude of this deviation over multiple consecutive simulation cycles, the degree of continuous cycle drift is calculated. At the same time, based on the direct storage access transmission waiting time, input / output device transmission time, and actual controller response return time recorded in the counter-proof delay state, an interpretable delay compensation amount that can be explained by the normal transmission link is extracted. After deducting this interpretable delay compensation amount from the degree of deviation and the degree of continuous cycle drift, the closed-loop timestamp counter-proof residual is obtained. The residual for closed-loop timestamp proof by contradiction is denoted as Actual closed-loop response time To and The actual return time of the matched controller; if no return time is recorded. To and The actual receiver reception time of the matched controller; if there is no reception time record and no return time record, then... Retrieve the closed-loop timeout determination time for the current simulation cycle. The closed-loop timeout determination time is taken from the runtime configuration file.

[0035] set up This represents the actual closed-loop response time in the previous simulation cycle. The simulation cycle length, To and The corresponding number of times the response order is misaligned. The non-negative order deviation coefficient. This represents the deviation of the closed-loop response. For continuous periodic drift, This is the amount of interpretable delay compensation.

[0036] set up For direct access transmission wait time, For input / output device transmission time, For the actual controller response return time, and This is a non-negative correction coefficient. and Only the delay explained by the normal link in the counter-evidence delay state is taken, excluding... and For delay entries lacking corresponding records, set the value to zero.

[0037] The deviation of the closed-loop response is obtained by the following formula.

[0038] There is no actual closed-loop response time in the previous simulation cycle. hour, .exist When the continuous periodic drift is obtained, the drift amount is obtained by the following formula.

[0039] The explanatory delay compensation amount is obtained by the following formula.

[0040] The residual is obtained by disproving the closed-loop timestamp using the following formula.

[0041] If the stator current field has been published according to version 126, but the actual controller response is consistently delayed for several simulation cycles, and this delay exceeds the range that can be explained by the direct memory access transmission wait time and the input / output device transmission time, then the closed-loop timestamp indicates that the residual has increased, suggesting that there may be old state mixed in or field version tearing in the pending release state.

[0042] Step 4: Based on the multi-domain running status, target release version sequence value, and closed-loop timestamp counter-evidence residual, generate a silent injection evidence vector and a dynamic evidence weight matrix, and determine the corrected old-state silent risk value based on the silent injection evidence vector and the dynamic evidence weight matrix, transforming scattered abnormal signs into calculable risk judgment results; The silent injection evidence vector aggregates evidence components such as input-output phase lead, state submission gap, output field tear spectrum value, transmission state mapping residual, and closed-loop timestamp inverse evidence residual. The dynamic evidence weight matrix, combined with the release task dependency graph and the changing trends over multiple simulation cycles, distinguishes the degree of influence of different evidence components. The corrected old-state silent risk value is jointly determined by the silent injection evidence vector and the dynamic evidence weight matrix, reflecting the differences in the contribution of different multi-core model computation tasks, different output fields, and different closed-loop response anomalies to the old-state silent injection risk.

[0043] Based on the multi-domain operating status, target release version sequence value, and closed-loop timestamp counter-evidence residual, the input-output phase lead, status submission water level gap, output field tear spectrum value, transmission status mapping residual, and closed-loop timestamp counter-evidence residual are extracted as silent evidence components, and silent injection evidence vectors are generated according to the arrangement relationship of each output field in the input-output release data packet. Silent injection of evidence vector denoted as . This refers to the input-output phase lead. Submit a status update regarding the water level gap. To output the tear spectrum value, For the transmission state mapping residual, The residual is proved by contradiction using the normalized closed-loop timestamp.

[0044] Following the above and .set up As a benchmark for version ordinal value normalization, Submit a normalized baseline for the task sequence number. The closed-loop timestamp serves as the reverse proof of the residual normalization benchmark, and all three are greater than zero. This is an indicator function; it returns 1 if the condition is true and 0 if the condition is false. Indicates will Limited to the range of zero to one.

[0045] The input-output phase lead is obtained by the following formula.

[0046] The status submission water level gap is obtained by the following formula.

[0047] The tear spectrum value in the output field is obtained by the following formula.

[0048] The transmission state mapping residual is obtained by the following formula.

[0049] The residual is obtained by contradiction proof using the normalized closed-loop timestamp as follows.

[0050] For example, in the hardware-in-the-loop simulation of motor control, the version sequence value corresponding to the stator current field has reached version 126, while the speed field is still stuck at version 125. Although the bus voltage field has completed direct storage access and transmission, the release buffer archive sequence number has not been updated. At this time, the input and output phase lead reflects the difference in release cycle time between fields, the status submission water level gap reflects the insufficient submission progress of the multi-core model calculation task, the output field tear spectrum value reflects the inconsistency of versions within the same input and output release data packet, and the transmission status mapping residual reflects the misalignment between the direct storage access transmission batch and the output field status. Based on the task dependency graph, the association weights between the above silent evidence components and the set of related tasks and the set of strongly coupled output fields are determined. The association weights are then corrected by combining the changing trend of the silent injection evidence vector in multiple consecutive simulation cycles and the closed-loop timestamp counter-evidence residuals, forming a dynamic evidence weight matrix. The dynamic evidence weight matrix is ​​denoted as ,for A 5x5 matrix. The set of related tasks to be published is... , The number of associated tasks to be published must be no less than one. , , Sum index for evidence components.

[0051] Basic association weight It is a non-negative quantity, consisting of the published task dependency graph, the set of strongly coupled output fields, and the coupling level of the output fields. Sure, It is obtained from the level configuration of control variables, feedback variables, or protection variables. Let... The update coefficient is non-negative. The normalized protection value is greater than zero. The updated weights are those before normalization.

[0052] When there is no dynamic evidence weight from the previous simulation cycle, the weight from the previous cycle is obtained by normalizing the basic correlation weight.

[0053] When there is no silent evidence component from the previous simulation cycle, the silent evidence component from the previous cycle in the update formula is taken as the silent evidence component from the current cycle.

[0054] The update weights before normalization are obtained by the following formula.

[0055] The dynamic evidence weight is obtained by the following formula.

[0056] The corrected old-state silent risk value is denoted as The first risk threshold is The second risk threshold is Both the first and second risk thresholds are within the range of normalized risk values, and the first risk threshold is lower than the second risk threshold.

[0057] When the corrected old state silent risk value is lower than the first risk threshold, it is considered low risk; when it is not lower than the first risk threshold but lower than the second risk threshold, it is considered restricted release risk; when it is not lower than the second risk threshold, it is considered rebalancing risk.

[0058] When the stator current field and overcurrent protection field show version differences for multiple consecutive simulation cycles, and the actual controller response time continuously deviates from the closed-loop response prediction window, the weights related to the electromagnetic calculation task, protection logic calculation task, and corresponding strongly coupled output fields are increased. The old state silent risk value is calculated based on the silent injection evidence vector and dynamic evidence weight matrix. This value reflects the risk level of old state data being silently mixed in in the release buffer.

[0059] Reference Figure 4 Step 5: Verify the validity of candidate state-sealed tokens, generate token validity verification results, and based on the token validity verification results, same-version release consistency conditions, and correction of old-state silent risk values, determine whether the token is in a valid state, a token release restricted state, or a multi-core task rebalancing state. The token validity verification results reflect the matching status between the candidate state-sealed token and the current target release version sequence value, calculation buffer state, and release consistency requirements. The consistent release conditions stipulate that related output fields within the same input / output release data packet should have a consistent version basis; the correction of the old state silent risk value reflects the risk level of potential old state mixing or hidden misversions in the release state. After the three factors jointly participate in the judgment, the candidate state sealing token that meets the requirements is determined as the valid state sealing token; when there is a release risk but there is no need to adjust the multi-core task scheduling, it enters the token release restricted state; when the risk is strongly related to the operation of the multi-core model computing task, it enters the multi-core task rebalancing state.

[0060] The validity of the candidate state sealing tokens corresponding to the input / output release data packets to be released in the computation buffer is verified. The verification includes whether the target release version sequence value recorded in the candidate state sealing token is consistent with the target release version sequence value corresponding to the current simulation cycle, whether the version sequence values ​​of each output field associated with the candidate state sealing token meet the same release condition, whether the input / output release data packets corresponding to the candidate state sealing token are still in the release position in the computation buffer, and whether the release buffer sealing reference sequence number has not been overwritten by the new sealing sequence number. In the above verification process, let the valid token verification result be: , . The result of sealing the token is valid. To issue a restricted state result for the token, This represents the result of a multi-core task rebalancing state.

[0061] Let the set of exception fields be , Including field version sequence value not equal to The task submission number is less than The following are examples of tightly coupled output fields where the direct access transmission batch number is not equal to the field version sequence value, or the release buffer archive reference sequence number is not equal to the current archive sequence number in the release buffer. When a release buffer archive reference sequence number inconsistency occurs, .

[0062] set up To associate values ​​for task fields in the published task dependency graph, Represents multi-core model computational tasks Directly generates or directly affects output fields , This indicates that there is no direct generation or direct influence relationship. Let the threshold for the anomaly field set be... The threshold for abnormal fields is greater than zero and not greater than one; let the number of consecutive risk assessment periods be... , It is an integer not less than two.

[0063] The conditions for the abnormal fields are: Not empty, and in each multi-core model computation task, with The number of abnormal fields that directly generate or directly affect relationships accounts for The maximum proportion of the quantity reached .

[0064] The condition for continuous high risk is: the number of corrected old-state silent risk values, including the current simulation cycle, is not less than [number missing]. Furthermore, the corrected old-state quiescent risk value does not decrease within this continuous period, and the current corrected old-state quiescent risk value... Not lower than the second risk threshold .

[0065] When both the abnormal field set condition and the continuous high-risk condition are met, the token validity verification result is the multi-core task rebalancing state result. .

[0066] When the conditions for abnormal fields and continuous high-risk conditions are different, the condition judgment value is consistent with the same version release. And correct the old state silent risk value At that time, the token validity verification result is a valid state and the token result is sealed. .

[0067] In all other cases, the token validity verification result is the token issuance restricted status result. .

[0068] Reference Figure 5 Step Six: Based on the token validity verification result, perform task control on the input / output release process and the multi-core task scheduling process to ensure that the simulation state of the controlled object released externally meets the same release conditions, thus implementing the aforementioned verification and risk assessment into actual operation control. Task control covers the input / output release process and the multi-core task scheduling process. For input / output release data packets whose token validity verification results meet the requirements, the token is sealed and released according to the valid state. For token release restricted state, release restriction control is performed on the input / output release process to prevent the simulation state of the controlled object that does not meet the same version release consistency condition from entering the release buffer. For multi-core task rebalancing state, the scheduling relationship of related multi-core model calculation tasks is adjusted according to the task abnormal contribution value to reduce the probability of cross-version tearing, old state mixing, or closed-loop response abnormality in strongly coupled output fields.

[0069] When the token validity verification result shows that the candidate state sealed token is in the token release restricted state, the release restriction control is performed on the input and output release process based on the target release version sequence value, release buffer sealed reference sequence number and version sequence value of each strongly coupled output field in the candidate state sealed token. The input and output release data packets are suspended from entering the release buffer, the output fields that have reached the target release version sequence value in the calculation buffer are retained, and the same version waiting boundary is set for the output fields with version lag.

[0070] Same version waiting boundary is recorded as .set up The remaining adjustable time for the current simulation cycle. The window length for adjusting the security task is given by selecting the delay state for the window. The minimum protection time for input / output devices, and all three values ​​are non-negative.

[0071] Version lag field set For a strongly coupled set of output fields The version number of the middle field is lower than The set of output fields. Let... For output fields Complete to The estimated remaining time required. The execution time is determined by the historical execution time, current execution time, and computation buffer write status of the corresponding multi-core model computation task; if no historical execution time record exists, the estimated execution time in the runtime configuration file is used; output fields It has been reached hour, Take zero.

[0072] The same version waiting boundary is obtained by the following formula.

[0073] When any All meet Furthermore, the condition value for consistent release after completion is satisfied. When the same version release deadline has passed, the release qualification of the input / output release data packet is discarded and the simulation state of the controlled object corresponding to the previous valid state release token is retained.

[0074] The abnormal contribution value of the task is recorded as .set up For multi-core model computation tasks Related token verification error flags, express The directly related output fields may have differences in field version, delayed task submission sequence number, different transmission batches, or different references in the release buffer archiving. This indicates that the aforementioned differences do not exist. Let... This is the non-negative token anomaly gain coefficient.

[0075] set up To process the core sequence number, To process the nucleus Waiting at the same boundary The set of multi-core model computing tasks already queued within the system. For multi-core model computation tasks The estimated execution time within the current simulation cycle, The time taken for a task to execute normally in the past, the current input size, and the running configuration file are all considered. To process the nucleus The remaining calculation margin.

[0076] The abnormal contribution value of the task is obtained by the following formula.

[0077] The remaining calculation margin for processing the kernel is obtained by the following formula.

[0078] A loosely coupled task refers to a task that does not directly generate or affect the set of exception fields in the task dependency graph. Internal output fields, and task exception contribution value Below the first risk threshold Multi-core model computational tasks. Multi-core task rebalancing and control according to... Select target tasks from high to low; when the remaining computational capacity of the processing core containing the target task is... Less than the target task's estimated execution time When there are loosely coupled tasks on the same processing core, adjust the binding relationship of the processing cores for the loosely coupled tasks; when there are fields in the set of strongly coupled output fields that have not reached the target release version order value, postpone the opening time of the synchronization barrier before release until the release consistency conditions of the same version are met or the waiting boundary of the same version is reached.

[0079] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations 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. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A hardware-in-the-loop simulation method for balancing multi-core tasks, characterized in that, include: Step 1: In the hardware-in-the-loop simulation system, based on the multi-core partitioning results of the simulation model of the controlled object, determine the set of deployment related tasks consisting of multi-core model computation tasks, the set of strongly coupled output fields consisting of output fields, and the deployment task dependency graph. Step 2: Collect multi-domain running status in each simulation cycle, determine the target release version sequence value corresponding to the current simulation cycle, and generate candidate state sealing tokens for the input and output release data packets to be released in the calculation buffer; Step 3: Based on the multi-domain operating status and time-series version baseline model, determine the closed-loop timestamp to prove the residual; Step 4: Based on the multi-domain running status, target release version sequence value, and closed-loop timestamp inverse evidence residual, generate a silent injection evidence vector and a dynamic evidence weight matrix, and determine the corrected old-state silent risk value based on the silent injection evidence vector and the dynamic evidence weight matrix. Step 5: Verify the validity of the candidate state sealed tokens, generate the token validity verification result, and based on the token validity verification result, the same version release consistency condition, and the correction of the old state silent risk value, determine the valid state sealed token, the token release restricted state, or the multi-core task rebalancing state. Step Six: Based on the token validity verification result, perform task control on the input / output release process and the multi-core task scheduling process to ensure that the simulation state of the controlled object released externally meets the same release conditions.

2. The hardware-in-the-loop simulation method for balancing multi-core tasks according to claim 1, characterized in that, The hardware-in-the-loop simulation system includes a real controller, a multi-core real-time simulator, and input / output devices. The multi-core real-time simulator runs the simulation model of the controlled object and sets up a calculation buffer and a release buffer. The input / output devices establish a closed-loop signal path between the simulation model of the controlled object and the real controller.

3. The hardware-in-the-loop simulation method for balancing multi-core tasks according to claim 2, characterized in that, In step one, the multi-core model calculation tasks that participate in the generation of the same input-output data packet are identified as the release associated task set, the output fields corresponding to the control quantity, feedback quantity, or protection quantity in the closed-loop signal path are identified as the strongly coupled output field set, and a release task dependency graph is generated based on the dependency relationship between the release associated task set and the strongly coupled output field set.

4. The hardware-in-the-loop simulation method for balancing multi-core tasks according to claim 1, characterized in that, The multi-domain operating states include the consistency sequence value state, the proof-of-contact delay state, the window selection delay state, and the closed-loop response state.

5. The hardware-in-the-loop simulation method for balancing multi-core tasks according to claim 4, characterized in that, The consistency sequence value state is the version sequence value state related to input / output release, direct storage access and transmission, multi-core model computation task submission, output field state, and release buffer archiving; the proof-of-contradiction delay state is the delay state used to explain the timing deviation of the closed-loop response; The window selection delay state is the delay state used to select the safety task control window; the closed-loop response state is the timing state of the real controller's response to the simulation state of the controlled object in the release buffer.

6. The hardware-in-the-loop simulation method for balancing multi-core tasks according to claim 5, characterized in that, The closed-loop timestamp rebuttal residual is determined as follows: the closed-loop response prediction window is determined based on the consistency sequence value state and the time-series version baseline model, and the closed-loop timestamp rebuttal residual is determined based on the degree of deviation of the closed-loop response state from the closed-loop response prediction window, the degree of continuous period drift, and the interpretable delay compensation amount corresponding to the rebuttal delay state.

7. The hardware-in-the-loop simulation method for balancing multi-core tasks according to claim 1, characterized in that, The determination of the correction of the old state silent risk value specifically includes: determining the silent evidence components based on the multi-domain operating status, the target release version sequence value, and the closed-loop timestamp rebuttal residual, and generating a silent injection evidence vector based on the silent evidence components; generating a dynamic evidence weight matrix based on the release task dependency graph, the changing trend of the silent injection evidence vector in multiple consecutive simulation cycles, and the closed-loop timestamp rebuttal residual; and determining the correction of the old state silent risk value based on the silent injection evidence vector and the dynamic evidence weight matrix.

8. A hardware-in-the-loop simulation method for balancing multi-core tasks according to claim 7, characterized in that, The silent evidence component includes the input-output phase lead determined by the consistency order value state, the state submission water level gap, the output field tear spectrum value and the transmission state mapping residual, as well as the closed-loop timestamp reciprocal evidence residual.

9. A hardware-in-the-loop simulation method for balancing multi-core tasks according to claim 8, characterized in that, The generation of the dynamic evidence weight matrix includes: determining the association weights between silent evidence components and the set of associated release tasks and the set of strongly coupled output fields based on the release task dependency graph; and correcting the association weights based on the changing trend of the silent injection evidence vector over multiple consecutive simulation cycles and the closed-loop timestamp inverse evidence residuals to form the dynamic evidence weight matrix.

10. A hardware-in-the-loop simulation method for balancing multi-core tasks according to any one of claims 1-9, characterized in that, Task control includes: performing release restriction control on the input and output release process under token release restriction state; and determining the task abnormality contribution value based on the silent injection evidence vector, dynamic evidence weight matrix and token validity verification result under multi-core task rebalancing state, and performing multi-core task rebalancing control based on the task abnormality contribution value.

Images