NASA Replaces Simulink With Julia to Cut Satellite Run Times by 99%

The Julia Programming Language

Slashing simulation times from 15 minutes to under 60 milliseconds refutes the aerospace dogma that compute cost is negligible compared to labor by turning batch runs into real-time interactive engineering.

AI-assisted summary of Jonathan Diegelman - Modeling Spacecraft Separation Dynamics in Julia — original source. Check the original for full context.

Source published: 2021-03-09

Key ideas

NASA's Launch Services Program developed RECURSAT in Julia to model spacecraft separation dynamics, replacing a legacy Simulink tool with a modular, recursive architecture capable of handling arbitrary rideshare and secondary payload topologies. (7:49)
The simulation execution time dropped from 15 minutes for 514 Monte Carlo runs in Simulink to under 60 milliseconds in Julia, achieving an approximate 15,000x speedup. (12:30)
RECURSAT leverages ecosystem composability across DifferentialEquations.jl, ComponentArrays.jl, MonteCarloMeasurements.jl, and Unitful.jl to eliminate unit conversion errors and support native automatic differentiation. (10:21)
Sub-60 millisecond solve times transform the engineering workflow, allowing analysts to perform interactive slider-based parameter sweeps and 3D visualization in MeshCat.jl before running numerical optimizers. (12:56)

Detailed notes

## Background Presented by Jonathan Diegelman of the NASA Launch Services Program and A.I. Solutions, this talk was published on YouTube by The Julia Programming Language channel on March 9, 2021. The presentation details how NASA GN&C engineers replaced legacy Simulink separation dynamics simulations with RECURSAT, a high-performance simulation built on Julia's SciML ecosystem that dramatically accelerates analysis workflows and leverages composable tooling.

## TL;DR NASA GN&C engineer Johnny Diegelman demonstrates the migration of spacecraft separation dynamics modeling from a rigid, slow Simulink environment to Julia. Separation analysis requires carefully balancing competing constraints—preventing vehicle re-contact via high separation velocity while restricting tip-off rotational rates to protect solar-sensitive instruments and save RCS propellant. By replacing over 1,000 lines of MATLAB configuration scripts with a lean, recursive multi-body solver utilizing DifferentialEquations.jl, ComponentArrays.jl, and Unitful.jl, simulation batch times collapsed from 15 minutes to under 60 milliseconds. Diegelman demonstrates how this 15,000x speedup transforms engineering workflows, enabling real-time interactive parameter sweeps in notebooks, native optimization under uncertainty, and seamless automatic differentiation for sensitivity analysis.

## Atmosphere & style The presentation possesses the pragmatic, quietly triumphant energy of a practicing aerospace engineer who successfully dismantled a frustrating daily workflow bottleneck. Diegelman speaks with understated technical authority and relatable candor, contrasting the clunky friction of sprawling legacy scripts with the tactile joy of sub-second computational responsiveness. Watching the talk feels like an inspiring peek into modern computational engineering, where interactive 3D sliders and instant Jacobians turn a once-tedious batch simulation chore into an intuitive, exploratory design sandbox.

## Bulletin - [07:49](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=469s) NASA's Launch Services Program developed RECURSAT in Julia to model spacecraft separation dynamics, replacing a legacy Simulink tool with a modular, recursive architecture capable of handling arbitrary rideshare and secondary payload topologies. - [12:30](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=750s) The simulation execution time dropped from 15 minutes for 514 Monte Carlo runs in Simulink to under 60 milliseconds in Julia, achieving an approximate 15,000x speedup. - [10:21](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=621s) RECURSAT leverages ecosystem composability across DifferentialEquations.jl, ComponentArrays.jl, MonteCarloMeasurements.jl, and Unitful.jl to eliminate unit conversion errors and support native automatic differentiation. - [12:56](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=776s) Sub-60 millisecond solve times transform the engineering workflow, allowing analysts to perform interactive slider-based parameter sweeps and 3D visualization in MeshCat.jl before running numerical optimizers.

## Key takeaways - [01:53](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=113s) Spacecraft separation dynamics are constrained by a fundamental trade-off: maintaining sufficient relative velocity to avoid re-contact while keeping tip-off rotation rates low enough to protect Sun-sensitive sensors and conserve fuel. - [01:53](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=113s) Separation forcing functions involve complex physical mechanisms, including clamp band release impulses and hinging moments, pusher spring strokes, and umbilical connector friction. - [04:22](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=262s) The legacy Simulink architecture was restricted to a single spacecraft separating from a launch vehicle, making it difficult to adapt to modern CubeSat and rideshare topologies. - [04:22](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=262s) The legacy workflow required MATLAB input decks exceeding 1,000 lines, creating high cognitive load, error-prone configuration, and steep onboarding barriers for junior engineers. - [04:22](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=262s) A 15-minute runtime for 514 Monte Carlo runs in Simulink created a workflow bottleneck that destroyed engineering intuition and precluded real-time sensitivity analysis. - [07:49](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=469s) RECURSAT uses a recursive tree-traversal algorithm that computes separation forces down through child stages and propagates equal and opposite reaction forces upward before each integration time step. - [10:21](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=621s) ComponentArrays.jl allows complex nested state vectors with named fields to behave as contiguous arrays compatible with native ODE and optimization solvers. - [10:21](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=621s) MonteCarloMeasurements.jl enables natural mathematical operations on uncertain parameters before unpacking them directly into an EnsembleProblem for differential equation solving. - [10:21](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=621s) Unitful.jl enforces physical unit safety across all parameters, preventing errors stemming from mixed imperial and metric specifications provided by international contractors. - [12:30](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=750s) The transition from a 15-minute Simulink runtime to under 60 milliseconds in Julia fundamentally shifts the analysis paradigm from batch execution to real-time interactivity. - [12:56](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=776s) In the ballast placement design problem, adding ballast to damp excessive y-axis tip-off rates introduces the competing risk of dropping separation velocity below the 0.55 m/s threshold. - [12:56](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=776s) Sub-60 millisecond performance enables engineers to manually sweep design variables via interactive notebook sliders to build physical intuition before applying automated optimization. - [12:56](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=776s) Local parameter sensitivities around the optimal ballast design can be evaluated in a single step using ForwardDiff.jacobian on the simulation function, normalized by allowable parameter limits.

## Detailed walkthrough ### [00:11](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=11s) Overview: Tooling for Engineering Simulations

Johnny Diegelman introduces himself as a Guidance, Navigation, and Control (GN&C) engineer at NASA's Launch Services Program in Florida. The focus of the presentation is a case study on migrating one of their critical separation simulation tools from Simulink over to the Julia programming language. A major theme of the discussion is how simulation tooling directly shapes how engineers work and think. Diegelman emphasizes that the integration of DifferentialEquations.jl and the SciML suite with the wider Julia package ecosystem provides a massive operational advantage, allowing engineers to pick and choose modular capabilities effortlessly.

The presentation follows an arc that begins with the physics of spacecraft separation, reviews the structural and performance limitations of their legacy Simulink tool, and presents RECURSAT—a new recursive separation simulation built on DifferentialEquations.jl. The session culminates in demonstrations of interactive parameter tuning, optimization under uncertainty, automatic differentiation, and global sensitivity analysis.

[01:53](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=113s) Spacecraft Separation: Dynamics and Competing Constraints

Spacecraft separation involves releasing a satellite from the launch vehicle's upper stage, a process highlighted by footage from the Sentinel-6 Michael Freilich mission, for which Diegelman served as the GN&C separation simulation and analysis engineer. The event is dominated by two strictly competing engineering requirements:

```mermaid flowchart LR accTitle: Separation Requirements Trade-off accDescr: Diagram illustrating the fundamental engineering tension between minimum relative separation velocity and maximum allowable tip-off rate.

subgraph Tension["Separation Trade-Off"] direction TB RelVel["High Relative Velocity (Prevents Re-contact)"] TipOff["Low Tip-Off Rate (Keeps Sun Off Sensors & Conserves Fuel)"] end

RelVel <--->|"Direct physical tension"| TipOff ```

1. **Strict Tip-Off Rotational Rate Limits:** Missions enforce tight rotational constraints, typically on the order of one to a few degrees per second. Because spacecraft often experience a delay before activating their reaction control systems (RCS), they remain in an uncontrolled free tumble immediately after separation. Any excessive rotational rate threatens to swing sensitive optical and scientific instruments toward the Sun. Furthermore, spacecraft operate under limited attitude control system (ACS) fuel budgets; burning excessive propellant simply to detumble compromises the mission lifecycle. 2. **Minimum Relative Velocity:** Simultaneously, the spacecraft and upper stage must achieve a minimum relative separation speed to prevent catastrophic re-contact.

Pushing harder to satisfy the relative velocity requirement inherently increases the energy pumped into the system, making it far more likely to exceed allowable tip-off rates. The dynamics are governed by rigid body equations of motion utilizing quaternions for attitude updates (handled computationally as four-element vectors). The forcing functions are intricate: - **Clamp bands:** The circumferential structural band holding the vehicles together imparts an impulse upon release, followed by a localized hinging moment as it peels away. - **Pusher springs:** Mechanical springs that supply the primary stroke and push force. - **Connectors:** Purge lines, electrical disconnects, and umbilical fittings that induce frictional drag during withdrawal.

Because slight variations in spring constants and vehicle mass properties dramatically sway the outcome, high-fidelity modeling is critical.

[04:22](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=262s) Limitations of the Legacy Simulink Architecture

The existing analysis framework relies on a GUI-driven, block diagram causal modeling environment in Simulink driven by a top-level MATLAB input deck. While originally structured so analysts would not have to modify internal simulation blocks, the architecture suffers from four core flaws:

```mermaid flowchart TD accTitle: Legacy Simulink Workflow Bottlenecks accDescr: Flowchart illustrating how rigid architecture, derived parameters, large input decks, and slow compute degrade the legacy workflow.

subgraph ArchitecturalBottlenecks["Simulink Tool Deficiencies"] Rigid["Rigid Single-Vehicle Limit (Cannot easily support CubeSats/rideshares)"] Dispersion["Late Monte Carlo Draws (Lumped masses force input deck bloat)"] DeckSize["1,000+ Line MATLAB Decks (Error-prone, high barrier for interns)"] SlowRun["15-Minute Compute Time (514 runs; blocks real-time trades)"] end

Rigid --> DeckSize Dispersion --> DeckSize DeckSize --> SlowRun ```

- **Inflexibility with Modern Multi-Payload Manifests:** The Simulink model is hardcoded for a single spacecraft separating from a launch vehicle. However, current flight manifests routinely incorporate secondary payloads, CubeSats, and rideshares. Accommodating arbitrary vehicle topologies in a visual block diagram environment is inherently awkward. - **Derived Dispersed Parameters:** The simulation draws Monte Carlo dispersions only *after* reading the input deck. If a vehicle has a normally distributed dry mass and a uniformly distributed propellant mass, the physics engine merely requires a single lumped mass value. Accommodating this requires writing custom parsing hooks directly into the input deck and parser, causing exponential code bloat. - **Input Deck Complexity and High Cognitive Load:** Input scripts exceed 1,000 lines of MATLAB code. Setting or unsetting flags across a script of that size is highly error-prone when turnaround times must be kept to a couple of hours. It creates an intimidating barrier to entry for incoming interns and junior engineers who are usually tasked with these introductory analyses. - **Runtime Bottlenecks and Workflow Friction:** Running a standard Monte Carlo set of 514 runs consumes roughly 15 minutes. Diegelman pushes back against the conventional industry justification that compute is negligible compared to labor:

> “The typical argument is you know engineering times expensive compute is cheap so don't really worry about it well the problem with that is when it takes engineering hours to iterate with slow tools all of a sudden compute becomes expensive.”

A 15-minute wait per run discourages interactive sensitivity analysis, destroys intuition, and makes numerical optimization under uncertainty effectively impossible.

[07:49](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=469s) RECURSAT: Design, Requirements, and Capabilities

To replace the legacy tool, Diegelman designed **RECURSAT**, honoring the NASA custom of project acronyms by making it a recursive acronym. RECURSAT handles arbitrary vehicle topologies using a tree-traversal calculation:

```mermaid flowchart TD accTitle: RECURSAT Recursive Force Evaluation Loop accDescr: Tree evaluation showing recursive force gathering down through child stages followed by reaction forces passed upward before stepping the integrator.

subgraph Traversal["Recursive Force Pass"] Parent["Parent Stage (LV)"] Child1["Spacecraft Child"] Child2["Secondary Payload / CubeSat"]

Parent --> Step["6. Take integration time step"] ```

The algorithm operates in a clear sequence: 1. The solver queries forces from the top-level parent separation system (which initially has none). 2. It recurses down into the children, calculating separation forces generated by their separation systems. 3. The traversal proceeds to leaf nodes lacking child separation interfaces. 4. Leaf vehicle equations of motion are updated with their local applied forces. 5. Equal and opposite reaction forces are propagated back up through the parent hierarchy to update each parent vehicle's equations of motion. 6. Once back at the root parent with no higher stages remaining, the simulation takes an integration time step.

Diegelman laid out several core performance requirements for RECURSAT: - **Efficiency:** Execute hundreds or thousands of Monte Carlo trajectories in less than a second, facilitating real-time exploration. - **Composability:** Interoperate cleanly across the Julia SciML ecosystem, allowing automatic differentiation through the dynamics without custom glue code. - **Universality:** Support arbitrary multi-body separation topologies seamlessly. - **Simplicity:** Eliminate giant scripts in favor of a lean interface where analysts import types, declare only the specific parameters required for their mission, and query docstrings directly from the Julia REPL.

The resulting input setup replaces more than 1,000 lines of MATLAB code with an input deck compact enough to display on a single slide.

[10:21](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=621s) Composability Across the Julia Ecosystem

The greatest strength of building the spacecraft separation tool in Julia is its deep composability with packages across the broader ecosystem. Rather than relying on a heavy, monolithic modeling framework like Simulink or Modelica to achieve modularity, the simulation uses native Julia libraries that plug directly into standard differential equation solvers. For handling complex state vectors, Diegelman utilizes ComponentArrays.jl, a library he authored. This package allows engineers to organize initial conditions and parameters into complex nested structures with named fields, while still behaving as standard contiguous arrays that pass seamlessly into ODE solvers or optimization routines without custom interfacing code.

To solve the dependent parameter issue that plagues traditional Monte Carlo frameworks, the tool uses MonteCarloMeasurements.jl. Engineers can define inputs as uncertain random variables and perform arithmetic operations directly on them—adding uncertainties and computing derived properties naturally. Because uncertain types do not always interact cleanly with conditional statements inside ODE loops, the parameters are unpacked into an `EnsembleProblem` immediately prior to hitting the differential equation solver. Physical units are another essential safeguard enforced via Unitful.jl. Because the Launch Services Program constantly coordinates with both American and European aerospace contractors, documentation frequently mixes imperial and metric units within the exact same specification document. Requiring strict physical units on every input completely prevents unit conversion disasters. Furthermore, global sensitivity analysis is accessible as a one-liner, and both forward-mode and source-to-source automatic differentiation integrate cleanly with the differential equations to provide local sensitivities for robust design and optimization under uncertainty.

```mermaid flowchart TD accTitle: RECURSAT Simulation Architecture accDescr: Pipeline showing nested inputs passing through Julia libraries to the solver and downstream analyses.

subgraph Inputs["1. Input Definitions"] CA["ComponentArrays.jl (Nested structured state)"] UN["Unitful.jl (Physical unit enforcement)"] MC["MonteCarloMeasurements.jl (Uncertain parameters)"] end

subgraph Core["2. Execution Core"] ENS["EnsembleProblem setup"] ODE["DifferentialEquations.jl (<60 ms solve time)"] end

subgraph Analysis["3. Downstream Analysis"] OPT["Optimization & AD (ForwardDiff / Jacobians)"] VIS["MeshCat.jl (3D Visualization)"] end

CA --> ENS UN --> ENS MC --> ENS ENS --> ODE ODE --> OPT ODE --> VIS ```

- ComponentArrays.jl preserves modular, nested variable naming while passing directly through ordinary differential equation solvers and optimization solvers. - MonteCarloMeasurements.jl propagates parameter uncertainties and correlations before unpacking states into an `EnsembleProblem`. - Unitful.jl enforces explicit unit annotations across all inputs to eliminate errors caused by mixing imperial and metric contractor specifications. - “It allows for like modular design that you would usually get with a modeling framework like Simulink or Modelica or something, but you don't need to have it—it's just a regular differential equation solver.” — Jonathan Diegelman

---

[12:30](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=750s) Dramatic Efficiency Gains Over Legacy Tools

When comparing the computational performance of RECURSAT against the legacy Simulink pipeline, the speedup is staggering. A standard simulation batch that previously required 15 minutes to evaluate in Simulink runs in under 60 milliseconds in Julia. While that amounts to an approximate 15,000x speedup, Diegelman emphasizes that the exact factor matters far less than the practical paradigm shift: the simulation has transitioned from a slow batch process into an essentially instantaneous calculation.

Even as additional physical effects and modeling features continue to be incorporated into the new tool—which could potentially double the run time—a 120-millisecond execution time remains fast enough to preserve real-time interactivity. This leap in speed fundamentally changes how guidance, navigation, and control (GN&C) engineers approach design problems, allowing them to iterate rapidly rather than waiting on overnight simulation queues.

- The simulation runtime dropped from 15 minutes in Simulink to under 60 milliseconds in Julia. - “The important part is we're under 60 milliseconds for that same set of runs that took 15 minutes in our Simulink tool, which was pretty amazing to us.” — Jonathan Diegelman

---

[12:56](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=776s) Demo: The Ballast Placement Problem and Interactive Exploration

To showcase RECURSAT in practice, Diegelman demonstrates a typical separation analysis problem where a spacecraft separates from a launch vehicle under strict mission requirements: the spacecraft must experience a rotation rate of less than 1.0 degree per second across all vehicle axes (tip-off rates), and the relative separation velocity between the spacecraft and the upper stage must exceed 0.55 meters per second to eliminate any risk of re-contact. Using MeshCat.jl, the simulation results are rendered directly in a dynamic 3D visualizer. An initial run immediately reveals a failure: the spacecraft exceeds the maximum allowable tip-off rate about its y-axis.

To mitigate this tip-off violation, the GN&C team must adjust the spacecraft's mass properties by placing an internal ballast mass. This presents a constrained design problem: the ballast has a defined mass envelope and must physically fit within a restricted spatial volume inside the bus. Adding too much ballast mass runs the risk of lowering the separation velocity below the mandatory 0.55 m/s threshold. Because the solver executes in real time (sub-60 ms), engineers do not need to leap directly into black-box optimizers; instead, they can use interactive notebook sliders to manually sweep parameters and build physical intuition.

``` +-----------------------------------------------------------------------------------+ | Baseline Requirements vs. Separation Dynamics | +------------------------------------+----------------------------------------------+ | Spacecraft Tip-off Rotation Rate | < 1.0 deg/s on all body axes | | Separation Relative Velocity | > 0.55 m/s relative velocity | | Initial Nominal Simulation Result | Fails y-axis tip-off rate requirement | | Mitigation Strategy | Internal ballast mass placement | | Ballast Design Constraints | Mass limit & geometric bounding box in bus | | Trade-off Risk | Excess ballast reduces velocity below 0.55m/s| +------------------------------------+----------------------------------------------+ ```

When automated optimization is needed, native Julia optimizers accept the structured `ComponentArray` types directly, returning the optimal solution in the exact same named format without manual vector packing and unpacking. Finally, sensitivity analysis is demonstrated on the ballast placement: a global sensitivity analysis using partial correlation coefficients (PCC) between ballast parameters and tip-off rates is constructed in a single line of code. For local sensitivity analysis, forward-mode automatic differentiation is executed simply by calling `ForwardDiff.jacobian` on the simulation function at the optimal ballast point. Because center-of-gravity (CG) coordinates and mass magnitudes differ substantially in magnitude, the sensitivities are normalized by the allowable parameter limits to prevent the CG coordinates from swamping the mass influence.

- Interactive 3D visualization of the separation dynamics is rendered via MeshCat.jl. - Real-time performance allows interactive slider-based parameter sweeps in notebooks, letting engineers explore system dynamics intuitively before running automated algorithms. - Forward-mode automatic differentiation produces local parameter sensitivities around the optimum by evaluating a single Jacobian call. - “A lot of times for engineering it's more important to actually get a feel for how your system behaves and be able to interactively explore it like that, and that's almost more important sometimes than getting the correct answer.” — Jonathan Diegelman - “It's cool that both the differential equation solver and the optimizer are written in native Julia, so you can just send the weirdest types you want through them and they come out correctly.” — Jonathan Diegelman

## Notable quotes > [12:56](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=776s) A lot of times for engineering it's more important to actually get a feel for how your system behaves and be able to interactively explore it like that, and that's almost more important sometimes than getting the correct answer. — Jonathan Diegelman

> [12:56](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=776s) It's cool that both the differential equation solver and the optimizer are written in native Julia, so you can just send the weirdest types you want through them and they come out correctly. — Jonathan Diegelman

## Mentioned Jonathan Diegelman, NASA Launch Services Program, A.I. Solutions, Julia, DifferentialEquations.jl, SciML, RECURSAT, Simulink, MATLAB, Sentinel-6 Michael Freilich, ComponentArrays.jl, MonteCarloMeasurements.jl, Unitful.jl, MeshCat.jl, ForwardDiff, Modelica, C++, Fortran

## Video description Modeling Spacecraft Separation Dynamics in Julia

Jonathan Diegelman, NASA Launch Services Program and A.I. Solutions

Abstract: A common requirement for commercially launched NASA science missions is that the launch vehicle imparts low enough rotational velocity to the spacecraft to avoid pointing sensitive equipment toward the sun while keeping high enough separation velocity to preclude re-contact between the vehicles. To assess compliance with this requirement, engineers in the Guidance, Navigation, and Control group in NASA’s Launch Services Program run high-fidelity simulations of the separation event. In the past, the GN&C group has favoured high-level modeling languages in order to reduce development time. Unfortunately, these simulations tend to be slow in comparison to direct implementations in low-level languages such as C++ or Fortran, making it difficult to iterate on analyses and build intuition about the system. In this presentation, a new spacecraft separation simulation written in Julia’s SciML suite of tools is shown to outperform the legacy tools by orders of magnitude while providing even greater flexibility. Additionally, the new simulation takes advantage of the key feature of the SciML tools: composability with the rest of the Julia ecosystem of packages. This allows features such as automatic differentiation/local sensitivity analysis, physical units, uncertainty propagation, interactive notebooks, and 3D visualization. Beyond the aerospace industry, this presentation is a case study in how better tooling can improve the way engineers think about complex systems.

For more information on the SciML Open Source Scientific Machine Learning Software Ecosystem, see https://sciml.ai/

For more info on the Julia Programming Language, follow us on Twitter: https://twitter.com/JuliaLanguage

Contents 00:00 Welcome! 00:15 Overview: A case study in tooling for engineering simulations 01:52 Spacecraft Separation: Problem description and modelling 04:22 Current Separation Analysis Tool: Flexibility, complexity and efficiency issues 07:49 RECURSAT: Design, requirements and capabilities 12:56 RECURSAT Demo: The ballast placement problem

S/O to https://github.com/pitmonticone for the video timestamps!

Want to help add timestamps to our YouTube videos to help with discoverability? Find out more here: https://github.com/JuliaCommunity/YouTubeVideoTimestamps

Interested in improving the auto generated captions? Get involved here: https://github.com/JuliaCommunity/YouTubeVideoSubtitles

[Source](https://www.youtube.com/watch?v=tQpqsmwlfY0)

中文简报

NASA以Julia替代Simulink，将卫星仿真运行时间缩短99% 将仿真时间从15分钟压缩至60毫秒以内，通过将批处理运行转变为实时交互式工程，打破了航天领域认为计算成本相比人力成本微不足道的传统观念。 NASA制导、导航与控制（GN&C）工程师Johnny Diegelman展示了将航天器分离动力学建模从僵化、缓慢的Simulink环境迁移至Julia的过程。分离分析需要审慎权衡相互冲突的约束条件——既要通过较高的分离速度防止航天器再次接触，又要限制倾斜角速度以保护光敏仪器并节省RCS推进剂。通过利用DifferentialEquations.jl、ComponentArrays.jl和Unitful.jl的精简递归多体求解器替换1000多行MATLAB配置脚本，仿真批处理时间从15分钟大幅缩短至60毫秒以内。Diegelman展示了这种约15000倍的加速如何变革工程工作流，使在笔记本中进行实时交互式参数扫描、不确定性下的原生优化以及用于灵敏度分析的无缝自动微分成为可能。 NASA发射服务计划（LSP）使用Julia开发了RECURSAT来模拟航天器分离动力学，用能够处理任意搭乘和次级载荷拓扑的模块化递归架构取代了原有的Simulink工具。 (7:49) 仿真执行时间从Simulink中运行514次蒙特卡洛模拟所需的15分钟骤降至Julia中的60毫秒以内，实现了约15000倍的加速。 (12:30) RECURSAT充分利用DifferentialEquations.jl、ComponentArrays.jl、MonteCarloMeasurements.jl和Unitful.jl之间的生态系统可组合性，消除了单位转换错误，并支持原生自动微分。 (10:21) 低于60毫秒的求解时间彻底改变了工程工作流，允许分析人员在运行数值优化器之前，在MeshCat.jl中进行基于滑块的交互式参数扫描和三维可视化。 (12:56)

Detailed notes — zh

## Background 该视频由 YouTube 频道 The Julia Programming Language 于 2021 年 3 月 9 日发布，主讲人为来自 NASA 发射服务计划（LSP）及 A.I. Solutions 的制导、导航与控制（GN&C）工程师 Jonathan Diegelman。视频基于其针对航天科学任务分离动力学仿真工具的工程实践，展示了团队如何利用 Julia 的 SciML 生态将原有的高层仿真工具重构升级，以兼顾极高计算性能与灵活的生态可组合性。 ## TL;DR 针对 NASA 航天器与运载火箭分离中极其严苛的倾侧角速度与相对分离速度约束，原有基于 MATLAB/Simulink 的传统工具链面临多星共乘拓展难、输入脚本臃肿庞杂以及运行耗时过长（514 次蒙特卡洛仿真需 15 分钟）的严重瓶颈。演讲者使用 Julia 语言及 SciML 套件开发了名为 RECURSAT 的新一代递归动力学仿真工具，不仅将原有运行时间大幅压缩至 60 毫秒以内（提速上万倍），还通过深度结合 ComponentArrays.jl、Unitful.jl 与微分方程求解器，实现了严格的物理单位校验、简化的不确定性传播及原生自动微分。在现场演示的配重块放置案例中，新工具不仅支持瞬时收敛的全局/局部敏感性分析与自动优化，更使工程师能够通过交互式滑块实时调参和 3D 可视化，快速建立对复杂力学系统的工程直觉。 ## Atmosphere & style 整场演讲呈现出一种严谨务实而又极具技术感染力的工程分享氛围。讲者 Diegelman 谈吐平实自信，在剖析航天工程严苛指标与历史工具缺陷时直击痛点，既有航天老将面对复杂动力学约束的严谨，又带有开源工具开发者特有的极客热情。从看到 15 分钟计算直接被压缩至 60 毫秒时的自豪，到现场演示拖动滑块实时渲染 3D 动力学姿态时的游刃有余，整场分享节奏轻快流畅，生动诠释了现代化编程工具如何为传统航天工程范式注入全新活力。 ## Bulletin - [00:11](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=11s) NASA 肯尼迪航天中心发射服务计划（LSP）的 GN&C 团队将航天器分离仿真工具从 MATLAB/Simulink 迁移至基于 Julia SciML 的自研工具 RECURSAT。 - [12:31](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=751s) 通过重构为纯 Julia 递归图算法，相同规模的蒙特卡洛分离仿真运行时间从原本的 15 分钟骤降至 60 毫秒以内，实现了近 15,000 倍的计算加速。 - [04:22](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=262s) RECURSAT 解决了传统因果框图对共乘任务（Rideshare）与立方星多星分离拓扑扩展困难的问题，将上千行的配置脚本精简为单页代码。 - [10:21](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=621s) 借助 Julia 生态的无缝组合性，新架构直接整合了 Unitful 物理单位强校验、ComponentArrays 命名数组、自动微分雅可比敏感性计算及 3D 动力学实时交互渲染。 ## Key takeaways - [01:53](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=113s) 航天器分离面临严苛且互斥的物理指标：既要压低倾侧角速度（< 1°/s）避免仪器直射太阳，又必须提供足够的相对速度（如 > 0.55 m/s）以防与火箭二次碰撞。 - [04:22](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=262s) 传统的 Simulink/MATLAB 仿真工具将单火箭-单航天器拓扑硬编码，无法敏捷应对近年来激增的多星共乘与小卫星次级载荷发射任务。 - [04:22](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=262s) Simulink 前端解析脚本处理派生分散参数逻辑错位，导致配置表单膨胀超过 1000 行，极易引发参数遗留错误并推高新人维护门槛。 - [04:22](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=262s) 针对“工程工时昂贵而算力廉价”的航天工程偏见，演说者指出迟缓的仿真会严重拖慢设计迭代周期，反向成倍消耗最昂贵的工程师工时。 - [07:49](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=469s) RECURSAT 工具采用深度优先的树状递归遍历算法，能够通用处理任意层级的航天器分离力学相互作用与反作用力传递。 - [10:21](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=621s) ComponentArrays.jl 允许将姿态四元数、角速度与弹簧形变等嵌套层级状态量直接传入原生 ODE 求解器，摆脱了笨重专用仿真框架的束缚。 - [10:21](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=621s) 引入 Unitful.jl 强制检查物理单位，有效避免了 NASA 在处理英制与公制混杂的跨国承包商工程图纸和技术协议时的人为换算失误。 - [10:21](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=621s) 蒙特卡洛参数不确定性在送入微分方程积分器前被解包为原生 EnsembleProblem，消除了离散事件（如弹簧脱开）与不确定度类型交互的异常。 - [12:31](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=751s) 仿真计算时间由 15 分钟直接压缩到 60 毫秒，颠覆了团队对复杂动力学系统的分析范式。 - [12:59](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=779s) 毫秒级的高性能求解器配合 MeshCat.jl 实时 3D 渲染，使工程师能通过滑块交互式微调配重块，相比黑盒优化更能培养直观的物理直觉。 - [12:59](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=779s) 优化器与求解器均基于纯 Julia 编写，结构化参数无需进行扁平化（Flatten）与反展平包装即可无缝穿透求解。 - [12:59](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=779s) 利用 ForwardDiff 前向自动微分单行提取仿真函数雅可比矩阵，需对偏导数按照参数允许界限进行无量纲归一化，以避免位置与质量量纲尺度的淹没效应。 ## Detailed walkthrough ### [00:11](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=11s) 讲座背景与工程仿真工具案例研究演讲者是来自 NASA 肯尼迪航天中心发射服务计划（Launch Services Program, 位于佛罗里达州）的制导、导航与控制（GN&C）工程师 Johnny Diegelman。他开门见山地指出，团队近期将一个关键分析工具从 MATLAB/Simulink 迁移到了 Julia 语言。这场演讲的核心并非单纯展示软件，而是作为一次深入的“工程仿真工具链案例研究”。Diegelman 特别强调了 Julia 科学机器学习（SciML）生态体系的模块化优势：“DifferentialEquations.jl 和所有 SciML 工具能够无缝协同整个 Julia 生态系统，这为我们打开了一扇通往广泛能力的大门，使我们能够按需挑选组件并直接装配到系统中。” 本次分享的脉络主要分为四个部分： 1. 航天器分离问题的工程背景与物理建模方式； 2. 团队原先基于 Simulink 的分离分析工具所面临的灵活性不足、复杂度膨胀与计算效率瓶颈； 3. 基于 Julia 开发的全新仿真工具 RECURSAT 的递归架构与设计规范； 4. 现场实机演示（Demo），展示参数交互式微调、不确定性下的优化、自动微分（AutoDiff）以及全局敏感性分析（Global Sensitivity Analysis）。 ### [01:53](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=113s) 航天器分离动力学与工程约束航天器分离看似简单，实则是发射任务中极为惊险的一环。Diegelman 展示了他近期参与的一项实际任务——哨兵6号“迈克尔·弗莱利克”卫星（Sentinel-6 Michael Freilich）。作为该任务的 GN&C 工程师，他负责了卫星与运载火箭二级分离的仿真分析。在工程指标上，分离动力学面临着极其严苛且相互冲突的物理约束： - **倾侧角速度（Tip-off Rotational Rate）限制**：分离瞬间赋予航天器的角速度通常必须压得极低，一般要求低于 1°/s 或每秒数度。绝大多数科学航天器在与火箭分离后，必须等待一段时间才能启动反作用控制系统（RCS）；在此之前航天器处于自由翻滚状态，绝对不能让敏感的科学载荷或光学仪器直面太阳。此外，航天器姿态控制系统（ACS）用于消除角动量（Detumbling）的推进剂预算极为有限。 - **相对分离速度要求**：与低角速度诉求正相反，分离系统必须提供足够大的相对分离速度，以确保航天器脱离后不会与运载火箭发生二次碰撞（Re-contact）。分离速度越大，分离机构引入的非对称扰动导致倾侧角速度超标的风险就越高。这种微妙的动力学权衡，使得整个系统对推冲弹簧刚度、接触点摩擦以及飞行器质量特性等参数极度敏感。在动力学建模方面，系统本质上是经典刚体动力学，姿态更新采用四元数进行传播。Diegelman 笑着承认仿真实现中的实用主义做法：“原谅我在这里滥用数学符号，把四元数当成了一个四维向量；我知道它并不是，但为了让代码更简洁，我们在仿真里就是这么实现的。”而整个模型中最复杂的力学机制来自边界分离部件： - **包带（Clamp Band）**：环绕固定航天器与运载火箭的卡环，释放时会释放巨大预紧能量，产生瞬时冲量；而且在脱离分离面边缘时会引发铰接力矩（Hinging Moment）。 - **推冲弹簧（Pusher Springs）**：提供轴向推力，实际推动航天器脱离火箭。 - **各类接插件（Connectors）**：包括吹风管路（Purge Lines）和电气脱落插头，拔出时会产生摩擦阻力与扰动力。 ### [04:22](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=262s) 现有 Simulink 工具的瓶颈：灵活性、复杂性与运行效率团队之前使用的生产工具是基于 Simulink 开发的，采用模块框图式因果建模语言（Block-diagram based causal modeling language），前端配备一个 MATLAB 脚本编写的输入文件（Input Deck），试图让工程师无需每次深入底层框图即可运行分析。然而在实际工程迭代中，这套系统暴露出三大致命缺陷：第一，**缺乏灵活性，无法应对多星共乘需求**。该 Simulink 模型在架构上被硬编码为“单火箭-单航天器”分离。当前商业发射中 CubeSat 以及各类共乘任务（Rideshares）呈现爆发式增长，“我们未来的几乎每一项任务现在都想搭载其他次级载荷，这是过去从未有过的”。在基于 GUI 的图形化建模语言中，动态配置任意数量和拓扑结构的多星分离系统极其困难。第二，**派生分散参数（Derived Dispersed Parameters）引发的架构复杂度爆炸**。在蒙特卡洛仿真中，参数抽样发生在输入文件被读取解析之后。例如，火箭干重服从正态分布，内部推进剂质量服从均匀分布；仿真内核实际上只关心二者相加的总质量（集中质量），但由于无法在解析层直接处理这种抽样分布运算，开发人员被迫在前端解析脚本中拼凑专门的逻辑。这种数据流向的错位使得输入文件极度臃肿。 ```mermaid flowchart TD accTitle: Simulink 与 RECURSAT 架构及蒙特卡洛流程对比 accDescr: 展示原有 Simulink 工具与基于 Julia 的 RECURSAT 在参数处理和仿真执行上的结构差异。 subgraph LEGACY["原有 Simulink 工具链"] direction TB M_IN["MATLAB 静态输入 Deck （超 1000 行配置代码）"] --> PARSE["输入解析函数 （处理复杂的派生参数分散）"] PARSE --> MC_OLD["Simulink 蒙特卡洛抽样 （514 次运算耗时约 15 分钟）"] MC_OLD --> LIMIT["架构缺陷：只支持单一分离体，无法交互调参"] end subgraph RECURSAT["RECURSAT (Julia) 工具链"] direction TB J_TYPES["轻量代码配置 （仅导入所需类型与函数）"] --> REC_EOM["通用递归动力学图 （支持任意多星/多级共乘拓扑）"] REC_EOM --> DIFF_JL["DifferentialEquations.jl 积分内核 （自动微分 / 并行蒙特卡洛）"] DIFF_JL --> INTERACT["亚秒级求解：支持实时交互、探索式优化"] end ``` 第三，**维护成本高且极度缓慢**。输入文件膨胀到了 1000 多行 MATLAB 代码。工程交期紧张时，在数千行配置中排查某个参数漏设或残留未清理，极其容易诱发人为失误，极高地拉抬了新人与实习生的培训门槛。更严峻的是运行耗时：执行 514 次蒙特卡洛模拟需要整整 15 分钟。航天工程界常有一种论调认为“工程师的工时是昂贵的，而计算资源是廉价的”，因此无需过度优化运行速度。Diegelman 对此给出了尖锐的反驳：“当使用迟缓的工具进行迭代需要消耗数倍的工程工时，计算本身就陡然变成了极其昂贵的成本。”由于无法进行即时反馈，工程师根本无法对设计权衡进行交互式探索，更谈不上在不确定性条件下进行数值优化。 ### [07:49](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=469s) RECURSAT 仿真器的递归设计与能力规范为了彻底根除上述痛点，Diegelman 基于 Julia 的 `DifferentialEquations.jl` 打造了一款名为 **RECURSAT** 的新仿真工具。遵循航天系统取缩写的传统，Diegelman 幽默地将其设计成了一个递归缩写词（Recursive Acronym）。 RECURSAT 能够以纯代码方式支持任意复杂的多级分离拓扑，其底层依靠优雅的深度优先树状递归遍历算法： ```mermaid flowchart TD accTitle: RECURSAT 递归力学评估与运动方程状态更新流程 accDescr: 描述 RECURSAT 在一个积分步长内，从父级到子节点递归计算分离力，并回传作用力与反作用力更新方程的过程。 P_FORCE["评估父级分离机构施加的作用力 （根节点/运载火箭无父级力）"] REC_CHILD["递归调用子节点函数"] C_FORCE["计算子节点分离系统产生的相互作用力"] LEAF_CHECK{"是否有更深层子节点？"} UPDATE_LEAF["更新当前叶节点运动方程 (EOM)"] RETURN_FORCE["向父级运动方程传递大小相等、方向相反的反作用力"] TIMESTEP["完成全系统力学平衡，步进时间步 (dt)"] P_FORCE --> REC_CHILD REC_CHILD --> C_FORCE C_FORCE --> LEAF_CHECK LEAF_CHECK -- "是" --> REC_CHILD LEAF_CHECK -- "否" --> UPDATE_LEAF UPDATE_LEAF --> RETURN_FORCE RETURN_FORCE --> TIMESTEP ``` 在设计指标上，团队对 RECURSAT 提出了明确要求： - **极致的计算效率**：单次运行仅需毫秒级，数百乃至数千次蒙特卡洛仿真必须在 1 秒以内完成，使实时交互式工程探索成为可能。 - **生态无缝组合（Composability）**：能够直接与 Julia 自动微分生态（如 ForwardDiff/Zygote）配合，支持端到端梯度反传。 - **通用性与极简配置**：适应任意复杂度的航天器构型。在最终落成的版本中，配置脚本从原来 Simulink 的 1000 多行断崖式压缩到可以直接展示在单页幻灯片内。用户不再面对庞大僵死的输入表单，只需按需导入类型与方法，并且随时可以在 Julia REPL 中调用 docstring 查看参数文档。 - 任务执行基准：原先需要运行 15 分钟的 514 次蒙特卡洛分析，在 RECURSAT 的性能目标下直接被压缩至 1 秒以内。 - 输入配置精简：用户侧代码实现完全模块化，省去复杂的派生变量预处理，彻底杜绝了脚本臃肿与配置遗留错误。 ### [10:21](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=621s) Julia 生态的可组合性：ComponentArrays、单位检查与不确定性传播 Jonathan Diegelman 指出，使用 Julia 进行重写最令人称道之处在于它能与整个 Julia 开源生态深度“无缝组合”（Composability）。首先，该仿真采用了 Diegelman 本人编写的开源库 `ComponentArrays.jl`。在航天动力学建模中，状态量通常具有高度复杂的嵌套层级结构（例如包含姿态四元数、角速度、各分离弹簧变形量等），`ComponentArrays.jl` 允许直接将这类带有字段命名的复杂嵌套数组无缝送入常微分方程（ODE）求解器或优化求解器中。正如 Jonathan Diegelman 所说：“And it allows it what's really nice is it allows for like modular design that you would usually get with a modeling framework like Simulink or Modelica or something but you don't need to have it it's just a regular differential equation solver so.” 这种设计无需依赖庞大笨重的专用仿真框架，就能提供同等的模块化建模体验。在不确定性传播与蒙特卡洛分析方面，该工具直接利用携带不确定度的随机变量进行运算，从根本上消除了此前困扰团队的相关参数（Dependent Parameters）耦合问题。工程师可以在输入端自由组合、相加各种不确定性分布；在正式进入微分方程求解器前，系统会将这些不确定性转换为求解器原生支持的集成问题（`EnsembleProblem`）。Diegelman 补充说明道，尽管微分方程求解器本身可以直接穿透处理不确定性变量，但由于这些变量与仿真系统中的某些条件判断语句（如弹簧触底、行程分离等离散事件）交互时的表现不够理想，因此团队在将参数送入求解器前会先进行显式解包。另一个不可或缺的组件是物理单位检查（通过 `Unitful.jl` 实现）。RECURSAT 强制要求仿真的每一个输入参数都必须明确附带物理单位。Diegelman 解释了这一严苛约束背后的现实痛点：NASA 的发射服务项目经常需要同时与欧洲和美国的承包商对接，工程技术人员甚至会在同一份技术协议或工程图纸中同时读到英制（Imperial）和公制（Metric）单位，稍有不慎就会引发灾难性的换算混乱。强制单位约束确保了数据录入阶段的绝对准确。此外，由于微分方程求解器与 Julia 生态的工具链兼容，代码只需单行调用即可完成全局敏感性分析（Global Sensitivity Analysis），并能通过前向模式（Forward-mode）或源码到源码（Source-to-source）的自动微分（AD）提取局部敏感性与雅可比矩阵（Jacobian），进而直接实现不确定性约束下的鲁棒设计优化。 ```mermaid flowchart TD accTitle: RECURSAT 架构与 Julia 生态组合流程 accDescr: 展示输入参数经单位校验与不确定性传播后，进入求解器并支持实时交互与敏感性分析的完整架构 subgraph Inputs ["参数定义与预处理"] A["物理参数输入 (带 Unitful 单位)"] --> B["不确定性与随机变量传播"] B --> C["ComponentArrays.jl 结构化状态量"] end subgraph SciML_Core ["SciML 核心求解"] C --> D["构建 EnsembleProblem 集成问题"] D --> E["原生 DifferentialEquations.jl 求解器"] end subgraph Downstream ["下游分析与工程应用"] E --> F["MeshCat.jl 3D 动力学实时渲染"] E --> G["前向自动微分 / 局部敏感性分析"] E --> H["鲁棒设计与不确定性优化"] end ``` - **核心包支持**：`ComponentArrays.jl`、`Unitful.jl`、`DifferentialEquations.jl`、`MeshCat.jl`。 - **单位安全性**：强制校验英制与公制单位输入，根除跨国承包商文档混用带来的单位换算错误风险。 - **敏感性支持**：支持全局敏感性分析（单行代码生成偏相关系数）与基于自动微分的局部敏感性分析。 --- ### [12:31](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=751s) 计算效率质的飞跃：从 15 分钟缩短至 60 毫秒在探讨了架构优势之后，Diegelman 将重点转向计算效率。对比结果十分悬殊：此前在传统 Simulink 工具链中需要耗时 15 分钟才能跑完的一整套标准分离仿真计算，在用 Julia 重构的新工具中耗时直接降到了 60 毫秒（0.06 秒）以内。正如 Jonathan Diegelman 所评价：“The important part is we're under 60 milliseconds for that same set of runs that took 15 minutes in our Simulink tool which it was pretty amazing to us it's you know that 15,000 number doesn't matter as much as just the fact that it's very, very fast now and we're still incorporating some features maybe maybe it'll take twice as much time when we're done but even so that's great still.” 这一高达 15,000 倍的提速令工程团队非常振奋。Diegelman 谦逊地表示，尽管后续为了支持更完备的工程特性，仿真时间可能会翻倍增长，但即便从 60 毫秒增加到 120 毫秒，这样的执行效率依然彻底颠覆了他们原有的工作流。 --- ### [12:59](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=779s) 演示：航天器配重块放置问题与交互式工程直觉 Diegelman 通过一个典型的工程分析案例演示了 RECURSAT 的实战能力：航天器分离配重块放置问题（Ballast Placement Problem）。任务的硬性动力学指标包含两条： 1. 分离引起的航天器各轴转动速率（Tip-off Rate）必须小于 1 度/秒（$< 1^\circ/\text{s}$），以防止敏感科学仪器在分离瞬间指向太阳或发生失稳； 2. 航天器与运载火箭级段之间的相对分离速度必须大于 0.55 米/秒（$> 0.55\text{ m/s}$），以确保两器不会发生二次碰撞。在未经优化的基线仿真中，团队利用 `MeshCat.jl` 实时生成了分离过程的 3D 交互动画。可视化与曲线结果显示，航天器绕 Y 轴的转动速率超出了要求上限。常规的工程缓解策略是在航天器内部加装配重块（Ballast Mass）。该方案包含特定的自由变量与物理约束：配重块的质量存在上限，且其空间位置必须严格位于航天器外壁所包络的允许装载空间内；同时配重块质量绝不能过大，否则会由于惯量与总重增加导致相对分离速度跌破 0.55 米/秒的下限。 ``` 典型分离分析约束对比： ┌──────────────────────────────┬──────────────────┬─────────────────┐ │ 约束指标 │ 工程要求 │ 基线仿真结果 │ ├──────────────────────────────┼──────────────────┼─────────────────┤ │ 三轴转动速率 (Tip-off Rate) │ < 1.0 deg/s │ 超标 (Y 轴不合格)│ │ 相对分离速度 (Separation V) │ > 0.55 m/s │ 达标 │ └──────────────────────────────┴──────────────────┴─────────────────┘ ``` 此时，极高的仿真效率带来了一种全新的工作模式——实时交互式参数探索。由于单次仿真只需几十毫秒，工程师可以在控制台中拖动滑块实时手动调整配重块的质量和空间坐标，并在毫秒级延迟下直观观察分离速率与 3D 动画的变化。针对这一点，Jonathan Diegelman 深刻地剖析了工程工具对思维习惯的影响：“One of the things is you tend to think of you know going straight to optimization or sensitivity analysis but a lot of times for engineering it's more important to actually get a feel for how how your system behaves and be able to interactively explore it like that and that's just it and it's almost more important sometimes than getting the you know correct answer or something.” 相比直接运行黑盒优化算法，这种实时的感官反馈能帮助工程师真正建立起对复杂力学耦合系统的“物理直觉”。在展示不确定性下的自动化优化时，Diegelman 强调，由于常微分方程求解器和优化器均由纯 Julia（Native Julia）编写，`ComponentArrays` 这种结构化复合类型可以直接作为待优化向量输入优化器，优化器迭代求解后能够直接输出同样结构的原生类型，完全不需要繁琐的数据展平（Flatten）与反展平打包。在敏感性分析展示中，左侧的全局敏感性分析代码仅用一行便完成了配重参数对脱轨角速度的偏相关系数（Partial Correlation Coefficient）计算。右侧的局部敏感性分析则直接对整个仿真函数调用雅可比矩阵求值： ```julia # 前向模式自动微分提取雅可比矩阵 ForwardDiff.jacobian(f, optimal_ballast_params) ``` Diegelman 解释道，在计算配重参数最优点附近的局部敏感度时，必须用参数的允许极限范围（Limit Range）对偏导数进行无量纲归一化缩放；否则，质心坐标（CG）量纲数值的微小变化就会因为尺度差异而完全淹没配重质量（Mass）的影响。演讲最后，Diegelman 总结了该工具带来的范式转变，并向听众致谢并开放问答。 ## Notable quotes > [04:22](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=262s) 当使用迟缓的工具进行迭代需要消耗数倍的工程工时，计算本身就陡然变成了极其昂贵的成本。 — Johnny Diegelman > [00:11](https://www.youtube.com/watch?v=tQpqsmwlfY0&t=11s) DifferentialEquations.jl 和所有 SciML 工具能够无缝协同整个 Julia 生态系统，这为我们打开了一扇通往广泛能力的大门，使我们能够按需挑选组件并直接装配到系统中。 — Johnny Diegelman ## Mentioned Jonathan Diegelman, NASA Launch Services Program, A.I. Solutions, 肯尼迪航天中心, Julia, MATLAB, Simulink, Modelica, SciML, DifferentialEquations.jl, ComponentArrays.jl, Unitful.jl, MeshCat.jl, ForwardDiff, Zygote, RECURSAT, Sentinel-6 Michael Freilich, CubeSat ## Video description Modeling Spacecraft Separation Dynamics in Julia Jonathan Diegelman, NASA Launch Services Program and A.I. Solutions Abstract: A common requirement for commercially launched NASA science missions is that the launch vehicle imparts low enough rotational velocity to the spacecraft to avoid pointing sensitive equipment toward the sun while keeping high enough separation velocity to preclude re-contact between the vehicles. To assess compliance with this requirement, engineers in the Guidance, Navigation, and Control group in NASA’s Launch Services Program run high-fidelity simulations of the separation event. In the past, the GN&C group has favoured high-level modeling languages in order to reduce development time. Unfortunately, these simulations tend to be slow in comparison to direct implementations in low-level languages such as C++ or Fortran, making it difficult to iterate on analyses and build intuition about the system. In this presentation, a new spacecraft separation simulation written in Julia’s SciML suite of tools is shown to outperform the legacy tools by orders of magnitude while providing even greater flexibility. Additionally, the new simulation takes advantage of the key feature of the SciML tools: composability with the rest of the Julia ecosystem of packages. This allows features such as automatic differentiation/local sensitivity analysis, physical units, uncertainty propagation, interactive notebooks, and 3D visualization. Beyond the aerospace industry, this presentation is a case study in how better tooling can improve the way engineers think about complex systems. For more information on the SciML Open Source Scientific Machine Learning Software Ecosystem, see https://sciml.ai/ For more info on the Julia Programming Language, follow us on Twitter: https://twitter.com/JuliaLanguage Contents 00:00 Welcome! 00:15 Overview: A case study in tooling for engineering simulations 01:52 Spacecraft Separation: Problem description and modelling 04:22 Current Separation Analysis Tool: Flexibility, complexity and efficiency issues 07:49 RECURSAT: Design, requirements and capabilities 12:56 RECURSAT Demo: The ballast placement problem S/O to https://github.com/pitmonticone for the video timestamps! Want to help add timestamps to our YouTube videos to help with discoverability? Find out more here: https://github.com/JuliaCommunity/YouTubeVideoTimestamps Interested in improving the auto generated captions? Get involved here: https://github.com/JuliaCommunity/YouTubeVideoSubtitles [Source](https://www.youtube.com/watch?v=tQpqsmwlfY0)

Source quotes

[4:22] Johnny Diegelman: 当使用迟缓的工具进行迭代需要消耗数倍的工程工时，计算本身就陡然变成了极其昂贵的成本。 [0:11] Johnny Diegelman: DifferentialEquations.jl 和所有 SciML 工具能够无缝协同整个 Julia 生态系统，这为我们打开了一扇通往广泛能力的大门，使我们能够按需挑选组件并直接装配到系统中。

Source quotes

[12:56] Jonathan Diegelman: A lot of times for engineering it's more important to actually get a feel for how your system behaves and be able to interactively explore it like that, and that's almost more important sometimes than getting the correct answer. [12:56] Jonathan Diegelman: It's cool that both the differential equation solver and the optimizer are written in native Julia, so you can just send the weirdest types you want through them and they come out correctly.

Original transcript

[0:11] so i assume you guys can hear me and see [0:12] my screen [0:14] right so let's talk about modeling [0:16] spacecraft [0:17] separation dynamics um so one thing i [0:21] uh my name is johnny diegelman i'm a [0:23] guidance navigation control engineer [0:25] at nasa on the launch services program [0:27] in florida um [0:29] so one thing i kind of wanted to talk [0:31] about is um [0:33] is so we recently migrated one of our [0:35] tools over from simulink to julia and i [0:38] really [0:38] wanted this talk to be kind of a case [0:40] study in um [0:41] tooling for engineering simulations and [0:45] and one thing to pay attention to is uh [0:48] i wanted to highlight uh how nice it is [0:51] that [0:52] the differential equations dot jl and [0:54] all the cml tools just work with the [0:56] entire julia ecosystem [0:58] so that just opens us up to a broad [1:01] range of capabilities that we can just [1:03] kind of [1:04] pick pieces as we want and put them in [1:06] place [1:08] all right so let's go so brief overview [1:12] we'll talk about spacecraft separation [1:14] what the problem even is [1:15] um how we model it we'll talk about our [1:18] current [1:18] separation analysis tool and simulink on [1:20] the problems that we have [1:22] with it and why we were looking for [1:23] something different [1:25] then i'll talk about a simulation i [1:27] wrote in differential equations.jl [1:29] called recursat [1:32] talk about its capabilities and then [1:33] finally the more interesting part is [1:35] you know i'll demo it a little bit with [1:39] a typical [1:40] design type design problem that we would [1:42] be solving um [1:43] so you'll see some interactive parameter [1:45] tuning um optimization under uncertainty [1:48] and um auto diff and global sensitivity [1:51] analysis [1:53] so let's talk about spacecraft [1:55] separation um this right here is a [1:57] mission that i worked on recently [2:01] uh that is the sentinel six michael [2:03] freilik mission i was the [2:04] um gnc engineer for it and i did the [2:08] separation simulation um and [2:11] um analysis for it so one of the [2:13] problems with uh [2:15] that so what that was a video of is the [2:17] spacecraft separating from the upper [2:19] stage of the launch vehicle [2:21] so one of the problems you have is you [2:23] have tight tip off [2:24] rotational rate requirements um usually [2:27] a degree per second or [2:29] a couple degrees per second and the [2:31] reason for that is [2:32] a lot of spacecraft have to wait to turn [2:35] on reaction control systems and they [2:37] can't [2:37] point sensitive equipment into the sun [2:39] while they're waiting [2:41] and they're just in a free tumble until [2:42] then and they [2:44] sometimes will have limited acs budget [2:48] for detumbling [2:49] because they're actually you know using [2:51] gas to detumble themselves [2:54] so what kind of works against this [2:56] tip-off requirement is there'll also be [2:58] a requirement [2:59] that the two vehicles have a minimum [3:02] relative [3:03] velocity so they don't re-contact each [3:05] other [3:06] so you know the the higher separation [3:08] velocity you have [3:10] the more likely you are to violate your [3:12] tip-off rates [3:13] so everything's very sensitive to [3:16] system parameters spring constants mass [3:19] vehicle [3:19] vehicle mass properties and such [3:22] so let's just talk briefly about [3:24] modeling it's simple [3:26] rigid body dynamics don't really need to [3:28] go over the equations [3:29] everyone kind of knows them we use [3:31] quaternions to update the attitude [3:34] i forgive the abusive notation here i'm [3:36] you know pretending a quaternion is a [3:38] four element vector i know it's not but [3:40] that's how it's coded in the simulation [3:42] because it makes it easier so our [3:44] forcing functions are [3:46] the more difficult part um is you have [3:49] things like the the clamp band is the [3:51] part that keeps the spacecraft and [3:52] launch vehicle together it's it's a ring [3:54] around it and [3:55] it releases it imparts um it [3:58] imparts an impulse when it releases and [4:00] then it can also [4:01] um as it separates around it can kind of [4:04] give a hinging moment so you have to [4:07] simulate that um you have pusher springs [4:10] that'll be what actually pushes the [4:12] vehicle off the [4:13] spacecraft off the launch vehicle and [4:15] then there's various connectors which [4:17] connectors which provide some friction [4:20] purge lines and electrical connectors [4:22] and such [4:23] um so our current tool is written in [4:27] a gui base it's written in simulink so [4:30] it's block diagram based uh causal [4:32] modeling language [4:33] um and we have a user facing input deck [4:36] which is a matlab script so you don't [4:38] have to dig into the simulation each [4:40] time [4:41] the idea is you want to keep it pretty [4:43] pretty easy to [4:45] set up new analyses every time so the [4:47] problem we had with it [4:48] for one is it's just not very flexible [4:51] it can only handle [4:52] one spacecraft launch vehicle separation [4:56] and there's a growing demand for [4:57] cubesats and other [4:59] ride shares almost every mission we have [5:01] going forward [5:02] is wanting to include other secondary [5:04] missions on it now which we never had [5:06] that in the past [5:08] and it's really hard to have something [5:10] like that in [5:12] a language in a gui based language like [5:15] simulink because how do you just handle [5:16] arbitrary configurations [5:18] it's a tough problem set up so another [5:21] problem [5:22] is handling derived dispersed parameters [5:24] and this one's a little more subtle but [5:26] it's important [5:27] so the monte carlo dispersion draws [5:29] happen after the input deck is right in [5:32] so the problem with this is let's look [5:34] at an example it'll [5:35] hopefully make it more clear let's say [5:37] you have a vehicle dry mass it's [5:38] normally distributed [5:40] and a the propellant mass inside of it [5:43] is you know uniformly distributed [5:45] well your simulation doesn't actually [5:47] care about either of those it just wants [5:49] to know the mass it's just treating it [5:50] as a lump mass well [5:52] now you need to if you want to disperse [5:55] those parameters and [5:56] handle them correctly now you need to [5:58] add stuff [5:59] into your input deck and the input [6:01] parsing function just to be able to [6:03] handle that so it really leads to this [6:05] explosion of complexity which leads to [6:07] the next problem [6:09] is that it just gets really complicated [6:11] for what should be a simple simulation [6:14] your input deck it's [6:17] over a thousand lines of matlab code [6:19] which for some projects wouldn't be that [6:21] much but if [6:22] you need to turn around analyses you [6:24] know within [6:25] a couple of hours or something like that [6:27] that it's pretty [6:29] prohibitive and it's error-prone did you [6:32] remember to set every parameter you [6:33] needed over those thousand lines did you [6:35] remember to unset parameters from other [6:37] things that you didn't need [6:39] it's just it's not great for that [6:42] so it really prohibits quick turnaround [6:44] analyses and [6:45] it's a high learning curve for [6:47] especially we we get in interns a lot [6:50] and new engineers and stuff and this is [6:52] supposed to be [6:53] the easier stuff that we do and this is [6:56] usually a task that we could give to [6:57] them but even so [6:59] just the tooling around it makes it very [7:01] difficult to teach [7:03] so and the biggest problem is that it's [7:05] slow it's about 15 minutes for [7:07] you know 514 monte carlo runs that was [7:10] our last analysis did that many [7:13] um and the typical argument is you know [7:16] engineering times expensive compute is [7:18] cheap so don't really worry about it [7:19] well the problem with that [7:20] is when it takes engineering hours to [7:22] iterate with slow tools [7:24] all of a sudden compute becomes [7:25] expensive um [7:27] so you know you end up spending hours [7:30] debugging something that [7:31] should be a 15-minute turnaround maybe a [7:34] little more than that [7:35] but um another problem is you can't [7:36] interactively explore things parameter [7:38] sensitivities design trade-offs and [7:41] if you want to optimize under [7:43] uncertainty it's just [7:45] you know that's that would just it takes [7:47] too long to really [7:48] be reasonable so let's talk about the [7:51] the tool that um i developed in julia [7:54] for uh solving these problems um so [7:57] let's go over the design first is [7:59] it's um it it's a recursive design [8:01] that's how it's able to handle you know [8:03] arbitrary configuration so [8:04] walk through the algorithm really quick [8:06] is forces and inputs [8:08] uh the forces um are calculated from the [8:11] parent separation system in this case [8:13] it doesn't have one that's the parent [8:15] vehicle right there and then the [8:16] function is called on the children [8:18] and then the forces are calculated for [8:20] that child [8:21] um it does have a separation system and [8:24] then it calls [8:25] uh the function on its children forces [8:27] are calculated [8:28] calls on its children this one doesn't [8:30] have any children so it goes to the next [8:32] step where [8:32] um updates the vehicle's equations of [8:35] motion with those forces [8:36] and then it passes back the equal and [8:38] opposite forces to the parent [8:40] equations of motion equal and opposite [8:42] equations of motion [8:44] and then there's no parent to pass back [8:46] to so you um take the update [8:48] step um you increment your time step [8:51] so the requirements we had for it um [8:54] were we want it to be efficient and we [8:56] want to run hundreds if not thousands of [8:57] monte carlo runs in under a second [8:59] because we want to be able to [9:00] interactively explore things which [9:01] sounds like a tall order coming from 15 [9:04] minutes before but [9:05] you'll see we wanted to be able to [9:07] compose with the rest of the [9:09] julie ecosystem so if you want to auto [9:11] diff through it great [9:13] um that that's something we wanted um [9:16] just as flexible as possible we want it [9:18] to be universal [9:20] to be able to handle any kind of mission [9:22] um [9:23] and reasonably simple we don't we want [9:25] it to be a simple uh input to set up [9:28] and of course because it's nasa it has [9:30] to have an acronym because [9:32] that's i guess what we do and because [9:34] it's a recursive tool i made it a [9:36] recursive acronym [9:37] um so let's talk about the uh [9:40] fulfilled requirements so it is uh [9:43] universal uh [9:44] the recursive structure really allows [9:46] for the equations of motion to be [9:48] written [9:48] for really arbitrary configurations [9:50] which is great [9:51] it's pretty simple this is the entire [9:54] input deck um [9:55] now going from a thousand lines to this [9:57] on the right i can fit it on one slide i [9:59] mean [10:00] it's a little more complicated if we [10:01] want to add some more [10:03] umbilical connectors and stuff like that [10:04] but this is kind of the general [10:07] setup so instead of having a static [10:09] input deck [10:10] that grows in complexity you import your [10:12] types and functions [10:14] you only specify what you need and [10:16] there's doc strings right there in the [10:18] ripple for [10:18] that'll tell you what to do um and the [10:21] nicest part about it is [10:23] um that it's really composable with the [10:26] rest of the julia ecosystem [10:27] um so for one we use component arrays a [10:30] library i i wrote so [10:32] the idea is you have these arrays with [10:34] complex nested structures like this one [10:36] on the right [10:37] and it can just pass right through a [10:38] differential equation solver or an [10:39] optimization solver [10:41] um so this is what our initial [10:43] conditions look like before they go into [10:45] the solver [10:47] and it allows it what's really nice is [10:50] it allows for like modular design that [10:51] you would usually get with a modeling [10:53] framework like simulink [10:55] or a delica or something but you don't [10:57] need to have it it's just a regular [10:58] differential equation solver so [11:01] um another thing is monte carlo [11:03] measurements we use um [11:04] it's random variables that propagate [11:07] uncertainty [11:08] and this really solves that problem that [11:10] dependent parameter problem i was [11:12] talking about because [11:13] you set up your inputs and you could add [11:15] together uncertainties you could [11:17] do whatever you want with them and then [11:19] right before we go into the [11:20] equation solver we turn it into an [11:22] ensemble problem [11:25] you could pass these through [11:26] differential equation solver it works [11:28] perfectly fine the problem is it doesn't [11:30] interact with conditional statements in [11:33] the way that you would really want so [11:34] we do unpack them before we send them [11:36] through so another thing we use is [11:39] unifor [11:39] every input we use has to have um [11:42] requires physical units um and [11:46] uh this is important for us because we [11:47] work with both european and american [11:50] contractors all the time and sometimes [11:51] even the same document we'll have [11:53] empirical imperial and metric um units [11:56] and it's just [11:57] it can be a mess if if you're not [11:59] careful about that so [12:00] this require this makes sure that people [12:03] are putting in correct units as they do [12:05] so if global sensitivity analysis is you [12:08] know one aligner [12:10] both forward mode and source to source [12:12] automatic differential equation [12:14] which are um so work with it [12:17] um gives us local sensitivity analysis [12:20] and makes it easier to [12:22] optimize designs and optimization under [12:25] uncertainty for robust design with [12:27] difficult uncertainty [12:28] and often so yeah let's talk about [12:31] efficiency [12:32] um the important part is we're under uh [12:35] 60 milliseconds for that same set of [12:38] runs that took 15 minutes in our [12:39] simulink tool [12:40] which it was pretty amazing to us it's [12:43] you know that [12:44] 15 000 number doesn't matter as much as [12:46] just the fact that [12:47] it's very very fast now and we're still [12:50] incorporating some features maybe [12:52] maybe it'll take twice as much time when [12:54] we're done but even so that's [12:57] great still uh so yeah let's actually [12:59] get into the demo [13:00] is kind of the more interesting part um [13:03] let's look at a kind of normal typical [13:06] analysis problem we have we have [13:08] requirements [13:09] less than a degree per second rotation [13:11] rate null spacecraft axes [13:13] and greater than 0.55 meters per second [13:15] relative velocity [13:16] between spacecraft and launch vehicle [13:18] and we simulate [13:20] it and this little 3d thing that's from [13:22] meshcat.jl [13:23] you know it's really easy to just throw [13:25] throw the results in there and get a [13:28] 3d um visualization um so we see in the [13:32] top right [13:32] we're not meeting our y-axis tip-off [13:34] requirement so let's uh talk about some [13:36] strategies to [13:37] mitigate that so one we would do is add [13:41] a ballast mast inside the spacecraft [13:43] so here's our free variables and [13:45] constraints [13:47] certain mass constraint and then you [13:49] have a positional constraint of where it [13:50] can be inside the spacecraft [13:54] and we have to make sure we don't add [13:55] too much mass because that'll bring down [13:56] our separation velocity and [13:58] below the requirement so here's one [14:01] thing that's really cool is now because [14:03] the tool is so fast if you want to just [14:04] manually look at parameters you could do [14:06] that and i think [14:07] one of the things is um you tend to [14:09] think of you know going straight to [14:11] optimization or sensitivity analysis but [14:14] a lot of times for engineering it's more [14:17] important to actually get a feel for [14:19] how um how your system behaves and be [14:22] able to interactively explore it um like [14:24] that [14:25] and that's just it and it's [14:28] almost more important sometimes than [14:30] getting the you know correct answer or [14:32] something so this [14:33] being able to run simulations this fast [14:35] and looked at and this is all real time [14:38] is incredibly helpful for engineers [14:41] um optimization under uncertainty one of [14:44] the cool things i want to highlight here [14:45] is that component array type [14:46] i showed you before that has you know [14:48] the kind of structured input or whatever [14:50] you could send that through an optimizer [14:53] and it [14:54] gives you out the answer as that [14:56] structured form so um [14:57] it's cool that both the differential [14:59] equation solver and the optimizer are [15:01] written in native julia so you can just [15:02] send the weirdest [15:04] types you want through them and they [15:05] come out correctly [15:07] and last i just want to show a [15:09] sensitivity analysis [15:10] so on on the left is a global [15:12] sensitivity it was a one-liner to set it [15:14] up [15:15] get the partial correlation coefficient [15:17] of the tip-off rates to ballast [15:19] parameters [15:20] super simple like very little code to [15:22] set this up [15:23] and then you could auto diff through it [15:25] um there's forward mode auto diff it's [15:27] literally just calling [15:28] the jacobian on the function and um and [15:31] the optimal ballast parameters [15:33] were um looking at about the optimal in [15:36] this case [15:36] and i scaled it by the the limit range [15:38] because otherwise the [15:40] cg swamps out the mass because the mass [15:42] is just a totally different scale than [15:43] the cg [15:44] so yeah that's um that's really all i [15:46] wanted to talk about today if you have [15:48] any questions [15:49] let me know [16:03] you