Confirmation reliability evaluation method for software and hardware interaction of electronic product

Abstract

The invention provides an electronic product software and hardware interaction confidential reliability evaluation method, which comprises the following steps of S1, analyzing a software and hardware failure mechanism, and determining existing software, hardware and software and hardware interaction failure mechanisms according to a system structure, functions and historical information; s2, establishing a relationship among software and hardware system performance parameters, software subsystem performance parameters and hardware subsystem performance parameters, and adopting a state accumulation analysis method to construct a performance equation for quantitative analysis; s3, considering interaction of software and hardware, and establishing a degradation model to calculate a state probability in a degradation process; s4, uncertainty quantitative evaluation: judging whether the triggering time and the triggering influence have uncertainty or not; and S5, reliability evaluation: when the digital circuit module and the software module are out of the fault state and the analog circuit margin is greater than 0, judging that the system is reliable. According to the method, a definite reliability analysis and modeling method can be introduced into software and hardware system modeling, so that the software and hardware system can be evaluated more accurately.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of reliability modeling, in particular to a method for evaluating the assured reliability of the interaction between the software and hardware of an electronic product. BACKGROUND

[0002] Soft and hardware systems are widely used in aerospace, weapon equipment, network communication and other fields. Traditional reliability research theories usually assume that hardware failure and software failure are independent of each other when studying the reliability of soft and hardware systems, and ignore the mutual influence between software and hardware. Studies have shown that nearly 35% of all observed software failures are related to hardware. The interaction between software and hardware can pose a serious threat to the reliability and safety of the system. For example, during the landing process of Airbus A320, the necessary conditions of the braking logic of the flight control system were not met due to the non-compression of the left landing gear leg, causing the aircraft to delay braking for about 9 seconds after landing, and the runway braking length was not enough to cause the aircraft to crash into the obstacle, resulting in 2 deaths and multiple injuries. As can be seen, analyzing the interaction between software and hardware is a necessary step in studying the reliability of soft and hardware systems.

[0003] Existing soft and hardware system reliability modeling methods mainly include soft and hardware fusion modeling method and soft and hardware integration modeling method. The soft and hardware fusion modeling method uses statistical methods to model software, hardware and soft and hardware interaction separately and then fuses them, which is difficult to describe complex interaction relationships. Compared with the soft and hardware fusion modeling method, the soft and hardware integration modeling method considers the differences in the failure mechanisms of software and hardware, which can reduce the errors in the modeling and analysis process, but has problems such as narrow application range and difficulty in quantization. In addition, existing researches mostly focus on data-driven modeling, lacking in-depth analysis of the failure mechanism of soft and hardware interaction. Although this modeling method can better evaluate the reliability of soft and hardware systems, it lacks guidance for the reliability design of soft and hardware systems.

[0004] The assured reliability analysis and modeling method is a modeling method that supports reliability analysis and forward design. This method is based on the three basic principles of reliability science: margin reliability principle, degradation perpetuity principle and uncertainty principle. According to the key performance parameters of the product, the threshold of the performance parameters and their sensitive external and internal causes, the product cross-disciplinary equations and margin equations are established; considering the long-term degradation of key performance parameters caused by working stress, environmental stress and other factors, the degradation equation is established; through uncertainty quantization, the reliability model is established, and on the basis of the model, the reliability is taken as the target for design optimization. The assured reliability analysis and modeling method not only clearly describes the relationships within the system, but also guides the forward design of product reliability. However, there is still no related research to apply the assured reliability analysis and modeling method to the evaluation of soft and hardware systems of electronic products, and therefore, there is an urgent need for a new modeling method to solve the above problems. SUMMARY

[0005] In order to solve the above-mentioned deficiencies of the prior art, the purpose of the present application is to provide an electronic product software and hardware interaction reliability evaluation method, which introduces the reliability analysis and modeling method into the software and hardware system modeling, so as to better evaluate the software and hardware system, and establishes a complete theoretical method from mechanism analysis, behavior modeling to uncertainty processing.

[0006] The present application provides an electronic product software and hardware interaction reliability evaluation method, which comprises the following steps: S1, analyzing the software and hardware failure mechanism to obtain the software, hardware and software and hardware interaction failure mechanism; S2, establishing the relationship between the software and hardware system performance parameters, the software subsystem performance parameters and the hardware subsystem performance parameters, and constructing the performance equation by using the state accumulation analysis method for quantitative analysis; S3, establishing a degradation model to calculate the state probability in the degradation process, specifically: S31, according to the hardware subsystem failure mechanism, constructing a hardware degradation injection model to represent the state probability of the unit in the hardware subsystem degradation process; S32, according to the software subsystem failure mechanism, establishing a software defect injection model to calculate the state probability of the unit in the software subsystem defect triggering process; S33, according to the software and hardware failure mechanism, establishing a software and hardware interaction fault model to calculate the state probability of the software and hardware system in the degradation process, the software and hardware interaction fault model includes a degradation propagation error model, a degradation triggering error model, a transient error triggering model and a software defect induction model, specifically: S331, constructing a degradation propagation error model to calculate the normal state probability of the unit in the software and hardware system when the degradation propagation error occurs Wherein, is a new margin of the analog circuit degradation propagated or amplified in the software; represents that the unit of the software subsystem contains independent failure mechanisms; is the failure rate of the i-th independent failure mechanism of the software subsystem; S332, constructing a degradation triggering error model to calculate the normal state probability of the unit in the software and hardware system when the degradation triggering error occurs: Wherein, represents the total number of software independent failure mechanisms and software and hardware interaction failure mechanisms, is the failure rate of the failure mechanism ; ​​​S333, constructing a transient error trigger model to calculate the normal state probability of the unit in the software and hardware system at the time of transient error triggering: ; S334, constructing a software defect induction model to calculate the normal state probability of the unit in the software and hardware system at the time of software defect induction: ; Wherein, is the margin of the hardware triggered by the software at the moment; S4, uncertain quantitative evaluation: judging whether the triggering time and triggering influence exist uncertainty or not; S5, reliability evaluation: when the digital circuit module and the software module are out of the fault state and the hardware subsystem margin is greater than 0, the software and hardware system is determined to be reliable.

[0007] Compared with the prior art, the beneficial effects of the present application are as follows: (1) The present application provides a certain reliability evaluation method for the interaction of electronic product software and hardware, which can introduce certain reliability analysis and modeling method into the modeling of software and hardware system, so that the software and hardware system can be better evaluated, and a complete theoretical framework from mechanism analysis, behavior modeling to uncertainty processing is established, which lays a solid theoretical foundation for accurately analyzing the reliability of the software and hardware system.

[0008] (2) The certain reliability evaluation method for the interaction of electronic product software and hardware of the present application expounds the software and hardware interaction mechanism, which provides a basis for modeling. In view of the problem that the traditional software and hardware reliability modeling is mostly based on data, and the software and hardware interaction failure mechanism is insufficiently analyzed, the present application summarizes the software and hardware interaction failure mechanism, which is summarized as hardware driving software failure, software defect inducing hardware damage and redundancy and shielding, wherein the hardware driving software failure is divided into degradation propagation error, degradation trigger misjudgment and transient error triggering, which provides a basis for software and hardware reliability modeling and evaluation.

[0009] (3) The present application proposes a software and hardware coordinated modeling method considering the interaction failure of software and hardware based on improved GO method. On the one hand, the traditional GO method assumes that each unit is a multi-state unit, but the analog circuit is continuously degraded, so the present application uses the margin reliability principle to convert the continuous degradation mechanism into a multi-state mechanism for GO graph quantization of the continuously degraded unit and GO graph coordinated modeling of the system. On the other hand, the present application analyzes and establishes the trigger, redundancy and other software and hardware interaction failure models, integrates the software and hardware interaction failure models into the GO method, expands the modeling capability of the GO method from “mutually independent system” to “software and hardware system with interaction mechanism”, and can better evaluate the certain reliability of the interaction of electronic product software and hardware. BRIEF DESCRIPTION OF DRAWINGS

[0010] Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 This is a schematic diagram of the hardware and software reliability analysis and modeling framework of the present invention; Figure 3 This is a schematic diagram of the circuit output GO diagram of the software subsystem of the present invention; Figure 4 This is a schematic diagram of the bus output GO diagram of the software subsystem of the present invention; Figure 5 This is a schematic diagram of the circuit output GO diagram of the hardware and software system of the present invention; Figure 6 This is a schematic diagram of the bus output GO diagram of the hardware and software system of the present invention; Figure 7 This is a schematic diagram illustrating the reliability evaluation results of an embodiment of the present invention. Detailed Implementation

[0011] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.

[0012] Specifically, this invention provides a method for assessing the reliability of software and hardware interactions in electronic products, such as... Figure 1 As shown, it includes the following steps: S1. Analyze the failure mechanisms of software and hardware. Based on the system structure, functions, and historical information, identify the existing software, hardware, and software-hardware interaction failure mechanisms. The analysis process is as follows: Figure 2 As shown. Step S1 specifically includes the following steps: S11. Analyze the hardware failure mechanism to determine whether the hardware has structural damage failure or performance degradation failure.

[0013] S12. Analyze the software failure mechanism and determine the possible failure modes and mechanisms of the software failure.

[0014] S13. Analyze the failure mechanisms of hardware and software, and determine whether there are failure mechanisms such as hardware driver software failure, software defects causing hardware damage, redundancy and shielding.

[0015] S131. Determine if there is a degradation propagation error, that is, whether the analog circuit will degrade due to its own performance, causing deviation in its output electrical performance parameters. This data signal deviation will be transmitted and amplified during software execution, eventually causing abnormal software output.

[0016] S132. Determine whether there is a degradation trigger misjudgment, that is, whether the analog circuit will degrade due to its own performance, causing the output electrical performance parameters to deviate, and the control signal or status signal of the deviation will be used as illegal input to the software, triggering software output error or execution error.

[0017] S133. Determine whether there is a transient error trigger, that is, whether the digital circuit will cause its output electrical performance parameters to deviate due to its own transient error, and whether the control signal or status signal of the deviation will be used as illegal input to the software, triggering software output error or execution error.

[0018] S134. Determine whether there is a software defect that could trigger an output error, which could affect the hardware input signal and ultimately lead to the failure of the hardware function.

[0019] S135. Determine whether there is redundant design for error signals in the software or whether a shielding effect can occur.

[0020] In specific examples, the software subsystem in a hardware / software system typically handles information processing and decision-making, while the hardware subsystem is responsible for information acquisition, action execution, and providing a platform for the software to run. This highly coupled and interconnected relationship means that the impact of failures between the software and hardware subsystems can propagate and potentially evolve into new system-level failure modes. The interdependence between software and hardware is mainly manifested in the following three aspects: ① Logical connection: refers to the logical connectivity between embedded application software and physical components in the state of observation, measurement, control or instruction; ②Physical connection: refers to the physical connection relationship established between the computer system and the physical system through sensors and actuators; ③Task dependency: refers to the deployment of application software tasks on a computer platform to utilize its computing resources to perform corresponding functions.

[0021] Based on the above dependencies, faults can be transmitted between software and hardware systems, collectively leading to system malfunctions. This invention summarizes typical software-hardware interaction fault mechanisms into the following categories: (1) Hardware driver software failure Hardware-driven software failure refers to a deviation in the electrical performance parameters output by hardware due to its own failure or performance degradation. This deviation is propagated and amplified during software execution, ultimately causing abnormal software output and system malfunction. Based on the type of hardware failure, this invention classifies it into the following three mechanisms: ① Degeneration propagation error Under the influence of electrical stress, temperature stress, and other factors, the performance parameters of analog circuits will slowly degrade. When these degraded parameters are used in numerical calculations in software, parameter deviations may be transmitted and amplified during software execution, ultimately leading to abnormal software output.

[0022] ② Degradation trigger misjudgment: Under the influence of electrical stress, temperature stress, and other factors, the performance parameters of analog circuits will slowly degrade. When these degraded parameters participate in the logical judgment of software, parameter deviations may trigger software output errors or execution errors.

[0023] ③ Transient error triggering: Under the influence of electrical stress, temperature stress, and other factors, digital circuits may degrade, leading to transient and permanent errors. Permanent errors in digital circuits directly cause system failure. Transient errors in digital circuits may result in brief output errors. If the error signal is used as a data signal in the software, the error only affects the software's output data. In this case, the transient fault data is quickly overwritten by new correct data, and its impact on the software is negligible.

[0024] If the error signal is a control signal or a status signal, it is similar to the degradation of analog circuits and may trigger software output errors or execution errors.

[0025] (2) Software defects induce hardware damage Software-driven hardware failure refers to a failure mechanism in which a specific operating mode or inherent defect in the software acts as a trigger, affecting the input signals of the hardware or the environmental stress it experiences, ultimately leading to hardware malfunction. Based on its mechanism and manifestation, this invention categorizes it into the following two types: ① Functional failure Software defects can trigger software output errors. When these erroneous outputs are fed back to subsequent hardware actuators as control signals, status signals, or data signals, they can cause a series of chain reactions, resulting in abnormal hardware function.

[0026] ②Stress damage accumulation In this type of failure, the software behavior conforms to expectations at the functional level, but it drives the hardware to continuously operate in specific modes of high load, high frequency, or high power consumption, subjecting the hardware to abnormal electrical or thermal stress for extended periods. This stress state accelerates the physical aging process of the hardware materials, thereby significantly shortening its lifespan and causing performance degradation or premature failure.

[0027] (3) Redundancy and shielding In integrated hardware and software systems, software is often designed to enhance the system's fault tolerance, specifically through redundant handling and dynamic masking of hardware errors. Software can use algorithm-level multiple backups or state reconstruction to replace or restore the function of a hardware unit when a fault is detected, thereby improving system reliability without relying on physical redundancy. Furthermore, software also has the ability to mask hardware input errors, concealing some underlying hardware anomalies and preventing them from propagating upwards to the system level. From the perspective of low-level logic implementation, this masking mechanism shares origins with the three typical masking effects in combinational logic circuits—logic masking, electrical masking, and time-windowing effects. Since the software in programmable logic devices (such as FPGAs / CPLDs) is essentially a functional implementation of combinational logic circuits, it also possesses characteristics such as logic masking and time-windowing effects, enabling it to suppress the impact of transient hardware errors on system behavior under specific conditions.

[0028] ① Logical shielding Logic shielding refers to the phenomenon in digital circuits where pulses propagating between logic gates are interfered with by the circuit shielding effect, preventing them from reaching the latch or main output. For example, if one input of an AND gate is low, it shields the high level of the other input.

[0029] ②Time window shielding When a transient propagates to a timing element (e.g., a latch), noise on the node may be outside the latch windows of all latches in subsequent combinational paths. Therefore, errors will not be latched, and soft errors will not occur; this is known as time-window masking.

[0030] S2. Establish the relationships between the performance parameters of the software and hardware systems, the performance parameters of the software subsystems, and the performance parameters of the hardware subsystems. Use the state cumulative analysis method to construct performance equations for quantitative analysis. This includes the following sub-steps: S21. Use FPMA to analyze the product's functionality, performance, and margins.

[0031] S22. Establish a GO diagram model, defining the operator graphs of the hardware subsystem as squares and the operator graphs of the software subsystem as circles. Based on FPMA analysis, select functional operators for each unit in the system, and connect the operators through signal flow to complete the GO diagram model construction for each performance parameter. The GO diagram is shown below. Figure 5 and Figure 6 As shown.

[0032] S23. Quantitative modeling using GO graphs to obtain performance equations: GO graphs are used to quantify the relationship between hardware and software, where the state probabilities of hardware sub-units are... This indicates that the state probability of a hardware sub-unit is represented by... This indicates that the process includes the following sub-steps: S231. Determine whether the unit belongs to a discrete degenerate unit or a continuous degenerate unit. If the unit is a discrete degenerate unit, proceed directly to step S233. If the unit is a continuous degenerate unit, proceed to step S232.

[0033] S232. Calculate the state probability of a continuously degenerate unit. The specific process is as follows: The performance parameter values ​​of the hardware sub-units of the continuously degrading unit are expressed as: ; in For the input signal value, For the output signal value, These are the performance parameters of components in analog circuits.

[0034] Simultaneously define the output signal value The margin is: .

[0035] State probabilities of continuously degenerate units satisfy: .

[0036] S233. Quantitative analysis is performed using the state cumulative analysis method. The specific formula for quantitative analysis using the state cumulative analysis method is as follows: .

[0037] S3. Establish a degradation model to calculate the state probabilities during the degradation process, specifically including the following sub-steps: S31. Based on the analyzed hardware failure mechanism, identify the analog circuits that are likely to degrade and the digital circuits that are likely to experience transient failures. Through circuit simulation or experiments, establish a margin model for the analog circuits. Or determine the transient failure rate of digital circuits. A hardware degradation injection model is constructed to characterize the state probabilities of units in the hardware subsystem during the degradation process.

[0038] Normal state probability of a unit in an analog circuit satisfy: ; Normal state probability of a digital circuit unit satisfy: Where i=1 represents the probability of the normal state.

[0039] S32. Based on the analyzed software failure mechanism, establish a software defect injection model to address the failure mechanism where defect triggering directly leads to system failure. , ; Defects in software probability of occurrence satisfy: ; in, For defects The probability distribution of the input space. Calculations based on historical software operation data: Assuming the software functional modules include... Group running data, in the first Under group running data, failure mode is triggered. The number of times Failure mode not triggered The number of times Then the failure mode Input space distribution probability satisfy: .

[0040] The software module includes Given a fault mechanism, the unit state probability of this module satisfies: .

[0041] S33. Based on the analyzed hardware and software failure mechanisms, establish a hardware and software interaction fault model, and calculate the state probability of the hardware and software system during the degradation process. The hardware interaction fault model is mainly divided into four types: degradation propagation error model, degradation triggering misjudgment model, transient error triggering model, and software defect induced model. This step specifically includes the following sub-steps: S331. Regarding degradation propagation errors, the degradation of analog circuits is continuous. If the analog circuit is the trigger source, due to its continuous degradation characteristics, when its performance degrades to a certain threshold, it enters the unexpected input space of the software, thereby triggering software failure. At this time, the initial condition for triggering is: ; in, The time when analog circuit degradation is used as a trigger condition. for The margin of the analog circuit is constantly monitored. When the margin of the analog circuit is zero, there is a probability of triggering a software fault. Depending on the type of margin, the margin... satisfy: ; in, Threshold for performance parameters; If the triggering source signal is used as a data signal in the software, it only affects the software's output data and has no impact on the software's logic or execution path. In this case, degraded data only propagates or amplifies within the software and does not trigger software failure; the system's failure time... satisfy ; in, This represents the new margin after analog circuit degradation propagates or is amplified in software. If analog circuit degradation only propagates in software and is not amplified by software, then... .

[0042] Assume the software module contains Each of the following is an independent failure mechanism, and the failure rates of each mechanism are as follows: The unit state probabilities of this hardware and software module satisfy: .

[0043] S332. Degradation triggering misjudgment: If the triggering source signal is used as a status signal or control signal in the software, it may trigger the software's logic or execution path, thereby directly changing the software's state and the system's failure time. satisfy: ; in The time it takes for hardware to trigger software failure. This refers to the time it takes for the software to fail under hardware triggering. Similarly, the initial triggering condition is: ; in, The time when analog circuit degradation is used as a trigger condition. for The margin of the analog circuit is constantly monitored. When the margin of the analog circuit is zero, it may trigger a software fault. Depending on the type of margin, the margin... satisfy: ; in, Assuming the software follows an exponential distribution and the performance parameters are thresholds, when the performance degradation of the analog circuit reaches a certain threshold, it may enter the software's unintended input space, at which point the software triggers a defect. The probability of failure increases. Assuming the failure rate of this failure mechanism is constant, its failure time satisfies: ; in, The failure rate of a new failure mechanism after a software subsystem is triggered. For defects The new input space probability distribution, considering the failure mechanism of software and hardware interaction, is given by the following probability distribution function: ; If the software module contains both independent software failure mechanisms and software-hardware interactive failure mechanisms... indivual, Failure Mechanism Failure rate, if If it is a software-independent failure mechanism, then Then the state probability of this hardware and software module satisfy: .

[0044] S333, Transient error triggering, assuming the probability of a transient fault occurring in the digital circuit is... When the initial triggering condition is a digital circuit, the triggering time satisfies: ; If the trigger source signal is used as a data signal in the software, it only affects the software's output data and has no impact on the software's logic or execution path. If the trigger source signal is used as a status signal or control signal in the software, its analysis method is similar to that of analog circuits, and the system's failure time... satisfy: ; in, The time it takes for hardware to trigger software failure. The time it takes for the software to fail under hardware triggering, satisfying the following: ; in, For defects The new input space probability distribution. Considering the hardware / software interaction failure mechanism, the probability distribution function is: ; If the software module contains both independent software failure mechanisms and software-hardware interactive failure mechanisms... indivual, Failure Mechanism Failure rate, if If it is a software-independent failure mechanism, then Then the state probability of this hardware and software module satisfy: ; S334. Software defects cause system failure. If the software execution fails or outputs a permanent error, it directly leads to system failure without interactive failure. If the trigger causes metastability in the output, it may trigger a hardware execution error, and the software trigger time may also be affected. satisfy: ; in For defects The probability of triggering failure; at this time, the hardware failure time after being triggered by software. satisfy: ; in After being triggered by software, the hardware The time margin is obtained using abnormal inputs from the software and circuit simulation modeling; the system failure time. satisfy: ; Then the state probability of this hardware and software module satisfy: ; If, in step S33, a software defect triggers and only causes transient errors such as metastability or glitches in the signal, shielding or redundancy will occur. In this case, the software failure rate is: ; in, This mechanism leads to the number of critical errors that cause system failure.

[0045] S4. Uncertainty Quantification Assessment: Determine whether there is uncertainty in the triggering time and the impact of the triggering.

[0046] Step S4 specifically includes the following steps: S41. Based on the state probabilities in the degradation process calculated in step S3, the degradation physical model of the analog circuit is fitted using the Wiener process.

[0047] By using performance parameter degradation data, performance parameters can be... Described using the Wiener process: in, The drift coefficient, The diffusion coefficient is... To follow a normal distribution Brownian motion, If the initial value is the value of the degradation process, then obey ; performance parameter margin satisfy: ; in, The threshold for the performance parameter, and These are the upper and lower thresholds for the performance parameters of the target device, respectively.

[0048] According to the state of the analog circuit in step S232, the following conditions are met. ; The above steps are used to assess the margin of the analog circuit in S33. The uncertainty is quantified.

[0049] S42. Based on the state probabilities in the degradation process calculated in step S3, the failure process of digital circuits or software is described using a Poisson process.

[0050] The uncertainty quantification methods for digital circuits and software are similar; the following discussion uses software as an example. Let... Let t be the cumulative number of software faults detected at time t. Then, the general form of the software defect triggering model is: ; If each software defect trigger leads to software failure, then the software state satisfies: ; This method can be used to quantify the uncertainties in the software and digital circuits of S33.

[0051] S43. Determine the probability that a software malfunction will cause incorrect software output. Using geometric distribution Quantification: ; in, The number of critical errors that cause system failure, and the time to failure of the software. satisfy: ; in, It follows a Poisson process.

[0052] In the specific implementation process, the uncertainty of software and hardware interaction can be summarized into two types: trigger time uncertainty and trigger impact uncertainty.

[0053] (1) Quantification of trigger time uncertainty ① Analog circuit degradation triggering Because both the initial state and degradation of devices are uncertain, the degradation physical model of analog circuits can be described by the Wiener process. Performance parameters It can be described as: ; in, The drift coefficient, The diffusion coefficient is... To follow a normal distribution Brownian motion, If the initial value is the value of the degradation process, then obey .

[0054] performance parameter margin satisfy: ; in, This is the threshold for the performance parameter.

[0055] As analog circuits degrade, the circuit margin gradually decreases. A value of 0 may trigger a software malfunction. Trigger time. satisfy: ; ② Software and Digital Circuits The timing of software defect triggering and transient fault occurrence in digital circuits also exhibit uncertainty, typically described using a Poisson process. The uncertainty quantification methods are similar; the following section uses software as an example. Let... Let t be the cumulative number of software faults detected at time t. Then, the general form of the software defect triggering model is: ; Therefore, the time interval between the two failure occurrence times Follows a negative exponential distribution: ; in This refers to the software failure rate. Assuming that a single software defect triggering a hardware failure, the trigger time is... satisfy: ; (2) Triggering the quantification of uncertainty In the process of hardware-triggered software failure, software faults may be masked by shielding and redundancy, thus not affecting the system. Therefore, the software failure time... satisfy: ; in The number of critical errors that cause system failure follows a geometric distribution. ,Right now ; in This represents the probability that a software malfunction will cause the software to output incorrectly.

[0056] S5. Reliability Assessment: Repeat steps S1-S4 using Monte Carlo simulation. If the digital circuit module and software module are outside of a fault state and the hardware module margin is greater than 0, the system is deemed reliable. This includes the following sub-steps: S51. Define simulation time points Monte Carlo sampling number num and number of reliable hardware and software systems sum = 0; S52. Select simulation time point ; S53. Extract the values ​​of uncertain parameters from S4, and use steps S2 and S3 to obtain the status of software, hardware and software-hardware interaction. S54. If the software, hardware, and software-hardware interaction are all in normal state, then sum = sum + 1; S55. Repeat S53 to S54 until the number of samples reaches num, at which point... The reliability is =sum / num; S56. Repeat S52 to S55 until the reliability calculation for all simulation time points is completed. Based on the calculation results, the hardware and software system is considered reliable when the digital circuit module and software module are outside the fault state and the hardware subsystem margin is greater than 0.

[0057] In a specific embodiment, the algorithm for evaluating the reliability of the software and hardware system is shown in Table 1.

[0058] Table 1. Algorithms for Reliability Assessment of Hardware and Software Systems The reliability of a software and hardware system hinges on the absence of destructive independent failures of software subsystems and hardware subsystems, as well as failures resulting from software-hardware interactions. Therefore, system failure time... satisfy: ; in, Indicates the time of failure due to software and hardware interaction malfunction. Indicates the independent failure time of a software subsystem. This indicates the independent failure time of the hardware subsystem. Specific Implementation In this embodiment, the input / output module of the civil aircraft's flight control system is responsible for signal interaction with external devices such as sensors and actuators, realizing functions such as control command output and device status acquisition. The normality of its communication directly affects the flight control system's monitoring and control of the aircraft. The functions of the flight control system's input / output module are implemented by both software and hardware. The hardware mainly includes amplifier circuits and rectifier circuits; the software mainly includes read / write modules, counting and timing modules, and signal control modules. Specifically, the reliability assessment method for the interaction between the electronic products' software and hardware in this embodiment of the civil aircraft includes the following steps: S1. Analyze the failure mechanisms of software and hardware. Based on the system structure, functions and historical information, identify the existing software, hardware and software-hardware interaction failure mechanisms.

[0060] S11. The hardware of the input / output module is a mixed-signal circuit, mainly composed of transceiver circuits, amplifier circuits, and comparator circuits. The transceiver circuits and comparator circuits are digital circuits, while the amplifier circuits are analog circuits. The operational amplifier in the analog circuit is the main component that experiences degradation.

[0061] S12. The software part of the input / output module is divided into three parts: read / write module, counting module, and signal control module. The main failure mode of the read / write module is tri-state bus contention; the main failure modes of the counting module signal are triggered metastability, clock domain cross-tab metastability, complex conditional logic and priority; the main failure modes of the signal control module are combinational logic loops, asynchronous processes and glitches.

[0062] S13. In this embodiment, the interaction mechanism of the input / output module is mainly due to hardware-triggered software failure and the software shielding effect. Based on the structural and functional analysis of the input / output module and its subsystems, it can be summarized into the following three types: ①According to S131, there is a degradation propagation error: the degradation of the input / output module hardware circuit is propagated or amplified in the software as a data signal; ②According to S132, there is a degradation triggering error: the degradation of the input / output module hardware circuit is used as a state or control signal to trigger software errors; ③According to S135, there is redundancy and masking: transient hardware failures of input / output modules are masked in the software.

[0063] S2. Establish the relationships between the performance parameters of the software and hardware systems, the performance parameters of the software subsystems, and the performance parameters of the hardware subsystems. Use the state cumulative analysis method to construct performance equations for quantitative analysis. This includes the following sub-steps: S21. Use FPMA to analyze the product's functionality, performance, and margins.

[0064] According to FPMA analysis, the key performance parameters of the input / output module system include two types: circuit output parameters and bus output parameters. Based on the functional principles or physical constraints of the product itself, the required values ​​for each relevant performance parameter are shown in Table 2.

[0065] Table 2 IOM Performance Analysis S22. Establish a GO diagram model and define the operator graph of the hardware subsystem as square and the operator graph of the software subsystem as circle. Based on FPMA analysis, select functional operators for each unit in the system one by one, and connect each operator through signal flow to complete the construction of the GO diagram model for each performance parameter.

[0066] Hardware performance model The hardware portion of the input / output module is a mixed-signal circuit, mainly composed of transceiver circuits, amplifier circuits, and comparator circuits. The transceiver circuits and comparator circuits are digital circuits, while the amplifier circuits are analog circuits. The core components are shown in Table 3.

[0067] Table 3 Core components of the input / output module hardware circuit ① Transceiver circuit The transceiver circuit mainly consists of a transceiver and a digital-to-analog converter. Its function is to convert the status signals input from the bus into analog signals for subsequent judgment.

[0068] According to the datasheet, digital-to-analog converter The output satisfies ; in The output is an 8-bit digital signal. , The reference voltage for this circuit is 10V. Therefore, the output of the digital-to-analog converter... The output range is 0~9.961V. Under normal operating conditions, the failure probability of the transceiver and digital-to-analog converter is extremely low, and its degradation is negligible. Therefore, the state probability of this output signal can be assumed. .

[0069] ②Amplifier circuit The amplifier circuit mainly consists of operational amplifiers and resistors. Its function is to amplify the signal output from the digital-to-analog converter for subsequent comparison.

[0070] The output V of the amplifier circuit AMout satisfy: ; Among them, V inThis is the input to the amplifier circuit.

[0071] ③ Comparison circuit The comparator circuit mainly consists of an operational amplifier, a NAND gate, semiconductor capacitors, and resistors. Its function is to compare the signal input from the bus with the signal input from the circuit.

[0072] In this circuit, the capacitors and resistors primarily function as low-pass filters. The operational amplifier acts as a comparator, and the NAND gate performs a logical comparison between the outputs of the two circuits. The degradation of the NAND gate is very slow and negligible; the circuit's state is mainly determined by the capacitors, resistors, and operational amplifier.

[0073] Based on the above, circuit models for the amplifier and comparator circuits are built using PSpice.

[0074] Simulation data was obtained from PSpice simulation analysis. Multiple linear regression and stepwise regression were performed on the data to determine the output V of the comparator circuit. U13out satisfy: Where V AN7 This is a comparison voltage signal input from outside the circuit. This is the inverting input of the operational amplifier in the comparator circuit. satisfy: in For the output of the amplifier circuit, This is the voltage at the non-inverting input of the operational amplifier in the amplifier circuit.

[0075] Operational amplifiers in circuits, under stress from factors such as temperature, humidity, and voltage, experience slow degradation of materials and structure over time, leading to performance deterioration and impacting system performance. Among the parameters most susceptible to this degradation, the input offset voltage is particularly vulnerable. Based on circuit analysis and PSpice simulations, the operational amplifier's input offset voltage... and The degradation of [the circuit] will affect the circuit switching condition. The switching condition becomes [the condition]. in and These are the input offset voltages of the operational amplifier in the comparator circuit and the operational amplifier in the amplifier circuit, respectively. Then, the flip-flop voltage error... satisfy: .

[0076] in, and These are the input offset voltages of the operational amplifier in the comparator circuit and the operational amplifier in the amplifier circuit, respectively.

[0077] Software performance model Based on the structural and functional analysis of the IOM software subsystem, functional operators were selected for each unit in the subsystem, and logical operators were selected according to the system's internal logic. All operators were then numbered. The operators selected for each unit are shown in Table 4.

[0078] Table 4 Operators for Input / Output Modules like Figure 3 and Figure 4 As shown, based on the system structure schematic diagram and the GO operators of each unit of the system, the GO graph model is constructed by connecting the operators through signal flow.

[0079] Hardware and software performance models Based on the structural and functional analysis of the input / output modules, functional operators were selected for each unit in the system, and logical operators were selected according to the system's internal logic. All operators were then numbered. The core subsystems for executing the input / output module functions were selected, and the operators selected for each unit are shown in Table 5.

[0080] Table 5 Operators for Input / Output Modules Based on the system architecture diagram and the GO operators of each unit in the system, the GO graph model is constructed by connecting the operators through signal flow, such as... Figure 5 and Figure 6 As shown.

[0081] S23. Quantitative modeling using GO graphs to obtain performance equations: GO graphs are used to quantify the relationship between hardware and software, where the state probabilities of hardware sub-units are... This indicates that the state probability of a software subunit is represented by... express.

[0082] according to Figure 3 The output GO diagram of the software subsystem circuit is established to determine the normal output of the software subsystem circuit. The performance model is as follows: in For unit The cumulative probability of the output signal's state. It is a software unit The state probability. Software unit Corresponding to the operator unit numbers in Table 4, Indicates the state of the unit. Indicates an advanced state. Indicates a normal state. This indicates a fault state, and its meaning in the formula below is similar.

[0083] according to Figure 4 Establish the normal output GO diagram of the software subsystem bus and build a normal output diagram of the software subsystem bus. The performance model is as follows: For hardware and software performance models, according to Figure 5 The output GO diagram of the hardware and software system circuit is established to determine the normal output of the hardware and software system circuit. The performance model is as follows: in For unit The cumulative probability of the output signal's state. or It is a software or hardware unit. The state probability of a unit. Corresponding to the operator unit numbers in Table 5, Indicates the state of the unit. Indicates an advanced state. Indicates a normal state. This indicates a fault state, and the same applies to the formulas below.

[0084] according to Figure 6 Establish the normal output GO diagram of the hardware and software system bus and build a normal output of the hardware and software system bus. The performance model is as follows: S3. Establish a degradation model to calculate the state probabilities during the degradation process.

[0085] S31, Hardware Subsystem Degradation Injection Based on existing experiments, the degradation V of the operational amplifier... io satisfy in, Kelvin temperature For time, in hours. Voltage error. For large parameters, its margin satisfies in, This is the threshold for the flip voltage error.

[0086] According to quantitative analysis methods, the probability of the output signal being in a normal state at this time is... satisfy: S32, Software Subsystem Defect Injection Based on the analysis of the working profile of the input / output module, the execution probabilities of each function of the software are determined as shown in Table 6.

[0087] Table 6. Functional execution probability of input / output modules Through analysis of the input / output module code and runtime profile, the input / output module mainly contains 6 failure modes. The input space distribution probability of each failure mode of the input / output module is shown in Table 7.

[0088] Table 7 Input Space Distribution Probability of Input / Output Module Failure Modes Based on the combined functional execution probability and input space distribution probability of the input / output modules, the occurrence probability of each fault mode of the input / output modules is determined as shown in Table 8.

[0089] Table 8. Probability of failure modes of input / output modules The correct output probability is the probability that a defect will not be triggered or that its triggering will not cause a failure. If the software defect triggering mechanism directly leads to software system errors, its failure rate satisfies... in The defect triggering probability is the signal triggering metastable state.

[0090] Therefore, the failure rate of the read / write module satisfies in For the first one in Table 8 Failure rate of each failure mode Operator units in Table 5 The failure rate is the same below. All of the above defects can be triggered and lead to system failure, and the triggering and development of each defect are independent of each other. For the counting module, this module has 3 failure modes, and its failure rate satisfies the following... Similarly, the failure rate of the signal control module satisfies... There is no redundant design in this system; therefore, the probability of premature states occurring in software or hardware units is low. Based on the above analysis, the probability of a successful output state of the circuit is: The probability of a successful state output by the bus is S33, Degradation Propagation Modeling Since transceivers generally do not degrade in practical use, the state probability of their output signals... .

[0091] ①Based on S331, establish a degradation propagation error model. As shown in the GO diagram model, in the bus output function, the output signal of the hardware circuit is input as a data signal into the software and then transmitted to the bus by the software. In this process, unexpected inputs from the circuit only affect the output data of the software, but have no impact on the software logic or execution path. Therefore, the failure time of the system triggering effect... satisfy Analysis of the software shows that the circuit degradation signal only propagates within the software and is not amplified by the software. ,Right now Combined with S31, bus output satisfy ②Based on S331, establish a degradation-triggered misjudgment model. In the circuit output function, the success probability of the circuit output satisfies: Degradation of the amplifier and rectifier circuits can lead to input signal errors in the signal control module. In other words, degradation of the amplifier and rectifier circuits allows the signal control module to enter a defective input space, making system defects more likely to occur and propagate. In this case, the failure time satisfies... in The probability of hardware triggering software failure. This represents the probability of software failure triggered by hardware. The time frame for hardware-triggered software failure satisfies... in This triggers a threshold. When performance degradation reaches this threshold, it may enter an unexpected input space where software combinational logic loops fail, thus triggering a software defect. And the probability of failure increases, then its failure time satisfies in This represents the new input space distribution probability of the defect "combinational logic loop failure". Through analysis and calculation, we can obtain... The probability distribution function considering the failure mechanism of software-hardware interaction is as follows: For the signal control module, there are two failure modes. Considering the hardware-software interaction failure mechanism, its failure rate becomes... Then consider the state probabilities of the software module due to hardware triggering effects. satisfy In the formula satisfy In summary, the circuit output It can be simplified to ③ Based on S33, establish a shielding or redundancy model. Signal-triggered metastability, clock-domain cross-tab metastability, asynchronous processes, and glitches generate transient errors. These error pulses may be "masked" by logic or "averaged" or "overwhelmed" by a large number of subsequent correct counts, thus not immediately manifesting as problems. Therefore, their failure rate is... in The defect triggering probability is the signal triggering metastability. Mechanism The number of critical trigger thresholds that could lead to system failure. Based on the analysis of the task profile and failure mechanism of the input / output modules, the number of critical trigger thresholds corresponding to each failure path is shown in Table 9.

[0092] Table 9 Number of critical trigger thresholds for input / output module failure paths S4. Uncertainty Quantification Assessment: Determine if there is uncertainty in the trigger time and trigger effect. Both the initial state and degradation of the device are uncertain, and its degradation physical model can be described by the Wiener process. Using the initial and degradation data of the operational amplifier, the degradation of the operational amplifier is calculated to follow a Wiener process: ; in, With a mean of 0 and a variance of It follows a normal distribution.

[0093] The timing of software defect triggering is also uncertain, and is typically described using a Poisson process. Software modules follow a Poisson process: .

[0094] S5. Reliability Assessment: Monte Carlo simulation is performed, repeating steps S1-S4. When the digital circuit module and software module are outside of a fault state and the hardware module margin is greater than 0, the system is considered reliable. In this embodiment, the reliability curves of the hardware and software system are calculated as follows: Figure 5 As shown.

[0095] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for assessing the reliability of software and hardware interaction in electronic products, characterized in that: It includes: S1. Analyze the failure mechanisms of software and hardware to obtain the failure mechanisms of software, hardware and software-hardware interaction; S2. Establish the relationship between the performance parameters of the software and hardware systems, the performance parameters of the software subsystems, and the performance parameters of the hardware subsystems. Use the state cumulative analysis method to construct performance equations for quantitative analysis. S3. Establish a degradation model to calculate the state probabilities during the degradation process, specifically: S31. Based on the failure mechanism of the hardware subsystem, construct a hardware degradation injection model to characterize the state probability of the unit degradation process in the hardware subsystem. S32. Based on the failure mechanism of the software subsystem, establish a software defect injection model to calculate the state probability during the unit defect triggering process in the software subsystem; S33. Based on the failure mechanism of software and hardware, establish a software-hardware interaction fault model, calculate the state probability of the software and hardware system during the degradation process. The software-hardware interaction fault model includes a degradation propagation error model, a degradation triggering misjudgment model, a transient error triggering model, and a software defect induction model, specifically: S331. Construct a degradation propagation error model to calculate the probability of a unit in the software and hardware system being in a normal state when a degradation propagation error occurs. : ； in, This is the new margin after analog circuit degradation propagates or amplifies in software; The unit representing a software subsystem includes An independent fault mechanism; Let f(i) be the failure rate of the i-th independent failure mechanism of the software subsystem. S332. Construct a degradation-triggered misjudgment model to calculate the probability of a unit in the software and hardware system being in a normal state when a degradation-triggered misjudgment occurs: ； in, This represents the total number of software-independent failure mechanisms and software-hardware interactive failure mechanisms. Failure Mechanism Failure rate; S333. Construct a transient error triggering model to calculate the probability of a unit in the hardware and software system being in normal state when a transient error is triggered: ； S334. Construct a software defect induction model to calculate the probability of a unit in the software and hardware system being in a normal state when a software defect is induced: ； in, Hardware triggered by software Ample time; S4. Uncertainty Quantification Assessment: Determine whether there is uncertainty in the triggering time and triggering impact; S5. Reliability assessment: When the digital circuit module and software module are not in a fault state and the hardware subsystem margin is greater than 0, the hardware and software system is determined to be reliable.

2. The reliable assessment method for software and hardware interaction of electronic products according to claim 1, characterized in that: Step S2 specifically includes the following sub-steps: S21. Use FPMA to analyze the functionality, performance, and margins of the software and hardware subsystems; S22. Establish a GO diagram model and define the operator graph of the hardware subsystem as a square and the operator graph of the software subsystem as a circle. Based on FPMA analysis, select functional operators for each unit in the software subsystem and hardware subsystem, and connect each functional operator through signal flow to complete the construction of the GO diagram model of the performance parameters of the software and hardware systems, the performance parameters of the software subsystem, and the performance parameters of the hardware subsystem. S23. Quantitative modeling using GO graphs to obtain performance equations: GO graphs are used to quantify the relationships between performance parameters of the software and hardware systems, performance parameters of the software subsystems, and performance parameters of the hardware subsystems. The state probabilities of units within the hardware subsystems are used... The state probability of a unit in a software subsystem is represented by... Indicates; specifically: S231. Determine whether the unit belongs to a discrete degenerate unit or a continuous degenerate unit. If the unit is a discrete degenerate unit, proceed directly to step S233. If the unit is a continuous degenerate unit, proceed to step S232. S232. Calculate the state probability of a continuously degenerate unit. The specific process is as follows: The output signal value of the performance parameter of the continuously degraded unit is expressed as: ； in, For the input signal value, For the output signal value, These are the performance parameters of components in an analog circuit; Define output signal value margin for: ； in, For performance parameters The threshold, and These are the upper and lower thresholds for the performance parameters of the target; the state probability of a continuously degenerate unit. satisfy: ； S233. The cumulative state probability is obtained by quantitative analysis using the state cumulative analysis method.

3. The reliable assessment method for software and hardware interaction of electronic products according to claim 1, characterized in that: In step S32, the fault mechanism that directly leads to system failure after a software defect is triggered is as follows: , ; in Defects in software subsystems The probability of occurrence is calculated using the following formula: ； in, For defects The probability distribution of the input space; The execution probability of a software subsystem unit; For example, a unit of a software subsystem contains Given a fault mechanism, the probability of the normal state of the unit is... satisfy: ； defect Input space distribution probability Calculations based on historical software operation data: Assuming the software functional modules include... Group running data, in the first Under group running data, failure mode is triggered. The number of times Failure mode not triggered The number of times Then the failure mode Input space distribution probability satisfy: 。 4. The reliable assessment method for software and hardware interaction of electronic products according to claim 1, characterized in that: In step S331, if the analog circuit is the trigger source, due to the continuous degradation characteristic of the analog circuit, when the performance of the analog circuit degrades to a certain threshold, it enters the unexpected input space of the software, thereby triggering the software failure. The initial condition for triggering at this time is: ； in, The time when analog circuit degradation is used as a trigger condition. for The margin of the analog circuit is constantly monitored. When the margin of the analog circuit is zero, there is a probability of triggering a software fault. Depending on the type of margin, the margin... satisfy: ； in, The threshold for the performance parameter, and These are the upper and lower thresholds for the performance parameters of the target device, respectively. for Performance parameters at any given time; If the trigger source signal is used as a data signal in the software, it only affects the software's output data and has no impact on the software's logic or execution path. In this case, the degraded data only propagates or amplifies within the software and does not trigger software failure. The failure time of the hardware and software system is thus determined. satisfy: ； in, This represents the new margin after analog circuit degradation propagates or is amplified in software; if analog circuit degradation only propagates in software and is not amplified by software, then... ; for The margin of the analog circuit at all times; In step S332, if the trigger source signal is used as a status signal or control signal in the software, there is a probability that it will trigger the software's logic or execution path, thus affecting the failure time of the hardware and software system. satisfy: ； in, The time it takes for hardware to trigger software failure. This refers to the time when the software fails under hardware triggering; the initial triggering condition is: ； in, The time when analog circuit degradation is used as a trigger condition. for The margin of the analog circuit at all times, the time when software fails under hardware triggering. satisfy: ； in, The failure rate of a new failure mechanism after a software subsystem is triggered. For defects The new input space probability distribution, considering the failure mechanism of software and hardware interaction, is given by the following probability distribution function: ； In step S333, it is assumed that the probability of a momentary fault occurring in the digital circuit is... If the initial triggering condition is a digital circuit, then the triggering time is... satisfy: ； If the trigger source signal is used as a status signal or control signal in the software, the system's failure time... satisfy: ； in, The time it takes for hardware to trigger software failure. The time it takes for the software to fail under hardware triggering, satisfying the following: ； in, The failure rate of a new failure mechanism after a software subsystem is triggered. For defects The new input space probability distribution, considering the failure mechanism of software and hardware interaction, is given by the following probability distribution function: ； If there is a software defect in step S334 If a trigger causes the software to malfunction or output a permanent error, it will directly lead to system failure, without any interactive failures; if there is a software defect... If a trigger causes metastability in the output, there is a probability of triggering a hardware execution error, and the software trigger time... satisfy: ； in, For defects The probability of triggering failure; at this time, the hardware failure time after being triggered by software. satisfy: ； in, After being triggered by software, the hardware The time margin is obtained using abnormal inputs from the software and circuit simulation modeling; the system failure time. satisfy: 。 5. The reliable assessment method for software and hardware interaction of electronic products according to claim 1, characterized in that: Step S5 specifically includes the following sub-steps: S51. Define simulation time points Monte Carlo sampling number num and number of reliable hardware and software systems sum = 0; S52. Select simulation time point ; S53. Extract the values ​​of uncertain parameters from step S4, and use steps S2 and S3 to obtain the status of software, hardware and software-hardware interaction. S54. If the software, hardware, and software-hardware interaction are all in normal state, then sum = sum + 1; S55. Repeat steps S53 to S54 until the number of samples reaches num. At this point, the time point is... The reliability is =sum / num; S56. Repeat steps S52 to S55 until the reliability calculations for all simulation time points are completed.

6. The method for assessing the reliability of software and hardware interaction in electronic products according to claim 1, characterized in that: If only a transient signal error occurs after the software defect is triggered in step S33, shielding or redundancy will occur, and the software failure rate will be reduced. for: ； in, This mechanism leads to the number of critical errors that cause system failure. Let be the probability of defect i occurring in the software subsystem.

7. The reliable assessment method for software and hardware interaction of electronic products according to claim 1, characterized in that: In step S31, a margin model of the analog circuit is established through circuit simulation or experimentation. Or determine the transient failure rate of digital circuits. A hardware degradation injection model is constructed to characterize the state probabilities of units in the hardware subsystem during the degradation process; Normal state probability of a unit in an analog circuit satisfy: ； Normal state probability of a digital circuit unit satisfy: 。 8. The method for assessing the reliability of software and hardware interaction in electronic products according to claim 1, characterized in that: Step S1, based on the system structure, function, and historical information, yields the failure mechanisms of software, hardware, and software-hardware interaction, specifically including the following steps: S11. Analyze the hardware failure mechanism and determine whether the hardware has structural damage failure or performance degradation failure. S12. Analyze the software failure mechanism and determine the possible failure modes and mechanisms of the software failure. S13. Analyze the failure mechanisms of hardware and software, and determine whether there are hardware driver software faults, software defects that induce hardware damage, or redundancy and shielding failure mechanisms.

9. The reliable assessment method for software and hardware interaction of electronic products according to claim 1, characterized in that: Step S4 Specifically, the following steps are included: S41. Based on the state probabilities in the degradation process calculated in step S3, the degradation physical model of the analog circuit is fitted using the Wiener process. S42. Based on the state probabilities in the degradation process calculated in step S3, use the Poisson process to describe the failure process of digital circuits or software. S43. Determine the probability that a software malfunction will cause incorrect software output. Using geometric distribution Quantification: ； in, The number of critical errors that would cause system failure, at which point the software state satisfies: ； in, It follows a Poisson process.

10. The method for assessing the reliability of software and hardware interaction in electronic products according to claim 2, characterized in that: The specific formula for quantitative analysis using the state accumulation analysis method in step S233 is as follows: 。

Images