Skip to content

System

Rocket as a system of systems

An integrated launch vehicle is 18 interdependent domains. Propulsion is where APEX started; every other domain has its own purpose, interfaces, evidence and partner capabilities.

Detail of APEX propulsion development hardware: a spherical vessel in the foreground, metal assemblies, tubing and cabling behind.
Fig. 04APEX propulsion development hardware — detail.

Why an engine is only the beginning

Building an engine is the beginning.

Progressing toward a credible launch system requires coordinated development across propulsion, structures, avionics, embedded systems, software, sensors, manufacturing, quality, testing, ground systems and specialist engineering.

1Engine demonstrator built
18System domains
40Specialist capabilities
  • Propulsion
  • Structures
  • Avionics
  • Embedded systems
  • Software
  • Sensors
  • Manufacturing
  • Quality
  • Testing
  • Ground systems
  • Specialist engineering

The engine is where APEX started. Each discipline above is a system of its own, with interfaces to the others.

System explorer

Select a domain

Six groups, eighteen domains. Open a group, then a domain, for its purpose, interfaces, evidence, partner capabilities and dependencies. The technical view adds the interface matrix.

  • Built
  • Concept
  • Partner Required
  • Evidence Required

Authority

Where APEX fits

Partners contribute capability. Intent, architecture, configuration and acceptance stay with APEX.

PropulsionEngine architecture, requirements and hardware.
Mission requirementsWhat the vehicle must do, and for whom.
System architectureHow the subsystems fit together.
IntegrationIntegration authority across partners.
Where APEX fits

APEX Rocket Systems

Rocket System & Propulsion Program Owner
Test objectivesWhat each test must prove.
ConfigurationThe hardware, firmware and software baselines.
Engineering decisionsDesign choices and trade-offs.
AcceptanceWhether evidence is good enough.

Specialist ecosystem partners contribute capabilities. APEX retains system intent and engineering authority.

Solid amber: what APEX holds. Dashed outer ring: where partners contribute.

Engineering governance

Review gates

Each gate asks one question and needs evidence to pass. They give investors, partners and authorities a shared view of maturity.

  1. GateMCRMission Concept ReviewIs the mission worth doing, and is the concept feasible?
  2. GateSRRSystem Requirements ReviewAre the requirements complete, consistent and verifiable?
  3. GatePDRPreliminary Design ReviewDoes the preliminary design meet the requirements with acceptable risk?
  4. GateCDRCritical Design ReviewIs the detailed design mature enough to build and test?
  5. GateTRRTest Readiness ReviewAre hardware, procedures, facilities and people ready to test safely?
  6. GateFRRFlight Readiness ReviewIs the evidence sufficient to fly?
Process conceptNo review is shown as completed. Gate records will be published only with APEX’s confirmation.

Technical view

Questions a CTO will ask

Who owns the architecture?
APEX.
Who owns technical decisions?
APEX.
How are interfaces managed?
Through systems engineering: interface definitions, traceability and configuration baselines under APEX authority.
How is hardware validated?
Progressively — material, part, component, subsystem, engine, propulsion system, vehicle — with evidence at each rung.
How is firmware validated?
Unit and interface tests, software- and hardware-in-the-loop, then integration — each tied to a released baseline.
How is model confidence built?
By predicting before each test and correlating with measurements on the same configuration.
How are changes controlled?
A configuration-aware digital thread links every change to the hardware, firmware, software and model revisions it affects.
How are partners kept from becoming silos?
Every partner is mapped to capabilities, every capability to interfaces, and every interface to evidence.