Pith. sign in

REVIEW 3 major objections 6 minor 4 references

Event-Driven Simulation for Rapid Iterative Development of Distributed Space Flight Software

T0 review · 3 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A deterministic, event-driven simulation environment runs compiled flight software as shared libraries and reproduces rare distributed-spacecraft failures that usually surface only in hardware-in-the-loop testing.

desk verdict A credible engineering report with real defect-detection results, but the headline fidelity claim rests on unvalidated environment models and no code is shipped. read the letter →

arxiv 2505.12502 v1 pith:I4B6RG5S submitted 2025-05-18 cs.SE cs.MAcs.RO

Toby Bell , Simone D'Amico This is my paper · ORCID
classification cs.SEcs.MAcs.RO
keywords event-drivensimulationdistributedspacesystemsflightsoftwaretestinginterfacevirtualizationdeterministicmemoryfragmentationcrosslinkcommunicationformationflyingGNC
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that a simulation environment built from three ingredients—a hybrid continuous/discrete-event scheduler, a lightweight virtualization layer that runs compiled flight software as shared libraries, and high-fidelity models of communication, sensing, and memory—can take over much of the work normally reserved for multi-spacecraft hardware-in-the-loop testing. If true, flight software for formations and swarms can be developed iteratively, delivered in its final compiled form, and checked for defects that only show up under distributed timing, packet loss, and memory pressure. The evidence comes from 33 months of developing two navigation and control packages, including detection of a memory-exhaustion crash at the 50 MB limit, invalid state transitions caused by dropped crosslink messages, and a crash from reordered GPS messages. The value is an engineering process in which rare, timing-dependent distributed bugs are reproducible and fixable quickly rather than observed only occasionally on hardware.

What carries the argument

The load-bearing object is the virtualized flight-software interface: flight software is compiled as shared libraries exposing event-driven input and output functions, multiple instances are loaded into one process, and a deterministic single-threaded scheduler invokes them through the simulation's event loop, with malloc and free interposed to route each instance's allocations to its own simulated heap. Around it sits the hybrid event-driven scheduler, which propagates continuous orbit dynamics lazily between discrete events, together with environment models—a Markov blackout link, log-normal transmission delays, GPS receiver noise, OpenGL camera rendering, and a fragmentation-prone first-fit heap—that exercise the software. The interface is what makes the claim more than a dynamics study: defects found in simulation are defects in the exact deliverable code, and the scheduler's total order makes any rare failure reproducible and debuggable with ordinary tools.

What would settle it

Replay a recorded 50-hour VISORS science campaign under the simulation's radio and heap models, then run the identical compiled binary on a flight-representative processor with real crosslink traffic and a system allocator; if the real heap stays under 50 MB while the simulated heap crashes, or the real link drops no messages where the model drops them, the detected defects are artifacts of the simulator's models rather than predictions about flight.

Watch

Extended reading notes

Core claim

The central claim is that executing the same compiled flight software binaries inside a deterministic, faster-than-real-time event-driven simulation, rather than simplified models or separate operating-system processes, gives distributed-space development a fidelity closer to hardware-in-the-loop testing while preserving software-only flexibility. The environment's three mechanisms—hybrid event-driven time flow, application-layer interface virtualization with per-spacecraft heaps, and environment models for radio blackouts and delays, GPS, cameras, and heap fragmentation—together expose defects that are otherwise invisible until integrated hardware testing. The paper reports that this setup detected a VISORS GNC memory-exhaustion crash at the 50 MB dynamic-memory limit, invalid state-machine transitions from dropped crosslink events, and a navigation-queue crash from reordered GPS crosslink messages, and reproduced each fault deterministically for debugging. It further reports that the same simulation produced centimeter-level relative navigation results and ran 100 Monte Carlo transfer simulations in about 9.5 seconds each, a speedup of roughly 7,500 times real time.

Load-bearing premise

The environment's models of radio communication, memory allocation, and cameras are representative enough of the real spacecraft that a defect found in simulation would also appear in orbit, and a clean simulation run means the flight software is safe; the paper itself leaves most of that validation to future work.

Editorial extensions

If this is right

  • Software teams can validate memory budgets and fragmentation behavior of flight-ready code before hardware is available, catching crashes like the 50 MB heap exhaustion in simulation.
  • Distributed logic such as crosslink state-machine synchronization can be stress-tested with dropped, delayed, and reordered messages during routine development rather than only in final integration testing.
  • Navigation and control performance metrics, including centimeter-level relative GPS accuracy and delta-v budgets, can be gathered from the final compiled software across Monte Carlo runs at roughly 7,500 times real time.
  • Rare faults become reproducible: because simulations are deterministic, a fault seen once can be rerun with added instrumentation and interactive debuggers to find its root cause.
  • Processor-in-the-loop testing can be added late and ported quickly, since the same shared-library flight software ran on an ARMv6 flight-representative processor within a day of the first attempt.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the three mechanisms are not space-specific, so the approach should port to other multi-agent embedded domains such as drone swarms, rover teams, or constellations with ground segments; the paper itself demonstrates only two guidance, navigation, and control packages.
  • Editorial inference: the single-threaded deterministic scheduler deliberately hides the nondeterminism of real operating-system scheduling, so a testable extension is to rerun the same scenarios under random scheduling perturbations and compare fault rates, especially since the paper's own determinism violation shows that hidden global state can matter.
  • Editorial inference: the paper does not report a ratio of defects found only in simulation versus only on hardware; collecting that ratio over the remaining mission lifecycle would quantify how much of hardware-in-the-loop testing this method can actually replace.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper presents a hybrid event-driven simulation environment for distributed space flight software, with three claimed contributions: a hybrid continuous/discrete-event simulation architecture, an application-layer virtualization interface that runs compiled flight software as shared libraries with deterministic scheduling and per-process memory allocation, and high-fidelity environment models including orbit dynamics, GPS receivers, radio crosslinks, heap allocation, and synthetic cameras. The environment was used over 33 months on two flight software packages (VISORS GNC and RPO Kit), and the paper reports specific defect detections: a state-machine crash from dropped crosslink messages, a navigation-queue crash from reordered GPS messages, and a 50 MB heap-exhaustion crash fixed by switching ECOS to sparse matrices. It also reports centimeter-level relative navigation accuracy in simulation, Monte Carlo delta-v analysis, roughly 7,500x faster-than-real-time speedup, deterministic reproducibility checks, and a processor-in-the-loop test on ARMv6 hardware.

Significance. If the environment performs as claimed, this is a practically significant contribution to distributed space flight software development: it offers deterministic, faster-than-real-time execution of source-identical flight software with multiple interacting spacecraft, and it demonstrably finds rare implementation-level defects that are usually sought in hardware-in-the-loop testing. The paper has real strengths: the S3 dynamics library is validated against PRISMA flight data, GPS noise parameters come from manufacturer specifications and a published antenna pattern, the processor-in-the-loop test runs the same binaries on real ARMv6 hardware, and the determinism checks in Table 4 provide concrete reproducibility evidence. The defect case studies in Section 6 are specific, time-stamped, and reproducible in principle. The central weakness is that the radio, memory, and camera models are explicitly acknowledged to be unvalidated, which means the headline defect detections and navigation results are currently results about the authors' models until their representativeness is established.

major comments (3)
  1. [§5 (Radio Communication), §6 (Dropped and Reordered Crosslink Messages)] The two headline defect detections—the state-machine crash from dropped crosslink messages (Figure 26) and the navigation-queue crash from reordered GPS messages (Figure 27)—are generated entirely against the Section 5 radio model, whose parameters are author-chosen: the log-normal delay parameters are chosen so that delays have 3-sigma bounds of 0.1 s and 10 s, and the per-link Markov blackout transition probabilities are never stated. No link budget, hardware test, or flight-data comparison is provided for this model, and no sensitivity analysis shows whether the detected crashes persist across the range of radio behaviors a real VISORS crosslink could exhibit. Because the paper's central claim is that the environment provides 'fidelity and depth normally attained only by real-time hardware-in-the-loop testing,' this unvalidated parameterized model is load-bearing rather than incidental. Please state the transition probabilities and delay parameters explicitly, justify them from link budgets or measured data, and add sensitivity runs over plausible parameter ranges to show which defect detections are robust.
  2. [§5 (Memory Allocation), §6 (Memory Exhaustion and Fragmentation)] The simulated heap allocator is 'intentionally more prone to fragmentation than a more sophisticated allocator' (Section 5), yet the 50 MB exhaustion crash (Figures 28–30) and the claimed six-month fragmentation verification are presented as findings about VISORS GNC's real memory behavior. The paper gives no quantitative comparison between the simulated allocator and the allocator on the VISORS flight computer or a representative BCM2835-class system, and the six-month fragmentation check is asserted without supporting data or scenario details. The paper's own conclusion observes that the memory model 'should be compared to system malloc/free performance in a real flight computer environment.' This is a load-bearing validation gap: as reported, the memory-exhaustion result measures the simulated allocator, not necessarily the real flight computer's allocator. Please add the allocator comparison and the fragmentation-check details, or explicitly reframe these claims as results about the model.
  3. [§4 (Capability 1), §4 (Limitation: Processor Architecture), §7 (Conclusion)] The first of the five central interface capabilities is 'Run unmodified compiled flight software,' and the abstract says the environment executes 'compiled flight software binaries.' The paper later concedes that when the flight computer uses a different ISA, the simulation runs source-identical rather than binary-identical code, and the conclusion states that this 'arguably violates the philosophy of running "unmodified" flight software.' This is a genuine inconsistency between a central capability claim and the implemented design. The processor-in-the-loop test in Table 5 exercises ARMv6 binaries and is a good step, but it compares only a few runtime metrics and does not establish behavioral equivalence for all input sequences. Please either present evidence of behavioral equivalence for the source-identical builds used in simulation, or qualify the 'unmodified' and 'binary-identical' wording in the abstract and Section 4.
minor comments (6)
  1. [§5 (GPS Receivers)] The closed-form perturbed orbit model used for the 31 simulated GPS satellites is described without a citation; please provide a reference or a derivation sketch so the model can be checked.
  2. [§5 (Radio Communication)] Figure 16 shows a histogram and density of transmission delay, but the numerical values of the log-normal parameters (mu and sigma) are not given in the text; please report them explicitly along with the Markov transition probabilities for the blackout model.
  3. [§6 (Fragmentation)] The statement that 'long-duration Monte Carlo testing was used to successfully verify that fragmentation did not cause memory exhaustion over the course of six months' is unsupported as written; please provide the number of runs, simulated durations, scenario setup, and a quantitative criterion for what was verified.
  4. [§6 (Table 5)] The footnote correctly notes that the observation-count difference (7/10 vs. 10/10) is not statistically significant, but the runtime metrics are hardware-dependent and should not be interpreted as model-fidelity validation; consider stating this explicitly in the text.
  5. [General] There are minor typographical and capitalization inconsistencies, such as 'RPO kit' versus 'RPO Kit' in several places; please standardize.
  6. [References] References [27] and [48] are the same work, and [31] and [51] are the same work; please consolidate duplicates.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the defect detections exercise real flight binaries against stated environment models; unvalidated radio/memory/camera fidelity is an external-validity risk, not a self-referential derivation.

full rationale

The paper's central claims are about a development process, not about predicting flight behavior from fitted parameters. The three headline defect detections (dropped crosslink messages, reordered GPS queue, memory exhaustion) are produced by running the actual VISORS GNC and RPO Kit shared libraries through the simulator's event loop, with the environment models as inputs. There is no equation in which a purported output is reinvented as an input: the radio blackout and delay parameters are author-chosen, but they are not fitted to the crashes they expose, and the memory model is explicitly designed to be conservative, with the 50-MB cap being a mission requirement rather than a fitted threshold. The orbit dynamics rest on the S3 library previously validated against PRISMA flight data, and GPS noise comes from manufacturer specifications and a published antenna pattern; these are external benchmarks. The processor-in-the-loop results use the same binaries on real ARMv6 hardware. The paper's own limitations, including camera images not rigorously compared to flight data and the allocator not compared to a real flight computer's malloc/free, are honest statements of external-validity risk. Under the hard rule that circularity requires a quotable reduction of a claimed derivation to its own inputs, no such step exists. Correctness risk from unvalidated models is real, but it is not circularity.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

The central claim rests on three kinds of assumptions: the representativeness of the unvalidated environment models (radio, memory, camera), the premise that cooperative flight software design (shared library, no globals, no threads, single tick) does not distort behavior, and the premise that serialized single-process execution preserves the timing effects that matter. Free parameters are concentrated in the radio model (author-chosen, values mostly unstated) and in orbit-dynamics coefficients. No new physical entities are postulated; the virtual heap, simulated scheduler, and virtual flight computer interface are software constructs whose risk is captured in the free parameters and axioms.

free parameters (4)
  • Log-normal transmission delay parameters (mu, sigma) = Chosen so 3 sigma bounds equal 0.1 s and 10 s
    Section 5, Radio Communication: 'The distribution parameters are adjustable; in this work we commonly choose [mu and sigma] such that transmission delays have 3 sigma lower bound of 0.1 s and 3 sigma upper bound of 10 s.' Author-chosen, not fitted to flight data or measured link behavior; affects message ordering and hence the reordered-crosslink defect findings.
  • Per-link Markov blackout transition probabilities = Not specified numerically
    Section 5, Radio Communication: unreliable delivery is 'modeled using a per-link Markov chain between blackout-on and blackout-off states' with user-selected transition probabilities. The values used in the VISORS and RPO Kit case studies are not reported, so the crosslink defect-detection results depend on unstated parameters.
  • Ballistic and reflectivity coefficients (Cd, Cr) = Cd = 2.2, Cr = 1.8
    Table 1: cannon-ball drag and solar radiation pressure with Cd = 2.2 and Cr = 1.8. Standard hand-picked values, not calibrated to the VISORS or RPO Kit spacecraft; affects ground-truth orbit accuracy over long simulations.
  • RK4 integration step size = 1 to 10 s
    Table 1: step size of 1 to 10 s for orbit propagation. An implementation choice that bounds the fidelity of the continuous dynamics layer relative to the discrete events in the simulation.
assumptions (5)
  • domain assumption Flight software can be compiled to a shared library, written without global state, without OS threads, and with a single-tick scheduling interface, and still represent the deployed behavior.
    Section 4 ('Flight Software Shared Libraries', 'Scheduling', 'Timed Execution') and the Conclusion: the authors call this an 'overarching limitation' that 'arguably violates the philosophy of running unmodified flight software' and limits retrofitting to existing executables.
  • domain assumption The per-link Markov blackout model plus log-normal transmission delay captures the radio failure modes that matter for distributed space flight software.
    Section 5, Radio Communication. The model is simple and adjustable, but no comparison to measured inter-satellite link behavior or flight data is provided; the conclusion requests 'continued characterization and refinement of the built-in environment models' fidelity against hardware testbeds and flight data.'
  • domain assumption A single-free-list, first-fit allocator with coalescing is a conservative model of heap fragmentation on the real flight computer.
    Section 5, Memory Allocation: 'conservatively model heap fragmentation.' The conclusion states the model 'should be compared to system malloc/free performance in a real flight computer environment.'
  • domain assumption Serialized execution of message-passing flight software in a single thread with event-time noise preserves the timing behavior that determines correctness.
    Section 4, Scheduling and Determinism: all processes run in one OS process with a deterministic scheduler and pseudo-random time perturbations; the paper cites the actor model for serializability but does not validate the timing fidelity of the simulated scheduler against real OS scheduling, and Table 5 shows large runtime differences between ARM and desktop.
  • domain assumption S3 astrodynamics library ground-truth dynamics are accurate for the VISORS and RPO Kit scenarios.
    Section 5, Orbit Dynamics: S3 was validated against PRISMA flight data at meter and centimeter level (references 72-73), but the mission-specific settings (Cd, Cr, step size) are not validated against VISORS or RPO Kit flight data.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Event-Driven Simulation for Rapid Iterative Development of Distributed Space Flight Software." pith.science (2026). https://pith.science/paper/I4B6RG5S

@misc{pith2026250512502,
  author       = {Pith},
  title        = {Pith review of: Event-Driven Simulation for Rapid Iterative Development of Distributed Space Flight Software},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/I4B6RG5S}},
  note         = {Machine review of arXiv:2505.12502}
}
read the original abstract

This paper presents the design, development, and application of a novel space simulation environment for rapidly prototyping and testing flight software for distributed space systems. The environment combines the flexibility, determinism, and observability of software-only simulation with the fidelity and depth normally attained only by real-time hardware-in-the-loop testing. Ultimately, this work enables an engineering process in which flight software is continuously improved and delivered in its final, flight-ready form, and which reduces the cost of design changes and software revisions with respect to a traditional linear development process. Three key methods not found in existing tools enable this environment's novel capabilities: first, a hybrid event-driven simulation architecture that combines continuous-time and discrete-event simulation paradigms; second, a lightweight application-layer software virtualization design that allows executing compiled flight software binaries while modeling process scheduling, input/output, and memory use; and third, high-fidelity models for the multi-spacecraft space environment, including for wireless communication, relative sensing such as differential GPS and cameras, and flight computer health metrics like heap exhaustion and fragmentation. The simulation environment's capabilities are applied to the iterative development and testing of two flight-ready software packages: the guidance, navigation, and control software for the VISORS mission, and the Stanford Space Rendezvous Laboratory software kit for rendezvous and proximity operations. Results from 33 months of flight software development demonstrate the use of this simulation environment to rapidly and reliably identify and resolve defects, characterize navigation and control performance, and scrutinize implementation details like memory allocation and inter-spacecraft network protocols.

Figures

Figures reproduced from arXiv: 2505.12502 by the authors.

Figure 1
Figure 1. European Space Agency's linear soft￾ware development model. Iterative Software Development—In contrast to the space industry, the consumer software industry has shifted almost entirely to an iterative development model, and most practi￾tioners consider frequent revisions and adaptability to changing requirements to provide greater value-for-cost than structured sequential processes . In 2012 the United States 25 Fed… view at source ↗
Figure 2
Figure 2. Typical time-driven simulation: succes￾sive states computed via continuous dynamics at regular intervals. Continuous simulation is commonly used to test guidance, navigation, and control algorithms for spacecraft, since spacecraft free motion is described well by a continuous dynamical system. A weakness of time-driven simulation is its inability to natively incorporate instantaneous or discrete state changes with b… view at source ↗
Figure 3
Figure 3. Typical discrete-event simulation: succes￾sive states computed by applying a sequence of het￾erogeneous events. Discrete-event simulation often models systems where state changes are mostly instantaneous, intervals between events are irregular or uncertain, and the system state does not change significantly between events—for example, process engineering for manufacturing34, healthcare35, business op￾S f : S × ℝ → S… view at source ↗
Figures from the paper (24 more)
Figure 5
Figure 5. Figure 5: Implementation of simulation event loop as a min-heap with function pointers for events [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]
Figure 7
Figure 7. Figure 7: Example distributed space system running compiled flight software, and corresponding simulation environment running the same compiled flight software through a virtualized interface. The virtual interface in this work is designed to achieve five central capabilities, s…
Figure 8
Figure 8. Figure 8: Flight software compiled as a shared li￾brary rather than executable, to load into simulation processes or deployed flight software processes. struct VisorsGnc { VisorsGnc(VisorsGncOutput&); void in_bus_telemetry(…); void in_gps_message(…); void in_crosslink(…); void i…
Figure 9
Figure 9. Figure 9: Flight software event-driven inputs and out￾puts implemented in C++ as class member functions. Explicit input and output functions allow the simulation to fully interface with the flight code and appropriately mock all sensors and actuators the flight software expects …
Figure 10
Figure 10. Figure 10: Flight software loaded as a shared library and executed by a deterministic simulation scheduler. Flight software execution order is identical from run to run. Using a simulated scheduler within a single operating sys￾tem process is crucial for providing (3) determinis…
Figure 11
Figure 11. Figure 11: Flight software loaded as an executable and run by a nondeterministic operating system scheduler. Flight software execution order varies from run to run. Timed Execution A callback-based interface is used to allow flight software to execute code at specific times, to …
Figure 12
Figure 12. Figure 12: Global memory allocator functions are overridden to dispatch malloc/free calls from dif￾ferent flight software processes to different heaps. portable C, however it means that the flight software is not binary-identical to the code that will ultimately run on the space…
Figure 13
Figure 13. Figure 13: 31 operational GPS satellites are simulated, and individual range and carrier phase measurements are generated for each spacecraft. 60 × 60 Cd = 2.2 Cr = 1.8 8 [PITH_FULL_IMAGE:figures/full_fig_p008_13.png]
Figure 15
Figure 15. Figure 15: Stochastic blackout model for radio links [PITH_FULL_IMAGE:figures/full_fig_p009_15.png]
Figure 14
Figure 14. Figure 14: Elevation-dependent antenna gain pattern determines effective standard deviation for GPS pseudorange and carrier phase noise. antenna attitude in order to provide the correct set of avail￾able ranges at each time step. Additionally, receiver-com￾puted position-velocit…
Figure 18
Figure 18. Figure 18: Memory layout of heap blocks [PITH_FULL_IMAGE:figures/full_fig_p010_18.png]
Figure 22
Figure 22. Figure 22: Synthetic images of far- and near-range targets generated using an OpenGL pipeline. 6. CASE STUDY RESULTS Event-driven simulation was used for iterative development of two state-of-the-art GNC flight software packages: VI￾SORS GNC and RPO Kit, developed by the Stanfor…
Figure 20
Figure 20. Figure 20: Free blocks stored in a doubly-linked free list. When freeing (free), adjacent blocks are checked using headers and footers, and if they’re free, the blocks are coa￾lesced into a single larger free block ( [PITH_FULL_IMAGE:figures/full_fig_p010_20.png]
Figure 21
Figure 21. Figure 21: On free, adjacent free blocks are coalesced. On-Board Cameras Finally, of particular interest for next-generation computer vision applications in space are models for vision-based sensors. Far-range angles-only navigation using ARTMS85 has recently been demonstrated s…
Figure 23
Figure 23. Figure 23: VISORS relative navigation error and 1- confidence over first orbit after initialization, estimated by spacecraft 0. Top/bottom plots are identical but for y-axis zoom. High-precision navigation with integer ambiguity resolution begins after ~8 min (red line) [PITH_F…
Figure 24
Figure 24. Figure 24: Histogram of required for a single transfer trajectory planned by VISORS GNC across 100 Monte Carlo simulations. Mean ≈ 0.325 m/s (red line). Simulation Speed By using hybrid event-driven simulation, idle time between flight software executions can be skipped entirely…
Figure 25
Figure 25. Figure 25: Simplified model of a VISORS GNC state machine that switches between science mode and observing in response to begin-observation and end￾observation events. Event-driven simulation and crosslink communication mod￾eling was used to detect these faults by randomly dropp…
Figure 26
Figure 26. Figure 26: Program crash caused by dropped state machine events between active and passive spacecraft leading to an invalid transition. Run Fingerprint Analysis hash Mean position error 1 e7174029 87c6affe… 14.592582331956 2 e7174029 87c6affe… 14.592582331956 3 e7174029 87c6affe…
Figure 28
Figure 28. Figure 28: shows resting and transient memory and total heap size on the active spacecraft over a 50-hour science campaign. Resting memory refers to allocations that persist in between flight software invocations; transient memory refers to memory allocated while running the fli…
Figure 27
Figure 27. Figure 27: Long-delayed earlier crosslink message re￾ceived after short-delayed later crosslink message, caus￾ing a software crash (red line) in the navigation queue. Memory Exhaustion Space flight computers often have less memory than terres￾trial computers, and space flight so…
Figure 29
Figure 29. Figure 29: Dense mostly-zero matrix replaced with sparse matrix representation as input to second-order cone program in order to reduce memory use. Fragmentation—Although memory consumption was re￾duced, a net increase in the total heap size can be observed from the start to the…
Figure 30
Figure 30. Figure 30: Resolved VISORS GNC memory use with sparse matrices during science campaign, with no crash and ~20x safety factor against memory exhaustion. fragmentation did not cause memory exhaustion over the course of six months of continuous operation. Additional defects detecte…
Figure 32
Figure 32. Figure 32: Off-the-shelf interactive debuggers were used to pause and inspect flight software on separate spacecraft at the same time [PITH_FULL_IMAGE:figures/full_fig_p015_32.png]
Figure 33
Figure 33. Figure 33: Apple Instruments was used on MacOS to profile and speed up both flight and simulation code. 7. CONCLUSION A novel simulation environment based on hybrid discrete￾continuous simulation was developed and used to enable rapid iterative development of two flight software…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

4 extracted references · 3 canonical work pages

  1. [247]

    Pattern-based design recovery of Java software

    IEEE, 2008. 63 J Seemann, JW von Gudenberg. “Pattern-based design recovery of Java software.” ACM SIGSOFT Software En- gineering Notes 23(6), 10–16. 1998. 64 R Fujimoto. “Parallel discrete event simulation.” Commu- nications of the ACM 33(10), 30–53. 1990. 65 T Curry. “Profiling and Tracing Dynamic Library Usage Via Interposition.” USENIX Summer, 267–278....

    work page 2008

  2. [319]

    Robust Closed-form Framework for Drag-Propulsive Control of Formation Flight

    2018. 10 M Hunter, S D’Amico. “Robust Closed-form Framework for Drag-Propulsive Control of Formation Flight.” 2024 IEEE Aerospace Conference, 1–17. IEEE, 2024. 11 D Dvorak. “NASA study on flight software complexity.” In AIAA infotech@aerospace conference, p. 1882. 2009. 12 SA Jacklin. “Small-satellite mission failure rates.” No. NASA/TM-2018-220034. 2019....

    arXiv 2020

  3. [2024]

    An empirical study into use of dependency injection in java

    https://lldb.llvm.org 62 HY Yang, E Tempero, H Melton. “An empirical study into use of dependency injection in java.” 19th Australian Conference on Software Engineering (aswec 2008), 239–

    work page 2008

  4. [5740]

    Generalized angles-only navigation architecture for autonomous dis- tributed space systems

    2024. 89 J Sullivan, A Koenig, J Kruger, S D’Amico. “Generalized angles-only navigation architecture for autonomous dis- tributed space systems.” Journal of Guidance, Control, and Dynamics 44(6), 1087–1105. 2021. 90 TH Park, M Märtens, G Lecuyer, D Izzo, S D’Amico. “SPEED+: Next-generation dataset for spacecraft pose estimation across domain gap.” 2022 IE...

    work page 2022

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.