For over two and a half years I’ve contributed to a free and open-source addon called “NASSP” for the Orbiter space flight simulator program. This addon simulates the Apollo space program that landed humans on the moon in the 1960s and ’70s. That is to say, it adds all the relevant space vehicles, including the Saturn IB, Saturn V, Command and Service Module, Lunar Module, and even the tangentially-related Skylab orbital workshop. Additionally, it includes the necessary logic to compute and fly the historical missions, or even plan one’s own custom missions.
For the Saturn launch vehicle, the Command and Service Module, and Lunar Module, a vast majority of systems are implemented and functional, acting very similarly to their real-life behavior. For each vessel, we have whole heaps of code which simulates the inner workings of the various systems and components inside the craft, including but not limited to: environmental control and life support; electrical power generation and distribution; cryogenic, gas, and liquid consumables; thermal control and heating/cooling; propulsion; and guidance, navigation, and computer subsystems. Orbiter, the simulator itself, handles the complex physics and aerodynamics of flight, and provides some help with loading and rendering assets like graphics, but pretty much all other computations and work is done by our code. Broadly speaking, every switch in the cockpit works and does what the NASA documentation and specifications say it does, and the systems running inside the spacecraft work extremely closely to how they would in real life, too.
This project is intended to be a “study simulation”: a simulation that is accurate and realistic enough that it can be used to study and learn about the spacecraft behavior, procedures, and mission profiles in as close to an academic manner as can be done with the information and technology available. There are alternative pieces of software out there, such as AMSO (Apollo Mission Simulator for Orbiter) and the excellent ReEntry: A Space Flight Simulator, but while both of these projects are very well-done, they are simplified by design; intended to be more accessible to a wide audience. While we do of course want NASSP to be accessible and easy to understand, we also try very hard not to compromise on accuracy in ways that other simulations of Apollo might. We do include some quality-of-life features such as a fast-forward function to skip portions of no mission activity, the ability to save at any time, as well as a semi-automated checklist display via Orbiter’s multi-functional display (MFD) system. But if, for example, you’re a stickler for pure historical accuracy (or just like paging through real Apollo documents like we often do) and you’ve got a copy of the real checklists and flight plan for a particular mission, you can absolutely fly using those if you want! Heck, if you’d prefer not to use the quicksave or fast-forward system, and have more than a week of continuous spare time, you can even fly the missions in real-time from start to finish. It’s actually been done a couple times already!
With all that said, since we try not to simplify, expect to follow procedures closely and to practice discipline and patience. This is actual rocket science, and it won’t always be easy! We recommend making quicksaves frequently: there will be times where you’ll need to reload from a previous point and retry while you’re learning the ins and outs of flying a mission. Systems and procedures are complex and require practice to master, there’s a few dozen acronyms and abbreviations to memorize, and there’s hundreds of switches and circuit breakers spread across two different spacecraft that you’ll need to find and use; not to mention you’re a single person doing the work of three trained astronauts! If that doesn’t sound like it’s for you, we highly recommend checking out some of the previously mentioned alternative software, particularly ReEntry, and see if that strikes your fancy! At the end of the day, we’d really love nothing more than for as many people to appreciate the significance and impact of the early space programs.
In its current state, you can generally expect that, for any given historical mission:
- The simulation is date- and time-accurate. That is, the simulated solar system should match the general conditions at the specified date and time of the real historical events. The Earth, moon, sun, and other celestial bodies should all be in an accurate position. This is courtesy of Orbiter’s ability to simulate at an arbitrary MJD.
- Due to the above point, lighting conditions generally match those of the real historical date, meaning that the visual context of maneuvers, optical sightings, etc. will line up with how things looked to the astronauts. This means it is also possible to somewhat faithfully recreate photos taken during the missions. It should be noted, however, that Orbiter’s graphics capabilities are rather limited, so anything close to true photorealism should not be expected.
- The guidance and navigation systems of the two spacecraft are fully simulated, including a full emulation of the Apollo Guidance Computer (AGC) and Abort Guidance System (AGS), as well as a partial emulation of the Instrument Unit (IU) on the Saturn launch vehicle. We have a nearly complete set of AGC software versions that were flown during the Apollo program, and with only two exceptions, nearly every mission flies the actual AGC code it was running in reality. Whenever a perfect match for a piece of flown computer software is unavailable, such as for the AGS where only two software versions have been archived, missions have been adapted to use whichever software version is closest to what they would have used in reality.
- Furthermore, the techniques, logic equations, and mathematical computations used by mission controllers in Houston and their Real-Time Computer Complex (RTCC) have been reimplemented for use by either manual user control, or by an automatic mission control simulation (currently available for the Apollo 7 through Apollo 12 historical missions). In the manual case, the user can perform a wide variety of calculations to verify or correct trajectories, adjust their orbit, plan mission-related maneuvers such as lunar orbit insertion, landing, and rendezvous, as well as monitor various mission and spacecraft parameters via simulated telemetry. In the automated case, the MCC automatically provides data via computer uplink and text-based Pre-Advisory Data (PAD) for all important mission milestones including engine burns, rendezvous, guidance and navigation updates, and more.
- Due to the above two points, generally speaking any tasks of guidance and navigation can be performed using the same procedures as reality and achieve typically very similar results for trajectory corrections, rendezvous, and other calculations.
We personally consider NASSP to be the single most accurate simulation of the Apollo program that currently exists. It’s not perfect, but we strive to make it better every time we work on it. If you’re interested, we have our own sub-forum on the Orbiter Forums, and we have a channel dedicated to discussing development and other stuff in the “Spaceflight Server” Discord.