Software reliability demand confirmation method based on actual combat scene analysis

Abstract

The invention provides a software equipment reliability demand confirmation method based on actual combat scene analysis. The method comprises the following steps: firstly, establishing an actual combat scene; according to the state machine model of the software task behavior, demand integrity is confirmed; secondly, actual combat scene simulation is carried out, and combat capability demand consistency of factors such as a detection range and a firepower range of a simulation entity is confirmed; in actual combat scene simulation, the reliability requirement of the software cross-linking interface is effectively confirmed; and finally, combining actual tasks to extract influence factors such as faults and interference in an actual scene, dividing value levels of actual scene factors, carrying out full combination and orthogonal combination, calculating an overall risk of each operation classification, carrying out combination sorting to form a new software reliability requirement, and comparing the new software reliability requirement with a clear software requirement in a software requirement specification. And determining whether the software reliability requirement is fully complete or not, and combining an actual test result and a simulation result to determine whether the clear software requirement in the requirement specification and the analyzed implicit software requirement are both effectively realized or not.

Description

Technical Field

[0001] The present invention relates to the technical field of software engineering, and in particular to a method for confirming software reliability requirements based on actual combat scenario analysis. Background Art

[0002] Software equipment refers to equipment that is purely software developed or mainly developed with software. For example, combat command information systems, intelligence reconnaissance information systems, etc., usually have complex command and coordination relationships, many external hinges, and detailed system characteristics. Verification and validation are widely recognized quality assurance methods and means. Verification refers to checking whether the software has correctly absorbed the system functions and characteristics defined in the product specification, and mainly answers whether the software is correctly implemented; validation is to verify the logical correctness of the software in a given external environment during or at the end of the software development process to confirm whether it is consistent with the software requirements, and mainly answers whether the correct software is implemented. Software confirmation focuses on whether the original needs of the user are met, and is result-oriented; software verification focuses on whether the software requirements are met, and is process-oriented. Software reliability requirement confirmation is to confirm the ability of software reliability to meet the expected use of the troops. On the one hand, it is necessary to verify the existing clear requirements, and on the other hand, it is necessary to confirm the requirements that users expect but have not clearly stated.

[0003] At present, software reliability requirements are mainly the reliability requirements of combat missions described under normal circumstances, and lack consideration of actual combat environment factors and system interaction factors.

[0004] At present, the research on software reliability is mainly focused on testing and verification, and there is no complete method for software reliability confirmation. This project proposes a systematic software reliability confirmation method for software reliability requirements, software fault tolerance, software code failure risk, and software reliability indicators. In the actual combat scenario model, the correlation analysis of multiple factors is carried out to extract the task sequence under the influence of internal and external environment cross-linking. Through testing, it is confirmed whether the expected tasks can be completed in the actual combat environment. At the same time, the integrity and consistency of the software reliability requirements are confirmed in the actual combat scenario model.

[0005] Currently, there is still a lack of effective software reliability requirement confirmation technology in verification and validation. At present, there is still a lack of effective software reliability requirement confirmation technology in equipment test software. There are a series of problems in the development process, such as incomplete, inaccurate, and unclear reliability requirements. There is a lack of a unified software reliability requirement specification system, and the description of software reliability requirements is not unified, resulting in the software verified according to the existing requirements still being a certain distance away from actual combat use. This problem can be solved by studying software reliability requirement confirmation technology based on actual combat scenarios. It is necessary to combine actual combat scenarios, extract complete requirements in actual combat scenarios as the basis for confirmation, and then verify the confirmed requirements, so as to ensure the completeness, consistency, rationality and effectiveness of the requirements. Summary of the invention

[0006] In view of the problems existing in the prior art, this application proposes a method for confirming software equipment reliability requirements based on actual combat scenario analysis, including:

[0007] Software equipment combat scenario modeling, analyzing the elements in the combat scenario of informationized equipment, and integrating the external situation environment, its own combat mission, and internal system interaction to establish a visual system combat scenario model. The combat scenario model can be saved in the form of a formalized XML document;

[0008] Confirm the completeness of the software task behavior requirements to confirm whether they include all the conditions and conditions that can trigger the output; these conditions represent the assumptions about the environment in which the program or system runs; in addition to the output and trigger events, each state machine should also confirm the following states, input and output variables, the relationship between the trigger condition and the corresponding output, and state transitions;

[0009] Conduct combat simulations to confirm the consistency of user requirements; requirement consistency refers to the correspondence between the three levels of requirements for combat, equipment and technology, and the mutual support and consistency between the requirements, without shortcomings, omissions, conflicts and deviations, and can be effectively integrated. Requirements consistency verification refers to analyzing whether different requirements elements can support and match each other. The requirements consistency verification method is closely related to the requirements description method, and can judge the conflicts between the requirements elements represented by multiple views and the adequacy of many-to-one support.

[0010] Confirm the validity of the reliability requirements of the software cross-linking interface. The effectiveness calculation model is used to process the impact effect of the weapons controlled by the software equipment after firing. When the weapon system fires, the dropped bombs or fired shells will explode at a certain landing point. For non-precision guided weapons, the trajectory of the shells after the strike is ignored, and the weapon effectiveness calculation model is used to calculate the actual explosion point of the shells, and the firing result message is fed back as the result of the completion of a single firing event;

[0011] Combination analysis of actual combat scenario factors and confirmation of software reliability requirements. Confirmation of software reliability requirements is to confirm the ability of software reliability to meet the expected use of troops. On the one hand, it is necessary to verify the existing clear requirements, and on the other hand, it is necessary to confirm the user's expected but not clearly stated requirements. Starting from the actual combat scenario, by combining and correlating the elements in the scenario, the various actual combat scenarios and abnormal situations faced by the software are analyzed, the software reliability requirements are extracted, and then compared and analyzed with the clear requirements, and all software reliability requirements are confirmed through simulation test verification.

[0012] Furthermore, the actual combat scenario modeling of the software equipment includes:

[0013] Battlefield environment modeling, based on the military geographic information system, includes functions such as electronic chart loading, battlefield environment setting, force organization and deployment, and path planning;

[0014] Cross-linking relationship modeling is used to analyze how the detection and perception devices and action control devices that interact with the software equipment interact with each other and the possible faults that may occur within the software system. The cross-linking interface model is represented by the following relationship:

[0015] R = {DUT, peripheral cross-linking device set, input-output relationship, interface type, interface data, fault information};

[0016] Task behavior modeling analyzes the combat mission scenarios faced by software equipment, clarifies the task execution sequence, software composition and actual combat environment constraints, clarifies the situation, environment, tasks, operations, data and other factors in the actual combat scenario, and establishes a means of describing system behavior based on state machine theory.

[0017] Furthermore, battlefield environment modeling specifically includes:

[0018] Situation definition performs entity creation, communication network setting, and route setting operations according to user editing instructions, and operates blackboard data to rewrite blackboard status; battlefield environment setting uses a visual way to view, edit, and apply information such as the geographical environment and meteorological environment in which the battle is located, supports the hierarchical display function of nautical charts, and can control the display and hiding of nautical chart annotation layers;

[0019] Perform initial action settings, set the combat objectives and intentions of the party to which you belong, and provide settings for the initial action status of the troops, such as the initial heading, speed, and route. Route settings mainly add navigation routes to the troops, support editing routes by continuously selecting points on the map, and support manual adjustment or deletion of individual selected points.

[0020] Confrontation rule setting: From the perspective of system confrontation, it provides qualitative and quantitative setting functions for different types of confrontation rules such as radar confrontation, electronic confrontation, communication confrontation, firepower strike, weapon confrontation, and damage effect, so as to achieve the effect of adjusting the overall combat capability of the equipment system by setting combat rules;

[0021] Combat mission binding supports binding of the combat missions of troops with combat routes, combat areas, etc. added in the assumed situation, to achieve coupling between combat missions and situation elements.

[0022] Furthermore, the specific steps of modeling are:

[0023] Describe in graphical form which peripheral cross-linking devices the device under test has a communication relationship with, and identify the names of the cross-linking devices;

[0024] Describe the input and output relationship between the DUT and the peripheral cross-linking equipment in the form of connecting lines, and identify the interface type between the DUT and the peripheral cross-linking equipment. Common interface types of the DUT include: RS232, RS422, RS485, CAN bus, and Ethernet;

[0025] For each connection line, set the interface data corresponding to each input and output, and open the data property window; display the variables contained in it through the data list and tree diagram; the data list displays the basic information of the data including: name, data type, cycle, transmission type, and the user can open the data configuration window by double-clicking the data; display all the information of the variable according to the category page, and display all the properties of the data in three pages of "General", "Protocol", and "Element" and configure them; the properties of the variable displayed in a reasonable layout in the "General" page include: variable name, transmission type, transmission cycle, data type, initial value, description information, and whether to use the data source; the configuration information of the corresponding IO connection is displayed in the "Protocol" page; the "Element" page is used to display the attribute information of elements and bit segments, and the "Element" list displays the element name, element data type, data length, element type, initial value, and description information. The bit segment list displays the name, start bit and end bit, initial value, and description information of the bit segment; select the element corresponding to the bit segment list through the focus position of the element list;

[0026] Interface fault settings can set data packet loss, communication bit jump, communication cycle too long, communication cycle too short, communication cycle random change, interface synchronization exception, field data synchronization exception, communication feedback delay, communication feedback in advance, feedback loss, condition combination constraint exception, interaction timing exception, transmission rate random change, transmission rate mismatch, incomplete message data, redundant message data, field value exceeds the lower boundary, field value exceeds the upper boundary, field value error value, field precision error, field type error fault information.

[0027] Furthermore, the state diagram is used to describe the task behavior, including:

[0028] Task element: is a state node, which automatically has a start state and an end state in each model diagram; the state is divided into a simple state and a combined state, and the combined state can be divided into an OR state and an AND state, and there is also a pseudo-state representing an abstract state; pseudo-state: a special abstract state, the initial state is a pseudo-state, which represents the starting point of the state diagram, represented by a solid circle, and represents the default entry state in the combined state; the end state is also a pseudo-state, represented by a solid circle nested inside a circle, representing the end of the state; simple state, a state without nested states, that is, without hierarchy , combined and concurrent states; combined state: refers to a state in which several states are nested, so a hierarchical relationship appears in the state diagram. The state in which other states are nested is called a super state, and the nested state is called a sub state; the nested state can be a simple state, a combined state or a pseudo state; the combined state is divided into two types: concurrent state and mutually exclusive OR state; double-clicking a state can expand the state structure and edit the internal structure of the state. After the state is expanded, it comes with two default nodes, [Start State] and [End State], which cannot be edited. All sub states in the state start at [Start State] and end at [End State];

[0029] Transition element: Transition is a collection of operations, and migration consists of sequential operations. State transition is represented by a solid arrow with parameters, which is used to connect two different states. The tail of the arrow indicates the source state, and the arrow indicates the target state. When a transition occurs, the state that the transition enters is called the active state, and when the transition leaves a state, this state becomes the inactive state.

[0030] The syntax of migration is: Event[guard condition] / action

[0031] An event is a description of an observable occurrence. Event types include entry, exit, time, call, signal, change, and defer. If there is no event that triggers a transition on a migration, it means that the transition is automatically executed. A guard condition is a condition that must be met to trigger a migration. When the corresponding event is distributed, the value of this expression is calculated. If the expression value is true, the migration is triggered. An action is a set of executable statements or calculation processes that call an operation. Actions are atomic and cannot be interrupted. Therefore, the above migration syntax expression can be understood as, when an event occurs and guard condition == true, the action occurs.

[0032] Migrations can be divided into several types:

[0033] Self-migration, the source state and the target state are the same state, and the entry action and exit action of the state will be called;

[0034] Internal migration, the internal activity of the corresponding state, but the state does not change;

[0035] Completed transition, which is automatically triggered when the action in this state is completed;

[0036] Compound migration is formed by combining simple migrations through branches, decision branches, etc.

[0037] Operation element: The lowest level unit. Each operation consists of preconditions, execution process and postconditions.

[0038] Furthermore, the completeness confirmation of software task behavior requirements includes:

[0039] Mission status integrity requirement confirmation: the system transitions from normal operation to abnormal operation often accompanied by accidents; especially when computers are used, many accidents and failures are caused by inadequate software processing during the startup process and the transition between normal processing and different types of shutdowns; therefore, the startup integrity requirements must be met when the software is started. Mission status integrity requirement confirmation is mainly based on the following columns in Table 24;

[0040] Confirm the integrity of task input and output variables. Input and output represent the information provided by the sensor to the software and the commands sent by the software to the brake. These input and output variables must be strictly defined in the document. In the black box boundary, only "time" and "value" can be observed by the software. Trigger events and outputs must be positioned as and can only be defined as "constraints" or observable "events", "conditions" "values" or "time". Events include program inputs, previous program outputs, program startups, and hardware-related events such as power outage interrupts. Conditions can be expressed as hardware-related attribute values ​​that can be obtained by the software, such as time period clocks and transfer switches. Confirm the integrity requirements of input and output variables according to Table 25.

[0041] Confirmation of the trigger event integrity requirement: a reliable system should be able to detect the deviation of the system from the unexpected input and respond appropriately; it can be seen that the reliability of the software depends on the integrity of the environmental assumptions, that is, there should be no events in the environment that are unobservable by the software and lead to uncertain behavior of the program. These events must be monitored by the software in the form of trigger events. Therefore, the integrity of the environmental assumptions is linked to the integrity of the trigger events and the computer's response to any potential input. In the process of confirming the trigger events, the following categories of integrity requirements should be considered: robustness requirements, determinism requirements, basic timing and value assumption integrity, overload requirements, and dangerous command requirements; among them, a dangerous command is a command that can be internal to the software or an external interface to the hardware or operator. Its unintentional, out-of-sequence or incorrect execution may lead to some identified, critical or catastrophic danger, or its execution may reduce the control of the danger;

[0042] Output event integrity requirements confirmation: Like trigger events, the complete description of output event behavior also needs to consider the value and timing of output events;

[0043] Output and trigger event relationship integrity requirements acknowledge that some requirements are not related to inputs or outputs alone, but to the relationship between inputs and outputs; although usually this relationship is based on specific control functions, such as feedback and stability requirements; Responsiveness and spontaneity involve actual behavior and how the process reacts to the controller's output; basic control models rely on feedback to provide information about changes in the controlled variable and state changes caused by disturbances in the control process;

[0044] The state transition relationship integrity requirement confirmation should not only check the trigger events, output events and the relationship between each state, but also check the paths between different states; these paths can be expressed as a sequence of trigger events; the transitions between different modes are very dangerous and are particularly sensitive to incomplete requirements and should be carefully checked.

[0045] Furthermore, the user requirements consistency confirmation specifically includes:

[0046] Combat scenario analysis: Analyze the combat scenario file to obtain the force configuration information, initial environment settings, and simulation exit conditions. After the scenario analysis is completed, the entity type and quantity obtained by the analysis, as well as the mapping relationship between the entity and the model, are used to schedule the model.

[0047] Actual combat simulation, loading simulation models, the runtime object management establishes runtime objects in memory, and initializes the relationships between various runtime object models; according to the description of the actual combat scenario file, the platform entity model objects and various communication equipment, sensor equipment, weapon systems, ammunition and other model objects constitute deployment relationships or other relationships, the runtime object management module is responsible for establishing and maintaining these relationships;

[0048] Confirmation of consistency of capability requirements;

[0049] Confirmation of the rationality of weapon control damage effectiveness.

[0050] Furthermore, the consistency confirmation of capability requirements specifically includes:

[0051] First, the consistency of the path planning capability of the combat area is confirmed. The combat area is displayed in a circular, sectoral, polygonal and other visual forms in the simulation, including patrol areas, assault areas, warning areas, and search sea areas. It is mainly used to control the visibility of the tracks or paths of different combat entities, including combat paths such as track points, tracking lines, planned routes, and historical tracks. According to the simulation results, the path planning that can be set is compared with the actual requirements to confirm whether they are consistent.

[0052] Then, the consistency of combat capability is confirmed. Combat capability includes the detection range and firepower range of the simulated entity and other elements. The detection range of each combat entity and the various types of sensors carried by it is displayed in the simulation, including the detection search distance, tracking distance or reconnaissance distance of different types of radars. The firepower range of each combat entity and the various types of weapons carried by it is displayed, including the effective range and maximum range of missiles. Visual simulation and display of engagement relationships, visualization of target allocation and firepower allocation, etc., can flexibly control the visibility of elements, and display them through firepower strike lines, signs, etc.; combat mission simulation is realized in the form of finite state machines, supporting the viewing of the tactics status and state transition process of any combat entity; based on the visually displayed combat capability results, confirm whether the software equipment's control capabilities for sensors and weapons are consistent with actual requirements;

[0053] Finally, the consistency of electromagnetic influence and communication relationship is confirmed; the target electromagnetic characteristics are combined with the target RCS database and the classical statistical model, and the classical statistical model or the target RCS database is selected; when the target RCS feature database is used, it is necessary to associate it with the target posture information, and use different relative posture information to obtain the RCS corresponding to the target; the index parameters of electronic equipment such as integrated communications and spatial geographic information data as well as meteorological and hydrological data are used to accurately analyze and simulate the multipath interference, waveguide propagation and actual composite propagation of the transceiver channel, and simulate the wireless channel characteristics of electromagnetic wave propagation; the current prediction models for radio wave propagation in complex environments can be generally divided into three categories: empirical models, deterministic models and semi-empirical and semi-deterministic models; Calculate the spatial power coverage of the radiation source; power coverage calculation is to analyze the power radiation of the radiation source after loading the antenna pattern; the advanced electromagnetic propagation algorithm is sampled in the calculation, which can fully consider the influence of terrain and meteorological environment on electromagnetic wave propagation and the influence of antenna pattern on electromagnetic waves; power coverage calculation can calculate the power radiation of electronic equipment in profile, cross section and sphere; after the calculation is completed, the result is displayed in a three-dimensional scene in a graphical way, and the power is distinguished by color, from red to blue to indicate the attenuation of intensity; according to the electromagnetic signal simulation, the communication range of each combat entity and the various types of communication equipment carried are displayed, and the communication link status between the force entities is displayed to confirm whether the electromagnetic impact and communication relationship are consistent with the actual required capabilities.

[0054] Furthermore, the rationality of weapon control damage effectiveness confirmation specifically includes:

[0055] The effectiveness calculation model is used to process the impact effect of weapons controlled by software equipment after firing. When the weapon system fires, the dropped bombs or fired shells will explode at a certain landing point. For non-precision guided weapons, the trajectory of the shells after the strike is ignored, and the weapon effectiveness calculation model is used to calculate the actual explosion point of the shells, and at the same time, the firing result message is fed back as the result of the completion of a single firing event.

[0056] Based on the destructive effects that can be achieved by the weapons controlled by the software equipment, confirm whether the software equipment's ability to control the destructive effectiveness of the weapons is consistent with the requirements.

[0057] Further, including:

[0058] The actual attack distance of the weapon firing is calculated, and the weapon hit probability is related to the attack distance length; the weapon hit probability function is defined, which stipulates the relationship between the weapon hit rate and the attack distance.

[0059] According to the current attack hit rate, a hit result is generated to determine whether it is a hit. If it is judged to be a hit, the explosion point is within the specific hit area; if it is judged to be a miss, the explosion point is outside the specific hit area;

[0060] According to the hit result, the explosion point position is randomly calculated and the explosion point position information is output;

[0061] After the weapon explodes, an explosion message is generated. According to the type of explosive weapon and ammunition, a certain area of ​​damage is formed with the explosion point as the center. After receiving the message, all units are checked to see if they are within the damage range, and the damage degree is calculated for the units within the damage range.

[0062] The damage model calculates the damage contribution of the explosion to the unit based on parameters such as the ammunition damage factor, the distance from the unit to the explosion center, and the thickness of the unit's own armor. The damage degree of the affected entity components within a certain range is calculated separately, and the overall damage suffered by the entity is the sum of the damage suffered by all components of the entity, which is obtained by accumulating the damage degrees of all components.

[0063] The damage level of this attack will be calculated and merged with the original damage level of the unit, and the damage level of the unit after this explosion will be updated; based on the overall damage level of the current unit entity, the current status will be recorded as normal, slightly injured, or seriously injured; when the damage to the entity exceeds a certain level, the entity will be destroyed and its entity will be deleted.

[0064] The software reliability requirement confirmation method based on actual combat scenario analysis provided by the present invention has the following beneficial effects compared with the prior art:

[0065] On the one hand, the present invention can verify existing clear requirements, and on the other hand, it can assist users in analyzing expected but not explicitly stated requirements based on actual combat scenarios, and confirm them from multiple angles such as completeness, rationality, consistency and effectiveness, to ensure that the implemented software reliability requirements meet user expectations and actual combat scenarios, thereby improving the equipment's actual combat capability. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Figure 1 It is a schematic diagram of the input relationship between the tested device and the peripheral cross-linking equipment of the present invention;

[0067] Figure 2 It is a configuration view of the model edge of the present invention;

[0068] Figure 3 It is the basic structure of the state diagram of the present invention;

[0069] Figure 4 A schematic diagram for modeling the task behavior of the present invention;

[0070] Figure 5 The integrity constraint of the software task behavior model of the present invention;

[0071] Figure 6 This is a technical solution for confirming software reliability requirements based on actual combat scenarios. DETAILED DESCRIPTION

[0072] In order to enable those skilled in the art to better understand the technical solution of the present invention, the present invention is further described below in conjunction with the accompanying drawings and specific implementation methods.

[0073] This application proposes a software reliability requirement confirmation method based on actual combat scenario analysis, which includes:

[0074] The first step is to model the actual combat scenario of software equipment

[0075] Analyze the elements in the actual combat scenario of informationized equipment, and integrate and establish a visual system actual combat scenario model from three aspects: external situation environment, own combat mission, and internal system interaction. The actual combat scenario model can be saved in the form of formalized XML document.

[0076] (1) Battlefield environment modeling

[0077] 1) Based on the military geographic information system, it supports electronic chart loading, battlefield environment setting, force organization and deployment, and path planning. Situation definition performs entity creation, communication network setting, route setting and other operations according to user editing instructions. It mainly operates blackboard data to rewrite the blackboard status. The battlefield environment setting uses a visual way to view, edit, and apply information such as the geographical environment and meteorological environment in which the operation is located. It supports the layered display function of the chart and can control the display and hiding of the chart annotation layer.

[0078] 2) Perform initial action settings, set the combat objectives and intentions of the party, and provide settings for the initial action status of the troops, such as the initial heading, speed, and route. Route settings mainly add navigation routes to the troops, support editing routes by continuously selecting points on the map, and support manual adjustment or deletion of individual selected points.

[0079] 3) Confrontation rule setting: From the perspective of system confrontation, it provides qualitative and quantitative setting functions for different types of confrontation rules such as radar confrontation, electronic confrontation, communication confrontation, firepower strike, weapon confrontation, and damage effect, so as to achieve the effect of adjusting the overall combat capability of the equipment system by setting combat rules.

[0080] 4) Combat mission binding: supports binding the combat mission of troops with the combat routes, combat areas, etc. added in the assumed situation, so as to realize the coupling correlation between combat missions and situation elements.

[0081] (2) Cross-link relationship modeling

[0082] The cross-linking environment mainly analyzes how the detection and perception devices and action control devices that interact with the software equipment interact with each other and possible faults that may occur within the software system;

[0083] The cross-link interface model is represented by the following relationship:

[0084] R = {DUT, peripheral cross-linking device set, input-output relationship, interface type, interface data, fault information}

[0085] The specific steps of modeling are:

[0086] 1) Describe in graphical form which peripheral cross-linking devices the device under test has a communication relationship with, and identify the names of the cross-linking devices;

[0087] 2)Reference Figure 1 , describe the input and output relationship between the DUT and the peripheral cross-linking equipment in the form of connecting lines, and identify the interface type between the DUT and the peripheral cross-linking equipment. Common interface types of the DUT include: RS232, RS422, RS485, CAN bus, Ethernet, etc.;

[0088] 3) For each connection line, set the interface data corresponding to each input and output, and open the data property window (such as Figure 2 ). The variables contained on it are displayed through the data list and tree diagram. The data list displays the basic information of the data: name, data type, cycle, transmission type, etc. The user can open the data configuration window by double-clicking the data. All the information of the variable is displayed in the category page, and all the properties of the data are displayed and configured in three pages: "General", "Protocol", and "Element". The properties of the variable are displayed in a reasonable layout in the "General" page: variable name, transmission type, transmission cycle, data type (this item is available when the type is message), initial value, description information, whether to use the data source, etc. The configuration information of the corresponding IO connection is displayed in the "Protocol" page. The "Element" page is used to display the attribute information of elements and bit segments. The "Element" list displays the element name, element data type, data length, element type, initial value, and description information. The bit segment list displays the name, start bit and end bit, initial value, and description information of the bit segment. Select the element corresponding to the bit segment list through the focus position of the element list.

[0089] 4) Interface fault settings, which can set data packet loss, communication bit jump, communication cycle too long, communication cycle too short, communication cycle random changes, interface synchronization abnormality, field data synchronization abnormality, communication feedback delay, communication feedback in advance, feedback loss, condition combination constraint abnormality, interaction timing abnormality, transmission rate random changes, transmission rate mismatch, incomplete message data, redundant message data, field value exceeds the lower boundary, field value exceeds the upper boundary, field value error value, field precision error, field type error fault information.

[0090] (3) Task behavior modeling

[0091] Analyze the combat mission scenarios faced by software equipment, clarify the task execution sequence, software composition and actual combat environment constraints, clarify the situation, environment, mission, operation, data and other factors in the actual combat scenario, and establish a description method for system behavior based on state machine theory.

[0092] The state diagram describes all possible states of objects of a class, as well as the transition conditions of states when events occur, and can capture the life cycle of objects, subsystems, and systems. It can tell the states that an object can have, and how events (such as the receipt of a message, the passage of time, errors, conditions becoming true, etc.) affect these states over time. A state diagram should connect all classes with clearly identifiable states and complex behaviors; the diagram can determine the behavior of the class and how the behavior changes according to the current state, and can also show which events will change the state of the class's objects. Figure 3 It is the basic structure of the state diagram.

[0093] 1) Task element: It is a state node. In each model diagram, it automatically has a start state and a terminal state. The state is divided into simple state and composite state. The composite state can be divided into OR state and AND state. In addition, there is a pseudo state that represents an abstract state. Pseudo state: A special abstract state. The initial state is a pseudo state. It represents the starting point of the state diagram. It is represented by a solid circle. It represents the default entry state in the composite state. The terminal state is also a pseudo state. It is represented by a solid circle nested inside a circle, which represents the termination of the state. Simple state: A state without nested states, that is, a state without hierarchy, combination and concurrency. Composition state: A state in which several states are nested, so a hierarchical relationship appears in the state diagram. The state in which other states are nested is called a super state, and the nested state is called a sub state. The nested can be a simple state, a composite state or a pseudo state. Composition state is divided into two types: AND state (concurrent) and OR state (mutually exclusive). Double-click a state to expand the state structure and edit the internal structure of the state. After the state is expanded, it comes with two default nodes, [Start State] and [End State], which cannot be edited. All states within a state (hereinafter collectively referred to as sub-states) start from [Start State] and end at [End State].

[0094] 2) Transition elements: Transition is a collection of operations, and migration consists of sequential operations. State transition is represented by a solid arrow with parameters, which is used to connect two different states. The tail of the arrow indicates the source state, and the arrow indicates the target state. When a transition occurs, the state that the transition enters is called the active state. When the transition leaves a state, this state becomes an inactive state.

[0095] Reference Figure 5 The grammatical form of migration is: Event[guard condition] / action

[0096] An event is a description of an observable occurrence. There are many types of events, such as entry, exit, time, call, signal, change, defer, and other events. If the event that triggers the transition is not marked on the migration, it means that the transition is automatically executed. The guard condition is a condition that must be met to trigger the migration. It is usually a Boolean expression. When the corresponding event is distributed, the value of this expression is calculated. If the expression value is true, the migration is triggered. An action is a set of executable statements or calculation processes. It calls an operation. Actions are atomic and cannot be interrupted. Therefore, the above migration syntax expression can be understood as when an event occurs and guard condition == true, the action can be obtained.

[0097] Migrations can be divided into several types:

[0098] Self-migration: The source state and the target state are the same state, and the entry and exit actions of the state will be called

[0099] Internal migration: internal activities of the corresponding state, but the state does not change

[0100] Completion transition: A transition that is automatically triggered based on the completion of actions in this state.

[0101] Composite migration: simple migration is formed by combining branches, decision branches, etc.

[0102] 3) Operation element: The lowest level unit, each operation consists of preconditions, execution process and postconditions.

[0103] Step 2: Confirm the completeness of software task behavior requirements

[0104] The software task behavior is a state machine model. As an abstraction of software requirements, the state machine model can be used to well describe the control function and reflect the task behavior of the software. Due to the inadequate identification of the reliability constraints that the system should follow, the internal process model of the computer represented by the requirement state machine model may not match the actual state, which leads to reliability problems. Software reliability is particularly dependent on the integrity and accuracy of the software (internal) process model. A software task behavior model is a state machine model that can clearly describe the process model and corresponding functions executed by the software.

[0105] The software task behavior requirement completeness confirmation mainly confirms whether all the conditions and conditions that can trigger the output are included. These conditions represent the assumptions about the environment in which the program or system runs. In addition to the output and trigger events, each state machine should also confirm the following states, input and output variables, the relationship between the trigger condition and the corresponding output, and state transitions. Figure 5 Describes all integrity constraints that should be included in the state machine model.

[0106] 1) Confirmation of task status integrity requirements

[0107] The transition of the system from normal operation to abnormal operation is often accompanied by accidents. Especially when computers are used, many accidents and failures are caused by inadequate software processing during the startup process and the transition between normal processing and different types of shutdowns (partial shutdown or complete shutdown). Therefore, the startup integrity requirements must be met when the software is started (starting after partial shutdown or starting after complete shutdown). The task status integrity requirements are mainly confirmed according to List 1.

[0108] Table 1. State integrity requirements confirmation

[0109]

[0110]

[0111]

[0112]

[0113] 2) Confirmation of task input and output variable integrity

[0114] Inputs and outputs represent the information provided by sensors to the software and the commands sent by the software to the actuators. These input and output variables must be strictly defined in the document. Within the black box boundary, only "time" and "value" are observable by the software. Trigger events and outputs must be positioned as and can only be defined as "constraints" or "values" or "times" of observable "events" or "conditions". Events include program inputs, previous program outputs, program starts (a unique observable event for each given program), and hardware-related events such as power out-of-tolerance interrupts. Conditions can be expressed as hardware-related attribute values ​​that can be obtained by the software, such as time period clocks and transfer switches. Confirm the input and output variable integrity requirements according to Table 2.

[0115] Table 2 Input and output variable integrity analysis requirements

[0116]

[0117] 3) Trigger event integrity requirement confirmation

[0118] A reliable system should be able to detect the deviation of the system from the expected input and respond appropriately. It can be seen that the reliability of software depends on the integrity of the assumptions about the environment, that is, there should be no events in the environment that are unobservable by the software and lead to uncertain behavior of the program. These events must be monitored by the software in the form of trigger events. Therefore, the integrity of the assumptions about the environment is linked to the integrity of the trigger events and the computer's response to any potential input. In the process of confirming the trigger events, the following categories of integrity requirements should be considered: robustness requirements, determinism requirements, basic timing and value assumption integrity, overload requirements, and dangerous command requirements. Among them, a dangerous command is a command that can be internal to the software (from one component to another) or an external interface to hardware or operators. Its unintentional, out-of-sequence or incorrect execution may lead to some identified, critical or catastrophic danger, or its execution may reduce the control of the danger (including reducing the failure tolerance capability of a certain danger or eliminating the prohibition of a certain danger). Table 3 describes the trigger event integrity requirements.

[0119] Table 3 Trigger event integrity design requirements

[0120]

[0121]

[0122]

[0123]

[0124]

[0125]

[0126] 4) Output event integrity requirements confirmation

[0127] As with trigger events, a complete description of output event behavior also requires consideration of output event values ​​and timing. Verify the integrity of output events as described in Table 4.

[0128] Table 4 Output event integrity design requirements

[0129]

[0130]

[0131]

[0132]

[0133]

[0134] 5) Confirmation of the integrity requirements of the relationship between output and trigger events

[0135] Some requirements are not related to inputs or outputs alone, but to the relationship between inputs and outputs. Although usually this relationship is based on specific control functions, such as feedback and stability requirements. Responsiveness and spontaneity involve the actual behavior and how the process reacts to the output of the controller. The basic control model relies on feedback to provide information about the changes in the controlled variable and the state changes caused by disturbances in the control process. Table 5 below lists the requirements that should be met for the relationship between the output and the triggering event.

[0136] Table 5 Output and trigger relationship integrity requirements

[0137]

[0138]

[0139] 6) Confirmation of state transition relationship integrity requirements

[0140] Requirements confirmation should not only check the trigger events, output events and the relationship between each state, but also the paths between different states. These paths can be expressed as a sequence of trigger events. The transition between different modes is very dangerous and is particularly sensitive to incomplete requirements and should be carefully checked. Confirm the state transition integrity requirements as described in Table 6.

[0141] Table 6 State transition integrity design requirements

[0142]

[0143]

[0144]

[0145]

[0146] The third step is to conduct combat simulation and confirm the consistency of user needs.

[0147] Requirements consistency refers to the fact that the requirements elements at different levels of the three requirements of combat, equipment and technology echo each other, support each other and have a consistent relationship, without shortcomings, omissions, conflicts and deviations, and can be effectively integrated. Requirements consistency verification refers to analyzing whether different requirements elements can support and match each other. The requirements consistency verification method is closely related to the requirements description method, and can judge the conflicts between the requirements elements represented by multiple views and the adequacy of many-to-one support.

[0148] 1) Analysis of actual combat scenarios

[0149] The actual combat scenario file is parsed to obtain the force configuration information, initial environment settings and simulation exit conditions, etc. After the scenario analysis is completed, the entity type and quantity obtained by the analysis, as well as the mapping relationship between the entity and the model are used to schedule the model.

[0150] 2) Actual combat simulation

[0151] The simulation model is loaded, and the runtime object management establishes the runtime object in the memory and initializes the relationship between various runtime object models. According to the description of the actual combat scenario file, the platform entity model object and various communication equipment, sensor equipment, weapon system, ammunition and other model objects constitute deployment relationships or other associations. The runtime object management module is responsible for establishing and maintaining these associations.

[0152] The simulation event dispatcher is mainly responsible for maintaining an independent event queue and dispatching all events that occur during the simulation. Events in the event queue come from different simulation entities and may also be processed by different simulation entities. The simulation event dispatcher module is responsible for distributing simulation events to different entities.

[0153] During the simulation, different processes are responsible for platform movement, communication interaction, sensor calculation, and electronic countermeasure solution. The simulation process scheduling module starts the above processes and initializes the simulation process. The simulation process scheduling module is also responsible for waking up the sleeping simulation process and ending the simulation process that has completed its mission.

[0154] Monitor the flow of combat operations in a visual flowchart format, and view the tactics and state transition process of any combat entity. View the force command relationship and communication relationship in a hierarchical relationship diagram. Display simulation entities in the form of dot icons, line icons, and surface icons. The types of simulation entities include surface ships (including aircraft carriers), submarines, various aircraft, ports, airports, and launched missiles and torpedoes. The inherent parameters of the entity and the detailed location and status information of the entity can be displayed in a table. Display of situational elements such as simulated combat areas, routes and paths, combat capabilities, command relationships, communication relationships, and engagement relationships.

[0155] 3) Confirmation of Capability Requirements Consistency

[0156] First, the consistency of the path planning capability of the combat area is confirmed. The combat area is displayed in a visual way such as a circle, sector, polygon, etc. in the simulation, including patrol area, assault area, warning area, search sea area, etc. It is mainly used to control the visibility of the tracks or paths of different combat entities, including combat paths such as track points, tracking lines, planned routes, and historical tracks. According to the simulation results, the path planning that can be set is compared with the actual requirements to confirm whether they are consistent.

[0157] Then, the consistency of combat capability is confirmed, which includes the detection range and firepower range of the simulated entity. In the simulation, the detection range of each combat entity and each type of sensor carried is displayed, including the detection search distance, tracking distance or reconnaissance distance of different types of radars, and the firepower range of each combat entity and each type of weapon carried is displayed, including the effective range and maximum range of missiles. Visual simulation and display of engagement relationships, visualization of target allocation and firepower allocation, etc., can flexibly control the visibility of elements, and display them through firepower strike lines, signs, etc. The combat mission simulation is realized in the form of a finite state machine, which supports viewing the tactics status and state transition process of any combat entity. According to the visual display of combat capability results, confirm whether the software equipment's control capabilities for sensors and weapons are consistent with actual requirements.

[0158] Finally, the consistency of electromagnetic influence and communication relationship is confirmed. The target electromagnetic characteristics are combined with the target RCS database (acquired by simulation or test) and the classical statistical model. Choose to use the classical statistical model or call the target RCS database. When using the target RCS feature database, it is necessary to associate it with the target posture information, and use different relative posture information to obtain the RCS corresponding to the target. The index parameters of electronic equipment such as integrated communications and spatial geographic information (GIS) data and meteorological and hydrological data are used to accurately analyze and simulate the multipath interference, waveguide propagation and actual composite propagation of the transceiver channel, and simulate the wireless channel characteristics of electromagnetic wave propagation. At present, the prediction models for radio wave propagation in complex environments can be generally divided into three categories: empirical models, deterministic models and semi-empirical and semi-deterministic models. Calculate the spatial power coverage of the radiation source. The power coverage calculation is to analyze the power radiation of the radiation source after loading the antenna pattern. The advanced electromagnetic propagation algorithm (APM) is sampled in the calculation, which can fully consider the influence of terrain and meteorological environment on electromagnetic wave propagation and the influence of antenna pattern on electromagnetic waves. The power coverage calculation can calculate the power radiation of electronic equipment in profiles, cross sections and spheres. After the calculation is completed, the results are displayed graphically in a three-dimensional scene, with colors used to distinguish the strength of the power, from red to blue to indicate the attenuation of the intensity. According to the electromagnetic signal simulation, the communication range of each combat entity and the various types of communication equipment carried are displayed, and the communication link status between the force entities is displayed to confirm whether the electromagnetic impact and communication relationship are consistent with the actual required capabilities.

[0159] 4) Confirmation of the rationality of weapon control damage effectiveness

[0160] The effectiveness calculation model is used to process the impact effect of weapons controlled by software equipment after firing. When the weapon system fires, the dropped bombs or fired shells will explode at a certain landing point. For non-precision guided weapons, the trajectory of the shells after the strike is ignored, and the weapon effectiveness calculation model calculates the actual explosion point of the shells, and at the same time feeds back the firing result message as the result of the completion of a single firing event.

[0161] 1) Calculate the actual attack distance of the weapon firing. The weapon hit probability is related to the attack distance. Define the weapon hit probability function and specify the relationship between the weapon hit rate and the attack distance.

[0162] 2) Generate a hit result based on the current attack hit rate to determine whether it is a hit. If it is a hit, the explosion point is within the specific hit area; if it is a miss, the explosion point is outside the specific hit area.

[0163] 3) According to the hit result, the explosion point location is randomly calculated and the resulting explosion point location information is output.

[0164] 4) After the weapon explodes, an explosion message is generated. According to the type of explosive weapon and ammunition, a damage range of a certain area is formed with the explosion point as the center. After receiving the message, it is checked whether all units are within the damage range, and the degree of damage to the units within the damage range is calculated.

[0165] 5) The damage model calculates the damage contribution of the explosion to the unit based on parameters such as the ammunition damage factor, the distance from the unit to the explosion center, and the thickness of the unit's own armor. The damage degree of the affected entity components within a certain range is calculated separately, and the overall damage suffered by the entity is the sum of the damage suffered by all components of the entity, which is obtained by accumulating the damage degree of all components.

[0166] 6) The calculated damage level of this attack is combined with the original damage level of the unit, and the damage level of the unit after this explosion is updated. According to the overall damage level of the current unit entity, the current status is recorded as normal, slightly injured, seriously injured, etc. When the damage to the entity exceeds a certain level, the entity is destroyed and its entity is deleted.

[0167] Based on the destructive effects that can be achieved by the weapons controlled by the software equipment, confirm whether the software equipment's ability to control the destructive effectiveness of the weapons is consistent with the requirements.

[0168] The fourth step is to confirm the effectiveness of the reliability requirements of the software cross-linking interface.

[0169] In the third step of combat simulation, the simulated sensor and weapon models interact with the software equipment under test. The relevant interfaces simulate relevant fault information according to Table 7 based on the interface timing requirements, observe whether the software interface runs reliably, and confirm whether the software interface timing requirements are valid.

[0170] Table 7. Interface reliability requirements effectiveness design requirements

[0171]

[0172]

[0173]

[0174] Step 5: Combination analysis of actual scenario factors and confirmation of software reliability requirements

[0175] Software reliability requirement confirmation is to confirm that the software reliability can meet the expected use of the troops. On the one hand, it is necessary to verify the existing clear requirements, and on the other hand, it is necessary to confirm the requirements that users expect but have not clearly stated. Starting from the actual combat scenario, by combining and correlating the elements in the scenario, the various actual combat scenarios and abnormal situations faced by the software are analyzed, the software reliability requirements are extracted, and then compared and analyzed with the clear requirements, and all software reliability requirements are confirmed through simulation test verification. Combined with Figure 6 , the specific plan is as follows:

[0176] 1) Obtain the elements in the actual combat scenario. In this project, the combat mission scenario is the main line, and the elements in each scenario are traversed separately to clarify the possible element combinations of each scenario in the combat mission. The main elements of the situation environment scenario facing the external environment include: system environment such as force deployment and typical targets, as well as physical environments such as geography, meteorology, hydrology, and electromagnetics. The main elements in the combat mission scenario include requirements such as tasks and operations, as well as constraints such as status, timing, and values. The main elements of the system interaction scenario include: cross-linked equipment, interactive relationships, interactive data, network impact, fault conditions, etc.

[0177] 2) Divide the value levels of practical scenario factors. The values ​​of practical scenario factors are diverse. Different values ​​of the same variable logically correspond to different software executions. However, for actual software systems, some values ​​have the same impact on failure. These values ​​with the same failure impact are divided into a group as a value level of the variable. Considering that variables have different types, the principles for dividing the value levels are also different. The following is an example of dividing the value levels of common variable types.

[0178] ①Boolean variable or switch quantity. For Boolean value or switch quantity, there are only two value levels: TRUE and FALSE or on and off.

[0179] ② Enumeration variables. For enumeration value variables, in principle, each enumeration value is a value level, but in special cases, multiple enumeration values ​​can be divided into a group.

[0180] ③ Integer variables or floating-point variables. For integer variables or floating-point variables, the value range is often used as a level, or some specific single values ​​can be used as a level, such as the variable only takes certain specific values, or specific values ​​that are known to play a key role in logical judgment, or values ​​on the boundary, etc.

[0181] 3) Analyze the reliability risk of each factor. The reliability risk of each factor is defined as:

[0182] Factor level reliability risk = factor level occurrence probability * factor level impact level coefficient

[0183] In practice, the probability of occurrence and impact of factors are difficult to obtain quantitatively, but can be obtained by level, which can be divided into relevant levels such as 100%, 80%, 60%, 50%, 40%, 20%, and 0.

[0184] The influence levels of factors on reliability are also divided into relevant levels such as 100%, 80%, 60%, 50%, 40%, 20%, and 0.

[0185] 4) Perform combinatorial analysis, define the combination strength (the default is two-by-two combination), and generate test coverage items based on the combinatorial testing algorithm.

[0186] Since there are many demand clues traversed in the actual scenario model, some may have no practical significance or some elements do not need to be considered, so a filter bar is set during the traversal to prevent combination explosion during the demand traversal process.

[0187] Ignore factors in the seed file that are not present in the model file.

[0188] Factor values ​​in the seed file that are not present in the model file are ignored.

[0189] Ignore rows in the seed file that violate constraints defined in the model file.

[0190] The combat mission scenario has been used as the main line to associate the scene, and various elements have been combined and traversed to form the software reliability requirement. The software reliability requirement becomes "the reliability capability of the system to perform a certain combat mission in a certain actual combat situation environment and under a certain state."

[0191] 5) Perform combinatorial sorting. First, calculate the overall risk of each operation category, sort them from large to small, and select them from large to small according to risk until the selected operation categories meet the 100% coverage of the two combinations. In this way, a group of operation categories with the highest risk and meeting the combinatorial coverage conditions are selected, thus unifying the risk considerations in reliability testing with the combinatorial coverage in software testing.

[0192] 6) Confirm the requirements of actual combat combination elements, compare the combination of elements to confirm the requirements, and confirm from multiple angles such as completeness, rationality and effectiveness.

[0193] First, we need to compare and analyze the software reliability requirements that have been clearly defined to confirm the completeness of the software requirements. The completeness of the requirements means that no necessary requirement information items are omitted during the requirements analysis process, and each requirement is fully and specifically described. Incomplete requirements and omissions are the most common problems in software reliability requirements. For example, there is a lack of processing for fault conditions and lack of processing for environmental factors. The completeness of the requirements is combined with the extracted requirements and compared with the actual requirements.

[0194] Then, confirm the rationality of the combination of practical elements and the rationality of user needs. Confirm whether the selected combination of practical elements conforms to objective reality, and whether the corresponding needs accurately express the user's vision for system application scenarios, application methods, and capability requirements without deviation.

[0195] Finally, confirm whether the software reliability capabilities meet the requirements under the combination of various combat elements; after the combat elements are combined, a new combat scenario is formed, and the test is carried out in the third step under this combat scenario. The extracted software reliability requirements are simulated and tested to verify whether the software system reliability requirements and combat capabilities can meet user expectations and combat mission requirements.

[0196] In summary, the above are only preferred embodiments of the present invention, and the protection scope of the present invention is not limited thereto. All equivalent changes and modifications made according to the patent scope of the present invention and the contents of the specification are within the scope covered by the patent of the present invention.

Claims

1. A method for confirming software equipment reliability requirements based on actual combat scenario analysis, characterized in that: include: Software equipment combat scenario modeling, analyzing the elements in the combat scenario of informationized equipment, and integrating the external situation environment, its own combat mission, and internal system interaction to establish a visual system combat scenario model. The combat scenario model can be saved in the form of a formalized XML document; Confirm the completeness of software task behavior requirements to confirm whether all situations and conditions that can trigger output are included; These conditions represent assumptions about the environmental conditions in which the program or system operates; In addition to output and trigger events, each state machine should also have the following confirmation states, input and output variables, the relationship between trigger conditions and corresponding outputs, and state transitions; Conduct combat simulations to confirm the consistency of user requirements; requirement consistency refers to the correspondence between the three levels of requirements for combat, equipment and technology, and the mutual support and consistency between the requirements, without shortcomings, omissions, conflicts and deviations, and can be effectively integrated. Requirements consistency verification refers to analyzing whether different requirements elements can support and match each other. The requirements consistency verification method is closely related to the requirements description method, and can judge the conflicts between the requirements elements represented by multiple views and the adequacy of many-to-one support. Confirm the validity of the reliability requirements of the software cross-linking interface. The effectiveness calculation model is used to process the impact effect of the weapons controlled by the software equipment after firing. When the weapon system fires, the dropped bombs or fired shells will explode at a certain landing point. For non-precision guided weapons, the trajectory of the shells after the strike is ignored, and the weapon effectiveness calculation model is used to calculate the actual explosion point of the shells, and the firing result message is fed back as the result of the completion of a single firing event; Combination analysis of actual combat scenario factors and confirmation of software reliability requirements. Confirmation of software reliability requirements is to confirm the ability of software reliability to meet the expected use of troops. On the one hand, it is necessary to verify the existing clear requirements, and on the other hand, it is necessary to confirm the user's expected but not clearly stated requirements. Starting from the actual combat scenario, by combining and correlating the elements in the scenario, the various actual combat scenarios and abnormal situations faced by the software are analyzed, the software reliability requirements are extracted, and then compared and analyzed with the clear requirements, and all software reliability requirements are confirmed through simulation test verification.

2. The method according to claim 1, characterized in that The software equipment actual combat scenario modeling includes: Battlefield environment modeling, based on the military geographic information system, includes functions such as electronic chart loading, battlefield environment setting, force organization and deployment, and path planning; Cross-linking relationship modeling is used to analyze how the detection and perception devices and action control devices that interact with the software equipment interact with each other and the possible faults that may occur within the software system. The cross-linking interface model is represented by the following relationship: R = {DUT, peripheral cross-linking device set, input-output relationship, interface type, interface data, fault information}; Task behavior modeling analyzes the combat mission scenarios faced by software equipment, clarifies the task execution sequence, software composition and actual combat environment constraints, clarifies the situation, environment, tasks, operations, data and other factors in the actual combat scenario, and establishes a means of describing system behavior based on state machine theory.

3. The method according to claim 2, characterized in that Battlefield environment modeling specifically includes: Situation definition performs entity creation, communication network setting, and route setting operations according to user editing instructions, and operates blackboard data to rewrite blackboard status; battlefield environment setting uses a visual way to view, edit, and apply information such as the geographical environment and meteorological environment in which the battle is located, supports the hierarchical display function of nautical charts, and can control the display and hiding of nautical chart annotation layers; Perform initial action settings, set the combat objectives and intentions of the party to which you belong, and provide settings for the initial action status of the troops, such as the initial heading, speed, and route. Route settings mainly add navigation routes to the troops, support editing routes by continuously selecting points on the map, and support manual adjustment or deletion of individual selected points. Confrontation rule setting: From the perspective of system confrontation, it provides qualitative and quantitative setting functions for different types of confrontation rules such as radar confrontation, electronic confrontation, communication confrontation, firepower strike, weapon confrontation, and damage effect, so as to achieve the effect of adjusting the overall combat capability of the equipment system by setting combat rules; Combat mission binding supports binding of the combat missions of troops with combat routes, combat areas, etc. added in the assumed situation, to achieve coupling between combat missions and situation elements.

4. The method according to claim 2, characterized in that: The specific steps of modeling are: Describe in graphical form which peripheral cross-linking devices the device under test has a communication relationship with, and identify the names of the cross-linking devices; Describe the input and output relationship between the DUT and the peripheral cross-linking equipment in the form of connecting lines, and identify the interface type between the DUT and the peripheral cross-linking equipment. Common interface types of the DUT include: RS232, RS422, RS485, CAN bus, and Ethernet; For each connection line, set the interface data corresponding to each input and output, and open the data property window; display the variables contained in it through the data list and tree diagram; the data list displays the basic information of the data including: name, data type, cycle, transmission type, and the user can open the data configuration window by double-clicking the data; display all the information of the variable according to the category page, and display all the properties of the data in three pages of "General", "Protocol", and "Element" and configure them; the properties of the variable displayed in a reasonable layout in the "General" page include: variable name, transmission type, transmission cycle, data type, initial value, description information, and whether to use the data source; the configuration information of the corresponding IO connection is displayed in the "Protocol" page; the "Element" page is used to display the attribute information of elements and bit segments, and the "Element" list displays the element name, element data type, data length, element type, initial value, and description information. The bit segment list displays the name, start bit and end bit, initial value, and description information of the bit segment; select the element corresponding to the bit segment list through the focus position of the element list; Interface fault settings can set data packet loss, communication bit jump, communication cycle too long, communication cycle too short, communication cycle random change, interface synchronization exception, field data synchronization exception, communication feedback delay, communication feedback in advance, feedback loss, condition combination constraint exception, interaction timing exception, transmission rate random change, transmission rate mismatch, incomplete message data, redundant message data, field value exceeds the lower boundary, field value exceeds the upper boundary, field value error value, field precision error, field type error fault information.

5. The method according to claim 2, characterized in that: Use state diagrams to describe task behaviors, including: Task element: is a state node, which automatically has a start state and an end state in each model diagram; the state is divided into a simple state and a combined state, and the combined state can be divided into an OR state and an AND state, and there is also a pseudo-state representing an abstract state; pseudo-state: a special abstract state, the initial state is a pseudo-state, which represents the starting point of the state diagram, represented by a solid circle, and represents the default entry state in the combined state; the end state is also a pseudo-state, represented by a solid circle nested inside a circle, representing the end of the state; simple state, a state without nested states, that is, without hierarchy , combined and concurrent states; combined state: refers to a state in which several states are nested, so a hierarchical relationship appears in the state diagram. The state in which other states are nested is called a super state, and the nested state is called a sub state; the nested state can be a simple state, a combined state or a pseudo state; the combined state is divided into two types: concurrent state and mutually exclusive OR state; double-clicking a state can expand the state structure and edit the internal structure of the state. After the state is expanded, it comes with two default nodes, [Start State] and [End State], which cannot be edited. All sub states in the state start at [Start State] and end at [End State]; Transition element: Transition is a collection of operations, and migration consists of sequential operations. State transition is represented by a solid arrow with parameters, which is used to connect two different states. The tail of the arrow indicates the source state, and the arrow indicates the target state. When a transition occurs, the state that the transition enters is called the active state, and when the transition leaves a state, this state becomes the inactive state. The syntax of migration is: Event[guard condition] / action An event is a description of an observable occurrence. Event types include entry, exit, time, call, signal, change, and defer. If there is no event that triggers a transition on a migration, it means that the transition is automatically executed. A guard condition is a condition that must be met to trigger a migration. When the corresponding event is distributed, the value of this expression is calculated. If the expression value is true, the migration is triggered. An action is a set of executable statements or calculation processes that call an operation. Actions are atomic and cannot be interrupted. Therefore, the above migration syntax expression can be understood as, when an event occurs and guard condition == true, the action occurs. Migrations can be divided into several types: Self-migration, the source state and the target state are the same state, and the entry action and exit action of the state will be called; Internal migration, the internal activity of the corresponding state, but the state does not change; Completed transition, which is automatically triggered when the action in this state is completed; Compound migration is formed by combining simple migrations through branches, decision branches, etc. Operation element: The lowest level unit. Each operation consists of preconditions, execution process and postconditions.

6. The method according to claim 1, characterized in that The completeness confirmation of software task behavior requirements includes: Mission state integrity requirements confirm that the system transition from normal operation to abnormal operation is often accompanied by accidents; especially when computers are used, many accidents and failures are caused by inadequate software processing during the startup process and the transition between normal processing and different types of shutdown; therefore, the startup integrity requirements must be met when the software is started; Confirm the integrity of task input and output variables. Input and output represent the information provided by the sensor to the software and the commands sent by the software to the brake. These input and output variables must be strictly defined in the document. In the black box boundary, only "time" and "value" can be observed by the software. Trigger events and outputs must be positioned as and can only be defined as "constraints" or observable "events", "values" or "time" of "conditions". Events include program inputs, previous program outputs, program startups, and hardware-related events such as power outage interrupts. Conditions can be expressed as hardware-related attribute values ​​that can be obtained by the software, such as time period clocks and transfer switches. Confirmation of the trigger event integrity requirement: a reliable system should be able to detect the deviation of the system from the unexpected input and respond appropriately; it can be seen that the reliability of the software depends on the integrity of the environmental assumptions, that is, there should be no events in the environment that are unobservable by the software and lead to uncertain behavior of the program. These events must be monitored by the software in the form of trigger events. Therefore, the integrity of the environmental assumptions is linked to the integrity of the trigger events and the computer's response to any potential input. In the process of confirming the trigger events, the following categories of integrity requirements should be considered: robustness requirements, determinism requirements, basic timing and value assumption integrity, overload requirements, and dangerous command requirements; among them, a dangerous command is a command that can be internal to the software or an external interface to the hardware or operator. Its unintentional, out-of-sequence or incorrect execution may lead to some identified, critical or catastrophic danger, or its execution may reduce the control of the danger; Output event integrity requirements confirmation: Like trigger events, the complete description of output event behavior also needs to consider the value and timing of output events; Output and trigger event relationship integrity requirements acknowledge that some requirements are not related to inputs or outputs alone, but to the relationship between inputs and outputs; although usually this relationship is based on specific control functions, such as feedback and stability requirements; Responsiveness and spontaneity involve actual behavior and how the process reacts to the controller's output; basic control models rely on feedback to provide information about changes in the controlled variable and state changes caused by disturbances in the control process; The state transition relationship integrity requirement confirmation should not only check the trigger events, output events and the relationship between each state, but also check the paths between different states; these paths can be expressed as a sequence of trigger events; the transitions between different modes are very dangerous and are particularly sensitive to incomplete requirements and should be carefully checked.

7. The method according to claim 1, characterized in that Confirming the consistency of user requirements specifically includes: Combat scenario analysis: Analyze the combat scenario file to obtain the force configuration information, initial environment settings, and simulation exit conditions. After the scenario analysis is completed, the entity type and quantity obtained by the analysis, as well as the mapping relationship between the entity and the model, are used to schedule the model. Actual combat simulation, loading simulation models, the runtime object management establishes runtime objects in memory, and initializes the relationships between various runtime object models; according to the description of the actual combat scenario file, the platform entity model objects and various communication equipment, sensor equipment, weapon systems, ammunition and other model objects constitute deployment relationships or other relationships, the runtime object management module is responsible for establishing and maintaining these relationships; Confirmation of consistency of capability requirements; Confirmation of the rationality of weapon control damage effectiveness.

8. The method according to claim 7, characterized in that The specific confirmation of capability requirement consistency includes: First, the consistency of the path planning capability of the combat area is confirmed. The combat area is displayed in a circular, sectoral, polygonal and other visual forms in the simulation, including patrol areas, assault areas, warning areas, and search sea areas. It is mainly used to control the visibility of the tracks or paths of different combat entities, including combat paths such as track points, tracking lines, planned routes, and historical tracks. According to the simulation results, the path planning that can be set is compared with the actual requirements to confirm whether they are consistent. Then, the consistency of combat capability is confirmed. Combat capability includes the detection range and firepower range of the simulated entity and other elements. The detection range of each combat entity and the various types of sensors carried by it is displayed in the simulation, including the detection search distance, tracking distance or reconnaissance distance of different types of radars. The firepower range of each combat entity and the various types of weapons carried by it is displayed, including the effective range and maximum range of missiles. Visual simulation and display of engagement relationships, visualization of target allocation and firepower allocation, etc., can flexibly control the visibility of elements, and display them through firepower strike lines, signs, etc.; combat mission simulation is realized in the form of finite state machines, supporting the viewing of the tactics status and state transition process of any combat entity; based on the visually displayed combat capability results, confirm whether the software equipment's control capabilities for sensors and weapons are consistent with actual requirements; Finally, the consistency of electromagnetic influence and communication relationship is confirmed; the target electromagnetic characteristics are combined with the target RCS database and the classical statistical model, and the classical statistical model or the target RCS database is selected; when the target RCS feature database is used, it is necessary to associate it with the target posture information, and use different relative posture information to obtain the RCS corresponding to the target; the index parameters of electronic equipment such as integrated communications and spatial geographic information data as well as meteorological and hydrological data are used to accurately analyze and simulate the multipath interference, waveguide propagation and actual composite propagation of the transceiver channel, and simulate the wireless channel characteristics of electromagnetic wave propagation; the current prediction models for radio wave propagation in complex environments can be generally divided into three categories: empirical models, deterministic models and semi-empirical and semi-deterministic models; Calculate the spatial power coverage of the radiation source; power coverage calculation is to analyze the power radiation of the radiation source after loading the antenna pattern; the advanced electromagnetic propagation algorithm is sampled in the calculation, which can fully consider the influence of terrain and meteorological environment on electromagnetic wave propagation and the influence of antenna pattern on electromagnetic waves; power coverage calculation can calculate the power radiation of electronic equipment in profile, cross section and sphere; after the calculation is completed, the result is displayed in a three-dimensional scene in a graphical way, and the power is distinguished by color, from red to blue to indicate the attenuation of intensity; according to the electromagnetic signal simulation, the communication range of each combat entity and the various types of communication equipment carried are displayed, and the communication link status between the force entities is displayed to confirm whether the electromagnetic impact and communication relationship are consistent with the actual required capabilities.

9. The method according to claim 7, characterized in that: The rationality confirmation of weapon control damage effectiveness specifically includes: The effectiveness calculation model is used to process the impact effect of weapons controlled by software equipment after firing. When the weapon system fires, the dropped bombs or fired shells will explode at a certain landing point. For non-precision guided weapons, the trajectory of the shells after the strike is ignored, and the weapon effectiveness calculation model is used to calculate the actual explosion point of the shells, and at the same time, the firing result message is fed back as the result of the completion of a single firing event. Based on the destructive effects that can be achieved by the weapons controlled by the software equipment, confirm whether the software equipment's control over the destructive effectiveness of the weapons is consistent with the requirements.

10. The method according to claim 9, characterized in that include: The actual attack distance of the weapon firing is calculated, and the weapon hit probability is related to the attack distance; The hit probability function of the weapon is defined, which stipulates the relationship between the weapon's hit rate and the attack distance. According to the current attack hit rate, a hit result is generated to determine whether it is a hit. If it is judged to be a hit, the explosion point is within the specific hit area; if it is judged to be a miss, the explosion point is outside the specific hit area; According to the hit result, the explosion point position is randomly calculated and the explosion point position information is output; After the weapon explodes, an explosion message is generated. According to the type of explosive weapon and ammunition, a certain area of ​​damage is formed with the explosion point as the center. After receiving the message, all units are checked to see if they are within the damage range, and the damage degree is calculated for the units within the damage range. The damage model calculates the damage contribution of the explosion to the unit based on parameters such as the ammunition damage factor, the distance from the unit to the explosion center, and the thickness of the unit's own armor. The damage degree of the affected entity components within a certain range is calculated separately, and the overall damage suffered by the entity is the sum of the damage suffered by all components of the entity, which is obtained by accumulating the damage degrees of all components. The damage degree of this attack is calculated and combined with the original damage degree of the unit, and the damage degree of the unit after this explosion is updated; According to the overall degree of damage suffered by the current unit entity, the current status is recorded as normal, slightly injured, or seriously injured; when the damage to the entity exceeds a certain degree, the entity is destroyed and its entity is deleted.

Images