MARS OR BUST, LLC

TABLE OF CONTENTS

1.0 MISSION SUMMARY....................................................................................................................2

2.0 SYSTEMS ENGINEERING AND INTEGRATION....................................................................2

3.0 MARS ENVIRONMENT AND IN-SITU RESOURCE UTILIZATION...................................2

4.0 STRUCTURES SUBSYSTEM........................................................................................................2

5.0 ELECTRICAL POWER DISTRIBUTION AND ALLOCATION SUBSYSTEM...................2

6.0 ENVIRONMENTAL CONTROL AND LIFE SUPPORT SUBSYSTEM.................................2

7.0 THERMAL CONTROL SUBSYSTEM.........................................................................................2

8.0 MISSION OPERATIONS AND CREW HABITATION.............................................................2

9.0 COMMAND, CONTROL, AND COMMUNICATION SUBSYSTEM.....................................2

9.1 OVERVIEW.....................................................................................................................................29.2 DESIGN AND ASSUMPTIONS...........................................................................................................39.3 VERIFICATION OF REQUIREMENTS...............................................................................................18

10.0 AUTOMATION AND ROBOTIC INTERFACES SUBSYSTEM............................................18

11.0 EXTRAVEHICULAR ACTIVITY INTERFACES SUBSYSTEM..........................................18

12.0 MANAGEMENT PLAN................................................................................................................18

13.0 APPENDICES................................................................................................................................18

13.1 APPENDIX A: ACRONYMS............................................................................................................1813.2 APPENDIX B: REFERENCES..........................................................................................................1813.3 Appendix C: Acknowledgements................................................................................................20

Table of FiguresFigure 11.1: EVA Illustration............................................Error! Bookmark not defined.

Table of TablesTable 6.1: ECLSS Atmospheric Technologies..................Error! Bookmark not defined.

Page 1 of 20

MARS OR BUST, LLC

1.0 Mission Summary

2.0 Systems Engineering and Integration

3.0 Mars Environment and In-Situ Resource Utilization

4.0 Structures Subsystem

5.0 Electrical Power Distribution and Allocation Subsystem

6.0 Environmental Control and Life Support Subsystem

7.0 Thermal Control Subsystem

8.0 Mission Operations and Crew Habitation

9.0 Command, Control, and Communication Subsystem

9.1 OverviewThe Command, Control and Communication (C3) subsystem supports and manages the habitat’s data flows. The C3 subsystem provides the data processing and communications equipment required to:

monitor and control the habitat’s environment and subsystems monitor and maintain crew health and safety communicate with Earth, rovers and EVA crewmembers support data processing related to the mission objectives

The C3 subsystem design is based on the level 2 mission requirements we derived from the DRM, high level qualitative data flows defined with the help of the other subsystems and existing C3 architectures operating on the International Space Station (ISS), the Space Shuttle and Mars probes. MOB tried to define detailed quantitative data flows, but our efforts were hampered by differences in the design fidelity levels reached by the subsystems. The C3 subsystem design considers quantitative data flows when possible, but our team did not feel that the limited quantitative information captured the volume of the data flows necessary to support the habitat.

Page 2 of 20

MARS OR BUST, LLC

The uncertainty in the quantitative data flows is reflected in our design. We were able to define a basic functional architecture for the C3 subsystem. We estimated the size of our subsystem and selected some specific technological components in order to provide baseline numbers for mass, volume and power for design integration. We believe our C3 subsystem is oversized, but we do not have enough quantitative information to determine an appropriate sizing adjustment. It is our hope that the modular nature of the architecture allows for easy C3 sizing adjustments as quantitative data flow information becomes available during subsequent design iterations. Additionally, the architecture’s modularity should facilitate the substitution of newer technologies into our design as the technologies mature to meet the reliability requirements necessary for a Mars habitat.

9.2 Design and AssumptionsThis section describes the C3 subsystem design in detail. Section 9.2.1 presents the requirements and data flows that are the basis for our design. We divided the C3 subsystem into two smaller subsections. The first subsection encompasses the command and control functionality within the habitat and is covered in Section 9.2.2. External communications makes up the second subsection and is described in Section 9.2.3. We conclude this section with a summary of the aggregate C3 design in Section 9.2.4.

9.2.1 Basis of DesignIn this section, we present the level 2 requirements, high-level data flows and quantitative data flows that, along with existing C3 architectures, provided the basis of our design. Any changes in these requirements or data flows may significantly impact the proposed C3 subsystem design.

Table 9.1 contains the level 2 requirements derived for the C3 subsystem based on the mission profile described in the DRM. The C3 subsystem design’s response to these requirements will be detailed in Section 9.3.

Figure 9.1 is a graphical representation of the C3 subsystem inputs and outputs. The only non-data flows for the C3 subsystem are electrical power entering C3 from the power subsystem and heat exchanged between C3 and the thermal subsystem. There are 6 different data flow types.

Two data flow types monitor and control the habitat. Telemetry data flows from the other subsystems into the C3 subsystem. Telemetry data contains status information from the habitat’s sensors. Telemetry message frequency varies from seconds to days depending on the sensor being monitored. Command data flows from the C3 subsystem to control mechanisms in the other subsystems. Command message frequency also varies. Both command and telemetry messages are expected to be small. We estimated about 25 bytes per telemetry message to contain the measurement date and time, the sensor identification and the sensor reading. Command messages are expected to be roughly the same size as the telemetry messages. The functions performed by these data flows are life critical and require a high degree of accuracy and reliability. Throughput should not be a problem for the telemetry and command flows.

Page 3 of 20

MARS OR BUST, LLC

Table 9.1: C3 Level 2 Requirements

Figure 9.1: C3 Subsystem Input Output Diagram

Heather will Insert figure after edits are complete

Video, audio and TCP/IP data flows are directed toward the habitat’s crew. (Data flows directed toward the crew are handled through crew accommodations, EVAS and robotics in Figure 9.1.) Video and audio communications are familiar to most people and will not be defined here. TCP/IP includes files and e-mails that do not contain audio or visual information. Message size and data rates (kbps to 10s of mbps) for these flows tend to be very large so throughput rates are the main concern for handling this data.9.15 These messages are not generally life critical so accuracy and reliability requirements for these data flows are not as demanding as for the command and control messages.

Packetized data is the final data flow. Any data transmitted to or received from outside the immediate vicinity of the habitat is included in this category regardless of its original data type. This category includes all information exchanged with Earth, long range rovers and crewmembers on long duration EVA missions. Accuracy, throughput, prioritization and link availability are the primary concerns with this data type.

Table 9.5 summarizes the quantitative data flows documented to date. While obviously incomplete, the quantitative data flows provide a general idea of the character of the telemetry and command messages. These initial data flows should also provide a starting point for the next iteration of this design.

9.2.2 Command and Control Subsystem

Page 4 of 20

MARS OR BUST, LLC

The command and control subsystem consists of the components required to monitor the habitat’s sensors, control the habitat’s subsystems and interface with the habitat’s crew. External communications are not included in the command and control subsystem and will be covered separately in Section 9.2.3.

Figure 9.2 is a functional diagram of the command and control architecture. The command and control subsystem has a three tiered architecture that is strongly based on the ISS C3 subsystem as documented in references 9.1, 9.2 and 9.3. The three tiered architecture was chosen over other architectural options for three reasons. First, the three tiered architecture is one of the only modern computing architectures that has the proven ability to support crewed missions away from Earth. The ISS architecture has been operationally tested for several years and provides a well documented and understood starting point for our Mars habitat. The three tiered architecture is also similar to architectures utilized on Earth today and can benefit from computing experience outside the aerospace industry. Second, the modularity of the architectural design allows for flexibility in sizing and technology selection without changing the basic character of the command and control subsystem. Flexibility is important because future design iterations will be able to adjust command and control subsystem sizing and plug in new technologies without losing the analysis effort we performed to create the initial subsystem concept. Finally, the tiered design allows for extra capacity and redundant processing capabilities at each level to increase the robustness and reliability of the subsystem. The components of the command and control subsystem will be discussed in detail below.

Figure 9.2: Command and Control Architecture

Heather will insert figure after edits are complete9.2.2.1 Tier 1 Command ComputersThe tier 1 command computers oversee the habitat’s major functional modes, interface with the communications components and coordinate the interface between the habitat’s control system and the crew.

The habitat will have at least four major functional modes: Transit mode Nominal crewed mode Nominal interim/uncrewed mode Emergency mode

The tier 1 command computers coordinate subsystem interactions to produce the desired habitat environment in each of these functional modes. Specific subsystem interactions in each mode are TBD.

The tier 1 computers prepare data for entry into the external communications system and prioritize the order of data transmission. Data concerning emergency conditions in the habitat and communication with crewmembers operating outside the habitat are expected to have the highest transmission priority followed in order of priority by regular habitat

Page 5 of 20

MARS OR BUST, LLC

status updates, personal and programmatic transmissions and scientific data transmissions. Transmission priority settings should be adjustable by the crew.

Finally, the tier 1 computers will provide the interface between the habitat’s subsystems and the crew. During normal operations, crewmembers will be able to link to the tier 1 computers through their workstations to view habitat status data. All commands from the crew or Earth will be disseminated to the rest of the command and control subsystem through the tier 1 computers. The tier 1 command computers also coordinate most caution and warning (C&W) system related activities.

Our design includes three redundant tier 1 computers, but a single tier 1 computer should be able to handle the tier 1 processing load. All three tier 1 computers perform identical command and control related operations, but only one actually controls the habitat at any one time. Each tier 1 computer monitors the performance of the other two tier 1 computers. Any tier 1 computer that exhibits signs of a problem is isolated from the system. If the problem concerns the tier 1 computer controlling the habitat, control automatically switches to one of the other two tier 1 computers. The ISS currently utilizes a single tier 1 computer with two synchronized backups for operations.9.4, 9.5 Our habitat’s operations should be less demanding than ISS operations because the habitat will not need to maintain an orbit and the C3 subsystem only manages a single structural module. The external communications load is also expected to be decreased due to limited link availability and operational differences necessitated by the communications delay. In addition, the habitat’s computers will probably be more advanced than the ISS computers, so the habitat’s tier 1 computers should be able to handle a larger processing load than the ISS computers.

9.2.2.2 Tier 2 Science ComputersThe current command and control architecture includes two tier 2 science computers. These terminals manage scientific payloads in the habitat. We estimated two dedicated payload computers because the ISS has two computers for this purpose.9.5 MOB did not address science related mission activities so further analysis will be required to better define the habitat’s scientific computing needs.

9.2.2.3 Tier 2 Subsystem ComputersThe tier 2 subsystem computers coordinate the operations of each subsystem to comply with the habitat operational mode designated by the tier 1 command computer. Ideally, the tier 2 computers will be non-specialized and act in concert to control the subsystems and balance the processing load. If the tier 2 computers must be subsystem specific, software specific to each subsystem must be loaded to at least 2 tier 2 computers so loss of a single tier 2 computer does not impair habitat operations. In addition to being monitored by the tier 1 command computers, tier 2 computers will monitor each other and report any problems to the tier 1 computers to be processed through the C&W subsystem.

We believe four computers should be sufficient to perform these functions. The ISS currently utilizes 10 tier 2 subsystem computers.9.5 Two of the ISS tier 2 computers are

Page 6 of 20

MARS OR BUST, LLC

designated for guidance and control functionality that is not needed for our habitat. Our estimate of 4 computers is based on the belief that our habitat’s operations will be simpler than ISS operations and the expected increase in processing speed detailed in Section 9.2.2.1.

9.2.2.4 Tier 3 Subsystem ComputersThe tier 3 subsystem computers directly interface with the sensors and controllers in each of the subsystems. The tier 3 computers collect telemetry data, perform some basic processing based on the telemetry data and transmit the data to the tier 2 computers for further analysis. Tier 3 computers also translate commands received from the tier 2 computers into the format required by the subsystem controllers.

It is impossible to design this tier of the command and control subsystem in detail without specific sensor information. Some general considerations for future design iterations are discussed in the remainder of this paragraph. Ideally, tier 3 computer software will be generic and sensors will be standardized to allow for cooperative computing similar to that described for tier 2 in Section 9.2.2.3. Realistically, tier 3 computers will probably require a fair amount of software specific to the sensors and controls governed by each computer. Each type of sensor or control specific software should be loaded to at least two different tier 3 computers. If possible within the habitat’s mass budget, each sensor and control should be connected to at least 2 tier 3 computers so habitat function is not impacted by a single tier 3 computer failure. At minimum, sensors providing duplicate data and any duplicate control mechanisms should be connected to different tier 3 computers.

We are budgeting for 8 tier 3 subsystem computers, but the lack of information concerning specific subsystem needs makes this estimate extremely uncertain. Eight tier 2 computers maintains a 2:1 ratio between tier 2 and tier 3 computers. The ISS ratio of tier 2 to tier 3 computers is about 3:1.9.5 We adjusted the ratio because we expect the habitat to use fewer sensors and controls and more advanced computers than the ISS. Please see Section 9.2.2.1 for further explanation concerning control subsystem sizing.

9.2.2.5 Tier 1 Emergency ComputerThe tier 1 emergency computer takes control of the habitat if there is a problem with all three tier 1 command computers. The tier 1 emergency computer maintains minimal habitat functions required to sustain life and ensure the health of the habitat until the tier 1 command computers can be repaired. The tier 1 emergency computer’s software and hardware should be completely different from the software controlling the tier 1 command computers so a single problem cannot disable all 4 tier 1 computers.

9.2.2.6 Personal WorkstationsCrewmembers use personal workstations (user terminals in Figure 9.2) to perform their day to day duties. Personal workstations include software that allows the crew to interface with the tier 1 computers to monitor and control the habitat. Habitat interface software must comply with the standards outlined in the Man-Systems Integration Standards NASA-STD-3000 (MSIS) document.9.6 Personal workstations also contain any

Page 7 of 20

MARS OR BUST, LLC

other software crewmembers need to perform their duties including but not limited to word processing software, e-mail software and spreadsheet software. Six personal workstations, one for each crewmember, will be available during crewed operations.

9.2.2.7 File Server The file server houses the computer-based library and provides a central repository for storage of shared and personal files. The computer based library must be updateable. Crewmembers have access to shared and personal files on the file server through a network connection via their personal workstations. Files on the file server should be backed up on a weekly basis.

9.2.2.8 Caution and Warning PanelsCaution and warning panels are mounted throughout the habitat to provide habitat status information to the crew at all times and alert the crew in case of an emergency. In addition to the lighted status display, the habitat’s C&W panels will generate auditory alarms.

The C&W panels are the primary component of the C&W subsystem. The C&W subsystem must comply with the standards detailed in Section 9.4.4 of the MSIS document.9.6 The MSIS document prescribes three alarm classifications and defines the alarm requirements for each type of alarm. Currently, we do not have enough information to define habitat specific caution and warning conditions. Based on the reporting requirements in the MSIS, we believe that the C&W subsystem will need to be integrated with the habitat interface software so these two components should be considered together during future design activity.

9.2.2.9 Military Standard 1553B Data BusWe selected a Military Standard 1553B data bus to handle communication between the habitat’s tier 1, 2 and 3 computers.9.10 The 1553B data bus also provides a backup link to the communications subsystem. MIL-STD-1553B defines a dually redundant data bus architecture and communication protocol.9.7 The 1553B communication protocol includes very strict data validation procedures to help ensure data integrity.9.7 Although developed about 20 years ago, MIL-STD-1553B is still the most reliable and deterministic network architecture available today.9.7 Speed is the primary trade off with MIL-STD-1553B architecture.

We selected the MIL-STD-1553B bus to support our life critical operations due to its robustness, reliability and track record of success in similar applications. The low bit rate (~1 mbps) should not be a problem for communication between our tier 1, 2 and 3 computers because the messages are small and can be scheduled to remain within the throughput constraints of the bus.9.7 (The 1553B data bus can handle approximately 5,000 25 byte messages per second.) A faster network technology may be required for the connection between the tier 2 science computers and the tier 1 command computers. Alternative technologies should be considered as replacements for the 1553B bus as they mature to have similar reliability and robustness characteristics.

Page 8 of 20

MARS OR BUST, LLC

9.2.2.10 Ethernet Ethernet connects the non-life critical components of our subsystem and provides the primary link to the communications subsystem. Ethernet was selected for several reasons. First, Ethernet supports data rates ranging from 10 mbps up to gigabits/second depending on the specific technology selected.9.7 These high data rates will allow video, audio and TCP/IP file transfer. Second, Ethernet technology is the most widely used network technology in the world today.9.7 The technology is well understood, compatible with most hardware platforms and there is a vast knowledge base of expertise. Finally, Ethernet technology currently supports similar activities on the ISS. As they mature, alternative technologies may be substituted for Ethernet as long as they can accommodate the high data rate requirements.

9.2.2.11 Radio Frequency LinkPersonal workstations will be able to tap into the habitat’s Ethernet via a radio frequency (RF) link. The RF link’s 1.6 mbps data rate is slower than the direct Ethernet connection but the rate should be sufficient to support most applications.9.3 The RF link to allow crewmembers to work throughout the habitat without requiring an excessive number of hardwired Ethernet jacks. (A few Ethernet jacks will be provided for high data rate processing.) Three RF hubs provide the wireless RF link. A similar RF network is operating on the ISS.9.2 Implementation of the RF link requires a small amount of power and a few additional hardware components (see Section 9.2.2.12). We believe the benefits of the RF link in cable mass savings, increased workplace efficiency and improved morale due to increased opportunities for privacy outweigh the modest tradeoffs required to provide the RF link.

9.2.2.12 Command and Control Mass, Power and Volume EstimatesError: Reference source not found and Table 9.3 contain the estimated mass, power and volume for the command and control subsystem. The estimates in these spreadsheets are based on the following assumptions:

Mission duration – A 3.1 year mission duration was assumed for spare part calculations based on 224 days in transit followed immediately by a 600 day surface mission and a 10 month standby between crews.9.12 This mission duration covers the time frame of the first Mars mission. The two subsequent missions will need to bring additional spare parts.

Computers – Mass, volume and power estimates for all habitat computers are based on IBM 760XD ThinkPad laptops. The IBM 760XD is flight rated for non-life critical operations and is used on the shuttle and ISS for payload and general support.9.11 We elected to use laptop specifications for two reasons. First, the IBM 760XD laptops are more modern than other flight rated computers. We felt that the specifications for these computers more accurately reflect the hardware that will eventually be selected for the Mars habitat. Second, the command and control computers in use on the ISS are approximately 15 kg each and are not an option given our limited mass budget.9.5 A 3 year lifetime was used to determine how many spare computers were required. The 3 year lifetime is based on IBM’s standard 3 year warranty on laptops and is probably lower than the actual lifetime.

Page 9 of 20

MARS OR BUST, LLC

RF Hubs – Mass, volume, power and lifetime estimates for the RF hubs are based on Linksys wireless access points.9.8 Detailed product specs for the Proxim RangeLAN2 access points operating on the ISS are no longer available but the Linksys product appears to be comparable.9.3 The 1 year RF hub lifetime is based on the 1 year Linksys warranty.9.8

C&W Panels – We could not locate detailed technical specs for the C&W panels used on the ISS. C&W mass, power and volume are estimated based on the picture in NASA-SP-2000-6109.9.2 The C&W panels are assumed to have a lifetime of about 3 years.

Replacement Batteries – Replacement battery mass, volume and lifetime estimates are based on IBM ThinkPad X30 extended life batteries. 9.13 Table 9.3 only includes replacement batteries for personal workstations. Initial battery mass and volume are included in the computer mass. Personal workstations are the only computers that will operate primarily on battery power. Battery lifetime is estimated at 1 year based on the warranty.

Ethernet and Coaxial Cable – Ethernet and coaxial cable unit mass and volume are based on average quality Ethernet cable specs.9.14 The 1,300 m of Ethernet cable includes 42 Ethernet links stretching approximately 31 m each. This allows for two Ethernet links stretching the entire length, width and height of the habitat between each tier 1 computer and the file server, RF hubs and communications subsystem. The 2,300 m of 1553B cable includes 75 similarly sized links connecting the tier 1, 2 and 3 computers and the communications subsystem. While the cable estimates above are probably oversized for the connections considered, no sensor links are included in the estimates. Spare cable is estimated at 1% of the total operational cable.

Minor Components – Ten percent is added to the mass and volume estimates for small subsystem components. Extra memory and video, audio and network cards are examples of small components.

Safety Factor – The safety factor mass, power and volume in Table 9.2 and Table 9.3 were obtained by multiplying the total mass, power and volume of the components listed above the safety factor by 0.2.

Page 10 of 20

MARS OR BUST, LLC

Table 9.2: Command and Control Power

Table 9.3: Command and Control Mass and Volume

9.2.2.13 Command and Control Failure Modes Effects Analysis (FMEA)Table 9.4 contains a high level failure modes effects analysis for the command and control subsystem.

Page 11 of 20

MARS OR BUST, LLC

Table 9.4: Command and Control Failure Modes Effects Analysis

9.2.3 Communications Subsystem

Page 12 of 20

MARS OR BUST, LLC

9.2.3.1 Communications Subsystem OverviewThe communications portion of the C3 subsystem is responsible for providing communications with Earth and any other mission activities on the surface of Mars. The DRM requires that C3 provide real-time communication capability with Earth. The term "real-time" can only be used loosely in this context because the round-trip transmission delay from Mars to Earth can be as much as 12 minutes. Normal conversation would be impossible with this kind of delay. Most likely, text messages or voice recordings would be sent and the time needed to prepare those messages would probably add to the delay. That would result in about 20 minutes between transmitting a message and receiving any kind of prepared reply. This would mean that we need a major shift in communication methodologies. The Mars surface activities would have to be much more independent from Earth control than the Apollo lunar surface activities. Any sudden emergencies would have to be handled completely by the Mars crew for the first twenty minutes or so. For our purposes, "real-time" was interpreted to mean that the only significant delay in sending or receiving information would be the propagation delay. That doesn't turn out to be very difficult on the Mars end of the communications link. That problem can be solved using an areostationary communications satellite in a Mars-synchronous orbit over the habitat similar to geostationary orbits at Earth. JPL's Marsnet concept includes just such an areostationary satellite. Except during eclipse periods (the areostationary satellite goes behind Mars and can't see Earth) which should be relatively rare, the communications link with Earth could be continuous. A bigger problem would be to have receivers available on Earth continuously. The Deep Space Network (DSN) currently has a large queue of interplanetary spacecraft customers that require DSN antennas to communicate with Earth. Time on DSN is valuable and hard to come by. A manned Mars mission would place considerable extra demands on DSN to the point that it would probably require almost double of the ground station assets already existing. Communication between the habitat and any long-range rovers that are not within line-of-sight (LOS) could also be relayed by the areostationary satellites. The scope of our current design does not include any relay satellites, but we assume that there will be at least one. Otherwise, real-time communications with Earth would not be possible during the portion of a Sol when the habitat is on the opposite side of Mars and not within Earth's LOS. Also, communication with remote rovers would require a network of relay stations deployed on the surface. Communicating with astronauts conducting EVA from remote rovers would have to be relayed through the nearest rover. A further consideration that merits attention is the security involved with the telecommunications. Encryption or other suitable methods should be used to ensure that no unauthorized commands or data can be relayed. Because this mission would be a high-profile American activity, a slight possibility exists for intentional interference or disruption.

9.2.3.2 Communications Subsystem Component DetailsSelecting a communications subsystem concept required looking at the various communications options available. At the time of this study, radio communications have been the only method used to communicate with probes at Mars. Laser communication methods have not reached sufficient maturity to be considered. No specific hardware was selected for the communications design, but several generic selections were made.

Page 13 of 20

MARS OR BUST, LLC

The X band was chosen for efficiency and high data rates. The high-gain antennas were designed to be 1 m diameter parabolic dishes. To avoid bit errors during transmission, a convolutional encoding scheme was selected. It is a rate 1/2 encoding scheme, meaning that the number of bits transmitted is doubled, but it reduces the bit error rate significantly over a wide range of signal-to-noise ratios. Amplifiers were assumed to have efficiencies similar to the TWTA relation shown in Brown.9.9 Other losses were estimated using link budget examples in Brown. For local EVA communications, UHF links similar to those used by the Space Shuttle or ISS could be used.

9.2.3.3 Communications Subsystem Hardware DetailsTo determine the amount and rate of data to be transferred to Earth, the other subsystems submitted lists of sensor readings and other forms of data for transmission. Provisions have been made to return 50 MB per day of video, 50 kB per person per day for personal communication, 1 MB per person per day for voice and 50 kB of data per person per hour of data to mission control. Also, the design includes the capability to send 50 MB per day of photographs. The rest of the information is composed of telemetry from the various subsystems. Table 9.5 and Y tabulate this information.

Table 9.5: Data for Transmission to Earth

System Transmission TypeRate (Hz) # sensors Rd(kbps)

message size

ECLSS     0        ppO2 Data 0.001667 36 0.012 25  Ptotal Data 0.001667 36 0.012 25  pCO2 Data 0.001667 36 0.012 25  relative humidity Data 0.001667 6 0.002 25  cabin temp Data 0.001667 6 0.002 25  water flow rates Data 0.001667 30 0.01 25  tank volumes Data 0.001667 10 0.003333 25  trace contaminants Data 0.001667 36 0.012 25  fire detection Data 0.000278 6 0.000333 25  radiation Data 0.001667 6 0.002 25  pH Data 0.000278 3 0.000167 25  Ammonia content Data 0.000278 3 0.000167 25  total organic carbon Data 0.000278 3 0.000167 25

 electrical conductivity Data 0.000278 3 0.000167 25

 microbial concentration Data 0.000278 3 0.000167 25

  color Data 0.000278 3 0.000167 25  odor Data 0.000278 3 0.000167 25  turbidity Data 0.000278 3 0.000167 25  foaming Data 0.000278 3 0.000167 25  heavy metals Data 0.000278 3 0.000167 25      0   0 0Power Current Data 0.001667 100 0.033333 25  Voltage Data 0.001667 100 0.033333 25      0   0 0

Page 14 of 20

MARS OR BUST, LLC

Thermal Flow Rate Data 0.001667 10 0.003333 25  Hot Loop Temp Data 0.001667 10 0.003333 25  Cold Loop Temp Data 0.001667 10 0.003333 25  Radiator Temp Data 0.001667 10 0.003333 25  Rad Out Temp Data 0.001667 10 0.003333 25  Sub Sys. Hot Temp Data 0.001667 10 0.003333 25  Sub Sys. Cold Temp Data 0.001667 10 0.003333 25  Pump Temp. Data 0.001667 10 0.003333 25  Pump Power Data 0.001667 10 0.003333 25  Pump Capacity Data 0.001667 10 0.003333 25  Rad In Temp Data 0.001667 10 0.003333 25      0   0 0EVA/Robotics     0   0 0      0   0 0Structures Load Data 0.000139 20 0.000556 25  Deployed Load Data 0.000139 20 0.000556 25  Levels Data 0.000139 20 0.000556 25      0   0 0ISRU Temperature Data 0.000278 12 0.000667 25  Pressure Data 0.000278 12 0.000667 25  Valve Control Data 0.000278 12 0.000667 25  Valve Control Data 0.000278 12 0.000667 25  Valve Control Data 0.000278 12 0.000667 25  Flow Rate Data 0.000278 12 0.000667 25  Flow Rate Data 0.000278 12 0.000667 25  Flow Rate Data 0.000278 12 0.000667 25      0   0 0Mission Ops Crew video Video 1.16E-05 1 4.62963 5.00E+07  personal comm Data 1.16E-05 6 0.027778 50000  Crew Comm Voice 2.31E-05 6 1.111111 1.00E+06  crew comm Data 0.000278 6 0.666667 50000  science photos 1.16E-05 50 4.62963 1.00E+06      0   0 0        Total 11.24448          Availability 0.25  

       Transmission

rate 44.97793 kbps

Link budgets were computed for several cases:1. Nominal case when the habitat transmits information for Earth to the Mars Sat.2. Emergency case when the habitat communicates directly with Earth.3. Emergency case when the habitat transmits to the Mars Sat with the medium gain.

A sample link budget showing the direct-to-Earth link is in Table 9.6.

Table 9.6: Earth-Mars Link Budget DIRECT TO EARTH LINK BUDGET Carrier Link Performance    Frequency 8.4259 GHz modulation index 78 degBER 0.00001 Pc / Pt -13.6424 dB

Page 15 of 20

MARS OR BUST, LLC

Range 4.01E+08 km received carrier power -173.972 dBsymbol rate 50 kbps carrier noise bandwidth 14.77 dB-Hzdata rate 6.25 kB carrier S/N 26.63573 dBbit rate increase 2 DSN carrier S/N 10 dBCoded symbol rate 100 ksps carrier link margin 16.63573 dBTrans power 20 WTran power 13.0103 dB Data Link Performance    cable loss -0.06 dB Pd/Pt -0.19191 dBantenna diameter 1 m Data power received -160.522 dBTrans. ant. gain 36.31233 dB data symbol rate -50 dB-HzEIRP 49.26263 dB Eb/N0 achieved 4.856239 dBfree space loss -283.022 dB Eb/N0 required 4.1 dBatmos. atten. -0.15 dB data link margin 0.756239 dBpolarization loss -0.12 dBDSN receive gain 74 dB RF power 20 Wpointing loss -0.3 dB TWTA power 89.164 Wreceiver cable loss 0 dB Other power 15 Wtotal receive power -160.33 dB Total power 124.164 Wreceiver noise Temp 21 Ksystem noise dens -215.378 dB/Hz

A summary of the links is shown in Table 9.7.

Table 9.7: Mars Habitat Link Summary

  Total powerData rate  

Case 1 20 W 10,000 KbpsCase 2 124 W 50 KbpsCase 3 70 W 500 kbps

The mass and gain of the high-gain parabolic dishes was estimated using equations 9.27 and 9.63 in Brown.9.9 Masses for the transponder, control unit and other components were estimated using equipment from the Magellan mission. RF power was taken from the link budgets and TWTA power and mass from Figure 9.27 in Brown. Cable mass and the UHF system mass were added to arrive at a mass estimate of 146 kg for the entire communication subsystem.

9.2.3.4 Failure Modes Effects Analysis (FMEA) Investigating the failure modes of the communications subsystem provided insight into designing for reliability. One unique challenge is maintaining a reliable communications system during the entire mission. It was decided to have two complete high-gain antenna systems on the habitat so that a failure with one would not restrict data flow for the entire mission. An example where this happened is the Galileo mission to the Jovian system. The high-gain antenna did not deploy properly and significantly reduced the amount of science data returned during the mission. For all life-critical systems, two backups are required as per the DRM. As communications with Earth can be considered vital for preserving the life of the crew, this subsystem needs two backups. For the communications system, the second high-gain antenna provides the first backup and a

Page 16 of 20

MARS OR BUST, LLC

medium-gain antenna provides a low-mass second backup. The medium gain antenna would only be able to provide low data rate transmissions. Consideration must be given to the possibility that the areostationary satellite will fail and the habitat's communication system must be able to communicate directly with Earth in an emergency. Once again, that would mean a lower data rate. Another possible emergency communications link with Earth could be through the high-gain antennas on any rovers near the habitat. Any Earth-return vehicles in Mars orbit might also provide communications capability with Earth on a more sporadic basis during passes overhead. For the amplifiers and signal generating equipment, two backups are required as well. Two fully functional sets of electronics can be connected to the antennas. If one set of equipment fails, the second set can be switched on. That would give the crew time to assess the failure on the first set. A third backup set of line replaceable (LRU) electronics components could then be used to repair the failed set of equipment. This study did not specify real hardware, so the causes of failure of the components can not be assessed. Other failures to communicate could arise from a loss of electrical power, loss of pointing accuracy for the antennas, and various types of interference. Loss of electrical power can not be addressed by this subsystem, but the pointing of the antenna should be manually adjustable in case the automatic pointing system fails. It would be advisable to be able to deploy one of the high-gain antennas away from the habitat so that any unexpected disruption at the habitat could not destroy both antennas, however it would probably be sufficient to install the antennas at separate ends of the habitat for simplicity.

9.2.4 Overall C3 Design SummaryThe C3 subsystem described above was designed based on DRM derived level 2 requirements, qualitative data flows and existing C3 systems. We realize that our design is at a very high level, but we think we have considered most of the important design issues and created a subsystem that provides a reasonable basis for future iterations. Our subsystem has a total mass of about 500 kg and requires approximately 2 kW of power. Section 9.3 will evaluate how well the proposed C3 subsystem meets our level 2 requirements.

Quite a few issues arose during the design process that either could not be answered at this level of design or must be addressed in order to better define the C3 subsystem. Three key issues are defining the quantitative data flows, investigating newer technologies and addressing the Earth based communications architecture.

Quantitative data flows need to be better defined before more accurate subsystem sizing and architecture can be determined. Our understanding of the data flows will naturally improve as the habitat’s design is iterated. We believe that our current subsystem is oversized so it is likely that better data flow information will allow us to decrease C3 subsystem mass, volume, power and complexity.

Technological advances are likely to have a profound impact on the C3 subsystem design. Increases in processing speed, decreases in component mass, power and volume requirements and architectural changes are likely as new technologies mature.

Page 17 of 20

MARS OR BUST, LLC

Microprocessors and wireless technologies may be of particular interest with respect to potential mass savings.

The Earth based communications infrastructure needs to be addressed. The Deep Space Network is our primary means of communicating with spacecraft over long distances, but it is already overtaxed. Reliability and data throughput needs are much greater for a manned mission than an unmanned mission. Humans have never traveled outside the vicinity of Earth so we do not have the communications facilities required to support the unique needs of a human mission. Link availability and the communications delay will need to be considered for operational support and communications architecture design.

9.3 Verification of Requirements

Table 9.8: C3 Requirements Verification

Page 18 of 20

MARS OR BUST, LLC

10.0 Automation and Robotic Interfaces Subsystem

11.0 Extravehicular Activity Interfaces Subsystem

12.0 Management Plan

13.0 Appendices

13.1 Appendix A: AcronymsPlease add any acronyms that you use in your section here.

C&W Caution and warningC3 Command, Control and CommunicationsDRM Design Reference ManualDSN Deep Space NetworkFMEA Failure Modes Effects AnalysisISS International Space StationJPL Jet Propulsion Laboratorieskbps Kilobits per secondLOS Line of sightmbps Megabits per secondMSIS Man-Systems Integration StandardsRF Radio frequency

13.2 Appendix B: References

9.1. Messerschmid, E. and Bertrand, R. (1999): Space Stations: Systems and Utilization. Berlin: Springer-Verlag.

9.2 Jorgensen, C. (ed.) (2000). International Space Station Evolution Data Book Volume I. Baseline Design Revision A NASA SP-2000-6109. Retrieved November 10, 2003 from NASA website: http://techreports.larc.nasa.gov/ltrs/PDF/2000/spec/NASA-2000-sp6109vol1rev1.pdf.

9.3 Dobek, G. (2000). Operations Local Area Network Interface Control Document: International Space Station Program JSC 36381 Baseline. Retrieved December 1, 2003 from Spaceref.com website: http://www.spaceref.com/iss/computer/iss.ops.lan.icd.doc.

9.4 Harwood, W. (2001). Mighty Mouse computer saves the day aboard station. Retrieved December 1, 2003 from Spaceflight Now website: http://spaceflightnow.com/station/stage6a/010426fd8/index2.html.

9.5 Honeywell Corp. (2002). Mulitplexers/Demultiplexers: Your Solution for

Onboard Processing. Retrieved December 1, 2003 from Honeywell Corp.

Page 19 of 20

MARS OR BUST, LLC

website: http://content.honeywell.com/dses/assets/datasheets/multiplexer-demultiplexer.pdf.

9.6 NASA (1995). Man-Systems Integration Standards, Revision B, July 1995 NASA-STD-3000. Retrieved November 10, 2003 from NASA website: http://msis.jsc.nasa.gov/.

9.7 Kwok, H. and Young, D. (2001). Communications Networks for the Military. COTS Journal. Retrieved December 3, 2003 from Dy 4 Systems website: http://www.dy4.com/support/TechWhitePapers/CommNetworks.pdf.

9.8 Linksys, Inc (n.p.d.). Wireless Access Point. Retrieved December 3, 2003 from Linksys website: ftp://ftp.linksys.com/datasheet/wap54ads.pdf.

9.9 Brown, p. 486

9.10 Condor Engineering, Inc. (n.p.d.). Mil-STD-1553 Tutorial 1500-030. Retrieved December 3, 2003 from Condor Engineering website: http://www.condoreng.com/support/downloads/tutorials/MIL-STD-1553Tutorial.PDF.

9.11 NASA (1999). Shuttle/Payload Interface Definition Document for the Payload and General Support Computer NSTS 21000-IDD-760XD. Retrieved December 3, 2003 from Spaceref.com website: http://www.spaceref.com/shuttle/computer/IDD_760XD.pdf .

9.12 Hoffman, S. and Kaplan, D. (1997). Human Exploration of Mars: The Reference Mission of the NASA Mars Exploration Study Team. Lyndon B. Johnson Space Center, Houston, TX.

9.13 IBM, Inc. (n.p.d.). Power & Power Protection. Retrieved December 3, 2003 from IBM website: http://www.pc.ibm.com/us/accessories/battery.html.

9.14 4S Products, Inc. (n.p.d.). CATo-5 UTP.100 ohm. Retrieved December 3, 2003 from http://www.4sproducts.com/catalogue/copper/premise/CATo5_utp-i.htm .

9.15 Larson, W. and Pranke, L. (2000). Human Spaceflight: Mission Analysis and Design. New York: The McGraw-Hill Companies, Inc.

13.3 Appendix C: Acknowledgements

Page 20 of 20