Risk Simulation and Security Boundary Assessment of Avionics Systems Using Digital Twin Techniques

1. Introduction

Modern avionics systems rely heavily on software to support flight control, monitoring, communication, and maintenance coordination. As these systems evolve, software must be updated frequently to correct faults, address security vulnerabilities, and introduce new functions. Core flight and mission-support systems now consist of large and complex code bases, where a single defect can affect multiple aircraft across a fleet [1,2]. Several recent incidents illustrate how unexpected software behavior can trigger rapid, fleet-wide responses and place significant pressure on airline operations [3]. These developments underscore the need for update mechanisms that are not only efficient but also predictable and low risk under operational constraints. Over-the-air (OTA) updates are widely adopted in other regulated industries because they reduce downtime and eliminate the need for physical access to deployed systems [4]. In aviation, however, software updates remain tightly coupled to scheduled maintenance windows and strict configuration management rules [5]. Although cloud-native OTA pipelines have been proposed for avionics contexts, their behavior under real operational conditions—such as update timing, batch size selection, communication load, and rollback handling—has not been sufficiently validated [6,7]. As a result, airlines remain cautious in adopting OTA beyond limited and well-controlled scenarios.

Digital twin technology provides a promising means to explore these issues without impacting live aircraft. Existing aviation digital twins are widely used for structural assessment, propulsion health monitoring, and maintenance planning [8]. More recent systems integrate sensor data with simulation environments to support condition monitoring, crew training, and operational analysis [9]. These studies demonstrate that digital twins can replay realistic operational scenarios and evaluate the effects of different policies. Nevertheless, most current twins focus primarily on hardware degradation and physical systems, while software updates—particularly fleet-wide OTA processes—are rarely modeled in detail. Recent work on cloud-native OTA architectures for regulated and safety-critical domains further suggests that update strategies cannot be transferred directly from enterprise IT environments without explicit consideration of operational control and safety constraints [10], reinforcing the need for aviation-specific evaluation frameworks. Discrete-event simulation (DES) and system dynamics (SD) are well-established tools in aviation operations research. DES is commonly used to model event-driven processes such as failures, inspections, task queues, and maintenance actions, while SD captures long-term feedback between reliability, maintenance workload, and resource utilization [11]. In existing studies, these methods are often applied separately and rely on simplified assumptions regarding software logic, communication quality, and operator decision-making. As a result, interactions between event-level software update behavior and fleet-level risk accumulation remain insufficiently understood. Risk modeling in aviation has advanced through the use of rare-event simulation and importance sampling, supporting safety assessment in areas such as loss of separation and landing risk [12]. These approaches are effective in quantifying how small disturbances can accumulate into unsafe states. However, they are rarely applied to OTA processes, even though software rollouts can introduce transient risk windows during staged deployment and rollback. Research on avionics OTA therefore remains fragmented. Many studies describe OTA architectures or security mechanisms but do not examine how strategy parameters interact with real flight schedules or maintenance workflows [13,14]. Industry reports point to increasing use of secure OTA solutions, yet few provide transparent, data-driven evaluations under realistic operational disturbances [23], [15]. Digital twin studies, in turn, often rely on limited datasets or a small number of test strategies, making it difficult to capture heterogeneous fleet behavior or rare combinations of communication issues and software faults [16]. These considerations motivate the development of a more comprehensive modeling approach for avionics OTA. Such an approach must connect onboard software configuration states, air–ground communication behavior, and maintenance processes; operate on large-scale operational data; and allow systematic exploration of different OTA strategies. It must also support quantitative assessment of risk evolution to inform both certification and operational planning.

In this study, a digital-twin-based framework is developed to analyze fleet-wide OTA update strategies for avionics systems. The framework couples software configuration changes, communication link dynamics, and maintenance workflows within a unified model. Discrete-event simulation is used to represent update-related events, including triggering, transmission, verification, and rollback, while system dynamics captures the long-term evolution of risk exposure and maintenance load. The model is calibrated using three years of operational logs comprising 7.2×10⁸ entries and is used to evaluate 32 OTA strategy combinations. Importance sampling is applied to estimate module-level risk contributions and to derive safety boundary curves for OTA deployment. The results provide quantitative insight into how OTA strategies influence fleet-level risk and operational stability, offering a data-driven basis for safer adoption of cloud-native OTA updates in avionics systems.

2. Materials and Methods

2.1. Sample and Study Area Description

The study uses operational records from a commercial fleet with network-connected avionics. The dataset contains 7.2×10⁸ log entries collected over 36 months. These records include software update attempts, link states, flight schedules, and maintenance actions. All aircraft use the same avionics software structure with modules for flight control, communication, and fault handling. The sample covers routes of different lengths and link conditions, allowing the model to represent typical and irregular operating states. This range of data provides the basis for testing OTA update strategies under realistic conditions.

2.2. Experimental Design and Control Setup

The experiment tests 32 OTA update strategies in a digital-twin environment that mirrors onboard software behavior, air–ground communication, and maintenance steps. Each strategy defines different rules for when to start an update, how to divide batches, how to set dynamic thresholds, and when to trigger a rollback. A control group represents the current practice where updates occur only during scheduled ground maintenance without dynamic checks. Flight schedules, fleet size, and operational conditions remain fixed across all runs. This setting ensures that differences in results come from the update strategies rather than outside factors.

2.3. Measurement Procedures and Quality Control

All simulation runs follow the same steps: initialize events, replay time-ordered logs, start update transmission, verify results, execute the flight mission, and record post-update checks. Link disturbances are modeled using measured latency, jitter, and packet-loss statistics. System states are sampled at fixed intervals to record update progress and potential fault signals. Quality control includes repeated runs for each strategy, comparison of simulated link behavior with historical patterns, and manual review of abnormal events. Events that fall outside the limits defined by the manufacturer or maintenance guidelines are marked and removed from analysis.

2.4. Data Processing and Model Formulation

Log data are processed through time alignment, event merging, and removal of noise entries. A discrete-event engine handles update events, while an additional layer tracks changes in fleet-level exposure and maintenance load. The probability that aircraft i completes an update under strategy s is computed using a logistic form [17]:

$$P_{i,s}={\displaystyle \frac{1}{1+\mathit{exp}[-({\beta }_0+{\beta }_1{L}_i+{\beta }_2{B}_s+{\beta }_3{R}_s\left)\right]}},$$

where ${\mathrm{L}}_{\mathrm{i}}$ is the link-quality index, ${\mathrm{B}}_{\mathrm{s}}$ is the batch size, and ${\mathrm{R}}_{\mathrm{s}}$ is the rollback threshold. Fleet-level exposure is calculated as:

$${\mathrm{E}}_{\mathrm{s}}=\sum _{\mathrm{i}=1}^{\mathrm{N}}{\mathrm{w}}_{\mathrm{i}}{\mathrm{q}}_{\mathrm{i},\mathrm{s}},$$

where ${\mathrm{w}}_{\mathrm{i}}$ is the mission weight for aircraft i and ${\mathrm{q}}_{\mathrm{i},\mathrm{s}}$ is the probability that an update produces a fault-related condition. These indicators are used to compare strategies and define safety limits.

3. Results and Discussion

3.1. Fleet-Level Behavior of OTA Strategies

Fleet simulations were first used to compare the 32 OTA strategies in terms of update completion, mission impact, and exposure value EsE_sEs​. As shown in Figure 1, single-shot updates finish quickly but create the highest exposure because many aircraft run the new version before enough feedback is available. Fixed batches lower exposure but show small spikes in aborted updates when link quality drops during flight. Static thresholds perform better under stable links but still react poorly to short, high-noise periods. The combined “batch + dynamic threshold + delayed rollback” strategy reduces exposure by 48.3% while keeping mission impact similar to current scheduled-maintenance practice. This confirms that the timing of rollback and threshold adjustment matters as much as batch size. Earlier digital-twin studies in aviation mainly tracked structural loads or maintenance cycles [18], but Figure 1 highlights software-related exposure as a measurable fleet metric.

3.2. Influence of Batch Size, Link Variation, and Rollback Delay

Next, we analyzed how batch size, link variation, and rollback delay shape both exposure and workload. Large batches shorten the update campaign but raise the fraction of aircraft running a partially tested version, which results in sharper exposure curves in Figure 1 under unstable links. When rollback triggers are too strict, link jitter causes repeated partial rollbacks and creates extra maintenance load. Small batches avoid this but may push updates into busy seasons with limited ground time. Dynamic thresholds reduce unnecessary rollbacks by adjusting sensitivity to current error rates and link quality. When combined with delayed rollback, the number of back-and-forth state switches drops. This behavior differs from earlier aircraft digital-twin studies, where communication issues and batch choices were simplified or not included [19,20]. These results show that OTA performance depends on both batch design and link-aware decision rules.

3.3. Module-Level Risk Breakdown and Safety Boundaries

Importance sampling was applied to identify which modules—update agent, communication stack, or ground scheduling logic—contribute most to residual risk. Figure 2 shows that under single-shot or fixed batches, most risk comes from the communication stack because link disturbances directly affect update completion. Dynamic thresholds and delayed rollback reduce this impact, shifting more of the remaining risk to the update agent, where edge-case state transitions still occur. The ground scheduling logic contributes less but becomes visible when very small batches are used, since schedule mismatches then affect a larger share of updates. These results were used to derive safety boundary curves that link batch size, threshold level, and rollback delay to an upper bound on Es. Earlier work often reported only mission-level results [21], while Figure 2 provides module-specific boundaries that can support engineering reviews and certification discussions.

3.4. Comparison with Existing Studies and Engineering Implications

We compared our findings with published results in OTA and aviation digital-twin research. Previous studies focused mainly on maintenance prediction or aircraft design and did not include end-to-end OTA processes with large operational logs [22]. Industrial OTA reports also discuss benefits but rarely provide quantitative results under real disturbances [23]. In contrast, the present simulations use three years of operational logs and explicit strategy combinations, making the results closer to engineering practice. The study still has limits: error events related to security are represented only as changes in error rates; human actions in maintenance are simplified; and the analysis covers one fleet configuration. Thus, the proposed boundary curves should be viewed as engineering guidance rather than final certification limits. Even with these limits, the results show that linking software updates, communication behavior, and maintenance timing in a digital twin can make OTA strategy design and safety assessment more precise.

4. Conclusion

This study used a digital-twin model to examine OTA update risk in modern avionics and evaluated 32 rollout strategies using three years of operational logs. The results show that a combination of batch updates, dynamic thresholds, and delayed rollback can cut exposure by almost half while keeping flight missions unaffected. The analysis also identifies how the update agent, the communication link, and ground scheduling each add to the remaining risk, and these estimates were used to form safety limit curves that can guide engineering and certification discussions. The study shows that software-focused digital twins can give practical support for planning OTA campaigns, which has been difficult to assess with routine maintenance data alone. The approach can help operators choose rollout plans that match link conditions, workload limits, and update timing. The work still has limits, including simplified human actions, a single fleet type, and no detailed security faults. Future studies should expand the model to more aircraft types, include security-related events, and add real-time link prediction to support in-service OTA decisions.