SEARCH · Engineering Papers

Results for “flight software testing”

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.

At least 1,459 records · Page 81

All sources NASA NTRS DOE OSTI

NASA NTRS2011

Ares I-X Range Safety Flight Envelope Analysis

Ares I-X was the first test flight of NASA's Constellation Program's Ares I Crew Launch Vehicle designed to provide manned access to low Earth orbit. As a one-time test flight, the Air Force's 45th Space Wing required a series of Range Safety analysis data products to be developed for the specified launch date and mission trajectory prior to granting flight approval on the Eastern Range. The range safety data package is required to ensure that the public, launch area, and launch complex personnel and resources are provided with an acceptable level of safety and that all aspects of prelaunch and launch operations adhere to applicable public laws. The analysis data products, defined in the Air Force Space Command Manual 91-710, Volume 2, consisted of a nominal trajectory, three sigma trajectory envelopes, stage impact footprints, acoustic intensity contours, trajectory turn angles resulting from potential vehicle malfunctions (including flight software failures), characterization of potential debris, and debris impact footprints. These data products were developed under the auspices of the Constellation's Program Launch Constellation Range Safety Panel and its Range Safety Trajectory Working Group with the intent of beginning the framework for the operational vehicle data products and providing programmatic review and oversight. A multi-center NASA team in conjunction with the 45th Space Wing, collaborated within the Trajectory Working Group forum to define the data product development processes, performed the analyses necessary to generate the data products, and performed independent verification and validation of the data products. This paper outlines the Range Safety data requirements and provides an overview of the processes established to develop both the data products and the individual analyses used to develop the data products, and it summarizes the results of the analyses required for the Ares I-X launch.

Starr, Brett R.↗

NASA NTRS2016

Next Generation Flight Displays Using HTML5

The Human Integrated Vehicles and Environments (HIVE) lab at Johnson Space Center (JSC) is focused on bringing together inter-disciplinary talent to design and integrate innovative human interface technologies for next generation manned spacecraft. As part of this objective, my summer internship project centered on an ongoing investigation in to building flight displays using the HTML5 standard. Specifically, the goals of my project were to build and demo "flight-like" crew and wearable displays as well as create a webserver for live systems being developed by the Advanced Exploration Systems (AES) program. In parallel to my project, a LabVIEW application, called a display server, was created by the HIVE that uses an XTCE (XML (Extensible Markup Language) Telemetry and Command Exchange) parser and CCSDS (Consultative Committee for Space Data System) space packet decoder to translate telemetry items sent by the CFS (Core Flight Software) over User Datagram Protocol (UDP). It was the webserver's job to receive these UDP messages and send them to the displays. To accomplish this functionality, I utilized Node.js and the accompanying Express framework. On the display side, I was responsible for creating the power system (AMPS) displays. I did this by using HTML5, CSS and JavaScript to create web pages that could update and change dynamically based on the data they received from the webserver. At this point, I have not started on the commanding, being able to send back to the CFS, portion of the displays but hope to have this functionality working by the completion of my internship. I also created a way to test the webserver's functionality without the display server by making a JavaScript application that read in a comma-separate values (CSV) file and converted it to XML which was then sent over UDP. One of the major requirements of my project was to build everything using as little preexisting code as possible, which I accomplished by only using a handful of JavaScript libraries. As a side project, I created a model of the HIVE lab and Building 29 using SketchUp. I obtained the floorplans of the building from the JSC Geographic Information Systems (GIS), which were computer-aided design (CAD) files, and imported them into SketchUp. I then took those floorplans and created a 3D model of the building from them. Working in conjunction with the Hybrid Reality lab in Building 32, the SketchUp model was imported into Unreal Engine for use with the HTC Vive. Using the Vive, I was able to interact with the model I created in virtual reality (VR). The purpose of this side project was to be able to visualize potential lab layouts and mockup designs as they are in development in order to finalize design decisions. Pending approval, the model that I created will be used in the Build-As-You-Test: Can Hybrid Reality Improve the SE/HSI Design Process project in the fall. Getting the opportunity to work at NASA has been one of the most memorable experiences of my life. Over the course of my internship, I improved my programming and web development abilities substantially. I will take all the skills and experiences I have had while at NASA back to school with me in the fall and hope to pursue a career in the aerospace industry after graduating in the spring.

Greenwood, Brian↗

NASA NTRS1988

Optimal solutions for complex design problems: Using isoperformance software for human factors trade offs

A major application of isoperformance is as a trade-off methodology of the three major drivers of system design; equipment, training variables, and user characteristics. The flexibility of isoperformance allows each of these three components to be nearly any rational variation. For example, aptitude may be military Armed Forces Qualification Testing (AFQT) categories, cutoff scores within a selection procedure, or simply dichotomizing high and low scorers (pass/fail). Equipment may be new versus old, 'smart' versus dumb, high versus low resolution, etc. Training may be short versus long or varieties of media types (lecture versus CAI/CBI versus self-paced workbooks). In its final computerized form isoperformance lets the user set an operational level of performance (e.g., a jet pilot in a simulated emergency must take prescribed corrective action and clear the plane in several seconds, pilot astronauts will check out all shuttle flight systems within 30 minutes, or Mission Specialists must handle sucdessfully a required number of job elements). At this point the computer program guides the user through any requested trade-offs of the three components while maintaining the specified operational level of performance through isoperformance curves. A demonstration of the computer program is currently available.

Kennedy, Robert S.↗

NASA NTRS2005

Hardware in-the-Loop Demonstration of Real-Time Orbit Determination in High Earth Orbits

This paper presents results from a study conducted at Goddard Space Flight Center (GSFC) to assess the real-time orbit determination accuracy of GPS-based navigation in a number of different high Earth orbital regimes. Measurements collected from a GPS receiver (connected to a GPS radio frequency (RF) signal simulator) were processed in a navigation filter in real-time, and resulting errors in the estimated states were assessed. For the most challenging orbit simulated, a 12 hour Molniya orbit with an apogee of approximately 39,000 km, mean total position and velocity errors were approximately 7 meters and 3 mm/s respectively. The study also makes direct comparisons between the results from the above hardware in-the-loop tests and results obtained by processing GPS measurements generated from software simulations. Care was taken to use the same models and assumptions in the generation of both the real-time and software simulated measurements, in order that the real-time data could be used to help validate the assumptions and models used in the software simulations. The study makes use of the unique capabilities of the Formation Flying Test Bed at GSFC, which provides a capability to interface with different GPS receivers and to produce real-time, filtered orbit solutions even when less than four satellites are visible. The result is a powerful tool for assessing onboard navigation performance in a wide range of orbital regimes, and a test-bed for developing software and procedures for use in real spacecraft applications.

Moreau, Michael↗

NASA NTRS2011

Ares I-X Range Safety Simulation Verification and Analysis Independent Validation and Verification

NASA s Ares I-X vehicle launched on a suborbital test flight from the Eastern Range in Florida on October 28, 2009. To obtain approval for launch, a range safety final flight data package was generated to meet the data requirements defined in the Air Force Space Command Manual 91-710 Volume 2. The delivery included products such as a nominal trajectory, trajectory envelopes, stage disposal data and footprints, and a malfunction turn analysis. The Air Force s 45th Space Wing uses these products to ensure public and launch area safety. Due to the criticality of these data, an independent validation and verification effort was undertaken to ensure data quality and adherence to requirements. As a result, the product package was delivered with the confidence that independent organizations using separate simulation software generated data to meet the range requirements and yielded consistent results. This document captures Ares I-X final flight data package verification and validation analysis, including the methodology used to validate and verify simulation inputs, execution, and results and presents lessons learned during the process

Merry, Carl M.↗

NASA NTRS2013

A Validated Set of MIDAS V5 Task Network Model Scenarios to Evaluate Nextgen Closely Spaced Parallel Operations Concepts

The Closely Spaced Parallel Operations (CSPO) scenario is a complex, human performance model scenario that tested alternate operator roles and responsibilities to a series of off-nominal operations on approach and landing (see Gore, Hooey, Mahlstedt, Foyle, 2013). The model links together the procedures, equipment, crewstation, and external environment to produce predictions of operator performance in response to Next Generation system designs, like those expected in the National Airspaces NextGen concepts. The task analysis that is contained in the present report comes from the task analysis window in the MIDAS software. These tasks link definitions and states for equipment components, environmental features as well as operational contexts. The current task analysis culminated in 3300 tasks that included over 1000 Subject Matter Expert (SME)-vetted, re-usable procedural sets for three critical phases of flight; the Descent, Approach, and Land procedural sets (see Gore et al., 2011 for a description of the development of the tasks included in the model; Gore, Hooey, Mahlstedt, Foyle, 2013 for a description of the model, and its results; Hooey, Gore, Mahlstedt, Foyle, 2013 for a description of the guidelines that were generated from the models results; Gore, Hooey, Foyle, 2012 for a description of the models implementation and its settings). The rollout, after landing checks, taxi to gate and arrive at gate illustrated in Figure 1 were not used in the approach and divert scenarios exercised. The other networks in Figure 1 set up appropriate context settings for the flight deck.The current report presents the models task decomposition from the tophighest level and decomposes it to finer-grained levels. The first task that is completed by the model is to set all of the initial settings for the scenario runs included in the model (network 75 in Figure 1). This initialization process also resets the CAD graphic files contained with MIDAS, as well as the embedded operator models that comprise MIDAS. Following the initial settings, the model progresses to begin the first tasks required of the two flight deck operators, the Captain (CA) and the First Officer (FO). The task sets will initialize operator specific settings prior to loading all of the alerts, probes, and other events that occur in the scenario. As a note, the CA and FO were terms used in developing this model but the CA can also be thought of as the Pilot Flying (PF), while the FO can be considered the Pilot-Not-Flying (PNF)or Pilot Monitoring (PM). As such, the document refers to the operators as PFCA and PNFFO respectively.

task network model↗

NASA NTRS2016

Safety Characteristics in System Application of Software for Human Rated Exploration Missions for the 8th IAASS Conference

NASA and its industry and international partners are embarking on a bold and inspiring development effort to design and build an exploration class space system. The space system is made up of the Orion system, the Space Launch System (SLS) and the Ground Systems Development and Operations (GSDO) system. All are highly coupled together and dependent on each other for the combined safety of the space system. A key area of system safety focus needs to be in the ground and flight application software system (GFAS). In the development, certification and operations of GFAS, there are a series of safety characteristics that define the approach to ensure mission success. This paper will explore and examine the safety characteristics of the GFAS development. The GFAS system integrates the flight software packages of the Orion and SLS with the ground systems and launch countdown sequencers through the 'agile' software development process. A unique approach is needed to develop the GFAS project capabilities within this agile process. NASA has defined the software development process through a set of standards. The standards were written during the infancy of the so-called industry 'agile development' movement and must be tailored to adapt to the highly integrated environment of human exploration systems. Safety of the space systems and the eventual crew on board is paramount during the preparation of the exploration flight systems. A series of software safety characteristics have been incorporated into the development and certification efforts to ensure readiness for use and compatibility with the space systems. Three underlining factors in the exploration architecture require the GFAS system to be unique in its approach to ensure safety for the space systems, both the flight as well as the ground systems. The first are the missions themselves, which are exploration in nature, and go far beyond the comfort of low Earth orbit operations. The second is the current exploration system will launch only one mission per year even less during its developmental phases. Finally, the third is the partnered approach through the use of many different prime contractors, including commercial and international partners, to design and build the exploration systems. These three factors make the challenges to meet the mission preparations and the safety expectations extremely difficult to implement. As NASA leads a team of partners in the exploration beyond earth's influence, it is a safety imperative that the application software used to test, checkout, prepare and launch the exploration systems put safety of the hardware and mission first. Software safety characteristics are built into the design and development process to enable the human rated systems to begin their missions safely and successfully. Exploration missions beyond Earth are inherently risky, however, with solid safety approaches in both hardware and software, the boldness of these missions can be realized for all on the home planet.

capability↗

NASA NTRS2011

Development of a Software Tool to Automate ADCO Flight Controller Console Planning Tasks

This independent study project covers the development of the International Space Station (ISS) Attitude Determination and Control Officer (ADCO) Planning Exchange APEX Tool. The primary goal of the tool is to streamline existing manual and time-intensive planning tools into a more automated, user-friendly application that interfaces with existing products and allows the ADCO to produce accurate products and timelines more effectively. This paper will survey the current ISS attitude planning process and its associated requirements, goals, documentation and software tools and how a software tool could simplify and automate many of the planning actions which occur at the ADCO console. The project will be covered from inception through the initial prototype delivery in November 2011 and will include development of design requirements and software as well as design verification and testing.

Anderson, Mark G.↗

NASA NTRS2003

Applying Model-Based Reasoning to the FDIR of the Command and Data Handling Subsystem of the International Space Station

All of the International Space Station (ISS) systems which require computer control depend upon the hardware and software of the Command and Data Handling System (C&DH) system, currently a network of over 30 386-class computers called Multiplexor/Dimultiplexors (MDMs)[18]. The Caution and Warning System (C&W)[7], a set of software tasks that runs on the MDMs, is responsible for detecting, classifying, and reporting errors in all ISS subsystems including the C&DH. Fault Detection, Isolation and Recovery (FDIR) of these errors is typically handled with a combination of automatic and human effort. We are developing an Advanced Diagnostic System (ADS) to augment the C&W system with decision support tools to aid in root cause analysis as well as resolve differing human and machine C&DH state estimates. These tools which draw from sources in model-based reasoning[ 16,291, will improve the speed and accuracy of flight controllers by reducing the uncertainty in C&DH state estimation, allowing for a more complete assessment of risk. We have run tests with ISS telemetry and focus on those C&W events which relate to the C&DH system itself. This paper describes our initial results and subsequent plans.

Robinson, Peter↗

NASA NTRS2006

Orbiting GPS Receiver Modified to Track New L2C Signal

The L2C signal is a great step forward for civil applications of GPS, enabling high-accuracy dual-frequency measurements. Engineers from the Jet Propulsion Laboratory and ITT teamed to reprogram FPGA firmware and add tracking software on an orbiting receiver to track the new GPS L2C signal from SAC-C. SAC-C is an Argentinean science satellite and was launched in November 2000 with a BlackJack GPS receiver. This is a dual-frequency digital receiver with 48 tracking channels and four antennas. On SAC-C, it provides precise orbits, atmospheric occultation data, tests of GPS surface reflections, and serves as an orbiting test bed for new GPS development such as the L2C tracking reported here.

GPS receiver↗

NASA NTRS2013

Wearable Technology

Wearable technology projects, to be useful, in the future, must be seamlessly integrated with the Flight Deck of the Future (F.F). The lab contains mockups of space vehicle cockpits, habitat living quarters, and workstations equipped with novel user interfaces. The Flight Deck of the Future is one element of the Integrated Power, Avionics, and Software (IPAS) facility, which, to a large extent, manages the F.F network and data systems. To date, integration with the Flight Deck of the Future has been limited by a lack of tools and understanding of the Flight Deck of the Future data handling systems. To remedy this problem it will be necessary to learn how data is managed in the Flight Deck of the Future and to develop tools or interfaces that enable easy integration of WEAR Lab and EV3 products into the Flight Deck of the Future mockups. This capability is critical to future prototype integration, evaluation, and demonstration. This will provide the ability for WEAR Lab products, EV3 human interface prototypes, and technologies from other JSC organizations to be evaluated and tested while in the Flight Deck of the Future. All WEAR Lab products must be integrated with the interface that will connect them to the Flight Deck of the Future. The WEAR Lab products will primarily be programmed in Arduino. Arduino will be used for the development of wearable controls and a tactile communication garment. Arduino will also be used in creating wearable methane detection and warning system.

Watson, Amanda↗

NASA NTRS2015

T-38 Primary Flight Display Prototyping and HIVE Support Abstract & Summary

This fall I worked in EV3 within NASA's Johnson Space Center in The HIVE (Human Integrated Vehicles & Environments). The HIVE is responsible for human in the loop testing, getting new technologies in front of astronauts, operators, and users early in the development cycle to make the interfaces more human friendly. Some projects the HIVE is working on includes user interfaces for future spacecraft, wearables to alert astronauts about important information, and test beds to simulate mock missions. During my internship I created a prototype for T-38 aircraft displays using LabVIEW, learned how to use microcontrollers, and helped out with other small tasks in the HIVE. The purpose of developing a prototype for T-38 Displays in LabVIEW is to analyze functions of the display such as navigation in a cost and time effective manner. The LabVIEW prototypes allow Ellington Field AOD to easily make adjustments to the display before hardcoding the final product. LabVIEW was used to create a user interface for simulation almost identical to the real aircraft display. Goals to begin the T-38 PFD (Primary Flight Display) prototype included creating a T-38 PFD hardware display in a software environment, designing navigation for the menu's, incorporating vertical and horizontal navigation bars, and to add a heading bug for compass controls connected to the HSI (Horizontal Situation Indicator). To get started with the project, measurements of the entire display were taken. This enabled an accurate model of the hardware display to be created. Navigation of menu's required some exploration of different buttons on the display. The T-38 simulator and aircraft were used for examining the display. After one piece of the prototype was finished, another trip of to the simulator took place. This was done until all goals for the prototype were complete. Some possible integration ideas for displays in the near future are autopilot selection, touch screen displays, and crew member preferences. Complete navigation, control, and function customization will be achievable once a display is fully developed. Other than the T-38 prototyping, I spent time learning how to design small circuits and write code for them to function. This was done by adding electronic circuit components to breadboard and microcontroller then writing code to speak to those components through the microcontroller. I went through an Arduino starter kit to build circuits and code software that allowed the hardware to act. This work was planned to assist in a lighting project this fall but another solution was discovered for the lighting project. Other tasks that I assisted with, included hands on work such as mock-up construction/removal, logic analyzer repairs, and soldering with circuits. The unique opportunity to be involved work with NASA has significantly changed my educational and career goals. This opportunity has only opened the door to my career with engineering. I have learned over the span of this internship that I am fascinated by the type of work that NASA does. My desire to work in the aerospace industry has increased immensely. I hope to return to NASA to be more involved in the advancement of science, engineering, and spaceflight. My interests for my future education and career lie in NASA’s work - pioneering the future in space exploration, scientific discovery and aeronautics research.

Boniface, Andrew↗

NASA NTRS2017

Image Navigation and Registration Performance Assessment Evaluation Tools for GOES-R ABI and GLM

The GOES-R Flight Project has developed an Image Navigation and Registration (INR) Performance Assessment Tool Set (IPATS) for measuring Advanced Baseline Imager (ABI) and Geostationary Lightning Mapper (GLM) INR performance metrics in the post-launch period for performance evaluation and long term monitoring. IPATS utilizes a modular algorithmic design to allow user selection of data processing sequences optimized for generation of each INR metric. This novel modular approach minimizes duplication of common processing elements, thereby maximizing code efficiency and speed. Fast processing is essential given the large number of sub-image registrations required to generate INR metrics for the many images produced over a 24 hour evaluation period. This paper describes the software design and implementation of IPATS and provides preliminary test results.

Image registration↗

NASA NTRS2017

Image Navigation and Registration Performance Assessment Evaluation Tools for GOES-R ABI and GLM

image registration↗

NASA NTRS2000

Internet Technology on Spacecraft

The Operating Missions as Nodes on the Internet (OMNI) project has shown that Internet technology works in space missions through a demonstration using the UoSAT-12 spacecraft. An Internet Protocol (IP) stack was installed on the orbiting UoSAT-12 spacecraft and tests were run to demonstrate Internet connectivity and measure performance. This also forms the basis for demonstrating subsequent scenarios. This approach provides capabilities heretofore either too expensive or simply not feasible such as reconfiguration on orbit. The OMNI project recognized the need to reduce the risk perceived by mission managers and did this with a multi-phase strategy. In the initial phase, the concepts were implemented in a prototype system that includes space similar components communicating over the TDRS (space network) and the terrestrial Internet. The demonstration system includes a simulated spacecraft with sample instruments. Over 25 demonstrations have been given to mission and project managers, National Aeronautics and Space Administration (NASA), Department of Defense (DoD), contractor technologists and other decisions makers, This initial phase reached a high point with an OMNI demonstration given from a booth at the Johnson Space Center (JSC) Inspection Day 99 exhibition. The proof to mission managers is provided during this second phase with year 2000 accomplishments: testing the use of Internet technologies onboard an actual spacecraft. This was done with a series of tests performed using the UoSAT-12 spacecraft. This spacecraft was reconfigured on orbit at very low cost. The total period between concept and the first tests was only 6 months! On board software was modified to add an IP stack to support basic IP communications. Also added was support for ping, traceroute and network timing protocol (NTP) tests. These tests show that basic Internet functionality can be used onboard spacecraft. The performance of data was measured to show no degradation from current approaches. The cost to implement is much less than current approaches due to the availability of highly reliable and standard Internet tools. Use of standard Internet applications onboard reduces the risk of obsolescence inherent in custom protocols due to extremely wide use across all domains. These basic building blocks provide the framework for building onboard software to support direct user communication with payloads including payload control. Other benefits are payload to payload communication from dissimilar spacecraft, constellations of spacecraft, and reconfigurability on orbit. This work is funded through contract with the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC).

Rash, James↗

NASA NTRS2017

Medical Data Architecture Capabilities and Design

Mission constraints will challenge the delivery of medical care on a long-term, deep space explorationmission. This type of mission will be restricted in the availability of medical knowledge, skills, procedures and resourcesto prevent, diagnose, and treat in-flight medical events. Challenges to providing medical care are anticipated, includingresource and resupply constraints, delayed communications and no ability for medical evacuation. The Medical DataArchitecture (MDA) project will enable medical care capability in this constrained environment.The first version of thesystem, called Test Bed 1, includes capabilities for automated data collection, data storage and data retrieval to provideinformation to the Crew Medical Officer (CMO). Test Bed 1 seeks to establish a data architecture foundation and developa scalable data management system through modular design and standardized interfaces. In addition, it will demonstrateto stakeholders the potential for an improved, automated, flow of data to and from the medical system over the currentmethods employed on the International Space Station (ISS). It integrates a set of external devices, software andprocesses, and a Subjective, Objective, Assessment, and Plan (SOAP) note commonly used by clinicians. Medical datalike electrocardiogram plots, heart rate, skin temperature, respiration rate, medications taken, and more are collectedfrom devices and stored in the Electronic Medical Records (EMR) system, and reported to crew and clinician. Devicesintegrated include the Astroskin biosensor vest and IMED CARDIAX electrocardiogram (ECG) device with INEED MDECG Glove, and the NASA-developed Medical Dose Tracker application.The system is designed to be operated as astandalone system, and can be deployed in a variety of environments, from a laptop to a data center. The system isprimarily composed of open-source software tools, and is designed to be modular, so new capabilities can be added. Thesoftware components and integration methods will be discussed.

Exploration medical system↗

NASA NTRSDate not supplied

Proof Testing Aluminum and Titanium Thin-Walled Tubes for Aerospace Applications

Proof testing aerospace components aids in verifying the structural integrity of flight hardware. This process is often an important step in the certification process for critical parts. Though proof testing is a common practice at NASA and in industry, there is often a need to understand better the effectiveness of proof testing pressure systems discovering cracklike flaws or defects. Often proof tests are used in requirements and in practice as technical rationale for screening critical defects in a part in lieu of performing a non-destructive inspection. The intent of this work is to define proof test failure envelopes for thin-walled tubes composed of two materials: aluminum and titanium. Both materials are common in aerospace thin-walled tubing applications which is why these were the materials chosen for this study. The fracture mechanics software NASGRO was used to perform a parametric study on the effect of defects in thin-walled tubes subjected to proof testing. For both materials, the parameters varied in the NASGRO analyses were aspect ratio, proof test pressure, thickness, diameter, and flaw multiplier. With each case defined as a through crack or failure, the results were then pulled into MATLAB in order to parse through the data and produce failure envelope plots. Failure envelopes were created by meshing a surface in between the minimum proof pressure failing data points. As expected, based on material properties, the plots indicated the aluminum material would fail at much lower proof tests than the titanium. The parametric data and failure envelopes may be used as general qualitative insight on the effectiveness of proof testing thin-walled tubes of similar alloys.

Leah B Davis↗

NASA NTRSDate not supplied

NASA’s Space Launch System Successfully Launches Artemis I Mission and Hardware Progress Continues for Next Artemis Missions

NASA’s Artemis I mission will be the first flight of the agency’s Space Launch System (SLS) rocket. It will launch an uncrewed Orion spacecraft to the Moon, where it will enter a highly elliptical retrograde orbit. In 2022, final tests, checkouts, and preparations were on schedule to be completed, including the vital wet dress rehearsal (WDR) at Kennedy Space Center’s (KSC) Launch Complex 39B. Following successful completion of WDR, which is expected in summer 2022, the Artemis I launch vehicle will be returned to the Vehicle Assembly Building (VAB) at KSC where it will be prepared for launch. Important data were collected during launch and will be shared as applicable. While the Artemis I hardware and mission took center stage in 2022, significant progress was made on hardware and software for future Artemis missions, including for the first crewed launch and the following SLS Block 1B and Block 2 variants of the rocket.

John Honeycutt↗