Search NASA⌕ Search

SEARCH · Search NASA

Results for “Team software development”

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 541 records · Page 30

Software Quality Assurance Metrics

Software Quality Assurance (SQA) is a planned and systematic set of activities that ensures conformance of software life cycle processes and products conform to requirements, standards and procedures. In software development, software quality means meeting requirements and a degree of excellence and refinement of a project or product. Software Quality is a set of attributes of a software product by which its quality is described and evaluated. The set of attributes includes functionality, reliability, usability, efficiency, maintainability, and portability. Software Metrics help us understand the technical process that is used to develop a product. The process is measured to improve it and the product is measured to increase quality throughout the life cycle of software. Software Metrics are measurements of the quality of software. Software is measured to indicate the quality of the product, to assess the productivity of the people who produce the product, to assess the benefits derived from new software engineering methods and tools, to form a baseline for estimation, and to help justify requests for new tools or additional training. Any part of the software development can be measured. If Software Metrics are implemented in software development, it can save time, money, and allow the organization to identify the caused of defects which have the greatest effect on software development. The summer of 2004, I worked with Cynthia Calhoun and Frank Robinson in the Software Assurance/Risk Management department. My task was to research and collect, compile, and analyze SQA Metrics that have been used in other projects that are not currently being used by the SA team and report them to the Software Assurance team to see if any metrics can be implemented in their software assurance life cycle process.

McRae, Kalindra A.↗

Turbine Manufacture

The machinery pictured is a set of Turbodyne steam turbines which power a sugar mill at Bell Glade, Florida. A NASA-developed computer program called NASTRAN aided development of these and other turbines manufactured by Turbodyne Corporation's Steam Turbine Division, Wellsville, New York. An acronym for NASA Structural Analysis Program, NASTRAN is a predictive tool which advises development teams how a structural design will perform under service use conditions. Turbodyne uses NASTRAN to analyze the dynamic behavior of steam turbine components, achieving substantial savings in development costs. One of the most widely used spinoffs, NASTRAN is made available to private industry through NASA's Computer Software Management Information Center (COSMIC) at the University of Georgia.

Source record↗

Serious Games that Improve Performance

Serious games can help people function more effectively in complex settings, facilitate their role as team members, and provide insight into their team's mission. In such games, coordination and cooperation among team members are foundational to the mission's success and provide a preview of what individuals and the team as a whole could choose to do in a real scenario. Serious games often model events requiring life-or-death choices, such as civilian rescue during chemical warfare. How the players communicate and what actions they take can determine the number of lives lost or saved. However, merely playing a game is not enough to realize its most practical value, which is in learning what actions and communication methods are closest to what the mission requires. Teams often play serious games in isolation, so when the game is complete, an analytical stage is needed to extract the strategies used and examine each strategy's success relative to the others chosen. Recognizing the importance of this next stage, Noblis has been developing Game Analysis, software that parses individual game play into meaningful units and generates a strategic analysis. Trainers create a custom game-specific grammar that reflects the objects and range of actions allowable in a particular game, which Game Analysis then uses to parse the data and generate a practical analysis. Trainers have then enough information to represent strategies in tools, such as Gantt and heat map charts. First-responder trainees in North Carolina have already partnered Hot-Zone and Game Analysis with great success.

McGowan, Clement, III↗

Software Users Manual (SUM): Extended Testability Analysis (ETA) Tool

This software user manual describes the implementation and use the Extended Testability Analysis (ETA) Tool. The ETA Tool is a software program that augments the analysis and reporting capabilities of a commercial-off-the-shelf (COTS) testability analysis software package called the Testability Engineering And Maintenance System (TEAMS) Designer. An initial diagnostic assessment is performed by the TEAMS Designer software using a qualitative, directed-graph model of the system being analyzed. The ETA Tool utilizes system design information captured within the diagnostic model and testability analysis output from the TEAMS Designer software to create a series of six reports for various system engineering needs. The ETA Tool allows the user to perform additional studies on the testability analysis results by determining the detection sensitivity to the loss of certain sensors or tests. The ETA Tool was developed to support design and development of the NASA Ares I Crew Launch Vehicle. The diagnostic analysis provided by the ETA Tool was proven to be valuable system engineering output that provided consistency in the verification of system engineering requirements. This software user manual provides a description of each output report generated by the ETA Tool. The manual also describes the example diagnostic model and supporting documentation - also provided with the ETA Tool software release package - that were used to generate the reports presented in the manual

Maul, William A.↗

Applying Model Based Systems Engineering to NASA's Space Communications Networks

System engineering practices for complex systems and networks now require that requirement, architecture, and concept of operations product development teams, simultaneously harmonize their activities to provide timely, useful and cost-effective products. When dealing with complex systems of systems, traditional systems engineering methodology quickly falls short of achieving project objectives. This approach is encumbered by the use of a number of disparate hardware and software tools, spreadsheets and documents to grasp the concept of the network design and operation. In case of NASA's space communication networks, since the networks are geographically distributed, and so are its subject matter experts, the team is challenged to create a common language and tools to produce its products. Using Model Based Systems Engineering methods and tools allows for a unified representation of the system in a model that enables a highly related level of detail. To date, Program System Engineering (PSE) team has been able to model each network from their top-level operational activities and system functions down to the atomic level through relational modeling decomposition. These models allow for a better understanding of the relationships between NASA's stakeholders, internal organizations, and impacts to all related entities due to integration and sustainment of existing systems. Understanding the existing systems is essential to accurate and detailed study of integration options being considered. In this paper, we identify the challenges the PSE team faced in its quest to unify complex legacy space communications networks and their operational processes. We describe the initial approaches undertaken and the evolution toward model based system engineering applied to produce Space Communication and Navigation (SCaN) PSE products. We will demonstrate the practice of Model Based System Engineering applied to integrating space communication networks and the summary of its results and impact. We will highlight the insights gained by applying the Model Based System Engineering and provide recommendations for its applications and improvements.

Bhasin, Kul↗

Integrated Design Results for the MSR DAC-0.0 Mars Ascent Vehicle

The NASA Mars Sample Return (MSR) Campaign endeavors to return Martian regolith, rock, and atmospheric samples to Earth for scientific study. One of many significant challenges to overcome in the return of these samples lies in transporting them from the Martian surface to space. In order to surmount this challenge, the Campaign has conceptualized the need for a Mars Ascent Vehicle (MAV) to perform this function and deliver Martian samples to orbit. There, the samples will be ejected and captured by a separate spacecraft for return to Earth. Many concepts for a MAV have existed in the past, but it has not been until now that an integrated, detailed design solution has been developed and analyzed. Preliminary assessments of the initial architecture examined multiple methods of propulsion. The team ultimately determined that a Two Stage to Orbit (TSTO) solid propulsion vehicle would provide the most effective performance and be the most technologically ready to support this mission. Following the decision to adopt a TSTO solid propelled vehicle, the first official Design Analysis Cycle, DAC-0.0, was performed in Spring 2020 to formally advance the fidelity of the vehicle to a maturity level acceptable for NASA Key Decision Point A (KDP-A). This paper describes the resultant MAV design concept developed as part of the DAC-0.0 study by the NASA Marshall Space Flight Center (MSFC), in association with the NASA Jet Propulsion Laboratory (JPL). The TSTO vehicle features two solid rocket motors, one powering each stage. Their thrust vectors are controlled with Thrust Vector Control (TVC) systems consisting of independent electromechanical actuators acting on gimballed nozzles. The vehicle is designed to deliver up to 0.47kg of Martian samples to a Mars circular orbit of 343km at 27° inclination. Due to the unique environmental conditions that this vehicle is required to operate in, the subsystem design teams were compelled to develop creative and unorthodox designs to ensure a successful mission. The detailed design and analysis of these subsystems are discussed in this paper and include topics on the MAV Guidance, Navigation, and Control (GNC); structures and mechanisms; integrated vehicle thermal; avionics and flight software; a hydrazine-based Reaction Control System (RCS); aerosciences; and vehicle assembly, integration, and test (AI&T) considerations, among others. Following the conclusion of the MAV DAC-0.0, additional alternative architecture concepts were also studied to further reduce the mass of the overall system. The results of these studies will also be examined in this paper.

Darius Yaghoubi↗

Integrated Design Results for the MSR DAC-0.0 Mars Ascent Vehicle

The NASA Mars Sample Return (MSR) Campaign endeavors to return Martian regolith, rock, and atmospheric samples to Earth for scientific study. One of many significant challenges to overcome in the return of thesesamples lies in transporting them from the Martian surface to space. In order to surmount this challenge, the Campaign has conceptualized the need for a Mars Ascent Vehicle (MAV) to perform this function and deliver Martian samples to orbit. There, the samples will be ejected and captured by a separate spacecraft for return to Earth. Many concepts for a MAV have existed in the past, but it has not been until now that an integrated, detailed design solution has been developed and analyzed. Preliminary assessments of the initial architecture examined multiple methods of propulsion. The team ultimately determined that a Two Stage to Orbit (TSTO) solid propulsion vehicle would provide the most effective performance and be the most technologically ready to support this mission. Following the decision to adopt a TSTO solid propelled vehicle, the first official Design Analysis Cycle, DAC-0.0, was performed in Spring 2020 to formally advance the fidelity of the vehicle to a maturity level acceptable for NASA Key Decision Point A (KDP-A). This paper describes the resultant MAV design concept developed as part of the DAC-0.0 study by the NASA Marshall Space Flight Center (MSFC), in association with the NASA Jet Propulsion Laboratory (JPL). The TSTO vehicle features two solid rocket motors, one powering each stage. Their thrust vectors are controlled with Thrust Vector Control (TVC) systems consisting of independent electromechanical actuators acting on gimballed nozzles. The vehicle is designed to deliver up to 0.47kg of Martian samples to a Mars circular orbit of 343km at 27° inclination. Due to the unique environmental conditions that this vehicle is required to operate in, the subsystem design teams were compelled to develop creative and unorthodox designs to ensure a successful mission. The detailed design and analysis of these subsystems are discussed in this paper and include topics on the MAV Guidance, Navigation, and Control (GNC); structures and mechanisms; integrated vehicle thermal; avionics and flight software; a hydrazine-based Reaction Control System (RCS); aerosciences; and vehicle assembly, integration, and test (AI&T) considerations, among others. Following the conclusion of the MAV DAC-0.0, additional alternative architecture concepts were also studied to further reduce the mass of the overall system.

Mars↗

Europa Clipper Payload Verification and Validation: Avionics-Instrument Interface Test Campaign

NASA's Europa Clipper mission will investigate Jupiter's icy moon Europa using a payload suite consisting of nine instruments to address a range of scientific objectives concerning Europa's habitability. As the project proceeds past its Critical Design Review, confidence is being built in the system's ability to achieve mission objectives through the implementation of a rigorous payload verification and validation (V&V) program. As part of this payload V&V program, instrument box-level testing was performed by the payload team to verify select instrument-avionics interface requirements. This testing was performed at JPL using the avionics testbed's Bulk Data Storage Emulator (BDSEM) with visiting instrument Test Models. This paper summarizes the Data Link test campaign involving roughly four days of functional testing per instrument, including planning, testing methods, types of issues found, and the requirement closure process. Detail is also provided on the development, deployment, and validation of a standardized analysis tool used in data reviews. This testing verified requirements related to commanding rates, loss of link, packet format, clock counters, loopback test capability, and SpaceWire jitter and skew margins. Additional risk reduction testing of basic commanding, counter behavior, science data collection and transfer, and interface swapping was also performed. Because the BDSEM venue was not originally designed to be a run for record venue, the process of characterizing venue fidelity and establishing suitability for requirement closure using data collected in this venue will also be addressed.In order to close requirements, an extensible tool was developed to post-process instrument command and telemetry data from their original binary to a human-readable format and give visibility to errors detected within the data, such as packets with Cyclic Redundancy Check errors. This tool, called payload-packet-parser, is a Python 3.9 command line tool built using a variety of open-source Python libraries. Payload-packet-parser was designed to support parsing command and telemetry packets for all Europa Clipper instruments and additional analysis tools were developed for verification of specific information interface requirements. This test campaign, including post-processing using a single parsing and verification toolset, allowed for early interface testing, alleviating testing burdens on instrument teams and buying down risk on the instrument-avionics interface by finding hardware and software issues and idiosyncrasies prior to integration with system test venues. Over twenty issues were discovered across the payload, resulting in software updates and instrument rework well in advance of any system impacts. This paper concludes with an assessment of benefits and costs of this type of testing and lessons learned.

Montanez, Leticia↗

Application of Human-Autonomy Teaming to an Advanced Ground Station for Reduced Crew Operations

Within human factors there is burgeoning interest in the "human-autonomy teaming" (HAT) concept as a way to address the challenges of interacting with complex, increasingly autonomous systems. The HAT concept comes out of an aspiration to interact with increasingly autonomous systems as a team member, rather than simply use automation as a tool. The authors, and others, have proposed core tenets for HAT that include bi-directional communication, automation and system transparency, and advanced coordination between human and automated teammates via predefined, dynamic task sequences known as "plays." It is believed that, with proper implementation, HAT should foster appropriate teamwork, thus increasing trust and reliance on the system, which in turn will reduce workload, increase situation awareness, and improve performance. To this end, HAT has been demonstrated and/or studied in multiple applications including search and rescue operations, healthcare and medicine, autonomous vehicles, photography, and aviation. The current paper presents one such effort to apply HAT. It details the design of a HAT agent, developed by Human Automation Teaming Solutions, Inc., to facilitate teamwork between the automation and the human operator of an advanced ground dispatch station. This dispatch station was developed to support a NASA project investigating a concept called Reduced Crew Operations (RCO); consequently, we have named the agent R-HATS. Part of the RCO concept involves a ground operator providing enhanced support to a large number of aircraft with a single pilot on the flight deck. When assisted by R-HATS, operators can monitor and support or manage a large number of aircraft and use plays to respond in real-time to complicated, workload-intensive events (e.g., an airport closure). A play is a plan that encapsulates goals, tasks, and a task allocation strategy appropriate for a particular situation. In the current implementation, when a play is initiated by a user, R-HATS determines what tasks need to be completed and has the ability to autonomously execute them (e.g., determining diversion options and uplinking new routes to aircraft) when it is safe and appropriate. R-HATS has been designed to both support end users and researchers in RCO and HAT. Additionally, R-HATS and its underlying architecture were developed with generalizability in mind as a modular software applicable outside of RCO/aviation domains. This paper will also discuss future further development and testing of RHATS.

automation↗

Addressing Human Error in International Space Station Flight Control Teams: Advances in Ground Training for Science Operators

In flight control, as with any human in the loop system, operator error is an inevitable reality. On the International Space Station (ISS) where crew time and physical resources are precious and often irreplaceable, operator errors can result in significant, irreversible consequences. Flight controllers at the Payload Operations Integration Center (POIC) located at NASA's Marshall Space Flight Center (MSFC) in Huntsville, Alabama know this reality well. At the POIC, operator errors can be caused by a variety of factors, from poor hardware or software design to environmental factors such as time pressure or fatigue. The most difficult errors to address, however, are those which result from ineffective teamwork. To address these teamwork errors, trainers at the POIC have drawn best practices from high reliability industries as well as from our sister ISS control center at the Johnson Space Center (JSC) in Houston, Texas, to develop and implement a new training program focused specifically on teamwork skills. This training program, called Team Skills Training, is inspired by modern and historical training programs developed by NASA and is specifically tailored to the needs of the payload operations flight control team at the POIC. The program consists of training for both certified and trainee flight controllers, and covers team skills topics such as situational awareness, leadership, and communication skills. To maximize effectiveness, the program uses novel instructional techniques which extend beyond the classroom to encourage students to apply what they have learned to their day to day work. Minimizing operator errors in flight control is an endeavor which requires constant vigilance and continuous improvement. At the POIC, Team Skills Training is an important step in this journey.

Harris, Samantha S.↗

DECOVALEX-2023: Task F2 Salt Final Report

The subject of Task F of DECOVALEX-2023 concerns performance assessment modelling of radioactive waste disposal in deep mined repositories. The primary objectives of Task F are to build confidence in the models, methods, and software used for performance assessment (PA) of deep geologic nuclear waste repositories, and/or to bring to the fore additional research and development needed to improve PA methodologies. In Task F2- (salt), these objectives have been accomplished through staged development and comparison of the models and methods used by participating teams in their PA frameworks. Coupled-process submodels and deterministic simulations of the entire PA model for a reference scenario for waste disposal in domal salt have been conducted. The task specification has been updated continuously since the initiation of the project to reflect the staged development of the conceptual repository model and performance metrics. Thermal, hydrological, mechanical, and chemical properties of individual components of the engineered and natural system were chosen for relevance by participating teams. The salt reference case system was characterized using data and measurements collected at relevant underground research laboratories (URLs), field sites, and simulation results from teams with specialized modelling capability. Participating teams made a wide range of model assumptions from compartmentalized networks to full 3D models of the salt formation. No single contributed model includes full-fidelity representation of all the features, events, and processes (FEPs) detailed in the task specification, but almost all features and processes are represented in at least one model. Despite differences in the modelling strategies developed by participating teams, all models indicate that salt compaction and radionuclide diffusion are key processes in the repository, and for the FEPs and model scenario considered, little of the disposed radionuclides will migrate beyond the repository seal over the 100,000 year simulations. In general, the model output quantities have the largest differences over the short term and near the waste. The models tend to be more similar further from waste and at later time. Disparities between the models are believed to be due to differing simplifications from the task specification, some of which are chosen simplifications to reduce complexity, and some are restrictions imposed by the modelling tools. A second round of this task has been accepted for DECOVALEX-2027 in conjunction with Task F1 on crystalline PA modelling. The future round includes waste package heating, improved modelling of salt creep closure, additional comparisons of coupled-process sub-models, and the impact of repository engineering design on radionuclide migration in the repository. Participants will also propose and finalize a set of uncertain inputs for the reference case simulations, propagate these uncertainties in a set of realizations, and conduct sensitivity analyses on the simulation results.

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

Development of a Space Station Operations Management System

To enhance the productivity of operations aboard the Space Station, a means must be provided to augment, and frequently to supplant, human effort in support of mission operations and management, both on the ground and onboard. The Operations Management System (OMS), under development at the Johnson Space Center, is one such means. OMS comprises the tools and procedures to facilitate automation of station monitoring, control, and mission planning tasks. OMS mechanizes, and hence rationalizes, execution of tasks traditionally performed by mission planners, the mission control center team, onboard System Management software, and the flight crew.

Brandli, A. E.↗

Aviation Data Integration System

During the analysis of flight data and safety reports done in ASAP and FOQA programs, airline personnel are not able to access relevant aviation data for a variety of reasons. We have developed the Aviation Data Integration System (ADIS), a software system that provides integrated heterogeneous data to support safety analysis. Types of data available in ADIS include weather, D-ATIS, RVR, radar data, and Jeppesen charts, and flight data. We developed three versions of ADIS to support airlines. The first version has been developed to support ASAP teams. A second version supports FOQA teams, and it integrates aviation data with flight data while keeping identification information inaccessible. Finally, we developed a prototype that demonstrates the integration of aviation data into flight data analysis programs. The initial feedback from airlines is that ADIS is very useful in FOQA and ASAP analysis.

Kulkarni, Deepak↗

Foreign Object Damage Identification in Turbine Engines

This report summarizes the collective work of a five-person team from different organizations examining the problem of detecting foreign object damage (FOD) events in turbofan engines from gas path thermodynamic and bearing accelerometer sensors, and determining the severity of damage to each component (diagnosis). Several detection and diagnostic approaches were investigated and a software tool (FODID) was developed to assist researchers detect/diagnose FOD events. These approaches include (1) fan efficiency deviation computed from upstream and downstream temperature/ pressure measurements, (2) gas path weighted least squares estimation of component health parameter deficiencies, (3) Kalman filter estimation of component health parameters, and (4) use of structural vibration signal processing to detect both large and small FOD events. The last three of these approaches require a significant amount of computation in conjunction with a physics-based analytic model of the underlying phenomenon the NPSS thermodynamic cycle code for approaches 1 to 3 and the DyRoBeS reduced-order rotor dynamics code for approach 4. A potential application of the FODID software tool, in addition to its detection/diagnosis role, is using its sensitivity results to help identify the best types of sensors and their optimum locations within the gas path, and similarly for bearing accelerometers.

Strack, William↗

Distributed Visualization Project

Distributed Visualization allows anyone, anywhere to see any simulation at any time. Development focuses on algorithms, software, data formats, data systems and processes to enable sharing simulation-based information across temporal and spatial boundaries without requiring stakeholders to possess highly-specialized and very expensive display systems. It also introduces abstraction between the native and shared data, which allows teams to share results without giving away proprietary or sensitive data. The initial implementation of this capability is the Distributed Observer Network (DON) version 3.1. DON 3.1 is available for public release in the NASA Software Store (https://software.nasa.gov/software/KSC-13775) and works with version 3.0 of the Model Process Control specification (an XML Simulation Data Representation and Communication Language) to display complex graphical information and associated Meta-Data.

Tech Port↗

SMC: SCENIC Model Control

NASAs Space Communications and Navigation (SCaN) program manages three active networks: the Near Earth Network, the Space Network, and the Deep Space Network. These networks simultaneously support NASA missions and provide communications services to customers worldwide. To efficiently manage these resources and their capabilities, a team of student interns at the NASA Glenn Research Center is developing a distributed system to model the SCaN networks. Once complete, the system shall provide a platform that enables users to perform capacity modeling of current and prospective missions with finer-grained control of information between several simulation and modeling tools. This will enable the SCaN program to access a holistic view of its networks and simulate the effects of modifications in order to provide NASA with decisional information. The development of this capacity modeling system is managed by NASAs Strategic Center for Education, Networking, Integration, and Communication (SCENIC). Three primary third-party software tools offer their unique abilities in different stages of the simulation process. MagicDraw provides UMLSysML modeling, AGIs Systems Tool Kit simulates the physical transmission parameters and de-conflicts scheduled communication, and Riverbed Modeler (formerly OPNET) simulates communication protocols and packet-based networking. SCENIC developers are building custom software extensions to integrate these components in an end-to-end space communications modeling platform. A central control module acts as the hub for report-based messaging between client wrappers. Backend databases provide information related to mission parameters and ground station configurations, while the end user defines scenario-specific attributes for the model. The eight SCENIC interns are working under the direction of their mentors to complete an initial version of this capacity modeling system during the summer of 2015. The intern team is composed of four students in Computer Science, two in Computer Engineering, one in Electrical Engineering, and one studying Space Systems Engineering.

Simulation↗

Space Communications Emulation Facility

Establishing space communication between ground facilities and other satellites is a painstaking task that requires many precise calculations dealing with relay time, atmospheric conditions, and satellite positions, to name a few. The Space Communications Emulation Facility (SCEF) team here at NASA is developing a facility that will approximately emulate the conditions in space that impact space communication. The emulation facility is comprised of a 32 node distributed cluster of computers; each node representing a satellite or ground station. The objective of the satellites is to observe the topography of the Earth (water, vegetation, land, and ice) and relay this information back to the ground stations. Software originally designed by the University of Kansas, labeled the Emulation Manager, controls the interaction of the satellites and ground stations, as well as handling the recording of data. The Emulation Manager is installed on a Linux Operating System, employing both Java and C++ programming codes. The emulation scenarios are written in extensible Markup Language, XML. XML documents are designed to store, carry, and exchange data. With XML documents data can be exchanged between incompatible systems, which makes it ideal for this project because Linux, MAC and Windows Operating Systems are all used. Unfortunately, XML documents cannot display data like HTML documents. Therefore, the SCEF team uses XML Schema Definition (XSD) or just schema to describe the structure of an XML document. Schemas are very important because they have the capability to validate the correctness of data, define restrictions on data, define data formats, and convert data between different data types, among other things. At this time, in order for the Emulation Manager to open and run an XML emulation scenario file, the user must first establish a link between the schema file and the directory under which the XML scenario files are saved. This procedure takes place on the command line on the Linux Operating System. Once this link has been established the Emulation manager validates all the XML files in that directory against the schema file, before the actual scenario is run. Using some very sophisticated commercial software called the Satellite Tool Kit (STK) installed on the Linux box, the Emulation Manager is able to display the data and graphics generated by the execution of a XML emulation scenario file. The Emulation Manager software is written in JAVA programming code. Since the SCEF project is in the developmental stage, the source code for this type of software is being modified to better fit the requirements of the SCEF project. Some parameters for the emulation are hard coded, set at fixed values. Members of the SCEF team are altering the code to allow the user to choose the values of these hard coded parameters by inserting a toolbar onto the preexisting GUI.

Hill, Chante A.↗

Research and Technology at the John F. Kennedy Space Center 1993

As the NASA Center responsible for assembly, checkout, servicing, launch, recovery, and operational support of Space Transportation System elements and payloads, the John F. Kennedy Space Center is placing increasing emphasis on its advanced technology development program. This program encompasses the efforts of the Engineering Development Directorate laboratories, most of the KSC operations contractors, academia, and selected commercial industries - all working in a team effort within their own areas of expertise. This edition of the Kennedy Space Center Research and Technology 1993 Annual Report covers efforts of all these contributors to the KSC advanced technology development program, as well as our technology transfer activities. Major areas of research include material science, advanced software, industrial engineering, nondestructive evaluation, life sciences, atmospheric sciences, environmental technology, robotics, and electronics and instrumentation.

Source record↗