Review Reports - QEMU-Based 1553B Bus Simulation and Precise Timing Modeling Method

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This paper provides a virtual time-driven precise timing modeling method that explicitly models key timing semantics as discrete events on a virtual timeline.
The experimental results using 10 timing scenarios support that the method reduces timing deviation, thereby achieving deterministic simulation decoupled from host execution speed while meeting the minimum resolution requirement. This work addresses the gap in virtualization platforms for modeling 1553B protocol timing semantics, and thus provides a low-cost, reproducible, and high-precision simulation environment for protocol compliance verification, driver development, and system integration.
Overall, this paper looks interesting and seems to be a meaningful work. Also, this paper is technically sound and highly relevant to the embedded systems and aerospace simulation communities.
Therefore, I recommend its publication in Electronics after a minor revision.

Comments:

1. On page 9, Figure 5: The figure shows the internal architecture of the Enhanced BC.
But the caption reads "Latency comparison between optimized virtual time event-driven approach (left) using queue (q) with precise t_v^{fire} triggering, and traditional main-loop approach (right)..."
It's awkward that the caption descibes completely different things. Also, there are no left and right parts in the figure.
Please revise the caption.

2. On page 11, Figure 6: The figure shows the BC frame timing diagram (CPU Execution, time axis).
But the caption reads "1553B bus system architecture with Bus Controller (BC), Remote Terminals (RT1, RT2), and Monitor Terminal (MT)".
I guess this caption belongs to Figure 5 on page 9.
Please revise the caption.

3. Section 4 explains the grid-based virtual timeline, but the interface with QEMU's timing infrastructure needs more detail, in order to be reproducible.
Does your proposed virtual time-driven mechanism rely on QEMU's "icount" to drive the virtual clock, or have you implemented a custom discrete event scheduler that overrides QEMU's default timer subsystem?

4. In the paper, the authors refer to a B64843GC device. I think this refers to the widely used DDC BU-64843 or similar ACE-compatible controllers, but the naming convention is slightly non-standard. I suggest the authors to clearly state if this models a specific commercial off-the-shelf (COTS) component (like Data Device Corporation BU-64843) or if it is a generic model.

5. On page 16, line 513: The authors mention that "Additionally, the virtual time mechanism introduces approximately 45 ns overhead per event for event queue management".
However, this was not mentioned in Section 5.2 (Experimental Results and Analysis).
I suggest that this is also mentioned in Section 5.2 .
Also, please clarify if this 45 ns overhead scales linearly with the number of terminals (RTs) on the bus.

Author Response

Thank you very much for your careful reading and constructive comments. We have revised the manuscript point-by-point. All revisions are highlighted in red in the revised PDF. Comment 1: On page 9, Figure 5: The figure shows the internal architecture of the Enhanced BC.
But the caption reads "Latency comparison between optimized virtual time event-driven approach (left) using queue (q) with precise t_v^{fire} triggering, and traditional main-loop approach (right)..."
It's awkward that the caption descibes completely different things. Also, there are no left and right parts in the figure.
Please revise the caption. Response 1: Thank you for identifying this mismatch. We fixed this by reorganizing the figure order in the architecture section: the original Figure 5 was moved to Section 3.1 as the current Figure 1, and the subsequent figure numbers were shifted accordingly. After this renumbering, the caption-content mismatch was removed. Revision note: "The original Figure 5 has been moved to Section 3.1 as Figure 1, and all following figure numbers have been updated in sequence." Location in revised PDF: Section 3.1 figure block (current Figure 1) and the updated downstream figure numbering. Comment 2: On page 11, Figure 6: The figure shows the BC frame timing diagram (CPU Execution, time axis).
But the caption reads "1553B bus system architecture with Bus Controller (BC), Remote Terminals (RT1, RT2), and Monitor Terminal (MT)".
I guess this caption belongs to Figure 5 on page 9.
Please revise the caption. Response 2: Thank you for this important correction. We fixed the figure order and caption mapping in this part as follows: the original Figure 4 was moved to the current Figure 5, and the current Figure 6 caption was corrected accordingly. Revision note: "The original Figure 4 is now Figure 5 after renumbering, and Figure 6 caption has been corrected to match its actual content." Location in revised PDF: current Figure 5 and current Figure 6 caption blocks in the revised manuscript. Comment3: Section 4 explains the grid-based virtual timeline, but the interface with QEMU's timing infrastructure needs more detail, in order to be reproducible.
Does your proposed virtual time-driven mechanism rely on QEMU's "icount" to drive the virtual clock, or have you implemented a custom discrete event scheduler that overrides QEMU's default timer subsystem? Response 3: Thank you for this reproducibility question. We added a detailed implementation description in Section 4.2 to clarify the interface with QEMU timing:
1) The mechanism is based on QEMU TCG icount mode and QEMU_CLOCK_VIRTUAL. 2) We run with TCG single-thread and icount enabled (example options included in text). 3) We implement a device-local discrete-event scheduler on top of QEMU_CLOCK_VIRTUAL. 4) This scheduler does not replace QEMU's default timer subsystem; it uses one QEMUTimer to drive due events and re-arm to the next deadline.
Representative revised text: "Our virtual time-driven mechanism is built on top of QEMU's TCG instruction counting (icount) mode..." "On top of QEMU_CLOCK_VIRTUAL, we implement a lightweight device-local discrete-event scheduler... This scheduler does not replace QEMU's default timer subsystem..."
Location in revised PDF: Lines 478-485 and 486-494 (Section 4.2 interface with icount/QEMU timer subsystem), and determinism setup line at 511 (Section 5.1). Comment 4: In the paper, the authors refer to a B64843GC device. I think this refers to the widely used DDC BU-64843 or similar ACE-compatible controllers, but the naming convention is slightly non-standard. I suggest the authors to clearly state if this models a specific commercial off-the-shelf (COTS) component (like Data Device Corporation BU-64843) or if it is a generic model. Response 4: Thank you for this suggestion. We standardized the naming to BU-64843 and clarified the modeled component as a COTS device from Data Device Corporation (DDC).
Revised text: "This research simulates the 1553B bus based on the BU-64843 interface device, a commercial off-the-shelf (COTS) 1553B terminal from Data Device Corporation (DDC)..."
Location in revised PDF: Lines 260-263 (Figure 2 context + COTS clarification) and Lines 260-270 (Section 3.2 unified device model details). Comment 5: On page 16, line 513: The authors mention that "Additionally, the virtual time mechanism introduces approximately 45 ns overhead per event for event queue management".
However, this was not mentioned in Section 5.2 (Experimental Results and Analysis).
I suggest that this is also mentioned in Section 5.2 .
Also, please clarify if this 45 ns overhead scales linearly with the number of terminals (RTs) on the bus. Response 5: Thank you for this valuable comment. We added an explicit overhead analysis in Section 5.2 and clarified scaling behavior.
We now report measured overhead directly in Section 5.2 based on the 10-scenario statistics (overall mean about 111 ns, with 65-124 ns range). We also clarified that, in our tested configurations, the overhead is mainly associated with scheduler processing and does not show a clear linear increase with RT count. The corresponding statement in the Conclusions/Limitations discussion has been synchronized accordingly.
Representative revised text: "Overhead Analysis: ... overall mean of approximately 111 ns..." "...does not show a clear linear increase with RT count."
Location in revised PDF: Section 5.2 overhead paragraph: Lines 573-584 Supporting example (96 ns vs 5398 ns latency): Lines 552-556 Discussion/Limitations consistency update: Lines 645-651 We sincerely appreciate your insightful comments, which helped us improve clarity, reproducibility, and technical rigor of the manuscript.

Reviewer 2 Report

Comments and Suggestions for Authors

on line 487-488, It would be more accurate to say: "...the optimized method maintains..." (adding "the" before "optimized method").

The experimental results demonstrate a dramatic improvement in determinism compared to the traditional QEMU approach. However, how does the temporal accuracy of their model (65-124 ns) compare with actual measurements of a physical B64843GC chip in an equivalent test bench scenario? Without this validation, how can we be sure that the model is accurate and not just "perfectly" inaccurate in a different way?

Their "virtual time" method is tightly coupled to the timing semantics of the 1553B protocol (message intervals, timeouts, etc.). How feasible would it be to abstract this methodology to model other communication protocols in QEMU (e.g., CAN, TTEthernet, ARINC 429) that also have strict timing requirements? Have you considered creating a generic framework within QEMU for this purpose?

The authors mention an overhead of ~45 ns per event for event queue management. In a complex simulation scenario with a high message rate (e.g., hundreds of messages per frame) and multiple active timers, have you analyzed how this overhead accumulates and whether it could affect overall simulation performance or even introduce unwanted latency into the event handling itself?

Could you add a section comparing the model's timings to those of a real chip? If that's not possible, at least discuss this limitation in more detail and propose it as the next clear step in future research.

In Section 2.4, when comparing with works such as [1] and [2], the difference could be quantified more directly. For example, stating: "While [1] reports an end-to-end latency of ~X µs, our method achieves Y ns, representing a Z-fold improvement." This would make the comparison more impactful.

Section 5.1 mentions that the experiments are compared "under load." It would be helpful to specify what type of load was placed on the host for testing (e.g., CPU or memory saturation). This would make the results more reproducible and robust.

Author Response

Dear Reviewer 2,
Thank you very much for your careful reading and constructive comments. We have revised the manuscript point-by-point according to your suggestions. All revisions are highlighted in red in the revised manuscript.
Comment 1: on line 487-488, It would be more accurate to say: "...the optimized method maintains..." (adding "the" before "optimized method").
Response 1: Thank you for this careful language correction. We added the article "the" before "optimized method" at the relevant locations for grammatical consistency.
Revised text examples: "...while the optimized method maintains..." "...while the optimized data maintains..." "...while the optimized method (right) triggers..."
Location in revised PDF: Figure 7 caption block on Page 16 (between Lines 555-556), Figure 8 caption block on Page 16 (between Lines 558-559), and Figure 10 caption block on Page 18 (between Lines 568-569).

Comment 2: The experimental results demonstrate a dramatic improvement in determinism compared to the traditional QEMU approach. However, how does the temporal accuracy of their model (65-124 ns) compare with actual measurements of a physical B64843GC chip in an equivalent test bench scenario? Without this validation, how can we be sure that the model is accurate and not just "perfectly" inaccurate in a different way?
Response 2: Thank you for this important point. We agree that physical-chip validation is essential for assessing absolute accuracy. At present, we do not have access to a BU-64843 chip and therefore cannot perform equivalent hardware bench measurements in this revision cycle. We added this as a limitation and clarified that systematic bias cannot be fully excluded without physical measurements.
Revised text excerpt: "...does not include direct comparison with a physical BU-64843 chip... we cannot rule out the possibility of systematic bias... physical hardware measurements are needed to validate absolute accuracy..."
Location in revised PDF: Lines 636-642.

Comment 3: Their "virtual time" method is tightly coupled to the timing semantics of the 1553B protocol (message intervals, timeouts, etc.). How feasible would it be to abstract this methodology to model other communication protocols in QEMU (e.g., CAN, TTEthernet, ARINC 429) that also have strict timing requirements? Have you considered creating a generic framework within QEMU for this purpose? Response 3: Thank you for this valuable suggestion. We expanded Future Work to discuss abstraction of our virtual-time method into a protocol-agnostic timing framework in QEMU. We also clarified protocol-specific mapping requirements for CAN, TTEthernet, and ARINC 429.
Revised text excerpt: "...abstracting the virtual time-driven approach into a generic timing framework within QEMU... CAN requires arbitration and bit-timing modeling, TTEthernet requires time-triggered scheduling..., and ARINC 429 requires word-gap and rate control."
Location in revised PDF: Lines 618-621 (Discussion Section 6.2 protocol mapping examples) and Lines 666-671 (Future Work protocol abstraction details).

Comment 4: The authors mention an overhead of ~45 ns per event for event queue management. In a complex simulation scenario with a high message rate (e.g., hundreds of messages per frame) and multiple active timers, have you analyzed how this overhead accumulates and whether it could affect overall simulation performance or even introduce unwanted latency into the event handling itself?
Response 4: Thank you for this question. We rewrote the Overhead Analysis section to address accumulation behavior. We now clarify that timing errors do not accumulate across successive events because each deadline is computed from the absolute protocol timebase, not from previous actual firing times. We also report that active timers are few in typical configurations, making queue-management overhead negligible in practice.
Revised text excerpt: "...timing errors do not accumulate across successive events... drift ... remains bounded by a single Delta t..."
Location in revised PDF: Lines 574-583.

Comment 5: Could you add a section comparing the model's timings to those of a real chip? If that's not possible, at least discuss this limitation in more detail and propose it as the next clear step in future research.
Response 5: Thank you for this recommendation. Since direct hardware comparison is not currently possible, we expanded the Limitations section and made physical-chip validation the first priority in Future Work.
Revised text excerpt: "...the most immediate priority is validating our model against a physical BU-64843 (or equivalent DDC BU-61580) chip..."
Location in revised PDF: Lines 636-642 (Limitation details) and Lines 662-664 (Future Work priority).

Comment 6: In Section 2.4, when comparing with works such as [1] and [2], the difference could be quantified more directly. For example, stating: "While [1] reports an end-to-end latency of ~X µs, our method achieves Y ns, representing a Z-fold improvement." This would make the comparison more impactful.
Response 6: Thank you for this suggestion. We strengthened the quantitative comparison in Section 2.4 by adding numerical values and improvement magnitude, including approximately 100 us end-to-end latency for prior DDS-based approaches and more than 160x reduction in timing deviation for our method.
Revised text excerpt: "...(approximately 100 us end-to-end latency)..." and "...representing a reduction of more than 160x in timing deviation."
Location in revised PDF: Lines 214-220 and Line 229.
Comment 7: Section 5.1 mentions that the experiments are compared "under load." It would be helpful to specify what type of load was placed on the host for testing (e.g., CPU or memory saturation). This would make the results more reproducible and robust.
Response 7: Thank you for pointing this out. We clarified this in two places. In Section 5.1, we defined "load" as 1553B communication workload (BC/RT1/RT2/MT active, frame auto-repeat, command/response exchanges). In Section 5.2, we replaced the original generic wording with a specific workload description.
Revised text excerpt: "In this study, the term "load" refers to the 1553B communication workload..."
Location in revised PDF: Lines 514-517 (new clarification paragraph) and Lines 532-533 (revised wording in Section 5.2).
We sincerely appreciate your insightful comments, which helped us improve technical clarity, reproducibility, and the completeness of our discussion.

Reviewer 3 Report

Comments and Suggestions for Authors

This paper presents a simulation environment that applies virtualization techniques to the important communication protocol MIL‑STD‑1553B, which is an interesting technique from the perspective of embedded systems engineering.

However, the technical focus of the paper is rather narrow and overly specialized to the specific target protocol. For a scientific and technical research article, the authors should extract the essential ideas of their proposed method and describe them in a more generalized manner.

If the paper is too tightly focused on a single topic, it risks reading more like a technical specification than a research contribution, making it difficult for readers to fully appreciate the advantages of the authors’ approach.

In addition, considering this point, it would be advisable to include a dedicated Discussion section to reflect on the broader implications and applicability of the proposed method.

Comment 1. Appropriateness of using QEMU

From the standpoint of the paper’s stated goal—detailed timing modeling—the use of a virtualized environment such as QEMU will likely appear questionable to a typical reader. This is because QEMU operates on virtual time rather than real time, making it inherently difficult to reproduce the behavior of physical embedded systems, particularly those involving time‑sensitive communication.

In the case of MIL‑STD‑1553B, which operates at 1 Mbps, the achievable timing fidelity is constrained by the performance and load of the host CPU. As a result, microsecond‑level timing accuracy cannot be guaranteed in a QEMU‑based simulation.

As the authors themselves note in their related‑work survey, numerous software‑based timing analysis approaches have been studied extensively—not only for 1553B but also for many other communication protocols. This is a well‑developed research area.

Therefore, the authors need to more clearly articulate the unique advantages of leveraging QEMU in their approach, and convincingly explain why their method offers benefits beyond existing software‑based simulation techniques. Strengthening this argument is essential for readers to appreciate the contribution and superiority of the proposed method.

Comment 2 Paper structure

This paper lacks a dedicated Discussion section.

In a scientific and technical research article, an independent Discussion chapter should always be included.

The Instructions for Authors provided by MDPI offer a useful reference:

https://www.mdpi.com/journal/electronics/instructions

Comment 3. Formulation

The formulation in this paper appears insufficient.

For a scientific and technical study, the authors should provide a clear and rigorous formulation of the key aspects of their method, including the design rationale and the timing evaluation.

A proper formalization would enable more quantitative analysis and would strengthen the credibility of the claimed applicability of QEMU for timing‑related investigations.

Comment 4. Technical Scope of the Proposed Method

The proposed use of QEMU as a simulation approach for the specific case of MIL‑STD‑1553B appears to have a rather narrow application scope, which may make it difficult for readers to fully appreciate the advantages of the method.

Is the proposed technique not applicable to arbitrary HIL (Hardware‑in‑the‑Loop) environments?

If the method can indeed be applied to general HIL systems, I would recommend reframing the main contribution of the paper as a general technical approach, and then presenting the 1553B protocol design as a case study within the Discussion or Evaluation.

Conversely, if the method is inherently difficult to generalize and is specifically tailored to the unique characteristics of 1553B, then the authors should clearly explain why 1553B is essential and how the method is designed around its particular constraints. This rationale should be explicitly discussed in both the methodological description and the Discussion section.

Author Response

Comment 1. Appropriateness of using QEMU

Response 1: Thank you for raising this critical concern. We agree that the original manuscript did not sufficiently justify the choice of QEMU for timing-sensitive simulation. We have addressed this in two ways.
First, we strengthened the Introduction (Lines 71–77) to explain why QEMU's virtual time is an advantage rather than a limitation: "We choose QEMU as the virtualization platform because its icount mode provides a deterministic virtual timebase tied to instruction execution rather than host wall-clock time, enabling fully reproducible timing behavior; combined with full-system emulation capability and an extensive device model ecosystem, QEMU offers a unique foundation for timing-sensitive bus simulation that pure protocol simulators or cycle-accurate models cannot easily match (see Section 6.1 for a detailed discussion)."
Second, we added a new Section 6.1 "Appropriateness of QEMU for Timing-Sensitive Simulation" (Lines 586–606), which addresses the reviewer's concern. This subsection explains that QEMU's icount mode creates a fully deterministic timebase independent of host CPU speed, scheduling jitter, or system load, which is the property that enables sub-microsecond timing fidelity. Unlike pure protocol simulators, QEMU performs full-system emulation encompassing CPU, memory controller, interrupt subsystem, and peripheral devices, so real device drivers and operating systems can run in a closed loop. QEMU's device model ecosystem also supports rapid construction of multi-node verification environments, and the entire simulation runs on commodity hardware without physical bus interface chips, enabling fully reproducible experiments.
Revised text excerpt (from Section 6.1): "A typical concern regarding QEMU-based timing simulation is that QEMU operates on virtual time rather than wall-clock time. However, this characteristic is precisely what enables deterministic timing reproduction. In QEMU's icount mode, virtual time advances in lockstep with the number of executed guest instructions, creating a fully deterministic timebase that is independent of host CPU speed, scheduling jitter, or system load."
Location in revised PDF: Lines 71–77 (Introduction) and Lines 586–606 (Section 6.1).

Comment 2 Paper structure

This paper lacks a dedicated Discussion section.

In a scientific and technical research article, an independent Discussion chapter should always be included.

The Instructions for Authors provided by MDPI offer a useful reference:

https://www.mdpi.com/journal/electronics/instructions

Response 2: Thank you for this recommendation. We agree that a Discussion section is essential. We added a new Section 6 "Discussion" containing three subsections. Section 6.1 "Appropriateness of QEMU for Timing-Sensitive Simulation" (Lines 586–606) addresses the rationale for using QEMU, as detailed in our response to Comment 1. Section 6.2 "Generalizability to Other Protocols and HIL Environments" (Lines 607–629) discusses protocol-agnostic components and adaptation to other bus protocols, as detailed in our response to Comment 4. Section 6.3 "Limitations" (Lines 630–651) consolidates and expands the limitations discussion, covering asynchronous event contention, absence of physical chip comparison, overhead characteristics, and idealized bus assumptions.
The original Conclusions section has been renumbered to Section 7 (Lines 652–679), with the limitations content migrated to Section 6.3 to avoid redundancy. The Introduction's section guide (Lines 103–109) has been updated accordingly: "Section 6 discusses the appropriateness of QEMU for timing-sensitive simulation, the generalizability of the approach to other protocols, and its limitations; Section 7 concludes the paper and discusses future work."
Location in revised PDF: Section 6 Discussion (Lines 585–651), Section 7 Conclusions (Lines 652–679), and updated section guide (Lines 103–109).

Comment 3. Formulation

The formulation in this paper appears insufficient.

For a scientific and technical study, the authors should provide a clear and rigorous formulation of the key aspects of their method, including the design rationale and the timing evaluation.

A proper formalization would enable more quantitative analysis and would strengthen the credibility of the claimed applicability of QEMU for timing‑related investigations.

Response 3: Thank you for this suggestion. We agree that formal treatment strengthens the paper. We added a mathematical formalization in Section 4.2 (Lines 447–473), and we summarize it below in plain-text notation for readability in this response.
We define the virtual time model with virtual time `Tv >= 0`, driven by QEMU icount. The quantization grid is `G = {k * Delta_t | k in N}` with `Delta_t = 256 ns`. Timing events are modeled as tuples `e_i = (t_fire_i, c_i)`, and fire time is computed by Equation (1): `t_fire_i = ceil(t_deadline_i / Delta_t) * Delta_t` (Lines 447–455). We then prove two propositions. Proposition 1 (single-event error bound): for any event `e_i`, quantization error satisfies `0 <= t_fire_i - t_deadline_i < Delta_t` (Lines 456–459). Proposition 2 (non-accumulation of errors): the quantization error of event `n` is independent of previous events, because each deadline is computed from the absolute protocol timebase rather than from the previous actual fire time (Lines 460–466). A corollary follows: since `Delta_t = 256 ns < 1 us`, the method satisfies the MIL-STD-1553B minimum timing resolution for all events, and expected mean quantization error is `Delta_t / 2 ~ 128 ns` (Lines 467–469). Finally, Algorithm 1 (Virtual Time Event Scheduler) gives formal pseudocode for deadline quantization, priority-queue insertion, QEMU timer arming, and event dispatch (Lines 470–473).
Revised text excerpt: "Proposition 1 (Single-event error bound). For any event e_i, the quantization error satisfies 0 <= t_fire_i - t_deadline_i < Delta_t." "Proposition 2 (Non-accumulation of errors). The quantization error of the n-th event is independent of all preceding events."
Location in revised PDF: Lines 447–473 (Section 4.2).

Comment 4. Technical Scope of the Proposed Method

Is the proposed technique not applicable to arbitrary HIL (Hardware‑in‑the‑Loop) environments?

Response 4: Thank you for this suggestion. We agree that the method's generalizability should be clearly stated. As the reviewer identifies, the core technique is applicable to general HIL environments, and we have reframed the paper to present the method as a general approach with 1553B as a representative case study.
In the Abstract and Introduction, we now position the paper as addressing "the general challenge of achieving deterministic timing reproduction in QEMU-based full-system simulation" (Line 78), with contributions explicitly noting generality (e.g., "While instantiated here for 1553B, the methodology applies to any protocol with microsecond-level timing constraints", Lines 91–92).
We added a new Section 6.2 "Generalizability to Other Protocols and HIL Environments" (Lines 607–629). This section explains that the three core components—icount-based deterministic execution, virtual time event scheduling with deadline-driven callback dispatch, and quantization grid alignment—are protocol-agnostic (Lines 609–614). The protocol-specific aspect lies only in the timing semantic mapping: CAN requires arbitration and bit-timing modeling, TTEthernet requires time-triggered scheduling and clock synchronization semantics, and ARINC 429 requires inter-word gaps and transmission rate control (Lines 615–621). MIL-STD-1553B was selected as the validation case because its strict microsecond-level timing constraints provide demanding test conditions for the method (Lines 623–626). We envision a two-layer architecture—a protocol-agnostic virtual time framework coupled with protocol-specific adaptation modules—as the natural extension (Lines 627–629).
Revised text excerpt (from Section 6.2): "Although this paper focuses on MIL-STD-1553B as the target protocol, the core mechanisms of the proposed method are protocol-agnostic. Specifically, three foundational components—icount-based deterministic execution, virtual time event scheduling with deadline-driven callback dispatch, and quantization grid alignment—operate independently of any particular protocol's timing semantics."
Location in revised PDF: Abstract (Lines 1–6, 21–24), Introduction (Lines 78–102), and Section 6.2 (Lines 607–629). General Feedback: However, the technical focus of the paper is rather narrow and overly specialized to the specific target protocol. For a scientific and technical research article, the authors should extract the essential ideas of their proposed method and describe them in a more generalized manner.
Response to General Feedback: Thank you for this observation. We agree that the original manuscript was too narrowly focused on the 1553B protocol and did not sufficiently present the general research contribution. We have restructured the manuscript to address this:
We reframed the Abstract and Introduction to position the work as a general virtual time-driven approach for timing-sensitive bus simulation, with MIL-STD-1553B as a representative case study. The Abstract now opens with the general challenge: "Achieving deterministic, microsecond-level timing in full-system virtualization platforms is a fundamental challenge for hardware-in-the-loop simulation of timing-sensitive communication buses" (Lines 1–3), and closes with a generalizability statement: "While demonstrated on 1553B, the virtual time-driven methodology is applicable to other timing-sensitive bus protocols in QEMU-based simulation environments" (Lines 21–23).
In the Introduction, the contributions are reframed to emphasize generality. For example, Contribution #2 states: "While instantiated here for 1553B, the methodology applies to any protocol with microsecond-level timing constraints" (Lines 91–92), and Contribution #4 concludes: "These results establish the feasibility of the virtual time-driven approach for timing-sensitive bus simulation in general" (Lines 100–102).
We also added a dedicated Discussion section (Section 6, Lines 585–651) with three subsections addressing QEMU appropriateness, generalizability, and limitations, as detailed in our responses to Comments 1, 2, and 4 below. Location in revised PDF: Abstract (Lines 1–27), Introduction contributions (Lines 78–102), and Section 6 Discussion (Lines 585–651). We sincerely appreciate your comments, which helped us improve the paper's positioning, structure, mathematical rigor, and discussion of generalizability. The revised manuscript presents a general virtual time-driven method validated through a 1553B case study, with formal analysis and a dedicated Discussion section.

Round 2

Reviewer 3 Report

Comments and Suggestions for Authors

The revisions have fully resolved all of the reviewer's concerns. The proposed QEMU‑based device‑emulation method is now more clearly defined, and its advantages are presented in a way that is much easier for readers to understand.