Simulation Environment

Andi Lamprecht ·2026-05-11· 2 min read· Accepted

UTM Simulation Environment

Context

UTM currently use the Sandbox > Dev > Prod deployment sequence, each with a different level of maturity for the application.

Our Dev environment is actively being tested for InterUSS in Dallas. As part of the InterUSS testing, we need an additional
environment that doesn’t conflict with Dev that we can pass simulated data through.

Problem Statement

This addresses the problem that our dev environment might be used for many, potentially conflicting, purposes:

• InterUSS Qualification Testing
• InterUSS Simulation Testing
• Uncrew Testing

In addition to conflicting test contexts, the InterUSS Qualification and Simulation environments
require different DSS and Auth servers to be used.

Note from Jake Goldsberry

There are a unique set of requirements for the InterUSS in Dallas project that have driven our
current approach to environment design. We will be afforded opportunities to amend these
requirements over time, but the base set of MVP requirements are locked in. It is worth remembering
that, to our knowledge, this is the first time an open source software project that is
industry-maintained has been used to support safety-critical applications. The emphasis of
these environment requirements is on verification and validation of the project’s MVP requirements
as two discrete steps in the onboarding and checkout process.

These are the requirements we are executing against:

• We need to be in a position to rapidly add support for new / updated requirements when prioritized by the consortium.
• Any functional change to our interUSS codebase must pass the existing set of automated tests in the qualification environment before publishing to production.
• Our interUSS interfaces must be highly available across all project environments.
• Our codebase must experience minimal environment drift.
• We must support checkout against an automated test suite locally and in an industry-shared qualification environment.
• We must support “day in the life” simulation in a non-production environment to validate operational practicality with Uncrew.
• Wing currently hosts a standalone Discovery and Synchronization Service (DSS) and OAuth authentication server for the project. These services exist in three environments: qualification, simulation, and production.

Decision Drivers

• predictable testing results
• reliable testing results

Decision

The stage environment will be repurposed to be simulation and deployed along with dev.

The new deployment sequence would then be: Sandbox > Dev/Simulation > Prod.

Consequences

• A FrontEgg QA environment must be shared with the Simulation environment