In the following I would like to briefly outline how Icarus could be launched computationally, on the Icarus Interstellar website.
The Icarus mission design will undoubtedly yield a series of computational models, which will be used to simulate the spacecraft’s behavior and reliability. System models for propulsion, trajectory, fault repair protocols, flight through interstellar medium, communications and science objectives all contribute to the final assessment of the mission’s success. Design validation is a crucial step in our feasibility study, the end product of which will be a wide range of computational models for each subsystem.
Combining each of these computational models into one master program will essentially BE the Icarus spacecraft. Once completed, Team Icarus plans to virtually launch Icarus, in real time, through cyberspace to its target star. This virtual Icarus “vIcarus”, will be made up of a real time simulation of the Icarus mission plan. A graphical interface will allow visitors to IcarusInterstellar.org to watch, as the spacecraft is built in orbit, performs system verification tests and makes its way through our solar system and on to the target star of choice.
Launching the spacecraft in real time will allow scientists and inquisitive visitors to witness and observe every detail of the mission’s progress. A detailed graphical interface will list engine status, sensor information and navigation orders exactly as the actual Icarus spacecraft may one day perform them. System logs will monitor the error and fault repair mechanisms as they maintain the spacecraft – a crucial part of Team Icarus’ design verification.
The idea for vIcarus came while thinking of the power and computer subsystems, where we imagined the spacecraft making programmed decisions such as fine-tuning the fusion reaction rate and course corrections all while interacting with the interstellar medium. Visualizing this process in real time would be extremely rewarding. Scientifically we could run full system simulations, without the need for statistical analyses and averaging schemes. As an educational tool, we could demonstrate spacecraft operation to students of spacecraft design and visually search for ways of improving on our design.
It would indeed be rewarding in itself if, after five years of dedication, our models could be put to the test, having them run in real time for the entire forty year duration of the mission. The following scenario is, an example of the type of situations a user would be able to witness, while exploring vIcarus:
The spacecraft is struck by a micrometeorite. CPU09 detects the fault and performs an assessment using its sensor grid. The fault is moderately severe, as the meteorite has fragmented and damaged a science subsystem as well as compromised the backup internal sensor shunt in charge of thermal control.
The thermal control module is tied into RTG06, so the computational fault repair cluster, instructs the robotic ARM05 to traverse the along-axis repair rail and perform a placebo data injection into the science subsystem. The robotic arm uses an on-board isolated data bank, which is specifically designed for testing hardware and software responses after fault detection – a dedicated internal diagnostic.
The science subsystem has lost two of its sixteen BIOS memory modules. CPU-Alpha, one of the central computational decision cluster, is designated to supervise repairs. It is informed of the fault and the science execution program begins rewriting data acquisition and analysis protocols. The thermal control module on the other hand is completely unresponsive.
The robotic arm immediately interfaces with the shunt and starts dissipating excess heat to space while repairs are underway. ARM02 is requested to complete ARM05’s sensor diagnostic, while CPU-Alpha instructs RTG05 sensor grid control module to initiate its sensor-broadening program to include RTG06, while repairs are affected. CPU-Alpha reports the vIcarus is again under full sensor surveillance. ARM02 evaluates the damaged sensor and issues a replacement order to CPU09.
Repair evaluations are queued for simulation and mission impact. ARM05 disengages its thermal control and performs a controlled sensor boot process. The sensor reports OK. ARM05, ARM02 return to their docks.
The computer estimates the changes in spacecraft attitude incurred by the motion of ARM02 and ARM05 as well as the micrometeorite impact and confirms its results with the inertial sensors. The star-tracker is fired up and an image is taken and compared against databanks. Spacecraft trajectory is adjusted by frictioning-off some angular momentum on the flywheels used to store excess energy from the RTGs.
The computer estimates the course correction of 0.000041 arc seconds will add 4.81 minutes to the Icarus flight time.
The information is stored in the monthly mission update file to be transmitted back to Earth.