ICES-2020-576

Gateway PTCS Integrated Thermal Math Model

Jonah R. Smith1 Jacobs Engineering, JSC Engineering Technology and Science (JETS), Houston, TX, 77058

As part of the Integrated Analysis Cycle 4 (IAC4) tasks for NASA’s Gateway Passive Thermal Control Systems (PTCS) team, a simplified thermal model of the Gateway vehicle in its 9:2 Lunar Synodic Resonant Near Rectilinear Halo (NRHO) was developed within the Thermal Desktop environment. This paper details the methodology and assumptions that were used to model Gateway’s heating rate and orbital environments for the purposes of performing thermal analysis for the Gateway program. Discussion includes determining worst-case hot and worst-case cold environments for Gateway, approximating Gateway’s 9:2 NRHO orbit by a Keplerian orbit for purposes of thermal analysis, and the derivations of solar, , and lunar IR heating rates experienced by Gateway.

Nomenclature °C = Degree Celsius K = Kelvin m = Meter W = Watt 휖 = Emissivity 퐼퐿푊 = Longwave (IR) Irradiance 푖 = Solar-Incidence Angle 푆0 = Solar Constant (at ’s surface) 푎̅ = Albedo 휎 = Stefan-Boltzmann Constant 푇 = Surface Temperature θ = True Anomaly 휙 = Orbit Inclination AE = HLS Ascent Element BOL = Beginning of Life DE = HLS Descent Element DSNE = Design Specification for Natural Environments DSXR = Deep Space Exploration Robotics EOL = End of Life ESPRIT = European Structure Providing Infrastructure for Refueling and Telecommunications ETCS = External Thermal Control System GN&C = Guidance Navigation and Control HALO = Habitation and Logistics Outpost HLS = Human Landing System IAC = Integrated Analysis Cycle IHAB = International Habitat IR = Infrared Radiation ITCS = Internal Thermal Control System JSC = Lyndon B. Johnson Space Center

1 Thermal Analysis Engineer, L2 Gateway PTCS Model Development Lead, 2224 Bay Area Blvd./JT-5EA. L2 = Level 2 L3 = Level 3 LM = Logistics Module (a.k.a. Logistics Vehicle) MLI = Multilayer Insulation MMOD = Micro-Meteoroid Orbital Debris MPM = Multipurpose Module Airlock NRHO = Near-Rectilinear Halo Orbit OLR = Outgoing Longwave Radiation (a.k.a. Planetary IR) PPE = Power and Propulsion Element PTCS = Passive Thermal Control Systems RTD = Resistance Temperature Detectors SINDA = Systems Improved Numerical Differencing Analyzer TD = Thermal Desktop TE = HLS Transfer Element USHAB = United States Habitat

I. Introduction HE NASA Gateway Passive Thermal Control Systems HLS T (PTCS) team has created a simplified thermal model of (TE/DE/AE) the Gateway space station in order to provide an accurate HALO radiative thermal environment for use by module, visiting PPE vehicle, and payload developers to evaluate the thermal impacts to their systems when attached to or in proximity of Gateway. The Gateway PTCS Integrated Thermal Math USHAB Model, shown in Figure 1, was developed in Thermal Desktop 6.0 within the AutoCAD 2019 environment. This model was created as part of the Gateway program’s fourth MPM Integrated Analysis Cycle (IAC4), and was distributed to IHAB NASA’s international, commercial, and government partners in November 2019. The NASA Gateway PTCS ESPRIT- LM Refueler team had previously created their first integrated thermal DSXR model of Gateway for IAC3 in February 2019. The IAC4 Figure 1. Gateway PTCS Integrated Thermal version of this model redefines worst-case hot and cold Math Model (IAC4 Configuration 52) orbital heating rate environments, provides new geometry for each module, updates boundary condition assumptions, and introduces a new symbol-driven tool for modelling the different configurations of Gateway. The thermal geometry shown in this document is representative of the best- available geometry provided by NASA’s Gateway program at the beginning of IAC4 (August 2019), and does not reflect the most recent design decisions of the Gateway program.

II. Thermal Model Development and Features

A. Modelling Philosophy and Assumptions The Gateway PTCS Integrated Thermal Math Model is intended to be a simplified model that can be provided to Gateway stakeholders for integration with a detailed thermal model of their own element. The integrated Gateway model provides a radiative environment, accounting for shadowing effects, reflections, and IR heat exchange, and was built with consideration to minimize model complexity. Figure 1 above shows the integrated model when all Gateway elements are present. Thermal geometry is built exclusively with Thermal Desktop primitive thin shell surfaces with reduced nodalization to minimize node count and decrease runtimes. All thermal geometry, except for the Human Landing System (HLS) Ascent Element (AE), was created by the NASA L2 Gateway PTCS team (L2 means “Level 2” and refers to teams responsible for the integrated Gateway stack as opposed to an individual module, which would be L3 or “Level 3” work). The NASA L3 HLS PTCS team out of JSC provided a simplified thermal model of AE for use in the integrated thermal model. Developers of each Gateway module were contacted for optical and thermophysical property references and MLI placement whenever available, but many module developers had not yet determined what their optical properties 2

International Conference on Environmental Systems

would be; in these cases, nominal assumptions were made by L2 Gateway PTCS. Given the lack of certainty in most module’s optical properties at the time, the IAC4 model did not distinguish between BOL and EOL optics. Future versions of the model in IAC5 and beyond include separate BOL and EOL optical property files, though EOL values for many thermal coatings are still being researched given the lack of flight heritage in Gateway’s NRHO environment. A full understanding of the optics and thermophysical properties assumed throughout the model is given in the model’s documentatation1, which was released along with the model to Gateway participants. Heater architecture for most Gateway elements is not yet defined, so in lieu of assuming some number of heaters/RTDs for each module, symbol-controlled boundary nodes are used to define temperatures of pressurized cabin walls. This also aids in reducing runtimes by eliminating the need to take small timesteps for use with heater logic, but comes with the consequence that a conservative hot/cold case temperature for pressurized shells had to be used. All MLI and MMOD shielding (if any exists) over interior cabin walls are left as diffusion nodes (where MLI is assumed arithmetic), typically with an effective emissivity of 0.03. Boundary temperatures on the cabin walls are controlled by 12 different symbols to allow for a high level of control by the model user, or the user can change the symbol “IHEATS” to a value of either 0, 1, or 2 to set cabin wall temperatures to 4 °C, 20 °C, or 27 °C respectively. Cold case analyses should set IHEATS to 0, and hot case analyses should set the symbol IHEATS to 2 to produce a worst-case environment. Radiator temperatures were set as boundary conditions (varying for hot and cold case analysis using the symbol IHEATS again) based on analysis using the minimum and maximum heat loads estimated for each module. Miguel Perez of the L2 Gateway ATCS team performed an analysis using a mock ETCS/ITCS loop sized to reject the expected maximum heat load on the HALO, IHAB, and USHAB modules to define worst-case instantaneous cold and worst- case instantaneous hot radiator temperatures. Body-mounted radiators were discretized, and FloCAD was integrated into a copy of the Gateway PTCS Integrated Thermal Math Model to model the ETCS/ITCS loops, as shown in Figure 2 to the left. Results from this analysis were implemented into the integrated PTCS model by taking the T4 area-weighted Figure 2. HALO Mock ETCS/ITCS Model average temperature of each radiator panel. Unlike the HALO, USHAB, and IHAB modules, the PPE uses a heat pipe radiator system. Operating temperatures for PPE’s radiators were provided by the L3 PPE thermal team.

B. Modelling Different Gateway Configurations Given that the design of each Gateway module is still under development, the Gateway PTCS team decided to model each Gateway element in its own AutoCAD drawing file, and import each element into a master drawing as “external references” using the AutoCAD “XREF” command. This allows for ease of use on the model developer’s end when making changes to individual Gateway elements as the design process continues. This also makes it easy for a thermal analyst working with a detailed thermal model of some Gateway element to replace the simplified representation of that element with their own detailed model. An in-depth step by step instruction guide to importing Thermal Desktop models using XREF was provided to the Gateway thermal community within the model’s documentation1. A typical integrated thermal model like this, like the one used on the ISS program, would have the user disable the building of certain SINDA submodels, and exclude certain radiation analysis groups from radiation conductor/heating rate calculations, in order to model different configurations of the vehicle. Similarly for Gateway, if analysis was being performed on only Gateway’s PPE and HALO modules prior to any other module arriving, then all SINDA submodels referring to other modules could be turned off, and their corresponding radiation analysis groups excluded from radiation calculations. While this is an option within the IAC4 Gateway thermal model to analyze different configurations of the Gateway vehicle, users may also choose to simply unload drawings for those elements which are not present in their analysis by using the XREF Manager.

3

International Conference on Environmental Systems

Figure 3 shows the XREF manager within AutoCAD being used to unload elements from Gateway to create a configuration where the HLS Ascent Element (AE), Descent Element (DE), and Transfer Element (TE) are not present at Gateway. Figure 4 shows IHAB, USHAB, MPM, ESPRIT-Refueler, and the robotic arm Deep Space Exploration Robotics (DSXR) being unloaded such that only Gateway Phase 1 (pre ) elements are present (under the IAC4 assumption that IHAB is not present in Phase 1). In this figure, it can be seen that Orion and the Logistics Module (LM) are now detached from the rest of the vehicle, instead of being docked to HALO as they should be. Rather than have the user shift every module to a different location when modelling the different configurations of Gateway, an articulator was attached to each Gateway module, and a symbol called “CONFIG” is used to move and rotate Figure 3. XREF Manager Used to Unload HLS modules around to model different Gateway configurations. CONFIG is an integer value ranging 1 through 5 that, when combined with XREF’s ability to load/unload individual Gateway elements, allows for the user to model any of the 60 different IAC4 baseline Gateway configurations. This is shown in Figure 5, where CONFIG has been set to a value of 1 to dock Orion to the +x port of HALO and LM to the -y port of HALO (per the coordinate system shown in the same figure). This is accomplished by having symbol-arrays defined for each Gateway module, where the articulators on each module read values for translation and rotation from these arrays based on the current value of CONFIG. The final component necessary to modelling the different configurations of Gateway is attitude control. As will be discussed in Section III, Gateway’s orbit around the Moon is non-Keplerian, which makes the Figure 4. Phase 2 Elements Unloaded Using XREF orbit difficult to implement into Thermal Desktop for calculation of environmental heating rates (solar, albedo, IR). Gateway’s orbit could be defined by a discretized list of vectors pointing to the and moon using GN&C data, but such a list would only describe a single unique attitude. For attitude control using vector-defined trajectories, the documentation for the model recommends creating an articulator at the origin of the model, and attaching all geometry to this articulator, such that yaw, pitch, and roll rotations can be applied using the articulator1. This is burdensome on the user of the model, and may be prone to error if the user forgets to attach new geometry to the articulator before running their model. As such, an attempt was made to model a Keplerian approximation to the worst-case hot and cold single passes of Gateway around the Moon. For these two Keplerian , yaw, pitch, and roll can be controlled from the Orbit Manager within Thermal Figure 5. Symbol CONFIG Changed from 5 to 1 Desktop using three symbols.

4

International Conference on Environmental Systems

III. Heating Rate Environment and Orbit Definition in 9:2 NRHO

A. NRHO Basics and Identifying Worst-Case Hot and Cold Orbits Gateway orbits the Moon in a type of orbit known as a Near Rectilinear Halo Orbit (NRHO). This orbit is heavily influenced by not only the of the Moon and the Sun, but also the gravity of the , such that Gateway’s orbit around the Moon cannot be described as a simple elliptical (Keplerian) orbit. The point in Gateway’s orbit at which it is closest to the Moon is known as perilune (as in periapsis), and the point at which Gateway is furthest from the Moon is known as apolune (as in apoapsis). Perilune and apolune will be defined as being at true anomalies of 0° and 180° respectively. Thinking about NRHO as if it were a Keplerian orbit, then the line between perilune and apolune would be the major axis of the orbit. For simplification, this line will be assumed to be collinear with the Moon’s axis of rotation, though in reality, Gateway’s orbital inclination measured from the (the mean plane of Earth’s orbit around the Sun) experiences small oscillations due to the nature of the orbit. The Moon’s axis of rotation is tilted from the ecliptic by an angle of 1.54°3, and it will be assumed that the average vector pointing from the center of the Moon to the Sun lies within the ecliptic. Gateway’s currently baselined orbit is known as 9:2 Lunar Synodic Resonant NRHO – which is to say that Gateway completes nine revolutions of NRHO over two lunar synodic periods (lunar ), chosen with the intention of avoiding by Earth’s shadow5. Gateway’s 9:2 NRHO is highly-elliptical, such that Gateway spends the vast majority of its orbit far away from the Moon (near apolune) where negligible albedo and OLR heating rates are experienced, making direct solar radiation the primary source of environmental heating incident to Gateway. Gateway’s mission design team from NASA’s Johnson Space Center performed a GN&C simulation of 15 years of Gateway’s orbit around the Moon. Data from this analysis was divided into increments of every 1° of true anomaly and provided to NASA’s L2 Gateway PTCS team. This data included timestamps, altitude, unit vectors (x, y, and z in Gateway’s local coordinate system) pointing to the Moon and the Sun, and the solar beta angle experienced by Gateway at each timestep. Based on the data from this simulation of Gateway in NRHO, the following table was constructed: Table 1. Gateway 9:2 NRHO Variance in Orbital Period, Perilune Altitude, and Apolune Altitude Orbital Period [days] Perilune Altitude [km] Apolune Altitude [km] Minimum 6.26 1,458 68,267 [Hot Case] Mean 6.56 1,629 69,363 Maximum 6.76 1,820 70,112 [Cold Case]

The data from this simulation matches the designed 15 year reference orbit for Gateway outlined in the publicly available white paper on Gateway’s reference trajectory5, assuming a Moon radius of 1737.5 km per NASA JPL’s Lunar Constants and Models Document3. An important point to note is that Gateway module developers were asked to perform thermal analysis down to an altitude of 100 km by the program (a much hotter environment than seen here), whereas Gateway’s minimum altitude flown under nominal operations is only 1,458 km. Module developers should consider their flown trajectories prior to insertion into Gateway’s orbit and any off-nominal/contingency operations when considering what their real design point should be. Given that the L2 Gateway PTCS team has no reference to any version of Gateway’s orbit which experiences an altitude near 100 km at perilune, no such trajectories are provided within the Gateway PTCS Integrated Thermal Math Model. Both worst-case hot and worst-case cold orbital environments for Gateway occur at a solar Beta angle of zero. This would be an orbit such that when Gateway lies within the ecliptic, Gateway would be located along the vector that points from the Sun to the center of the Moon (i.e. Gateway would be located directly over the Moon’s “subsolar” point). In a worst-case hot environment, this maximizes the albedo and OLR heating rates Gateway experiences. In a worst-case cold environment, this maximizes the duration that Gateway spends in from the Moon’s shadow. Due to the nature of Gateway’s orbit, it is possible for Gateway to approach either the sunlit side of the Moon or the shadowed side of the Moon directly after passing perilune. That is to say, at a solar beta angle of 0°, Gateway having a true anomaly of ≈90° will fall within the ecliptic on either the sunlit side of the Moon or shadowed side of the Moon. Eclipse is a far colder environment for Gateway than apolune, and Gateway’s pass around the sunlit side of the Moon is a hotter environment than apolune. As such, a worst-case hot environment for Gateway is an orbit at a solar beta angle of 0° with minimal perilune altitude (causing maximum albedo and OLR heating rates) for which Gateway approaches the sunlit side of the Moon directly after passing apolune (which avoids pre-chilling effects from eclipse). 5

International Conference on Environmental Systems

Conversely, a worst-case cold environment for Gateway is an orbit at a solar beta angle of 0° with maximum perilune altitude (causing maximum eclipse time and minimum albedo and OLR heating rates) for which Gateway approaches eclipse from the Moon’s shadow directly after passing apolune (which avoids pre-heating effects before going into eclipse). Two trajectories were defined within the orbit manager of the Gateway PTCS Integrated Thermal Math Model using the vector data provided by mission design which most closely-aligned to these definitions of worst-case cold and worst-case hot environments.

B. Approximating Gateway’s Orbit as Keplerian When using Thermal Desktop as an analysis software, there are several advantages to defining an orbit as Keplerian rather than as a vector-defined trajectory. Keplerian orbits within Thermal Desktop make it easy for a user to change an orbiting vehicle’s attitude and define which positions in the orbit that heating rate calculations will be performed. Keplerian orbits also have the benefit of giving the user access to a whole host of symbols associated with the orbit from within the Symbol Manager (which have capability to be output to SINDA). These symbols may also be useful when modelling articulating geometry, such as robotic transfer operations or rotations of solar panels. Gateway PTCS’s first-cut at creating a Keplerian approximation to NRHO for purposes of thermal analysis was very successful in modelling the shape of Gateway’s orbit. The idea was to define a polar orbit around the Moon, locked at a solar beta angle of zero, where the shape of the ellipse was defined by specifying the altitude of Gateway at perilune and apolune. For the hot case orbit, the minimum perilune and apolune altitudes experienced by Gateway were used, and for the cold case orbit, the maximum perilune and apolune altitudes experienced by Gateway were used (both per Table 1). As a note, varying the apolune altitude between its maximum and minimum values as reported in Table 1 had little effect on the thermal performance of the orbit, whereas the altitude chosen for perilune has major effects on the most thermally critical portions of the orbit (duration in eclipse, and distance from the hottest parts of the Moon). In order for the idealized orbit to be considered a good approximation to the real orbit for purposes of thermal analysis, it is necessary that the following criteria be met: 1. When in close proximity to the Moon (close enough such that non-negligible OLR and or albedo heat fluxes are experienced), the orbiting vehicle’s altitude as a function of orbit position (true anomaly) should closely match the real orbit. Rationale: The position of the orbiting vehicle around the Moon and the altitude of the vehicle determine the instantaneous OLR and albedo heat loads experienced by the vehicle. For very high altitudes in which the vehicle’s small view-factor to the Moon causes very small OLR and albedo heat fluxes to be experienced, it is not necessary to accurately model these negligible heat loads. 2. When in close proximity to the Moon, the duration of time spent by the orbiting vehicle at each true anomaly should closely match the real orbit. Rationale: The combination of the first criterion and this second criterion results in the time-integrated heat loads from the orbital environment matching between the idealized orbit and the real orbit for any single pass of the vehicle around the Moon. 3. The duration of time spent by the orbiting vehicle eclipsed by the Moon’s shadow should match the real orbit. Rationale: Correctly modelling eclipse duration is critical to the thermal performance of any orbit, given that direct solar heating is often the greatest environmental heat source on most spacecraft. This is called out separately from the second criterion as an orbiting vehicle may experience negligible OLR heating rates at a position corresponding to eclipse, as is the case with Gateway. Because Gateway spends so much time far away from the Moon where negligible OLR and albedo are experienced (roughly 6 ± 0.25 days of its 6.5 ± 0.25 days orbit), it is reasonable to assume that Gateway reaches a quasi-steady state temperature at an apolune-like environment (full view to Sun, negligible view to Moon). For cold cases, Gateway approaching eclipse from this steady state condition, combined with the negligible OLR/albedo heat loads experienced by Gateway prior to reaching eclipse under worst-case cold assumptions, make it such that a worst-case cold model of Gateway needs only to satisfy the third criterion from above. Similarly for hot cases, Gateway approaches the hot (sunlit) side of the Moon after reaching thermal steady state around apolune, making only the first two criteria from above necessary for modelling Gateway’s worst-case hot environment. If Gateway were unable to reach thermal quasi- steady state at apolune before its next pass around perilune, then eclipse duration would affect hot case analysis, and OLR and albedo would affect cold case analysis.

6

International Conference on Environmental Systems

The hot case Keplerian approximation of Gateway’s orbit strongly matched altitude vs. true anomaly to the GN&C data for true anomalies between -120° and +120° (Figure 6), being only 60 km and 70 km off at a true anomaly of -120° and +120° respectively. However, the Keplerian orbit passes over the Moon slightly faster than what the true GN&C data shows (Figure 7), diverging by 6.6 minutes over the course of the 385 minute perilune pass from true anomalies -120° to +120°. For purposes of worst-case hot analysis, the Keplerian orbit having a slightly lower than real altitude can be considered conservative, while the quicker flyby around the Moon under- predicts the time-integrated heat load from OLR and albedo incident to the vehicle. Therefore, a slower flyby around the Moon was desired to better define a worst-case hot orbit for Gateway. Additionally, the Keplerian orbit greatly exaggerated the duration of time spent at/around apolune, Figure 6. Altitude Comparison of Keplerian increasing the orbital period from 6.5 ± 0.25 days to over 7.5 Orbit to 9:2 NRHO days. Based on the criteria above, this increase in total orbital period isn’t actually an issue, since we assume already that Gateway reaches thermal quasi-steady state at the apolune location (deep space, not seeing the Moon). An interesting trick that can be used to change orbital period of a Keplerian orbit without changing the orbit’s shape is to change the gravitational mass of the object being orbited. By reducing the mass of the Moon by 4%, the orbit time taken for the hot case Keplerian orbit to advance from -120° to +120° true anomaly increases to match the GN&C data to within 30 seconds, rather than the 6.6 minute difference seen before. This same method of reducing the Moon’s mass is also considered in the following section as a means to match the longest duration Gateway spends in eclipse for the cold- case Keplerian orbit.

C. Defining Solar Heating Rate and Eclipses Calculating the solar heat flux experienced by Gateway was a fairly simple task using NASA’s cross-program document, the Design Specification for Natural Figure 7. Orbit Time Comparison of Keplerian Orbit to 9:2 NRHO Environments (DSNE)2, which is available online to the public. Based on the distance from the Moon to the Sun, the DSNE document calculates the minimum and maximum 2 solar flux incident to the Moon, 푆0, as 1,315 W/m and 1,421 W/m2 respectively, with a measurement uncertainty of ±5 W/m2. As such, the Gateway PTCS Integrated Thermal Math Model assumes an incident solar heating rate of 1,310 W/m2 when performing worst-case cold analyses, and 1,426 W/m2 when performing worst-case hot analyses. Figure 8 is a diagram showing how conical shadows are produced behind the Moon, under the assumption that the Moon and Sun can be considered to be perfect spheres. Real shadows can be divided into two regions: the umbra, where view to the Sun is completely eclipsed by the Moon, and the penumbra, where view to the Sun is partially eclipsed by the Figure 8. Conical vs. Cylindrical Shadows

7

International Conference on Environmental Systems

Moon (many sources consider the umbra to be part of the penumbra shadow, but for purposes of this discussion, assume they are two distinct regions). Thermal Desktop does not know how to distinguish between the umbra (total eclipse) and penumbra (partial eclipse), so instead, Thermal Desktop assumes a cylindrical shadow is cast by the Moon, in which an orbiting vehicle experiences zero sunlight4. Analysis was performed to answer the following three questions: 1. For the pass of Gateway around the Moon corresponding to the longest duration eclipse experienced, what is the duration Gateway spends in the penumbra and umbra shadows cast by the Moon? 2. How do these durations compare between the real orbit data and that found using a Keplerian approximation of Gateway’s orbit? 3. How does the cylindrical shadowing assumption made by Thermal Desktop compare to the real conical shadows experienced in Gateway’s orbit? GN&C has stated that Gateway’s orbit will be phased as to avoid shadows cast by the Earth5. Developers of Gateway modules and visiting vehicles should consider whether or not they will be shadowed by the Moon or Earth in their transit phase, and design accordingly if this results in a new worst-case cold environment for them. Figure 9, taken from Jared Berg of Glenn Research Center based on NASA Technical Paper 35476, shows the trigonometry used to calculate the shape of the umbra and penumbra shadows cast by the Moon. Given Figure 9. Conical Shadow Geometry that the longest eclipse experienced by Gateway occurs at a solar beta angle of zero, it becomes very easy to calculate if Gateway is in the penumbra or umbra shadows for any combination of altitude and true anomaly. Using the coordinate system defined in Figure 8 (where the +x axis points towards the Sun) and assuming an orbit inclination from the ecliptic of 휙 = 1.54°, the 푍 and 푋 coordinates of Gateway were calculated as a function of true anomaly, θ, and distance between the vehicle and the center of the Moon, 푟(휃). This inclination 휙 is set to match the tilt of the Moon’s axis of rotation from the ecliptic per previous assumptions (where the case when perilune is tilted towards the Sun will increase the duration of eclipse experienced). These Z and X coordinates, calculated at a solar beta angle of zero, are given by the equations: 푍(휃) = [푟(휃)][cos(휃) cos(휙) − sin(휃) sin(휙)] 푋(휃) = [푟(휃)][sin(휃) cos(휙) + cos(휃) sin(휙)] Where for any coordinate pair (푍(휃), 푋(휃)), and considering the angles 훼푝 and 훼푢 as defined in Figure 9, with a Moon radius of 퐷푃, an orbiting vehicle is: In Umbral Shadow if: |푍(휃)| ≤ tan(훼푢) 푋(휃) + 퐷푃, and 휃 > 180° Else: In Penumbral Shadow if: |푍(휃)| ≤ − tan(훼푝) 푋(휃) + 퐷푃, and 휃 > 180° Likewise, it can be determined whether or not the orbiting vehicle lies within the cylindrical shadow of the Moon by the relationship: In Cylindrical Shadow if: |푍(휃)| ≤ 퐷푃, and 휃 > 180° − 휙 The time spent in eclipse is not necessary to be computed for the worst-case hot orbit as Gateway achieves its highest possible temperatures by first reaching thermal quasi-steady state at apolune, and then passing by the sunlit side of the Moon. That is, the greatest temperatures experienced by Gateway occur prior to reaching eclipse. Applying the above methodology to the worst-case hot orbit would be very similar, but care would have to be taken to account for the fact that true anomaly θ is measured in the opposite direction from perilune, and the orbit inclination relative

8

International Conference on Environmental Systems

to the ecliptic 휙 would have to be applied correctly. Carrying out the analysis defined above to determine eclipse durations, the following table was constructed:

Table 2. Worst-Case Eclipse Durations Experienced by Gateway for Varying Orbit Definitions Penumbra Penumbra Umbra (prior to Umbra) (after Umbra) Orbit Definition Shadow Shape TA at Entry [°] Duration [min] TA at Entry [°] TA at Exit [°] Duration [min] TA at Exit [°] Duration [min] GN&C Data Conical 256.26 1.93 256.79 288.51 67.83 289.29 1.01 Keplerian Conical 256.53 1.59 256.96 287.14 69.36 287.84 1.00 Keplerian Cylindrical 256.70 287.60 70.51 Note: The row “GN&C” data in this table refers to the longest eclipse found by Gateway PTCS using the 15 years of reference orbit data provided by GN&C to our team, but GN&C states that the worst-case eclipse that will occur for Gateway in nominal 9:2 NRHO will last 73.2 minutes in umbra, and an additional 2.9 minutes in penumbra based on their current 15 year reference orbit. The baseline requirement for Gateway is that eclipses shall not surpass 90 minutes in duration, which is what L3 module developers are required to design to.

It can be seen in Table 2 that the Keplerian approximation to the reference 9:2 NRHO data provided by GN&C matches eclipse durations very well, and is slightly conservative, having an eclipse duration about 1.5 minutes greater than that experienced from the GN&C vector data (this is an artifact of the worst-case beta angle from the vector data not being the same case which experienced the highest apolune altitude). Looking at both of the rows corresponding to the conical shadow equations, it can be seen that the duration of time spent in penumbral eclipse is significantly less than that spent in umbral eclipse. It can therefore be assumed that it is not necessary to distinctly model penumbral vs. umbral eclipses, and instead, it is sufficient to simply increase the time spent in the umbral eclipse. From this table, we see that the cylindrical shadow assumption made by Thermal Desktop does just that – increasing the umbral eclipse duration experienced in the Keplerian orbit by 1.15 minutes, while removing the 2.59 minutes of penumbral eclipse that is experienced. It is worth addressing the note under Table 2 – the eclipse duration of the Keplerian orbit (and even the GN&C vector data provided to L2 Gateway PTCS) are a few minutes shorter than the maximum possible eclipse duration that could be experienced by Gateway. It would make sense then that when creating a worst-case cold orbit for the Gateway PTCS Integrated Thermal Math Model, the cold-case Keplerian orbit ought to be changed to maximize eclipse duration to extend to the full 73.2 minutes. One method mentioned before, is to change the gravitational mass of the Moon within Thermal Desktop’s orbit manager. Alternatively, eclipse duration could be altered by changing orbit inclination (denoted as 휙 in the equations above), which is likely the cause for the discrepancy. Then again, for purposes of designing to the maximum 90 minute eclipse duration, an analyst may simply choose to reach thermal quasi-steady state with their vehicle at apolune, and then simply turn off environmental heat sources for 90 minutes and analyze the effects.

D. Defining Lunar Albedo Heating Rate Per NASA’s DSNE2 document, albedo varies across the Moon’s surface, having a minimum value of 0.07 and maximum value of 0.20. On the side of the Moon facing the Earth (“near side”), the Moon’s albedo has an average value of 0.12, and on the opposite side (“far side”), the Moon’s albedo has an average value of 0.15. Gateway’s polar orbit is designed to have constant view to Earth – that is, Gateway flies on the line of between the near side and . Given that Gateway orbits the Moon at a high altitude (having line of sight to a large percentage of the Moon’s total surface area at any given time), the L2 Gateway PTCS team opted to use the average values listed for albedo of 0.12 and 0.15 for defining Gateway’s heating rate Figure 10. Albedo Heating Rates vs. Orbit environment. The higher the albedo, the greater the amount True Anomaly of reflected off of the hits the orbiting vehicle. Therefore, when calculating albedo heat fluxes, a value for albedo of 0.15 was assumed for hot case analysis, and a value for albedo of 0.12 was assumed for cold case analysis. When equations for the Moon’s radiance are discussed in the following section, these same assumptions for albedo will not be made in order to remain conservative. 9

International Conference on Environmental Systems

To produce curves of albedo heating rate vs. orbit position for Gateway for the hot case and cold case orbits (at a solar beta angle of zero), a simple Thermal Desktop model was made to capture albedo fluxes over time throughout the two Keplerian approximations to Gateway’s orbit. The model consisted of a flat 1 m2 plane with blackbody optics which was constantly fixed to point towards the Moon, with which a heating rate case was run in RadCAD calculating only heat loads from albedo. Results for the hot and cold cases are shown above in Figure 10. Given the Moon’s very low solar reflectivity, and Gateway’s very high altitude orbit, albedo heating rates are considerably smaller than other forms of environmental heating.

E. Defining Lunar OLR Heating Rate Outgoing Longwave Radiation (OLR), a.k.a. “planetary IR”, is more difficult to calculate than the other two forms of environmental heating due to the Moon having a varying temperature across its surface. The Moon is a slow- rotating, highly solar absorptive, atmosphere-less, near-perfect spherical body, whose thermal diffusivity is small enough such that the temperature of the Moon is dominated by the effects of radiation heat transfer2. According to the DSNE, the temperature of the Moon can be represented then by a Lambertian reflectance model at any point on the sunlit side of the Moon’s surface based on the solar-incidence angle at that location, following the equation2:

4 퐼퐿푊,푠푢푛푠𝑖푑푒 = 휖푀표표푛휎푇푆푢푟푓푎푐푒,푠푢푛푠𝑖푑푒 = (1 − 푎̅)푆0 cos(푖) (1)

Equation (1) simply states that the radiance of the Moon in the IR spectrum (퐼퐿푊) is equal to the amount of incident solar flux absorbed at the Moon’s surface at any given point. This is based on the assumed solar constant (푆0) as defined before, albedo (푎̅), and angle between the surface normal and solar vector (푖). Converse to the assumption made for calculating albedo heat fluxes, when calculating OLR heat fluxes, assuming a low value for albedo results in a worst-case hot environment. Therefore, L2 Gateway PTCS chose to assume an albedo of 0.12 for hot case and 0.15 for cold case analyses when defining lunar radiance. Note that this equation creates a discontinuity as solar-incidence angle (푖) approaches 90°, at which point this equation would set the Moon’s absolute surface temperature to a value of zero. To correct for this, L2 Gateway PTCS chose to fix the amplitude and y-intercept of the cosine wave to meet the radiance of the “nightside” of the Moon (side which does not see sunlight) at a solar-incidence angle of 90° using the following equation:

4 퐼퐿푊,푠푢푛푠𝑖푑푒 = 휖푀표표푛휎푇푆푢푟푓푎푐푒,푠푢푛푠𝑖푑푒 = [(1 − 푎̅)푆0 − 퐼퐿푊,푛𝑖푔ℎ푡푠𝑖푑푒] cos(푖) + 퐼퐿푊,푛𝑖푔ℎ푡푠𝑖푑푒 (2)

To use this model, the temperature of the nightside of the Moon (푇푆푢푟푓푎푐푒,푛𝑖푔ℎ푡푠𝑖푑푒) is considered to be a single temperature, which the DSNE states varies between 100 ± 20 K. A value of 80 K is used for worst-case cold analysis, and 120 K is used for worst-case hot analysis2. Radiance on the nightside then can be computed knowing the Moon’s IR emissivity, which, based on DSNE data, is assumed to be 0.95 for cold analyses and 0.98 for hot analyses. Following this logic, the nightside radiance can be calculated with the following equation:

4 퐼퐿푊,푛𝑖푔ℎ푡푠𝑖푑푒 = 휖푀표표푛휎푇푆푢푟푓푎푐푒,푛𝑖푔ℎ푡푠𝑖푑푒 (3)

It is important that thermal models of satellites orbiting the Moon account for the gradient of temperature across the Moon’s surface that can be seen by the satellite at any point in its orbit. A common mistake is to specify the flux emitted at the Moon’s surface as a function of an orbiting vehicle’s true anomaly and solar beta angle within Thermal Desktop’s expression editor using the equations above for the Moon’s radiance or temperature, as shown below in Figure 11. This would be done by writing Equation (2) directly into the expression editor, taking the value for cos(푖) to be the dot product between the satellite-Moon vector and Moon-Sun vector. Although this may seem like a reasonable approach, doing so only solves Equation (2) at the location on the Moon’s surface directly nadir to the orbiting vehicle, and does not account for the varying radiance across the Moon with non-zero view-factor to the vehicle. This causes OLR heat loads to be calculated higher than they should be when directly over the subsolar region, and lower than they should be when over the boundary between the sunlit side and nightside of the Moon. The most readily-available way to calculate the incident OLR flux on some satellite orbiting the Moon is to use 4 Monte Carlo ray tracing to perform numerical integration of the view-factor weighted (푇푆푢푟푓푎푐푒) average seen by the orbiting vehicle. Simply put, OLR heating rates should be calculated using a model of the Moon with variable temperature across its surface. Thermal Desktop natively provides the capability to discretize the temperature or 10

International Conference on Environmental Systems

radiance of a planetary body being orbited, which leads to the question of what level of discretization is required to achieve convergence in OLR heating rates experienced. Interestingly, this problem has two opposing effects which counteract each other to negate the need to model the Moon to a high-level of fidelity. As the altitude of an orbiting vehicle increases further and further, it is able to see a broader-range of lunar surface temperatures, increasing the need to discretize the Moon. Simultaneously, increasing altitude reduces the total view-factor of the satellite to the Moon, reducing the total OLR heat load incident to the surface, eventually making OLR negligible to the thermal balance on the orbiting vehicle. To test the effects of discretization of the Moon’s surface temperature on its performance within a thermal model, and to understand the amount of incident OLR flux that would impinge on the Gateway vehicle when in its worst-case hot orbit, a simple thermal model was made within Thermal Desktop and ran through a parametric analysis varying the level of discretization of the Moon’s surface temperature. This was the same thermal model used to calculate albedo Figure 11. Incorrect Use of TD Expression Editor to Define Lunar OLR heat loads incident to Gateway in Figure 10 from before, but this time, only OLR heat loads were calculated. This model can be seen to the left in Figure 12, where the Moon’s radiance has been discretized every 0.5° of solar-incidence angle. From visual inspection, it appears that fairly large areas of the Moon’s surface could be considered to have a uniform temperature, and indeed, it takes only a small level of discretization to converge OLR heat load results incident to Gateway. The graph below in Figure 13 compare heat load incident to Gateway when discretizing the Moon every 0.5°, 5°, and 30° of solar-incidence angle. Figure 13. Discretized Moon Radiance in Gateway’s Worst-Case Hot Orbit As a note to any Thermal Desktop user attempting to replicate this definition for lunar OLR in their own models, it is highly recommended that the “ Coordinate System” chosen in Thermal Desktop be set to a “Subsolar Coordinate System” for / whose temperature is defined as a function of solar-incidence angle on its surface, rather than as a function of geographic features (see the two different radio buttons in Figure 11). The “Planet Coordinate System” uses more memory to achieve the same level of discretization, because the Subsolar Coordinate System needs only to model temperature/radiance as a function of latitude, Figure 12. Discretization of Moon Radiance vs. without consideration to longitude (again, this is only the OLR Incident to Gateway per True Anomaly in case for planets/moons whose temperature is a function of Worst-Case Hot Orbit solar-incidence angle). That is to say, there are fewer Discretizing every 0.5° (red) vs. every 5° (purple) are “points” where temperature is defined across the surface nearly the same, diverging at most by 0.45%. to be interpolated between, helping to calculate heating Discretizing every 30° (blue) diverges at most 2.73% rates slightly quicker. More importantly, when an orbital from the 0.5° discretization. heating rate environment in Thermal Desktop is created 11

International Conference on Environmental Systems

as a vector-defined trajectory rather than as a Keplerian orbit, using the Planet Coordinate System will regularly yield incorrect results, as Thermal Desktop has no understanding of what the vehicle’s attitude should be at any given point. Using the Subsolar Coordinate System fixes the error of Thermal Desktop incorrectly calculating the latitude and longitude over which the orbiting vehicle is located.

IV. Conclusion This paper discussed the creation of an integrated thermal math model of Gateway by the NASA L2 Gateway PTCS team, and the work that has been done to define a worst-case cold and worst-case hot environment for the Gateway vehicle in its 9:2 NRHO. The Gateway PTCS Integrated Thermal Math Model was designed to be reconfigurable to model the 60 different IAC4 baseline Gateway configurations and allow for users to replace simplified geometry of their element with their own detailed thermal models. This enables module, payload, and visiting vehicle developers to perform thermal analysis on their elements when docked to or in close proximity of Gateway, capturing the effects of the natural and induced thermal environments on the Gateway vehicle. This paper examined in detail a Keplerian approximation to the worst-case hot and cold single-passes of the Gateway vehicle around the Moon. It was found that for Gateway’s orbit, the cylindrical shadow approximation made by Thermal Desktop very strongly approximates the true shadowing experienced by the vehicle in its worst-case cold orbit. It was also found that the Keplerian representation of the worst-case hot and cold orbits performed well at matching altitude vs. true anomaly and true anomaly vs. orbit time to the provided GN&C data. An analysis was performed to determine the level of discretization of the Moon’s radiance necessary to capture the effects OLR heating rates incident to Gateway, and showed that little discretization had to be given to the Moon for heating rates to converge. Additionally, the ability to change the orbital period in Keplerian approximations to Gateway’s orbit in order to exaggerate shadowing and heating effects by reduction of the Moon’s mass within the model was discussed. Although much forward work exists for the L2 Gateway PTCS team in future integrated analysis cycles, the foundation for creating a modular thermal model has been put in place with the work of IAC4. Additionally, the definitions for Gateway’s orbit for purposes of thermal analysis have been cemented, and will not need to be revisited until new revisions to the DSNE are created, or a change in Gateway’s orbit is baselined.

Acknowledgments Thanks to Diane Davis of mission design for providing orbital data and guidance to the L2 Gateway PTCS team. Thanks to Miguel Perez of L2 Gateway ATCS for analysis of radiator temperatures, and aid in testing/debugging of the integrated thermal math model. Thanks to Lourdes Ibrahim of L2 Gateway PTCS for assistance in obtaining thermophysical and optical property data from module developers. Thanks to Abigail Zinecker of L2 Gateway PTCS for aid in defining eclipse durations for the Keplerian approximations to NRHO, and calculations of penumbral vs. umbral eclipse durations. Thanks to Lauren Foley and Andrew Hong of JSC’s EC branch for their assessments at the beginning of IAC4 which showed capability for NRHO to be modelled as a Keplerian orbit for purposes of thermal analysis. Finally, thanks to Dr. Laurie Carrillo, Subsystem Manager of L2 Gateway PTCS, for her support and guidance to the team.

References 1Smith, J. R., “Gateway Passive Thermal Guidelines and Model Utilization – IAC4,” NASA SEI-DM-MAN-001-4, Oct. 28, 2019. 2“Cross-Program Specification for Natural Environments (DSNE),” NASA SLS-SPEC-159 Rev. G, Dec. 11, 2019. 3Roncoli, R. B., “Lunar Constants and Models Document,” NASA JPL D-32296, Sep. 23, 2005. 4“Thermal Desktop Manual Version 6.0,” C&R Technologies, May 17, 2017. 5Lee, D. E., “White Paper: Gateway Destination Orbit Model: A Continuous 15 Year NRHO Reference Trajectory,” NASA JSC-E-DAA-TN72594, Aug. 20, 2019. 6Ortiz Longo, C. R., Rickman, S. L., “Method for the Calculation of Spacecraft Umbra and Penumbra Shadow Points,” NASA-TP-3547, Apr. 1, 1995.

12

International Conference on Environmental Systems