The Mars Society analog studies is providing crews with a habitat, vehicles, spacesuits, laboratory equipment, other tools, and a context in which to conduct scientific field research under constraints in part similar to those that would be faced on Mars, in order to study various mission strategies and tooling. One important aspect of a mission that must be studied is that of information management. A Mars mission, which will likely be of long duration, will require a large amount of information to be managed by the crew and mission support. The Data Logger prototype used during this expedition deals with information management while in the field on EVA, whereas MarsComm, the project described here, is meant to potentially provide insight into information management for everything else. The software was developed as a volunteer effort by Jim Oliver and Jean Lagarde.

Besides communication to and from Mars being itself an analog activity that would take place on a real mission, information management tools are also used as the vehicle to accumulate meta-data *about* the analog operations, i.e. data that will help to analyze the analog operations and allow to reach quantifiable conclusions about the effectiveness of tools and procedures used during these operations.

The analog studies conducted so far at the Mars Desert Research Station (MDRS) and Flashline Mars Arctic Research Station (FMARS) have mostly used email as a means of communication on a regular basis. More high tech equipment or more complex software has been used sporadically by specific crews which could not leave these components behind. Web-based Distributed Authoring and Versioning (WebDAV), similar in some respects to the older File Transfer Protocol (FTP), has also been used recently as a means of document exchange with mission support. Although email and WebDAV are better than nothing (and some aspects of communication on a Mars mission will probably be similar to email), they are very unstructured and therefore not conductive to easy retrieval and analysis of data. On the input side, they also do not ensure that crews or mission support will enter all the required data, a situation which might only be detected too late, once an attempt is made to analyze the data many months later.

The approach of MarsComm is to provide both a means of communication and an archival system in the form of a shared database. The database is shared in that both mission support on Earth and the Crew on Mars have their own copy of the database, but a synchronization system works in the background to exchange data between both databases. From the point of view of users, all they access is the local database. The tool internally simulates the Earth-Mars communication delay.

The prototype has too many features to enumerate here, but here some of the goals that we want to meet:

• Data should need to be entered only once. By having the “internal” mission database of the Mars crew shared with mission support, there is no need to duplicate data for the purpose of transmittal.
  
  
• At least part of the data produced by the crew (e.g. waypoints) should be continually transmitted to Earth with low latency, without requiring a lot of effort from the Mars crew.
  
  
• The tool should permit to experiment with various levels of data organization, from highly unstructured (similar to email), to very structured (like a database).
  
  
• The system should be expandable, without programming, to allow for the storage of new kinds of information as they are needed. The creation of new data tables should be simple enough to allow mission support to build them with a reasonable amount of planning.
  
  
• The tool should use an intuitive interface that allows anyone to use it with only minimal training.
  
  
• The tool should require no more, and possibly less effort than email.
  
  
• The tool should allow a distributed (i.e. not co-located) and part-time mission support crew.
  
  
• The system should allow for site-specific updating to occur, whereby various remote locations would only receive the data that they require.
  
  
• The system should simulate Mars-Earth communication delays (this may be a minor requirement depending on the type of information being transmitted).
  
  
• The transmission layer should be robust; it should allow the transmittal of large files without requiring the crew to detect failures and re-initiate transmission themselves, i.e. the system should automatically handle unreliable data channels such as the DirecWay satellite Internet connection (this only at the application level; improvements to the TCP/IP transport layer, such as those provided by the Interplanetary Internet project, have not been considered in this project so far).
  
  
• Historical data should be searchable as much as the data's internal structure permits, in order to facilitate post-mission analysis (at the meta level), but also as a research tool within the context of the mission.

The current version of the prototype is implemented with the Zope application server and the Python programming language. Most of the data is stored in XML format, with binary files, like images, stored separately. Users interact with the tool through a web browser, which makes deployment very easy once the server is set up. For example, in principle, instruments readings from the GreenHab could be entered in MarsComm in real time in a web browser running on a Personal Digital Assistant over a wireless connection to the hab server, thus meeting the first goal above. There was hope to establish a wireless network during the expedition to try something like that, but this did not happen during my stay.

Although there had been some attempts to put the MarsComm prototype through its paces prior to an actual MDRS or FMARS mission, this did not happen and thus the tool got a baptism by fire during this expedition. It ended up being used very little, largely because I am hopeless as a marketer, even within the somewhat captive crew at the hab. As one example of MarsComm use during the expedition, all of the EVAs for the expedition had been planned beforehand, and this data had been entered in MarsComm. During the actual expedition, corrections could be entered to the plans and updated EVA checklists produced from the database. These changes to the EVA plans were automatically transmitted to the Mission Support copy of the MarsComm database (that is the main idea of MarsComm) and in principle Mission Support could have reviewed the change of plans, but as is the case for this expedition as well as most other rotations, actual involvement of mission support in these matters did not occur.

Other data that was managed, on an experimental basis, through MarsComm was the generator and gas tank readings, crew biographies, Geographical Information System data, problem tracking data, and two tables designed while at the hab by the commander, a generic messaging system he called "Interactions" and a mission support questionnaire. From these last two I was able to judge to some degree how intuitive the tools is for the design of new tables (it needs work). The table which in my opinion worked the best was the crew biography one, because a few crew members actually used it to update their biography and seemed genuinely interested in the approach.

All in all, the system got less use than I had hoped, but I did get many improvement ideas from the experience. Among other things, some aspects of the tool are clearly not intuitive enough, and some critical usability features need to be added, such as a better notification system. At this point I do not generally consider the tool to be ready for trial by other crews, although I would be happy to support crews which are self motivated to try it out.