“Virtual” Icarus: a Spacecraft in Cyberspace

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:

<— vIcarus Test | Decision Tree Exemplar Scenario —>

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.

<— End vIcarus Exemplar Scenario —>

The image shows a mock-up of what the vIcarus web interface may look like, using a Daedalus model as a placeholder for the spacecraft graphic. A central animation depicts the current state of the spacecraft, showing appropriate background and damaged systems. Control panels to the right allow the user to focus on specific subsystems. A virtual mission control room is depicted beside a running graphic of Icarus within a star field. Clicking on various terminals within the mission control room brings up subsystem performance graphs, maps, fuel burn ratios, current speed, etc. In the mean time, a dashboard displays general mission information, such as current speed, location, mission time, current status, etc. The message bar at the bottom of the frame shows the current command and control sequence vIcarus is addressing.

Of course, in the duration of the simulation, we would have real images of planets around the target star. vIcarus could then be updated with real graphics and information on the actual condition at our target star – its primary programming could then be put under a real test to see how it performs.

Even with the advent of new computer systems, vIcarus could hold up as something of an ancient spacecraft, something like the Voyager or Pioneer missions. I for one would certainly want to know what Voyager-2 is actually doing at this particular moment in realtime. Mission summaries are ok, but a realtime display would be even better.

The vIcarus model could also be of great educational value. A full spacecraft simulator would make a great educational tool, toy and research platform. Class projects can be designed where students learn about mission administration, engineering and aspects of spacecraft design. An idealized version of the vIcarus simulator could be instanced to subscribers, where they can construct and launch their own spacecraft, anywhere they want. Spacecraft designs may even be shared amongst the community through something like Facebook, only we would have a “SpaceBook” or “SimsGalaxy”.

JPL/NASA has a spacecraft design educational tool designed for children under 13.

vIcarus has the added merit of keeping the Icarus Project alive and active over many many years. After the scientific study of the Icarus is completed, Team Icarus will either direct some development time to this project, or make the endeavor Open Source, and in doing so giving it a life of its own.

This has never been done before, which sounds just like Team Icarus.

Tags: vIcarus, virtual icarus