A satellite communication support process deduction modeling system based on SysML

Abstract

The application discloses a satellite communication guarantee process deduction modeling system based on SysML and relates to the field of satellite communication simulation.The system comprises an application module, a system module and the like.The application module is used for constructing an application scene model based on SysML, taking a scene task as event driving, generating a scene construction message for constructing a simulation scene and a scene task message for driving process deduction.The system module is used for constructing a system digital model based on SysML, receiving the message sent by the application module, responding to the event driving to execute network building, user network access and service network utilization process deduction, and evaluating the application response time of each process in real time.The application scheme can significantly improve the consistency of requirement definition and decomposition, effectively reduce the information deviation and design omissions caused by document transmission.

Description

Technical Field

[0001] This invention relates to the field of satellite communication simulation, and in particular to a satellite communication assurance process simulation and modeling system based on SysML. Background Technology

[0002] With the rapid development of aerospace engineering technology, the functional complexity and large-scale integration of satellite communication systems have significantly increased, posing severe challenges to system development, such as long verification cycles and difficulties in achieving full engineering coverage. Currently, domestic aerospace product design mainly relies on natural language-based documents as information carriers, with system requirements, functional definitions, interface relationships, and behavioral logic all described in text form. However, satellite communication systems involve deep coupling of multiple subsystems, interfaces, and disciplines. The traditional document-driven model is prone to information deviations and design omissions during requirement decomposition, transmission, and verification, resulting in unclear requirement definitions, ambiguous decomposition, and difficulty in ensuring consistency. Furthermore, the physical verification phase of system design requires the construction of complex ground simulation environments, but due to differences between space and ground environments and incomplete operational condition coverage, the effectiveness of test results is limited, and defects are often only exposed in the later stages of development, significantly extending the system verification cycle and failing to meet the current rapidly iterating needs of aerospace system development.

[0003] In light of the aforementioned technical background, existing satellite communication system development methods suffer from the following main technical shortcomings: First, system requirements are described in natural language text, making it difficult to efficiently manage dependencies and traceability paths between requirement items. This results in a lack of consistent data closure in the requirement definition, decomposition, and verification processes, highlighting the contradiction between requirement complexity and consistency. Second, the design schemes of multiple subsystems are deeply coupled. Professional verification based on a single system is insufficient to reveal cross-system issues such as interface incompatibility and abnormal signaling interaction. Design defects are often only discovered in the later stages of system integration, lacking early verification methods. Third, system performance verification heavily relies on physical prototypes and ground tests. The full range of operating conditions of complex systems is difficult to reproduce on the ground, and measurement errors introduced by differences between ground and space further reduce the effectiveness of test results, leading to lengthy and incomplete verification cycles, making it impossible to fully assess the satellite communication system's assurance capabilities in actual missions during the development phase. Therefore, based on these challenges, this invention proposes a satellite communication assurance process deduction and modeling system based on SysML (System Modeling Language). Summary of the Invention

[0004] To address the aforementioned issues, the present invention aims to provide a satellite communication assurance process simulation and modeling system based on SysML. By introducing model-based systems engineering concepts, a digital model is constructed to achieve graphical design and verification of system requirements and functions. This allows for early assessment of key performance indicators such as communication assurance capabilities and application response time of the satellite communication system during the R&D phase, and provides system gap analysis and layout suggestions for subsequent satellite system construction.

[0005] To achieve the above objectives, this invention provides a SysML-based satellite communication assurance process simulation and modeling system. The application module constructs application scenario requirement models, process models, and unit models based on SysML, using scenario tasks as event drivers. It sends topology import messages, scenario import messages, and scenario task messages to the system module via the User Datagram Protocol (UDP). The system module constructs requirement models, structural models, behavioral models, and parameter models based on SysML. Following the MBSE forward design process, it sequentially executes requirement analysis, workflow design, architecture design, and interface design. After responding to the messages, it sequentially simulates network construction, user network access, and service network usage processes, evaluating the application response time at each stage in real time and correcting and optimizing the evaluation results based on measured data. The two modules interact via a design-integration closed-loop verification mechanism. After each process is completed, the system module returns a response message to the application module. The application module drives scenario task simulation based on the feedback status, thereby achieving iterative verification of the system design model and system gap analysis.

[0006] In a first aspect, the present invention provides a SysML-based satellite communication assurance process simulation and modeling system, comprising: The application module is used to build application scenario models based on SysML, define the top-level goals, activity sequences and capability requirements of scenario tasks, and parse scenario tasks into executable scenario construction messages and scenario task messages, which are issued in an event-driven manner. The system module is used to build a digital model of the system based on SysML, receive messages sent by the application module, map the scenario task messages to the corresponding functions and behavior units in the digital model of the system, and perform process simulations of network construction, user access, and business network use accordingly, and evaluate the application response time of each process in real time. The application module and the system module interact via a communication protocol. The application module sends messages to the system module to drive the simulation, and the system module returns a response message to the application module after executing each process to provide feedback on the execution status.

[0007] Furthermore, the system module acquires measured data from the satellite communication system, corrects and optimizes the evaluated application response time based on the measured data, and feeds back the corrected response time parameters to the application module, thereby correcting model deviations with measured data and improving the consistency between simulation evaluation results and real system performance.

[0008] Furthermore, the application module compares the response time parameters fed back by the system module with preset demand indicators, identifies the shortcomings that do not meet the indicators and quantifies the deviation, and generates satellite system construction suggestions based on the deviation; the comparison, identification and quantification process constitutes system gap analysis.

[0009] Furthermore, the message interaction between the application module and the system module specifically includes: The application module sends a topology import message to the system module, which carries a network topology specification description required for the scenario. After receiving the message, the system module establishes the network topology and configures the underlying links in its system digital model according to the specification description, and then returns a topology import response message. The application module sends a scenario import message to the system module to trigger the system module to generate a communication scheme and allocate satellite resources, and then the system module returns a scenario import response message.

[0010] Furthermore, the scenario task message sent by the application module to the system module includes sequential triggering instructions for network construction, user access, and service network use, as well as behavioral parameters required for each stage. After receiving the triggering instructions for each stage, the system module drives its system digital model to perform the simulation of the corresponding stage. After completing the response time evaluation, it returns a scenario task response message carrying simulation data to the application module. The application module advances the simulation progress of the scenario task based on the response message.

[0011] Furthermore, the system module acquires historical measured response time data and constructs a time series, uses a trend prediction algorithm to generate a trend prediction value for the response time; constructs a dynamic weight function based on the timeliness of the measured data and the prediction deviation, and adaptively adjusts the weight according to the system operating condition change rate; and uses the dynamic weight to fuse the trend prediction value with the theoretical response time based on the SysML behavioral model simulation to generate the final evaluated response time.

[0012] Furthermore, the system module extracts message sequences and their time constraints and dependencies from the SysML time sequence diagram constructed by the application module, constructs a message partial order set, identifies message pairs without direct dependencies, and calculates the time sequence conflict probability between message pairs based on the uncertainty distribution of shared resource status and message arrival time; summarizes the conflict probabilities of all message pairs, generates a conflict risk index for the overall scenario task, and adjusts the message sending strategy of the scenario task according to the index.

[0013] Furthermore, the system module is pre-built with a digital system model that follows a model-based forward design process for systems engineering. This model includes structured information such as requirements analysis, workflow design, architecture design, inter-system interface design, subsystem function design, and system indicator decomposition. During the simulation process, the system module calls the model to perform a full-system workflow simulation. When the simulation results do not match the preset requirements, it marks the inconsistencies and triggers a model correction prompt, thus forming a closed-loop verification.

[0014] Furthermore, the application scenario model constructed by the application module is a specification-descriptive model, including: a scenario requirement model, used to define top-level concepts, scenario goals, and capability requirements; a scenario process model, used to decompose scenario goals into serialized scenario activities and interactive information flows; and a scenario unit model, used to describe the entities participating in the activities and their collaborative relationships. The application module encapsulates the activity sequence and information flow in the scenario model into scenario task messages and sends them to the system module to drive simulation execution.

[0015] Furthermore, the system module is also used to perform timing flow and signaling interaction modeling on the behavior of the space segment, ground segment and user segment during network construction, user access and service network use, and interact with the application module through the communication protocol to present the timing flow and signaling interaction relationship in the timing diagram in real time, thereby visually displaying the cross-segment signaling interaction process and assisting in the identification of interface timing anomalies and signaling conflicts.

[0016] Furthermore, the communication protocol is User Datagram Protocol (UDP). The application module and the system module establish a socket connection through this protocol and exchange topology import messages, scene import messages, scene task messages, and corresponding response messages in the form of message packets.

[0017] Secondly, a SysML-based method for modeling and extrapolating satellite communication assurance processes is also provided. This method is based on the system described in the first aspect and includes: The application module builds an application scenario model based on SysML, and uses scenario tasks as events to generate scenario building messages and scenario task messages. The message is sent to the system module via a communication protocol; The system modules construct a digital model of the system based on SysML. After receiving the message, the system sequentially performs the process simulation of network construction, user network access, and business network use, and evaluates the application response time of each process in real time. After completing each process, the system module returns a response message to the application module, and the application module drives the simulation progress of the scenario task based on the response message.

[0018] This invention provides a SysML-based satellite communication assurance process simulation and modeling system. The application module establishes scenario requirement models, scenario process models, and scenario unit models based on SysML. Driven by scenario tasks, it sends structured messages such as topology import, scenario import, and scenario task information to the system module via a communication protocol. The system module establishes requirement models, structural models, behavioral models, and parameter models based on SysML. Following a model-based forward design process for systems engineering, it performs requirement analysis, architecture design, interface design, and indicator decomposition. Upon responding to messages from the application module, it sequentially simulates network construction, user onboarding, and service network usage processes, evaluating application response times at each stage in real time and obtaining measured data to correct and optimize the evaluation results. After each process is completed, the system module returns a response message to the application module. The application module uses the feedback status to drive scenario task simulation, thereby achieving iterative verification of the system design model, system gap analysis, and generation of satellite system construction recommendations.

[0019] This invention introduces a model-based systems engineering approach into the R&D phase of satellite communication systems. By graphically designing and verifying system requirements, functions, processes, and interface relationships in the form of digital models, it significantly improves the consistency of requirement definition and decomposition, effectively reducing information discrepancies and design omissions caused by document transmission. Through event-driven process simulation and real-time response time assessment, coupling issues such as interface mismatches and signaling interaction anomalies between multiple subsystems can be exposed in advance in a digital environment, preventing design defects from extending to the physical verification stage. The design-integration closed-loop verification mechanism, combined with measured data for correction and optimization, reduces reliance on physical prototypes and ground tests, significantly shortens the system verification cycle, and lowers verification costs, while improving the consistency between simulation evaluation results and real system performance. Furthermore, by analyzing system gaps, simulation results are transformed into quantitative decision-making basis, providing support for subsequent satellite system capability building and layout optimization, thereby comprehensively improving the efficiency and quality of satellite communication system R&D.

[0020] Beneficial effects By implementing the SysML-based satellite communication assurance process simulation and modeling system provided by the present invention, the following technical effects are achieved: (1) By constructing a closed-loop message interaction between the application module and the system module, the system module returns a response message to the application module after each process is completed, and the application module drives subsequent scenario tasks based on the feedback status. This framework deeply couples the simulation verification of the system design model with the scenario task inference. Compared with the linear process of design, verification and modification in the traditional document-driven mode, it realizes the immediate discovery and iterative correction of design defects at the model level, avoids the transmission of defects to the physical verification stage, thereby shortening the system verification cycle and reducing the correction cost.

[0021] (2) By sequentially executing requirements analysis, workflow design, architecture design, interface design, functional design, indicator decomposition, and full system simulation in the system modules, and iterating back to the requirements analysis step when the simulation results do not meet the requirements, this process moves the requirements verification in aerospace system development to the digital modeling stage. It establishes a traceable and closed-loop positive design chain from top-level requirements to bottom-level implementation, realizes multiple rounds of rapid iteration and automated consistency verification of system solutions, and effectively reduces the risk of rework in the later stages due to unclear requirements decomposition or design omissions.

[0022] (3) By introducing a trend prediction algorithm and a dynamic weighting function, this method changes the traditional approach of fixed-weight fusion or reliance solely on simulation values ​​in response time assessment. When the system acquires new measured data, this method enables the assessment results to quickly converge to the actual system performance, shortening the model calibration cycle. When measured data is sparse or its timeliness decreases, the assessment results automatically regress to the model simulation values, avoiding assessment bias introduced by outdated data. This method significantly improves the stability of the assessment results throughout their entire lifecycle and its adaptability to data sampling non-uniformity, ensuring continuous and reliable response time assessments from the R&D stage to the on-orbit operation stage.

[0023] (4) By constructing a partially ordered message set and quantifying the conflict probability at the model level, this method overcomes the limitation of traditional time series analysis, which can only verify ideal sequences and cannot predict concurrent conflicts. This method can identify the risk of time series conflicts caused by message arrival time uncertainty and resource contention in advance during the simulation phase and output a quantifiable conflict risk index. This index can drive the dynamic adjustment of the scenario task message sending strategy, thereby eliminating signaling collision risks during the design phase, significantly reducing the probability of signaling retransmission and timeout events, and reducing the number of iterations for cross-system interface testing. Attached Figure Description

[0024] To make the above-described SysML-based satellite communication assurance process simulation and modeling system of the present invention more obvious and understandable, the accompanying drawings used in the specific embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0025] Figure 1 This diagram illustrates the architecture of a satellite communication system simulation platform. Figure 2 This diagram illustrates the workflow of a satellite communication system simulation platform. Figure 3 This represents the application model design flowchart; Figure 4 This represents the system module design flowchart; Figure 5 This diagram illustrates the interface relationships between modules. Figure 6 This represents a scenario-based message flow diagram. Figure 7 This represents the flowchart of the scenario task message. Detailed Implementation

[0026] Example 1: This embodiment takes a typical satellite communication system as the implementation object and constructs a full-process simulation platform based on SysML. In the research and development stage, it introduces the concept of model-based systems engineering to realize the system system confirmation, indicator evaluation, process deduction and application mode verification of the satellite communication system, while providing quantitative decision support for the subsequent satellite system construction.

[0027] The satellite communication assurance process simulation and modeling system described in this embodiment has the following overall architecture: Figure 1As shown, the core consists of two main units: the application module and the system module. The application module, based on SysML, constructs application scenario requirement models, application scenario process models, and application scenario unit models. Employing a systematic design approach, it starts with tasks in typical application scenarios, using scenario task behavior as an event driver, and establishes communication connections with the system module via Sockets. The system module, also based on SysML, constructs requirement models, structural models, behavioral models, and parameter models. Its core function is to pre-verify and confirm the overall system plan, satellite overall plan, ground overall plan, and network management system documents, complete the verification of the satellite-ground interface relationship, and possess comprehensive indicator evaluation capabilities. It can evaluate the response time of the entire process of network construction, user access, and service network use under different application modes. The application module triggers the system module's operation through event-driven methods and does not participate in the specific simulation of underlying behaviors. The system module, based on the task items sent by the application module, maps the scenario tasks to its pre-built system digital model, performs time-series process and signaling interaction modeling of the behaviors of the space segment, ground segment, and user segment, and can also access measured data to correct and optimize key indicators such as application response time.

[0028] The complete workflow of the simulation platform built in this embodiment is as follows: Figure 2As shown, after the user starts the simulation through the application module, the application module generates event-driven instructions according to the preset scenario task sequence, controlling the operation rhythm of the system module. After the simulation starts, the application module first sends a topology import message to the system module. Upon receiving the message, the system module establishes the network topology and configures the underlying links in its system digital model according to the specifications. After completing the internal operations, it returns a topology import response message to the application module. Subsequently, the application module sends a scenario import message. Based on this, the system module generates a communication scheme and completes satellite resource allocation, returning a scenario import response message, thus completing the basic construction of the simulation scenario. On this basis, the application module completes task planning and sends scenario task messages for each stage to the system module in sequence according to the business logic. After responding to the messages, the system module drives its own system digital model to execute detailed behavioral simulations for the corresponding stages, sequentially completing network construction process simulation, user terminal network access process simulation, user terminal packet service access process simulation, user terminal cross-satellite process simulation, and user terminal packet service termination process simulation. At each process stage, the response time is evaluated in real time, and the scenario task response results carrying simulation data are fed back to the application module in real time. That is, the application module controls the triggering timing, and the system module is responsible for the specific simulation behavior. Throughout the simulation, the application module and the system module communicate bidirectionally via the User Datagram Protocol (UDP). The application module sends topology import messages and scenario task messages for each stage to the system module, which in turn returns topology import response messages and scenario task execution status feedback. Based on the progress of the scenario tasks, the application module can trigger the system module to display key processes such as network construction, network access, and network use in real time on the sequence diagram, thereby achieving full-process visual control.

[0029] This embodiment provides a complete design for the modeling method of the application module, and its modeling process is as follows: Figure 3As shown. The application module focuses on the application scenario level, and its core is used to define the system's mission, tasks, and scenario environment. Developed based on SysML, it fully supports system construction, covering core elements such as system integration, task planning, process design, and application analysis. It can accurately define the specific requirements of the application scenario for satellite system development. It is important to emphasize that the design output of the application module is a specification description of the scenario tasks, not executable code. During the modeling process, firstly, the top-level concepts, hypothetical scenarios, application scenario nodes, and high-level application scenario goals, capability requirements, and key performance indicators are clarified through the application scenario requirement model. Then, the application scenario process model decomposes the application scenario requirements into specific, sequential application scenario activities, clearly describing the interaction content and information flow between each application scenario node required to complete the mission. Finally, the application scenario unit model fully describes the various entities participating in the application scenario activities and the collaborative relationships between them. The application module encapsulates these specification descriptions into scenario task messages and sends them to the system module to drive simulation execution. The application module can adopt a system design approach based on project mission requirements, starting with scenario analysis to clarify the capability requirements of the satellite system, and carry out satellite system architecture design in combination with the current status of satellite systems. After the simulation is completed, the application module receives the evaluation results such as response time returned by the system module, compares them with the preset requirement indicators, performs system gap analysis, and finally proposes development suggestions such as capability requirements and layout schemes for the construction of typical aerospace satellite systems. It can clearly present the complete process of communication scenarios to users and fully support the simulation and demonstration of the entire process of aerospace missions.

[0030] This embodiment provides a detailed design of the modeling method for system modules, such as... Figure 4As shown. The system module is centered on the communication model, integrating system technical indicators and design experience through relationship tracing to achieve digital modeling of the satellite communication system. The system module pre-builds a digital system model following the MBSE forward design process. The model construction process includes the following steps: Step 1, Requirements Analysis: This involves analyzing and summarizing the system's usage requirements and technical indicators, listing them item by item in text form; Step 2, Workflow Design: Based on usage requirements, design the system's functional flow, define subsystems, allocate functions to each subsystem, and realize the complete system workflow; Step 3, Architecture Design: Based on the definitions and deployment relationships of each subsystem, clarify the system composition and design the connection relationships between subsystems according to the system workflow; Step 4, Inter-system Interface Design: Based on… The interaction requirements between the functional modules of each subsystem are defined, including the signal types for receiving information and the interface types for transmitting information, thus forming the interface relationships between the subsystems. Step five involves subsystem function design, which designs independently operable subsystem functional units based on the subsystem functions, signal types, and interface types. Step six involves system indicator decomposition, which allocates satellite-to-ground technical indicators to each subsystem. Step seven involves full-system workflow simulation, which involves distributing and independently running each subsystem functional unit according to different system operating conditions to simulate the system workflow. The simulation results are then used to verify whether the requirements are met and to confirm the rationality of the subsystem design. If the simulation results do not match the preset requirements, the system module does not automatically modify the model; instead, it marks the specific location and deviation of the unmet requirements and outputs model correction prompts to the user interface, allowing the user to decide whether to iteratively adjust the pre-built model.

[0031] The interface interaction relationship between the application module and the system module is as follows: Figure 5 As shown, the two communicate bidirectionally via the User Datagram Protocol (UDP), forming a complete closed-loop verification mechanism. The application module, acting as the upper-level control unit, sends scenario construction and task-related instructions to the system module, enabling operation control of the system module. Simultaneously, based on feedback from the system module, it performs scenario demonstration, system gap analysis, and outputs satellite system construction suggestions. The system module, acting as the lower-level execution unit, upon receiving instructions, completes the entire process simulation, including network construction, user network access, and service network usage. It also evaluates and calculates application response time based on measured data, correcting and optimizing the measured data, and returns instruction feedback messages to the application module. The application module then continuously advances the scenario simulation based on the received feedback messages, forming a complete closed loop that fundamentally ensures the reliability of system operation.

[0032] The complete message interaction process in the scene building phase is as follows: Figure 6As shown, after the simulation starts, the application module first sends a topology import message to the system module. Upon receiving the message, the system module completes network topology establishment and underlying link configuration based on the message content. After route convergence is complete, it returns a topology import response message to the application module, confirming the execution result of topology construction. Subsequently, the application module sends a scenario import message to the system module. Upon receiving the message, the system module generates a communication scheme and completes satellite resource allocation based on the message content. After the allocation is completed, it returns a scenario import response message to the application module, confirming the construction of the entire simulation scenario. The complete message interaction process during the scenario task execution phase is as follows: Figure 7 As shown, after the scenario is built, the application module sends a scenario task message to the system module. After receiving the message, the system module completes the full-process simulation of network construction, user access, and business network use through signal interaction. After each stage of the process is completed, the application response time of the corresponding link is evaluated synchronously, and a scenario task response message is returned to the application module to provide real-time feedback on the execution results. The application module then continuously advances the simulation progress of the scenario task based on the returned response message, realizing event-driven control of the entire process.

[0033] Example 2: In satellite communication support process simulations, the response time assessment of system modules for network construction, user access, and service network usage relies on both theoretical simulation values ​​based on SysML models and is limited by the sparsity and timeliness of measured data. Traditional methods use fixed weights to fuse model values ​​and measured values, which fails to reflect the confidence decay of measured data as operating conditions change and ignores the trend influence of past measured values. This embodiment introduces a double exponential smoothing algorithm to predict the trend of historical measured sequences and constructs a measured deviation driving function to dynamically generate fusion weight coefficients. These weight coefficients adaptively adjust according to the age of the measured data, the magnitude of the deviation, and the rate of change of system operating conditions. This ensures that the response time assessment results maintain the stability of model predictions even when measured data is lacking, and quickly converges to the actual system performance when new measured data is obtained. This solves the problem of non-uniform sampling of measured data and the difficulty in quantifying weights due to differences in the ground and space environments in satellite communication systems.

[0034] Within the system module, a measured data storage unit is established to record the measured values ​​of application response time obtained from each ground test or on-orbit test, forming a time series of length N, which is then arranged in reverse chronological order.

[0035] For the above sequence, the predicted value for the next time step is calculated using double exponential smoothing. Let the recursive formulas for the horizontal and trend components be:

[0036]

[0037] In the formula, For the first The horizontal component at time; This is a horizontal smoothing parameter with a value range of (0,1), which is dynamically selected based on the system operating condition change rate. For the first Historical measured response time values ​​at any given moment; For the first The trend component of time; This is a trend smoothing parameter with a value range of (0,1), which is dynamically selected based on the rate of change of the system operating conditions.

[0038] Predicted value .

[0039] Define the freshness factor of measured data ,in, λ The attenuation coefficient set for the system. This represents the time difference between the current moment and the most recent measurement. Define the deviation magnitude factor. If the most recent measured value If it is greater than zero, then ;like Then set directly ;in This is the most recent measured value. Therefore, the dynamic fusion weight calculation formula is:

[0040] In the formula, The dynamic fusion weights have a value range of [0,1], representing the credibility of the measured values ​​and trend predictions in the final evaluation. The normalized exponent for the system operating condition change rate approaches 1 when the operating condition changes drastically and approaches 0 when it is stable. The specific determination method is as follows: Continuously monitor multiple operating condition characteristic parameters, including network load factor, user access rate change, and channel quality fluctuation coefficient. Sum the products of the above parameters with their respective preset weight coefficients, and consider the network load change rate and sampling time interval between the current time and the previous time to calculate the original value of the operating condition change. Then, compare the original value with the upper limit threshold of the operating condition change rate calibrated by the system and normalize it so that the normalized exponent is between zero and one. This value is recalculated every time the measured data is updated and is used to dynamically adjust the fusion weight.

[0041] The system module also outputs the theoretical response time obtained from simulation based on the SysML behavioral model. The final evaluation result is as follows:

[0042] In the formula, The final evaluation result is the application response time; This represents the theoretical response time obtained from simulations based on the SysML behavioral model.

[0043] This value is fed back to the application module for system gap analysis.

[0044] After each simulation, if new measured data is obtained, the sequence is updated and the smoothing parameters and weights are recalculated; if no new measured data is available, the simulation continues over time. Increase The system automatically reduces its size, gradually returning to model simulation as the primary driver, thus ensuring the robustness of the evaluation results.

[0045] Compared to traditional response time assessment methods that use fixed weights (e.g., always assigning 50% weight to measured values ​​and 50% weight to simulated values), this method introduces a dynamic weighting function driven by a double exponential smoothing trend prediction and measured deviation. Comparative tests were conducted in a support scenario built on a typical satellite communication system simulation platform. Test data came from measured data collected during the on-orbit operation of a low-Earth orbit satellite communication system (including response time records for three stages: network establishment, user access, and service network use, totaling 1200 sample points), and corresponding simulated data generated based on a SysML model. The test set the measured data sampling interval to 30 days, and the normalized index of the system operating condition change rate gradually varied from 0.2 to 0.8 with service load. During the comparison, the conventional method used a constant weight of 0.5, while this method dynamically updated the weights every 5 seconds based on the freshness factor and deviation amplitude factor. Each experiment was repeated 30 times, and the significance of differences was assessed using an independent samples t-test (p<0.05). Experimental results show that after obtaining three consecutive sets of measured data, the average absolute percentage error between the response time evaluation results of this method and the actual on-orbit test values ​​decreased from 18.7% for the conventional method to 6.2%, a significant reduction (t=12.3, p=0.002). When the time span without new measured data was extended to 60 days, the evaluation error of the conventional method increased to 25.3% due to unchanged weights, while the error of this method only increased to 9.8% by automatically reducing the dynamic weight to 0.12, allowing the model simulation value to dominate the evaluation results (t=8.7, p=0.008). These results showed a consistent trend in 30 repeated experiments, indicating that this method has a statistically significant adaptive evaluation advantage in scenarios with sparse measured data or changing operating conditions.

[0046] Example 3: In satellite communication assurance processes, application modules and system modules drive network construction, user onboarding, and service network usage through user datagram message sequences. Since multiple concurrent task scenarios or satellite beam switching may introduce asynchronous signaling, traditional SysML timing diagrams can only describe ideal sequences and cannot quantify the probability of timing conflicts occurring when multiple signaling messages are interleaved. This embodiment maps each message in the SysML timing diagram to a partially ordered set of elements with timestamp intervals and dependencies. By constructing a message dependency graph and defining a conflict sensitivity function, the probability of timing conflicts between any two messages is calculated. This probability is dynamically quantified based on the message transmission delay distribution, processing delay variance, and the current system load, ultimately outputting a conflict risk index for the entire task scenario. This index can be used to guide application modules to adjust event-driven strategies or re-plan the task sequence, thereby proactively avoiding signaling collisions that may occur in the actual system during the simulation phase.

[0047] When constructing the scenario flow model, the application module automatically parses the lifelines and message arrows defined in the SysML sequence diagram. Each message is represented as a quintuple.

[0048] Due to variations in channel conditions during satellite communication, the actual transmission time follows a certain distribution. The expected arrival time of a message is defined as... ,in, This is the minimum transmission time given based on the SysML parametric model; The maximum transmission time is given by the SysML parametric model; variance The system module monitors the current network load factor in real time. The adjusted variance is ,in This is the load amplification factor.

[0049] For any two messages that have no direct dependency, a conflict may occur if their source or destination lifelines share resources. The probability of a conflict is defined as:

[0050] In the formula, This represents the probability of a timing conflict occurring between two messages that have no direct dependency. η The conflict sensitivity coefficient is set by the user according to the criticality of the task, and is preferably 2, which is used to adjust the steepness of the probability curve. For the message Expected arrival time; For the message The expected arrival time.

[0051] The formula is essentially a logistic function. The smaller the difference in the expected arrival times of two messages is relative to the joint standard deviation, the closer the probability of conflict approaches 1, and vice versa.

[0052] For all independent message pairs in the partially ordered set, accumulate the collision probabilities and normalize them. Define the overall risk index as:

[0053] In the formula, Φ is the message conflict risk index for the entire scenario task, with a value range of [0,1]. This represents the total number of messages in the sequence diagram; To ensure that each message pair is counted only once, the traversal conditions for the message index are used. Indicates message and There is no direct or indirect dependency between them; For the indicator function, if the message and If any physical or logical resource is shared, the value is 1; otherwise, it is 0.

[0054] The system module will feed back the calculated Φ to the application module in real time. If Φ exceeds a preset threshold, the application module will automatically perform one or more of the following operations: Insert a time offset into the scene task message to stagger the two originally concurrent messages; Reorder the sending sequence of scenario task messages to make dependencies clearer; Trigger the resource reservation mechanism in the system module to temporarily increase the processing latency limit of a certain lifeline to smooth out conflicts.

[0055] After adjustment, the timing diagram deduction is re-executed until Φ drops below the threshold, thereby completing the pre-elimination of signaling conflicts at the model level.

[0056] Compared to conventional modeling methods that rely solely on the ideal order of SysML timing diagrams for logical verification and cannot quantify the risk of concurrent signaling conflicts, this method introduces a message partial order set extraction and conflict probability quantification mechanism during the simulation and extrapolation phase, and performs comparative verification in a preset concurrent satellite beam switching scenario. The comparative data comes from two sets of control experiments on the same simulation platform: the experimental group enabled the conflict probability quantification and strategy adjustment functions of this invention, while the control group disabled these functions under the same simulation conditions (i.e., only executed the message sequence according to the ideal order of the timing diagram, without calculating conflict probability or adjusting the strategy), to simulate the modeling effect of conventional methods. The scenario was set as follows: three user terminals simultaneously initiated network access requests, two inter-satellite handover tasks, a total of 24 messages, a load factor of 0.7, and a conflict sensitivity coefficient of 2. Each experiment was repeated 30 times, and the significance of differences was assessed using an independent samples t-test (p<0.05). Experimental results show that conventional methods can only detect signaling collisions through subsequent physical integration testing, while this method can calculate the overall collision risk index at the model level as 0.43, exceeding the preset threshold of 0.3, and automatically trigger message offset insertion and sequence reordering strategies. After two rounds of iterative adjustments, this method reduced the collision risk index to 0.12 (t=10.5, p=0.003), while the control group, lacking quantitative prediction methods, showed a message out-of-order probability of 34.6% under the same simulation conditions, with an average additional signaling retransmission delay of approximately 2.1 seconds per inter-satellite handover. These results showed a consistent trend in 30 repeated experiments, indicating that this method has statistically significant superiority in signaling collision prediction and avoidance.

Claims

1. A SysML-based satellite communication assurance process simulation and modeling system, characterized in that, include: The application module is used to build application scenario models based on SysML, define the top-level goals, activity sequences and capability requirements of scenario tasks, and parse scenario tasks into executable scenario construction messages and scenario task messages, which are issued in an event-driven manner. The system module is used to build a digital model of the system based on SysML, receive messages sent by the application module, map the scenario task messages to the corresponding functions and behavior units in the digital model of the system, and perform process simulations of network construction, user access, and business network use accordingly, and evaluate the application response time of each process in real time. The application module and the system module interact via a communication protocol. The application module sends messages to the system module to drive the simulation, and the system module returns a response message to the application module after executing each process to provide feedback on the execution status.

2. The system according to claim 1, characterized in that: The system module acquires measured data from the satellite communication system, corrects and optimizes the evaluated application response time based on the measured data, and feeds back the corrected response time parameters to the application module.

3. The system according to claim 2, characterized in that: The application module compares the response time parameters fed back by the system module with the preset demand indicators, identifies the shortcomings that do not meet the indicators and quantifies the deviation, and generates satellite system construction suggestions based on the deviation; the comparison, identification and quantification process constitutes the system gap analysis.

4. The system according to claim 1, characterized in that, The message interaction between the application module and the system module specifically includes: The application module sends a topology import message to the system module, which carries a network topology specification description required for the scenario. After receiving the message, the system module establishes the network topology and configures the underlying links in its system digital model according to the specification description, and then returns a topology import response message. The application module sends a scenario import message to the system module to trigger the system module to generate a communication scheme and allocate satellite resources, and then the system module returns a scenario import response message.

5. The system according to claim 4, characterized in that: The scenario task message sent by the application module to the system module includes sequential triggering instructions for network establishment, user network access, and service network use, as well as the behavioral parameters required for each stage. After receiving the trigger instructions for each stage, the system module drives its system digital model to perform the simulation of the corresponding stage. After completing the response time evaluation, it returns a scenario task response message carrying simulation data to the application module. The application module advances the simulation progress of the scenario task based on the response message.

6. The system according to claim 1, characterized in that: The system module acquires historical measured response time data and constructs a time series, uses a trend prediction algorithm to generate trend prediction values ​​for response time, constructs a dynamic weight function based on the timeliness of measured data and prediction deviation, and adaptively adjusts the weight according to the system operating condition change rate. The trend prediction value is fused with the theoretical response time based on the SysML behavioral model simulation using the dynamic weights to generate the final evaluation response time.

7. The system according to claim 1, characterized in that: The system module extracts message sequences and their time constraints and dependencies from the SysML sequence diagram constructed by the application module, and constructs a message partial order set; identifies message pairs without direct dependencies, and calculates the probability of time-series conflict between message pairs based on the uncertainty distribution of shared resource status and message arrival time; summarizes the conflict probabilities of all message pairs, generates a conflict risk index for the overall scenario task, and adjusts the message sending strategy of the scenario task according to the index.

8. The system according to claim 1, characterized in that: The application scenario model constructed by the application module is a specification-descriptive model, including: a scenario requirement model, used to define top-level concepts, scenario goals, and capability requirements; a scenario process model, used to decompose scenario goals into serialized scenario activities and interactive information flows; and a scenario unit model, used to describe the entities participating in the activities and their collaborative relationships. The application module encapsulates the activity sequence and information flow in the scenario model into scenario task messages and sends them to the system module to drive simulation execution.

9. The system according to claim 1, characterized in that: The system module is also used to perform time sequence flow and signaling interaction modeling of the behavior of the space segment, ground segment and user segment during network construction, user access and service network use, and interact with the application module through the communication protocol to present the time sequence flow and signaling interaction relationship in the time sequence diagram in real time.

10. A method for modeling and extrapolating satellite communication assurance processes based on SysML, characterized in that: The method is implemented based on the system described in any one of claims 1-9: The method includes: The application module builds an application scenario model based on SysML, and uses scenario tasks as events to generate scenario building messages and scenario task messages. The message is sent to the system module via a communication protocol; The system modules construct a digital model of the system based on SysML. After receiving the message, the system sequentially performs the process simulation of network construction, user network access, and business network use, and evaluates the application response time of each process in real time. After completing each process, the system module returns a response message to the application module, and the application module drives the simulation progress of the scenario task based on the response message.

Images