Altair Lander Life Support: Requirement Analysis Cycles 1 and 2 Molly Anderson', Su Curley' and Henry Rotter' NASA Johnson Space Center, Houston, Texas, 77058 Evan Yagoda4 Jacobs Technology, Houston, Texas, 77058 Life support systems are a critical part of human exploration beyond low earth orbit. NASA's Altair Lunar Lander has unique missions to perform and will need a unique life support system to complete them. Initial work demonstrated a feasible minimally -functional Lander design. This work was completed in Design Analysis Cycles (DAC) 1, 2, and 3 were reported in a previous paper'. On October 21, 2008, the Altair project completed the Mission Concept Review (MCR), moving the project into Phase A. In Phase A activities, the project is preparing for the System Requirements Review (SRR). Altair has conducted two Requirements Analysis Cycles (RACs) to begin this work. During this time, the life support team must examine the Altair mission concepts, Constellation Program level requirements, and interfaces with other vehicles and spacesuits to derive the right set of requirements for the new vehicle. The minimum functionality design meets some of these requirements already and can be easily adapted to meet others. But Altair must identify which will be more costly in mass, power, or other resources to meet. These especially costly requirements must be analyzed carefully to be sure they are truly necessary, and are the best way of explaining and meeting the true need. If they are necessary and clear, they become important mass threats to track at the vehicle level. If they are not clear or do not seem necessary to all stakeholders, Altair must work to redefine them or push back on the requirements writers. Additionally, the life support team is evaluating new technologies to see if they are more effective than the existing baseline design at performing necessary functions in Altair's life support system. I. Introduction HE Altair lunar lander is part of NASA's Constellation Program and performs three basic missions: sortie, Toutpost delivery, and cargo. Sorties are 7-day missions that bring a crew of 4 people to explore locations anywhere on the lunar surface. The lander life support system provides habitation and extravehicular activity (EVA) support to enable the crew to live in and out of the lander during the sortie without resources from other vehicles or surface assets. The crew returns in the ascent module (AM) to lunar orbit to rendezvous with the Orion vehicle for the return to Earth. Outpost delivery missions bring 4-person crews to the location of a lunar Outpost. To maximize cargo delivery with the crew, the lander life support does not provide overnight habitation, and the only EVA performed from the lander is the transfer to the Outpost. The crew again returns to orbit in the AM. Cargo missions are unmanned missions to delivery supplies to the lunar surface without a pressurized habitable volume. No part of the cargo vehicle returns to Lunar orbit. To achieve flexibility, but not add the cost of multiple unique designs. Altair is designed to have maximum commonality between versions. The same descent module is designed to support all of these functions. The ascent stage is largely common between missions. Altair has been primarily designing for the sortie mission, and then deleting components unnecessary for the outpost delivery mission. Overall; the vehicle is designed to be an affordable way to provide flexibility for many different mission types. 'Altair Life Support Lead, NASA Johnson Space Center, EC2 2 Life Support Engineer, NASA Johnson Space Center, EC3 ' Altair ECLSS Architect; NASA Johnson Space Center, C 104 4 Life Support Engineer, Jacobs Technology at NASA JSC, JE44 1 American Institute of Aeronautics and Astronautics A. Project Status The Altair project began as a small conceptual design team, and has been working through the early phases of the NASA systems engineering process cycle. While there are many processes and tasks going on concurrently, the project management tends to organize most of the domain engineers into Design Analysis Cycles (DACs) or Requirements Analysis Cycles (RACs). The first three Design Analysis Cycles were used to develop confidence that a feasible conceptual design for an Altair lander did exist. On October 18, 2008, Altair passed the Mission Concept Review milestone. Starting in spring 2009, the team turned their focus to performing RACs in order to prepare for a System Requirements Review (SRR) by developing an official System Requirements Document (SRD). The SRR was originally planned for summer or fall of 2010- Eventually the 2010 date was replaced with a synchronization of the lunar architecture between Constellation projects including Orion, EVA, and Lunar Surface Systems (LSS), with the SRR planned for 2011. As the project matures, conceptual design efforts have continued to provide the feasibility or cost of the proposed requirements or answer program questions with parametric models. The team also began planning for the effort required to move from SRR to a Preliminar y Design Review (PDR). But the team has changed its primary focus to performing a methodical analysis of the requirements set for the Altair vehicle to create the SRD. B. Altair Life Support Requirements The Altair requirements most pertinent to the life support system come largely from the Constellation Architecture Requirements Document (CARD) or the Constellation Human Systems Integration Requirements (HSIR). The CARD includes both requirements that apply to all Constellation vehicles, and requirements allocated specifically to the individual vehicle projects. Some of the CARD requirements describe architecture decisions made to distribute certain functions across each vehicle in the Constellation program. The CARD also contains requirements for many contingency scenarios that are not caused by a failure in the vehicle that needs to respond. Putting these requirements in a pro gram level document allows each vehicle team to understand the role their system plays in the ultimate solution. The document also defines responses to threats from external issues, like a micrometeoroid or orbital debris (MMOD) strike, to help balance the protection from these risks across the program. The HSIR contains requirements that specify what is required to support the crewmembers so that they can perform their mission functions successfully. The HSIR defines acceptable environmental conditions, contains unique functions that the vehicle must perform to support the crew, and describes crew inputs and outputs the life support system must supply or remove. When the HSIR allows a range of environmental conditions, a project Altair is free to set narrower bounds inside that range in the SRD. At the Altair SRD level, many related HSIR requirements are grouped into a top-level functional requirement. The details of the HSIR would be flowed down to children requirements in a life support or other system specification. The Altair project must review all of the requirements in the CARD, HSIR, and many other documents, and either negotiate changes or accept them into the SRD document. II. Requirements Analysis Cycle 1 In the first Requirements Analysis Cycle (RAC-1), the Altair team tried to focus on key drivin g requirements (KDRs) or requirements critical to the lander architecture. The life support team supported work on architecture requirements on airlocks, crew access before landing on the moon, and long surface donnancy periods. Several contingency scenarios were also identified as key driving requirements for the life support system. These included fire detection and suppression, cabin pressure leaks, and contingency ascent and microgravity EVA scenarios. The acceptance of these requirements adds unique functionality to the lander and must be addressed early. A. Airlocks and Lunar Dust Mitigation Engineers, medical experts, and crew representatives in the Constellation program are very aware that lunar regolith poses threats and challenges to activities on the lunar surfaces. In RAC-1, the Altair project studied a CARD requirement for the lander to include an airlock. The Altair team had already included a detachable airlock in their Sortie vehicle concept, but did not include one for Outpost Delivery missions, and of course did not include one for cargo missions. The team initially found the requirement suspect because it was written for the Altair project as a whole, and not specific to the different configurations. One other issue with this requirement is that it seems to specify an implementation, and not a need ; which is not usually considered good systems engineering. After much discussion, the team suggested that there were really two core issues that had led to the initial writing of this requirement. The Constellation program was concerned about lunar dust issues, and an airlock is assumed to American Institute of Aeronautics and Astronautics help mitigate the movement of lunar dust into the habitable volumes. The program also wants to have the flexibility to leave some crewmembers in a shirt-sleeve cabin environment, while others go out on EVA. Sometimes called "split operations", this design allows the mission to continue if a crewmember is temporarily injured or ill, or a single spacesuit fails. Altair already had requirements in place to allow "1, 2, 3, or 4" crewmembers to perform EVAs, and a requirement to mitigate the impacts of lunar dust. After discussion with the program that continued after the RAC-1 end date, it was agreed that the requirement to have an airlock could be removed because Altair accepted the requirements to meet all the functions an airlock provided. B. Lunar Transit Crew Access Operations concepts and timelines are an important source of requirements. This is especially important in the early phases of design when detailed documents are not complete. The location, activities, and status of the crewmembers is almost solely documented in these concepts and timelines. Defining whether life support system components like waste collection or food rehydration need to be used in microgravity or only on the surface is an important design driver.