Search NASA⌕ Search

SEARCH · Search NASA

Results for “software development kit”

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.

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

At least 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

Marshall Space Flight Center Telescience Resource Kit

Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.

Wade, Gina↗
NASA NTRS1997

NURBS-Based Geometry for Integrated Structural Analysis

This grant was initiated in April 1993 and completed in September 1996. The primary goal of the project was to exploit the emerging defacto CAD standard of Non- Uniform Rational B-spline (NURBS) based curve and surface geometry to integrate and streamline the process of turbomachinery structural analysis. We focused our efforts on critical geometric modeling challenges typically posed by the requirements of structural analysts. We developed a suite of software tools that facilitate pre- and post-processing of NURBS-based turbomachinery blade models for finite element structural analyses. We also developed tools to facilitate the modeling of blades in their manufactured (or cold) state based on nominal operating shape and conditions. All of the software developed in the course of this research is written in the C++ language using the Iris Inventor 3D graphical interface tool-kit from Silicon Graphics. In addition to enhanced modularity, improved maintainability, and efficient prototype development, this design facilitates the re-use of code developed for other NASA projects and provides a uniform and professional 'look and feel' for all applications developed by the Iowa State Team.

Oliver, James H.↗
NASA NTRS1997

The Application of New Software Technology to the Architecture of the National Cycle Program

As part of the Numerical Propulsion System Simulation (NPSS) effort of NASA Lewis in conjunction with the United States aeropropulsion industry, a new system simulation framework, the National Cycle Program (NCP), capable of combining existing empirical engine models with new detailed component-based computational models is being developed. The software architecture of the NCP program involves a generalized object- oriented framework and a base-set of engine component models along with supporting tool kits which will support engine simulation in a distributed environment. As the models are extended to contain two and three dimensions the computing load increases rapidly and it is intended that this load be distributed across multiple work stations executing concurrently in order to get acceptably fast results. The research carried out was directed toward performance analysis of the distributed object system. More specifically, the performance of the actor-based distributed object design I created earlier was desired. To this end, the research was directed toward the design and implementation of suitable performance-analysis techniques and software to demonstrate those techniques. There were three specific results which are reported in two separate reports submitted separately as NASA Technical Memoranda. The results are: (1) Design, implementation, and testing of a performance analysis program for a set of active objects (actor based objects) which allowed the individual actors to be assigned to arbitrary processes on an arbitrary set of machines. (2) The global-balance-equation approach has the fundamental limitation that the number of equations increases exponentially with the number of actors. Hence, unlike many approximate approaches to this problem, the nearest-neighbor approach allows checking of the solution and an estimate of the error. The technique was demonstrated in a prototype analysis program as part of this research. The results of the program were checked against the global-balance solution discussed above. Late during the grant, a much better approximation was developed and this is discussed in result below. As a consequence, a proposal was submitted to continue the research by developing the new approximation including development of a complete program from the prototype. (3) The source of approximation in the nearest-neighbor algorithm is the requirement for estimating some joint probabilities from some marginal distributions. A completely ad hoc estimate was used in the prototype.

Schoeffler, James D.↗
NASA NTRS2010

Modeling and Simulation of an UAS Collision Avoidance Systems

This paper describes a Modeling and Simulation of an Unmanned Aircraft Systems (UAS) Collision Avoidance System, capable of representing different types of scenarios for UAS collision avoidance. Commercial and military piloted aircraft currently utilize various systems for collision avoidance such as Traffic Alert and Collision A voidance System (TCAS), Automatic Dependent Surveillance-Broadcast (ADS-B), Radar and ElectroOptical and Infrared Sensors (EO-IR). The integration of information from these systems is done by the pilot in the aircraft to determine the best course of action. In order to operate optimally in the National Airspace System (NAS) UAS have to work in a similar or equivalent manner to a piloted aircraft by applying the principle of "detect-see and avoid" (DSA) to other air traffic. Hence, we have taken these existing sensor technologies into consideration in order to meet the challenge of researching the modeling and simulation of an approximated DSA system. A Schematic Model for a UAS Collision Avoidance System (CAS) has been developed ina closed loop block diagram for that purpose. We have found that the most suitable software to carry out this task is the Satellite Tool Kit (STK) from Analytical Graphics Inc. (AGI). We have used the Aircraft Mission Modeler (AMM) for modeling and simulation of a scenario where a UAS is placed on a possible collision path with an initial intruder and then with a second intruder, but is able to avoid them by executing a right tum maneuver and then climbing. Radars have also been modeled with specific characteristics for the UAS and both intruders. The software provides analytical, graphical user interfaces and data controlling tools which allow the operator to simulate different conditions. Extensive simulations have been carried out which returned excellent results.

Oliveros, Edgardo V.↗
NASA NTRS2018

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for users to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS "App Store".. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

Computer Programming and Software↗
NASA NTRS2015

Attitude Design for the LADEE Mission

The Lunar Atmosphere and Dust Environment Explorer (LADEE) satellite successfully completed its 148-day science investigation in a low-altitude, near-equatorial lunar orbit on April 18, 2014. The LADEE spacecraft was built, managed and operated by NASA's Ames Research Center (ARC). The Mission Operations Center (MOC) was located at Ames and was responsible for activity planning, command sequencing, trajectory and attitude design, orbit determination, and spacecraft operations. The Science Operations Center (SOC) was located at Goddard Space Flight Center and was responsible for science planning, data archiving and distribution. This paper details attitude design and operations support for the LADEE mission. LADEE's attitude design was shaped by a wide range of instrument pointing requirements that necessitated regular excursions from the baseline one revolution per orbit "Ram" attitude. Such attitude excursions were constrained by a number of flight rules levied to protect instruments from the Sun, avoid geometries that would result in simultaneous occlusion of LADEE's two star tracker heads, and maintain the spacecraft within its thermal and power operating limits. To satisfy LADEE's many attitude requirements and constraints, a set of rules and conventions was adopted to manage the complexity of this design challenge and facilitate the automation of ground software that generated pointing commands spanning multiple days of operations at a time. The resulting LADEE Flight Dynamics System (FDS) that was developed used Visual Basic scripts that generated instructions to AGI's Satellite Tool Kit (STK) in order to derive quaternion commands at regular intervals that satisfied LADEE's pointing requirements. These scripts relied heavily on the powerful "align and constrain" capability of STK's attitude module to construct LADEE's attitude profiles and the slews to get there. A description of the scripts and the attitude modeling they embodied is provided. One particular challenge analysts faced was in the design of LADEE maneuver attitudes. A flight rule requiring pre-maneuver verification of in-flight maneuver conditions by ground operators prior to burn execution resulted in the need to accommodate long periods in the maneuver attitude. This in turn complicated efforts to satisfy star tracker interference and communication constraints in lunar orbit. In response to this challenge, a graphical method was developed and used to survey candidate rotation angles about the thrust vector. This survey method is described and an example of its use on a particular LADEE maneuver is discussed. Finally, the software and methodology used to satisfy LADEE's attitude requirements are also discussed in the context of LADEE's overall activity planning effort. In particular, the way in which strategic schedules of instrument and engineering activities were translated into actual attitude profiles at the tactical level, then converted into precise quaternion commands to achieve those pointing goals is explained. In order to reduce the risk of time-consuming re-planning efforts, this process included the generation of long-term projections of constraint violation predictions for individual attitude profiles that could be used to establish keep-out time-frames for particular attitude profiles. The challenges experienced and overall efficacy of both the overall LADEE ground system and the attitude components of the Flight Dynamics System in meeting LADEE's varied pointing requirements are discussed.

LADEE↗
NASA NTRS1993

An Interactive Tool for Discrete Phase Analysis in Two-Phase Flows

Under a NASA MSFC SBIR Phase 1 effort an interactive software package has been developed for the analysis of discrete (particulate) phase dynamics in two-phase flows in which the discrete phase does not significantly affect the continuous phase. This package contains a Graphical User Interface (based on the X Window system and the Motif tool kit) coupled to a particle tracing program, which allows the user to interactively set up and run a case for which a continuous phase grid and flow field are available. The software has been applied to a solid rocket motor problem, to demonstrate its ease of use and its suitability for problems of engineering interest, and has been delivered to NASA Marshall Space Flight Center.

Dejong, Frederik J.↗
NASA NTRS2011

Mars Science Laboratory Flight Software Internal Testing

The Mars Science Laboratory (MSL) team is sending the rover, Curiosity, to Mars, and therefore is physically and technically complex. During my stay, I have assisted the MSL Flight Software (FSW) team in implementing functional test scripts to ensure that the FSW performs to the best of its abilities. There are a large number of FSW requirements that have been written up for implementation; however I have only been assigned a few sections of these requirements. There are many stages within testing; one of the early stages is FSW Internal Testing (FIT). The FIT team can accomplish this with simulation software and the MSL Test Automation Kit (MTAK). MTAK has the ability to integrate with the Software Simulation Equipment (SSE) and the Mission Processing and Control System (MPCS) software which makes it a powerful tool within the MSL FSW development process. The MSL team must ensure that the rover accomplishes all stages of the mission successfully. Due to the natural complexity of this project there is a strong emphasis on testing, as failure is not an option. The entire mission could be jeopardized if something is overlooked.

entry, descent, and landing (EDL)↗
NASA NTRS2002

Integrated Global Positioning Systems (GPS) Laboratory

The purpose of this research is to develop a user-friendly Integrated GPS lab manual. This manual will help range engineers at NASA to integrate the use of GPS Simulators, GPS receivers, computers, MATLAB software, FUGAWI software and SATELLITE TOOL KIT software. The lab manual will be used in an effort to help NASA engineers predict GPS Coverage of planned operations and analyze GPS coverage of operation post mission. The Integrated GPS Laboratory was used to do GPS Coverage for two extensive case studies. The first scenario was an airplane trajectory in which an aircraft flew from Cape Canaveral to Los Angeles, California. In the second scenario, a rocket trajectory was done whereas a rocket was launched from Cape Canaveral to one thousand kilometers due east in the Atlantic Ocean.

Brown, Dewayne Randolph↗
NASA NTRS2016

Squat Biomechanical Modeling Results from Exercising on the Hybrid Ultimate Lifting Kit

Long duration space travel will expose astronauts to extended periods of reduced gravity. Since gravity is not present to aid loading, astronauts will use resistive and aerobic exercise regimes for the duration of the space flight to minimize loss of bone density, muscle mass and aerobic capacity that occurs during exposure to a reduced gravity environment. Unlike the International Space Station (ISS), the area available for an exercise device in the next generation of spacecraft is limited and therefore compact resistance exercise device prototypes are being developed. The Advanced Resistive Exercise Device (ARED) currently on the ISS is being used as a benchmark for the functional performance of these new devices. Biomechanical data collection and computational modeling aid the device design process by quantifying the joint torques and the musculoskeletal forces that occur during exercises performed on the prototype devices. The computational models currently under development utilize the OpenSim software, an open source code for musculoskeletal modeling, with biomechanical input data from test subjects for estimation of muscle and joint loads. The subjects are instrumented with reflective markers for motion capture data collection while exercising on the Hybrid Ultimate Lifting Kit (HULK) prototype device. Ground reaction force data is collected with force plates under the feet and device loading is recorded through load cells internal to the HULK. Test variables include applied device load, narrow or wide foot stance, slow or fast cadence and the harness or long bar interface between the test subject and the device. Data is also obtained using free weights for a comparison to the resistively loaded exercise device. This data is input into the OpenSim biomechanical model, which has been scaled to match the anthropometrics of the test subject, to calculate the body loads. The focus of this presentation is to summarize the results from the full squat exercises across the different test variables.

Bioengineering↗
NASA NTRS2010

Tool for Forecasting Cool-Season Peak Winds Across Kennedy Space Center and Cape Canaveral Air Force Station

The expected peak wind speed for the day is an important element in the daily morning forecast for ground and space launch operations at Kennedy Space Center (KSC) and Cape Canaveral Air Force Station (CCAFS). The 45th Weather Squadron (45 WS) must issue forecast advisories for KSC/CCAFS when they expect peak gusts for >= 25, >= 35, and >= 50 kt thresholds at any level from the surface to 300 ft. In Phase I of this task, the 45 WS tasked the Applied Meteorology Unit (AMU) to develop a cool-season (October - April) tool to help forecast the non-convective peak wind from the surface to 300 ft at KSC/CCAFS. During the warm season, these wind speeds are rarely exceeded except during convective winds or under the influence of tropical cyclones, for which other techniques are already in use. The tool used single and multiple linear regression equations to predict the peak wind from the morning sounding. The forecaster manually entered several observed sounding parameters into a Microsoft Excel graphical user interface (GUI), and then the tool displayed the forecast peak wind speed, average wind speed at the time of the peak wind, the timing of the peak wind and the probability the peak wind will meet or exceed 35, 50 and 60 kt. The 45 WS customers later dropped the requirement for >= 60 kt wind warnings. During Phase II of this task, the AMU expanded the period of record (POR) by six years to increase the number of observations used to create the forecast equations. A large number of possible predictors were evaluated from archived soundings, including inversion depth and strength, low-level wind shear, mixing height, temperature lapse rate and winds from the surface to 3000 ft. Each day in the POR was stratified in a number of ways, such as by low-level wind direction, synoptic weather pattern, precipitation and Bulk Richardson number. The most accurate Phase II equations were then selected for an independent verification. The Phase I and II forecast methods were compared using an independent verification data set. The two methods were compared to climatology, wind warnings and advisories issued by the 45 WS, and North American Mesoscale (NAM) model (MesoNAM) forecast winds. The performance of the Phase I and II methods were similar with respect to mean absolute error. Since the Phase I data were not stratified by precipitation, this method's peak wind forecasts had a large negative bias on days with precipitation and a small positive bias on days with no precipitation. Overall, the climatology methods performed the worst while the MesoNAM performed the best. Since the MesoNAM winds were the most accurate in the comparison, the final version of the tool was based on the MesoNAM winds. The probability the peak wind will meet or exceed the warning thresholds were based on the one standard deviation error bars from the linear regression. For example, the linear regression might forecast the most likely peak speed to be 35 kt and the error bars used to calculate that the probability of >= 25 kt = 76%, the probability of >= 35 kt = 50%, and the probability of >= 50 kt = 19%. The authors have not seen this application of linear regression error bars in any other meteorological applications. Although probability forecast tools should usually be developed with logistic regression, this technique could be easily generalized to any linear regression forecast tool to estimate the probability of exceeding any desired threshold . This could be useful for previously developed linear regression forecast tools or new forecast applications where statistical analysis software to perform logistic regression is not available. The tool was delivered in two formats - a Microsoft Excel GUI and a Tool Command Language/Tool Kit (Tcl/Tk) GUI in the Meteorological Interactive Data Display System (MIDDS). The Microsoft Excel GUI reads a MesoNAM text file containing hourly forecasts from 0 to 84 hours, from one model run (00 or 12 UTC). The GUI then displays e peak wind speed, average wind speed, and the probability the peak wind will meet or exceed the 25-, 35- and 50-kt thresholds. The user can display the Day-1 through Day-3 peak wind forecasts, and separate forecasts are made for precipitation and non-precipitation days. The MIDDS GUI uses data from the NAM and Global Forecast System (GFS), instead of the MesoNAM. It can display Day-1 and Day-2 forecasts using NAM data, and Day-1 through Day-5 forecasts using GFS data. The timing of the peak wind is not displayed, since the independent verification showed that none of the forecast methods performed significantly better than climatology. The forecaster should use the climatological timing of the peak wind (2248 UTC) as a first guess and then adjust it based on the movement of weather features.

Barrett, Joe H., III↗
NASA NTRS1990

Resource Allocation Planning Helper (RALPH): Lessons learned

The current task of Resource Allocation Process includes the planning and apportionment of JPL's Ground Data System composed of the Deep Space Network and Mission Control and Computing Center facilities. The addition of the data driven, rule based planning system, RALPH, has expanded the planning horizon from 8 weeks to 10 years and has resulted in large labor savings. Use of the system has also resulted in important improvements in science return through enhanced resource utilization. In addition, RALPH has been instrumental in supporting rapid turn around for an increased volume of special what if studies. The status of RALPH is briefly reviewed and important lessons learned from the creation of an highly functional design team are focused on through an evolutionary design and implementation period in which an AI shell was selected, prototyped, and ultimately abandoned, and through the fundamental changes to the very process that spawned the tool kit. Principal topics include proper integration of software tools within the planning environment, transition from prototype to delivered to delivered software, changes in the planning methodology as a result of evolving software capabilities and creation of the ability to develop and process generic requirements to allow planning flexibility.

Durham, Ralph↗
NASA NTRS2014

Validation of Solar Sail Simulations for the NASA Solar Sail Demonstration Project

NASA's Solar Sail Demonstration project partner L'Garde is currently assembling a flight-like sail assembly for a series of ground demonstration tests beginning in 2015. For future missions of this sail that might validate solar sail technology, it is necessary to have an accurate sail thrust model. One of the primary requirements of a proposed potential technology validation mission will be to demonstrate solar sail thrust over a set time period, which for this project is nominally 30 days. This requirement would be met by comparing a L'Garde-developed trajectory simulation to the as-flown trajectory. The current sail simulation baseline for L'Garde is a Systems Tool Kit (STK) plug-in that includes a custom-designed model of the L'Garde sail. The STK simulation has been verified for a flat plate model by comparing it to the NASA-developed Solar Sail Spaceflight Simulation Software (S5). S5 matched STK with a high degree of accuracy and the results of the validation indicate that the L'Garde STK model is accurate enough to meet the potential future mission requirements. Additionally, since the L'Garde sail deviates considerably from a flat plate, a force model for a non-flat sail provided by L'Garde sail was also tested and compared to a flat plate model in S5. This result will be used in the future as a basis of comparison to the non-flat sail model being developed for STK.

Braafladt, Alexander C.↗
NASA NTRS2011

Design and Implementation of a Mechanical Control System for the Scanning Microwave Limb Sounder

The Scanning Microwave Limb Sounder (SMLS) will use technological improvements in low noise mixers to provide precise data on the Earth's atmospheric composition with high spatial resolution. This project focuses on the design and implementation of a real time control system needed for airborne engineering tests of the SMLS. The system must coordinate the actuation of optical components using four motors with encoder readback, while collecting synchronized telemetric data from a GPS receiver and 3-axis gyrometric system. A graphical user interface for testing the control system was also designed using Python. Although the system could have been implemented with a FPGA-based setup, we chose to use a low cost processor development kit manufactured by XMOS. The XMOS architecture allows parallel execution of multiple tasks on separate threads-making it ideal for this application and is easily programmed using XC (a subset of C). The necessary communication interfaces were implemented in software, including Ethernet, with significant cost and time reduction compared to an FPGA-based approach. For these reasons, the XMOS technology is an attractive, cost effective, alternative to FPGA-based technologies for this design and similar rapid prototyping projects.

Mars Science Laboratory Robotics↗
NASA NTRSDate not supplied

Space Station Operations Capabilities in a Shoebox: Marshall Space Flight Center’s Telescience Resource Kit

The International Space Station (ISS) has provided the world an unprecedented capability, establishing a continuous human foothold in outer space for more than 22 years now. But maintaining that capability and supporting the ambitious portfolio of scientific research it hosts has required another unprecedented capability – providing groundbased operations support for the crew and a diverse manifest of research payloads, all simultaneously. To help meet this challenge, NASA’s Marshall Space Flight Center (MSFC) developed TReK, the Telescience Resource Kit, providing a robust solution for data, command, metadata, and file transfer capabilities. In response to an increasingly wide and diverse need for operations support resources, the TReK team has worked to find ways to make the software more flexible in order to support a wide range of missions. Today it has supported not only hundreds of ISS payloads, but also free-flying spacecraft and even aircraft-based research. This presentation will discuss how the team has modified capabilities needed to enable 24/7/365 research aboard ISS to provide the flexibility needed to support Small Sat missions, going back to one of MSFC’s first “minisatellite” missions in 2010 and beyond.

Jeff Lippincott↗
NASA NTRSDate not supplied

Space Station Operations Capabilities in a Shoebox Marshall Space Flight Center’s Telescience Resource Kit

The International Space Station (ISS) has provided the world an unprecedented capability, establishing a continuous human foothold in outer space for more than 22 years now. But maintaining that capability and supporting the ambitious portfolio of scientific research it hosts has required another unprecedented capability – providing groundbased operations support for the crew and a diverse manifest of research payloads, all simultaneously. To help meet this challenge, NASA’s Marshall Space Flight Center (MSFC) developed TReK, the Telescience Resource Kit, providing a robust solution for data, command, metadata, and file transfer capabilities. In response to an increasingly wide and diverse need for operations support resources, the TReK team has worked to find ways to make the software more flexible in order to support a wide range of missions. Today it has supported not only hundreds of ISS payloads, but also free-flying spacecraft and even aircraft-based research. This presentation will discuss how the team has modified capabilities needed to enable 24/7/365 research aboard ISS to provide the flexibility needed to support Small Sat missions, going back to one of MSFC’s first “minisatellite” missions in 2010 and beyond.

Jeff Lippincott↗
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↗