SEARCH · Search NASA

Results for “Summary of the technical management process”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

43 records · Page 3

All sources NASA NTRS DOE OSTI

NASA NTRS1999

SIRTF Science Operations System Design

SIRTF Science Operations System Design William B. Green Manager, SIRTF Science Center California Institute of Technology M/S 310-6 1200 E. California Blvd., Pasadena CA 91125 (626) 395 8572 Fax (626) 568 0673 bgreen@ipac.caltech.edu. The Space Infrared Telescope Facility (SIRTF) will be launched in December 2001, and perform an extended series of science observations at wavelengths ranging from 20 to 160 microns for five years or more. The California Institute of Technology has been selected as the home for the SIRTF Science Center (SSC). The SSC will be responsible for evaluating and selecting observation proposals, providing technical support to the science community, performing mission planning and science observation scheduling activities, instrument calibration during operations and instrument health monitoring, production of archival quality data products, and management of science research grants. The science payload consists of three instruments delivered by instrument Principal Investigators located at University of Arizona, Cornell, and Harvard Smithsonian Astrophysical Observatory. The SSC is responsible for design, development, and operation of the Science Operations System (SOS) which will support the functions assigned to the SSC by NASA. The SIRTF spacecraft, mission profile, and science instrument design have undergone almost ten years of refinement. SIRTF development and operations activities are highly cost constrained. The cost constraints have impacted the design of the SOS in several ways. The Science Operations System has been designed to incorporate a set of efficient, easy to use tools which will make it possible for scientists to propose observation sequences in a rapid and automated manner. The use of highly automated tools for requesting observations will simplify the long range observatory scheduling process, and the short term scheduling of science observations. Pipeline data processing will be highly automated and data-driven, utilizing a variety of tools developed at JPL, the instrument development teams, and Space Telescope Science Institute to automate processing. An incremental ground data system development approach has been adopted, featuring periodic deliveries that are validated with the flight hardware throughout the various phases of system level development and testing. This approach minimizes development time and decreases operations risk. This paper will describe the top level architecture of the SOS and the basic design concepts. A summary of the incremental development approach will be presented. Examples of the unique science user tools now under final development prior to the first proposal call scheduled for mid-2000 will be shown.

Green, William↗

NASA NTRSDate not supplied

Strategy for Developing Technologies for Megawatt-class Nuclear Electric Propulsion Systems

In late fiscal year 2020, the Space Nuclear Propulsion (SNP) project began the process of formulating an investment strategy to support development of the technologies required for a high-power (megawatt-class) nuclear electric propulsion (NEP) system capable of performing human-scale missions. This activity was initiated concurrent with several high-level studies and assessments were either under way or had just concluded. Studies of human-scale Mars missions have been performed several times over the past two decades. One of the most recent studies examined opposition-class human Mars missions to occur in the late 2030s timeframe [1,2]. The mission architecture assumed a hybrid NEP/chem-propelled vehicle that used a high specific impulse (Isp) NEP-system and a liquid oxygen (LOx)-liquid methane high thrust chemical stage (two 110 kN (25 klbf) thrust, 365 s Isp engines) for maneuvers performed to enter and exit gravity wells. Trajectory analyses performed in this study showed that such a mission could be performed with 2-4 MWe directed into the electric propulsion system (operating for 20,000+ hours), with the large range representing different opposition-class Mars mission opportunities and permutations on the trajectory design, concept of operations, and technology choices. In 2020, the NASA Engineering and Safety Center (NESC) performed a study to evaluate the maturity of the different technologies required for nuclear propulsion systems [3]. The executive summary of this report provided the following top-level conclusions: • “The majority of critical technologies for… NEP/Chem… systems are relatively immature” • “TRLs [technology readiness levels] in the literature are often overestimated” • “The majority of critical technologies… for NEP/Chem… systems are at a relatively high level of advancement degree of difficulty (AD2 > 4) for maturation, requiring a dual development approach” • “The proper assessment of baseline TRL and AD2 values and the estimation of requirements and resources required for advancement have been consistent issues for NEP,” • “Non-advocate reviews should occur at the start of a technology program and at all key milestones.” In 2021, the National Academies of Science, Engineering, and Medicine (NASEM) issued a separate report [4] identifying the “primary technical and programmatic challenges, merits, and risks for maturing space nuclear propulsion technologies of interest to a future human Mars exploration mission.” That work contained several important findings, including: • “Developing a MWe-class NEP system for the baseline mission would require increasing power by orders of magnitude relative to NEP system flight- or ground-based technology demonstrations completed to date.” • “Subscale in-space flight testing of NEP systems cannot address many of the risks and potential failure modes associated with the baseline mission NEP system. With sufficient M&S [modeling & simulation] and ground testing, including modular subsystem tests at full scale and power, flight qualification requirements can be met by the cargo missions that will precede the first crewed mission to Mars. Fully integrated ground testing may not be required.” • “As a result of low and intermittent investment over the past several decades, it is unclear if even an aggressive program would be able to develop an NEP system capable of executing the baseline mission in 2039.” These efforts motivated the SNP project to investigate the technologies available for a megawatt-class high power nuclear electric propulsion system. That system is illustrated schematically in Figure 1 and is comprised of five separate top-level critical technology elements (CTEs). 1. Nuclear Reactor – Thermal power source for the system, utilizing high-assay low enriched uranium (HALEU) as the nuclear fuel. Reactor radiation shielding is also included in this CTE. 2. Power Conversion – Operates as a thermodynamic cycle, accepting nuclear reactor thermal power as an input and converting it to mechanical power. 3. Power Management and Distribution (PMAD) – Accepts as an input mechanical power from the power conversion system, which is used to generate electrical power. The PMAD system also distributes the generated electrical power to all other parts of the spacecraft, including the high-power EP system. The PMAD system may also perform duties such as isolation, fault detection, and power transformation/rectification for different spacecraft systems, including the thrusters. 4. Electric Propulsion (EP) – Accepts as an input electrical power, which is used to accelerate a propellant to high speeds to produce thrust. This system includes the power processing unit (PPU), which converts the power it receives to the correct current and voltage required by the thrusters, and the propellant storage and feed systems, which contain and meter the flow of propellant to the thrusters. 5. Thermal Management (Radiators/Heat Rejection) – The cold side of the thermodynamic power conversion cycle, accepts thermal power from the power conversion system and radiatively rejects that heat to space. In this paper, we describe the SNP project formulation and investment strategy that aims to accomplish the research and development required to advance the technology readiness for each CTE. The strategy relies heavily upon experimental testing supported by modeling and simulation to yield realistic assessments of the technologies, which in turn will be used to inform future NEP system-level design decisions and any potential technology downselects.

Kurt A Polzin↗

NASA NTRS2017

Lessons Learned from Applying Design Thinking in a NASA Rapid Design Study in Aeronautics

In late 2015, NASA's Aeronautics Research Mission Directorate (ARMD) funded an experiment in rapid design and rapid teaming to explore new approaches to solving challenging design problems in aeronautics in an effort to cultivate and foster innovation. This report summarizes several lessons learned from the rapid design portion of the study. This effort entailed learning and applying design thinking, a human-centered design approach, to complete the conceptual design for an open-ended design challenge within six months. The design challenge focused on creating a capability to advance experimental testing of autonomous aeronautics systems, an area of great interest to NASA, the US government as a whole, and an entire ecosystem of users and developers around the globe. A team of nine civil servant researchers from three of NASA's aeronautics field centers with backgrounds in several disciplines was assembled and rapidly trained in design thinking under the guidance of the innovation and design firm IDEO. The design thinking process, while used extensively outside the aerospace industry, is less common and even counter to many practices within the aerospace industry. In this report, several contrasts between common aerospace research and development practices and design thinking are discussed, drawing upon the lessons learned from the NASA rapid design study. The lessons discussed included working towards a design solution without a set of detailed design requirements, which may not be practical or even feasible for management to ascertain for complex, challenging problems. This approach allowed for the possibility of redesigning the original problem statement to better meet the needs of the users. Another lesson learned was to approach problems holistically from the perspective of the needs of individuals that may be affected by advances in topic area instead of purely from a technological feasibility viewpoint. The interdisciplinary nature of the design team also provided valuable experience by allowing team members from different technological backgrounds to work side-by-side instead of dividing into smaller teams, as is frequently done in traditional multidisciplinary design. The team also learned how to work with qualitative data obtained primarily through the 70-plus interviews that were conducted over the course of this project, which was a sharp contrast to using quantitative data with regards to identifying, capturing, analyzing, storing, and recalling the data. When identifying potential interviewees who may have useful contributions to the design subject area, the team found great value in talking to non-traditional users and potential beneficiaries of autonomous aeronautics systems whose impact on the aeronautics autonomy ecosystem is growing swiftly. Finally, the team benefitted from using "sacrificial prototyping," which is a method of rapidly prototyping draft concepts and ideas with the intent of enabling potential users to provide significant feedback early in the design process. This contrasts the more common approach of using expensive prototypes that focus on demonstrating technical feasibility. The unique design approach and lessons learned by the team throughout this process culminated in a final design concept that was quite different than what the team originally assumed would be the design concept initially. A summary of the more usercentered final design concept is also provided.

McGowan, Anna-Maria↗

NASA NTRS2013

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗

NASA NTRS2015

Human System Risk Management for Space Flight

This brief abstract reviews the development of the current day approach to human system risk management for space flight and the development of the critical components of this process over the past few years. The human system risk management process now provides a comprehensive assessment of each human system risk by design reference mission (DRM) and is evaluated not only for mission success but also for long‐term health impacts for the astronauts. The discipline of bioastronautics is the study of the biological and medical effects of space flight on humans. In 1997, the Space Life Sciences Directorate (SLSD) initiated the Bioastronautics Roadmap (Roadmap) as the "Critical Path Roadmap", and in 1998 participation in the roadmap was expanded to include the National Space Biomedical Research Institute (NSBRI) and the external community. A total of 55 risks and 250 questions were identified and prioritized and in 2000, the Roadmap was base-lined and put under configuration control. The Roadmap took into account several major advisory committee reviews including the Institute of Medicine (IOM) "Safe Passage: Astronaut care for Exploration Missions", 2001. Subsequently, three collaborating organizations at NASA HQ (Chief Health and Medical Officer, Office of Space Flight and Office of Biological & Physical Research), published the Bioastronautics Strategy in 2003, that identified the human as a "critical subsystem of space flight" and noted that "tolerance limits and safe operating bands must be established" to enable human space flight. These offices also requested a review by the IOM of the Roadmap and that review was published in October 2005 as "A Risk Reduction Strategy for Human Exploration of Space: A Review of NASA's Bioastronautics Roadmap", that noted several strengths and weaknesses of the Roadmap and made several recommendations. In parallel with the development of the Roadmap, the Office of the Chief Health and Medical Officer (OCHMO) began a process in 2004 of evaluating the tolerance limits and safe operating bands called for in the Bioastronautics Strategy. Over the next several years, the concept of the "operating bands" were turned into Space Flight Human System Standards (SFHSS), developed by the technical resources of the SLSD at the NASA Johnson Space Center (JSC). These standards were developed and reviewed at the SLSD and then presented to the OCHMO for acceptance. The first set of standards was published in 2007 as the NASA‐STD‐3001, Volume 1, Crew Health that elaborated standards for several physiological areas such as cardiovascular, musculoskeletal, radiation exposure and nutrition. Volume 2, Human Factors, Habitability and Human Health was published in 2011, along with development guidance in the Human Integration Design Handbook (HIDH). Taken together, the SFHSS Volumes 1 and 2, and the HIDH replaced the NASA‐STD‐3000 with new standards and revisions of the older document. Three other changes were also taking place that facilitated the development of the human system risk management approach. In 2005, the life sciences research and development portfolio underwent a comprehensive review through the Exploration Systems Architecture Study (ESAS) that resulted in the reformulation of the Bioastronautics Program into Human Research Program (HRP) that was focused on appropriate mitigation results for high priority human health risks. The baseline HRP budget was established in August 2005. In addition, the OCHMO formulated the Health and Medical Technical Authority (HMTA) in 2006 that established the position of the Chief Medical Officer (CMO) at the NASA JSC along with other key technical disciplines, and the OCHMO became the responsible office for the SFHSS as noted above. The final change was the establishment in 2008 of the Human System Risk Board (HSRB), chaired by the CMO with representation from the HRP, SLSD management and technical experts. The HSRB then began to review all human system risks, established a comprehensive risk management and configuration management plan and data sharing policy. These major developments of standards, the HRP, the HMTA and a forum for review of human system risks (HSRB) facilitated the integration of human research, medical operations, systems engineering and many other disciplines in the comprehensive review of human system risks. The HSRB began a comprehensive review of all potential inflight medical conditions and events and over the course of several reviews consolidated the number of human system risks to 30 where the greatest emphasis is placed for investing program dollars for risk mitigation. The HSRB considers all available evidence from human research, medical operations and occupational surveillance in assessing the risks for appropriate mitigation and future work. All applicable DRMs (low earth orbit 6 and 12 months, deep space sortie for 30 days and 1 year, a one year lunar mission, and a planetary mission for 3 years) are considered as human system risks are modified by the hazards associated with space flight such as microgravity, exposure to radiation, distance from the earth, isolation and a closed environment. Each risk has a summary assessment representing the state of knowledge/evidence base for that risk, the available risk mitigations, traceability to the SFHSS and program requirements, and future work required. These data then can drive coordinated budgets across the HRP, the International Space Station, Crew Health and Safety and Advanced Exploration System budgets. These risk assessments were completed for 6 DRMs in December of 2014 and serve as the baseline for which subsequent research and technology development and crew health care portfolios can be assessed. The HSRB will review each risk at least annually and especially when new information is available that must be considered for effective risk mitigation. The current status of each risk can be reported to program management for operations, budget reviews and general oversight of the human system risk management program.

Davis, Jeffrey↗

NASA NTRS1974

Pioneer Odyssey: Encounter with a Giant

Ancient peoples, perhaps thousands of years ago, undoubtedly conceived the idea of "reaching out" to Jupiter, the largest and most brilliant of the "wandering stars." But for mankind to stretch across the half billion miles to the giant planet of the Solar System many advances in technical and organizational fields of human endeavor had to be made. Outreach to Jupiter did not become a serious possibility until the Pioneer F and G Project was formed by NASA early in 1968. And then man began to design an extension of his senses that would probe the environs of the giant of the Solar System, a truly pioneer odyssey into the virtually unknown regions beyond the orbit of Mars. In the ensuing year. a dedicated and cooperative effort of several thousand people in Government, university, and private industrial organizations converted the idea into a reality. Less than twelve generations after Galileo first saw the banded disc of Jupiter and the flickering dots of its large satellites in the newly invented telescope, mankind sent a machine to make observations within that Jovian system. The two Pioneer spacecraft for the mission to Jupiter each weighed only about 570 pounds, yet carried eleven highly sophisticated instruments capable of operating unattended for many year in space. The spacecraft consumes less electrical power than a standard 100 watt lamp yet is able to accept instructions from Earth to control numerous operating modes of its scientific payload, process observations from these scientific instruments and format the observations into information usable on Earth. Even more remarkable. the spacecraft transmits a radio signal of only 8 watts power - equal to a nightlight - yet the information carried by the radio signal is received back on Earth from a distance of several billion miles. The Pioneer mission could not have been a success without the special engineering, scientific and management organization created for its accomplishment. This organization was rather unique in that it first had to meet a launch date target relatively quickly and then had to function for an extremely long mission operational time, far longer than any previous mission to planets. The first task was thus to organize so that the mission could be planned and the spacecraft designed and fabricated to be ready for launch within a few weeks of a 30-month target for completion. The program also produced an organization that planned mission operations to such detail that more than 16,000 commands were transmitted flawlessly to the distant spacecraft during Jupiter encounter. And each command reached the spacecraft within one second of the planned time despite the more than 90 minutes required for the radio message to travel from Earth to the spacecraft and for the spacecraft to return a confirmation to controllers back on Earth. The organization for Pioneer also determined the required flight path from Earth to Jupiter with such precision, and controlled the launch vehicle with such accuracy, that 21 months after launch the spacecraft was able to fly behind Jupiter's satellite lo, thereby providing the first measurement that indicated the possibility of a tenuous atmosphere about this large satellite. Finally, the Pioneer organization processed and analyzed each year sufficient information from the spacecraft to fill a book having about 3 million pages and reduced this avalanche of data from space into summaries of manageable size. And all this organization depended on people, consisted of people: the people who really made this whole mission possible. Pioneer has always depended on the dedication of many individuals from many organizations throughout the world to achieve its scientific objectives, and, as evidenced by the success of the Pioneer series, this dependence is completely justified. Relatively few individuals have an opportunity during their lives to participate in such a challenging, historic, pioneering effort; and still fewer are able to enjoy the rewards of such an activity. We who have worked on Pioneer 10 and its sister spacecraft, Pioneer 11, consider ourselves fortunate to be in both classes. For the opportunity we thank the people of the United States of America, who have supported our country's space effort and its spreading of human awareness of a vast and intriguing universe in which our own unique planet Earth is only one of myriads of worlds. This volume describing the mission to Jupiter and its results is one of the many rewards for our effort which we share with you, the reader.

Fimmel, Richard O.↗

NASA NTRS2020

X-HAB 2020: AR Field Treks Summary and Conclusions

As part of the FY20 X-Hab Challenge, BLiSS sought to create an Augmented Reality (AR) toolkit to help with analog field trek operations under the supervision of the Solar System Exploration Research Virtual Institute (SSERVI). These treks are operational and technical demonstrations at space-like destinations on Earth to test current extra-vehicular activity (EVA) techniques. While BLiSS as an organization has experience studying operational tasks such as this, it has never developed AR software at this scale. For that reason, another team at the University was brought on to work in parallel. The Collaborative Lab for Advancing Work in Space (CLAWS) is a veteran group of the NASA Spacesuit User Interface Technologies for Students (SUITS) challenge in which Hololens displays for astronauts are created within a year. The operational and technological pairing was ideally suited for tackling this problem. The team divided its responsibilities so that BLiSS would handle the research required to shape the project. As this deliverable had an end user, it was decided that interviewing these field geologists and operations specialists would provide the best insight. These interviews paired with literature review would reveal niche applications for AR that remained within feasible bounds. These science-driven EVAs in unknown terrain require more flexible tools than the current generation of EVA assistants. Rather than focus on sequential instructions, there instead needs to be a broad toolkit that's only called upon in specific instances. This AR Toolkit for Lunar Astronauts and Scientists (ATLAS) became the development goal of the project: create a non-intrusive assembly of tools that could be accessed in AR on the field. The current ATLAS design makes use of a geospatially and temporally annotated eld note system called GeoNotes. This allows for data to be collected and coordinated in a way that's synchronized across time, space, and different users. A Mission Control Center (MCC) and Mobile Support Equipment (MSE) were all needed to transport the AR headset into the field with the user. A network infrastructure was designed and set up within the University to enable this functionality. The software is based on a Protocol-Module structure that allows for modular development of each capability. A Protocol Manager coordinates different protocols that make use of modules. Each module tackles a different individual task while the protocol puts each one to use. The protocol manager coordinates when these are called to be used. This software is hosted on a head-mounted display (HMD) with the MCC acting as support from afar. While the software would be unit-tested at each level and each hardware component verified, a final demonstration would serve to prove the system's capabilities: an analog field trek. The team would prepare to support a user in a remote location from the MCC back at the University. A local area near campus would be tested before going out to do sample field geology further away. This unfortunately became impossible with the arrival of COVID-19. Access to all of the facilities to complete the project as planned were shut down. Our team was scattered across the globe and forced to complete the rest virtually. Adjustments were made to produce a small virtual concept in Adobe XD in the meantime. Even digital surveys were created based on the NASA task-load index (TLX) originally intended for testing actual users. The goal shifted towards completing software and getting feedback on the user interfaces (UI) and user experiences (UX). This team has reformed in response to COVID and its focus has shifted to what can be done remotely. There is still an intention to finish the original deliverable described in this report. The work has been expanded beyond the original X-Hab challenge and has instead become its own research e ort to be continued afterwards. This report collects the processes and knowledge gained from a year of studying and working at this problem with two teams. It should preserve it for the time until the world returns to normal and work can resume. CLAWS will be taking over full responsibility from that point forward, eventually surpassing the original needs of the project. While this document captures the work done towards an eventual end, the CLAWS team has written their own proposal alongside it. It outlines a new future for ATLAS beyond X-Hab, BLiSS, and hopefully beyond COVID-19. This project began as a vague goal hoping to place a new technology into the unique setting of exploration science. The project has since comfortably taken root and will hopefully bloom over the next year.

Alex Sena↗