Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Human and Technology Integration”

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 19 records

Avionics/crew station integration

The U.S. Navy has been encouraging advanced development concepts aimed at increasing the aircraft instrumentation performance for multi-platform applications of 1990's weapons systems. The three areas covered by the Navy's research and development effort are: System Integration, Technology, and Human Factors. The System Integration objectives are to produce a system architecture easily adaptable to many platforms. Technology objectives are to determine the state of the art for displays, electronics, and controls. The Human Factors objectives are to determine the proper human-machine interfaces so that the ultimate crew station will be capable of providing the pilot with the proper display and controls performance to satisfy the diverse requirements of a fighter, attack, ASW, fixed-wing, rotary-wing, and V/STOL platforms in both a one-man crew or two-man crew matrix. All data/control interface among units of this crew station and other platform subsystems will be via digital data buses and video multiplex buses. No individual discrete signal, data, or control lines will be needed. This paper discusses the six interfaces necessary to ensure the optimum development of this crew station, the predicted platform mission improvements, and the requisite life-cycle cost considerations. This concept will serve as a basis for planning the integration of the necessary hardware and software features in current and future weapons systems.

Mulley, W. G.↗

Step 1: Human System Integration Pilot-Technology Interface Requirements for Weather Management

This document involves definition of technology interface requirements for Hazardous Weather Avoidance. Technology concepts in use by the Access 5 Weather Management Work Package were considered. Beginning with the Human System Integration (HIS) high-level functional requirement for Hazardous Weather Avoidance, and Hazardous Weather Avoidance technology elements, HSI requirements for the interface to the pilot were identified. Results of the analysis describe (1) the information required by the pilot to have knowledge of hazardous weather, and (2) the control capability needed by the pilot to obtain hazardous weather information. Fundamentally, these requirements provide the candidate Hazardous Weather Avoidance technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how Hazardous Weather Avoidance operations and functions should interface with the pilot to provide the necessary Weather Management functionality to the UA-pilot system. Requirements and guidelines for Hazardous Weather Avoidance are partitioned into four categories: (1) Planning En Route (2) Encountering Hazardous Weather En Route, (3) Planning to Destination, and (4) Diversion Planning Alternate Airport. Each requirement is stated and is supported with a rationale and associated reference(s).

Source record↗

SSTAC/ARTS review of the draft Integrated Technology Plan (ITP). Volume 5: Human Support

Viewgraphs of briefings from the Space Systems and Technology Advisory Committee (SSTAC)/ARTS review of the draft integrated technology plan (ITP) on human support are included. Topics covered include: human support program; human factors; life support technology; fire safety; medical support technology; advanced refrigeration technology; EVA suit system; advanced PLSS technology; and ARC-EVA systems research program.

Source record↗

Step 1: Human System Integration (HSI) FY05 Pilot-Technology Interface Requirements for Command, Control, and Communications (C3)

The document provides the Human System Integration(HSI) high-level functional C3 HSI requirements for the interface to the pilot. Description includes (1) the information required by the pilot to have knowledge C3 system status, and (2) the control capability needed by the pilot to obtain C3 information. Fundamentally, these requirements provide the candidate C3 technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how C3 operations and functions should interface with the pilot to provide the necessary C3 functionality to the UA-pilot system. Requirements and guidelines for C3 are partitioned into three categories: (1) Pilot-Air Traffic Control (ATC) Voice Communications (2) Pilot-ATC Data Communications, and (3) command and control of the unmanned aircraft (UA). Each requirement is stated and is supported with a rationale and associated reference(s).

Source record↗

Process for Selecting System Level Assessments for Human System Technologies

The integration of many life support systems necessary to construct a stable habitat is difficult. The correct identification of the appropriate technologies and corresponding interfaces is an exhaustive process. Once technologies are selected secondary issues such as mechanical and electrical interfaces must be addressed. The required analytical and testing work must be approached in a piecewise fashion to achieve timely results. A repeatable process has been developed to identify and prioritize system level assessments and testing needs. This Assessment Selection Process has been defined to assess cross cutting integration issues on topics at the system or component levels. Assessments are used to identify risks, encourage future actions to mitigate risks, or spur further studies.

Watts, James↗

Step 1:Human System Integration (HSI) FY05 Pilot-Technology Interface Requirements for Collision Avoidance

This document provides definition of technology human interface requirements for Collision Avoidance (CA). This was performed through a review of CA-related, HSI requirements documents, standards, and recommended practices. Technology concepts in use by the Access 5 CA work package were considered... Beginning with the HSI high-level functional requirement for CA, and CA technology elements, HSI requirements for the interface to the pilot were identified. Results of the analysis describe (1) the information required by the pilot to have knowledge CA system status, and (2) the control capability needed by the pilot to obtain CA information and affect an avoidance maneuver. Fundamentally, these requirements provide the candidate CA technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how CA operations and functions should interface with the pilot to provide the necessary CA functionality to the UA-pilot system .Requirements and guidelines for CA are partitioned into four categories: (1) General, (2) Alerting, (3) Guidance, and (4) Cockpit Display of Traffic Information. Each requirement is stated and is supported with a rationale and associated reference(s).

Source record↗

Step 1: Human System Integration (HSI) FY05 Pilot-Technology Interface Requirements for Contingency Management

This document involves definition of technology interface requirements for Contingency Management. This was performed through a review of Contingency Management-related, HSI requirements documents, standards, and recommended practices. Technology concepts in use by the Contingency Management Work Package were considered. Beginning with HSI high-level functional requirements for Contingency Management, and Contingency Management technology elements, HSI requirements for the interface to the pilot were identified. Results of the analysis describe (1) the information required by the pilot to have knowledge of system failures and associated contingency procedures, and (2) the control capability needed by the pilot to obtain system status and procedure information. Fundamentally, these requirements provide the candidate Contingency Management technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how Contingency Management operations and functions should interface with the pilot to provide the necessary Contingency Management functionality to the UA-pilot system. Requirements and guidelines for Contingency Management are partitioned into four categories: (1) Health and Status and (2) Contingency Management. Each requirement is stated and is supported with a rationale and associated reference(s).

Source record↗

Alignment of NASA’s Human System Risks with Technological Capability Gaps to Enable Integrated Research and Technology Development Strategic Planning

BACKGROUND: Radiation, reduced gravity, distance from earth, isolation and confinement, and habitation within artificially created and controlled life support environments are hazards that present risk to human space explorers. NASA’s Human System Risk Board (HSRB) maintains a set of twenty-nine different Human System Risks with subject matter experts from across the agency providing regular updates to the estimated likelihood and consequence associated with each risk. The Human Research Program (HRP) has historically used these risk classifications as a primary basis for identifying and prioritizing human research investments aimed at characterizing and/or mitigating the respective human system risks. In many cases, technology development is required to mature and validate risk mitigation strategies, however, NASA’s primary technology development programs have not typically used Human System Risks as a basis for strategic planning. A primary function of the Environmental Control and Life Support Systems (ECLSS) – Crew Health and Performance (CHP) System Capability Leadership Team (SCLT) is to continually identify, review, and update technological capability gaps and to establish and oversee multiyear strategic roadmaps aimed at guiding NASA’s technology development priorities in these areas. These roadmaps are intended to be agency-wide and independent of any program, directorate, or other organization within NASA. DESCRIPTION: The SCLT and HRP collaborated to establish a set of Human System Capability Gaps, which establish a formal linkage between the capability gaps used to prioritize investments across much of NASA, and the Human System Risks that are primarily used to inform and prioritize human research. This set of twenty-eight gaps was developed by subject matter experts, and each gap mapped to the primary associated Human System Risks. The gaps and risk mapping were then reviewed and approved via the HSRB, thereby formally aligning the research-focused Human System Risks with the technology-focused capability gaps. DISCUSSION: This effort has enabled development of integrated roadmaps and budget coordination with research and technology development activities that are formally linked to agency-recognized capability gaps and Human System Risks. Close and ongoing coordination between the SCLT, HRP, Mars Campaign Office, and the Health & Medical Technical Authority (HMTA) is essential to ensure alignment and prioritization of CHP-related research and technology development to enable NASA’s future exploration missions.

Andrew F J Abercromby↗

Systems Engineering and Integration for Advanced Life Support System and HST

Systems engineering (SE) discipline has revolutionized the way engineers and managers think about solving issues related to design of complex systems: With continued development of state-of-the-art technologies, systems are becoming more complex and therefore, a systematic approach is essential to control and manage their integrated design and development. This complexity is driven from integration issues. In this case, subsystems must interact with one another in order to achieve integration objectives, and also achieve the overall system's required performance. Systems engineering process addresses these issues at multiple levels. It is a technology and management process dedicated to controlling all aspects of system life cycle to assure integration at all levels. The Advanced Integration Matrix (AIM) project serves as the systems engineering and integration function for the Human Support Technology (HST) program. AIM provides means for integrated test facilities and personnel for performance trade studies, analyses, integrated models, test results, and validated requirements of the integration of HST. The goal of AIM is to address systems-level integration issues for exploration missions. It will use an incremental systems integration approach to yield technologies, baselines for further development, and possible breakthrough concepts in the areas of technological and organizational interfaces, total information flow, system wide controls, technical synergism, mission operations protocols and procedures, and human-machine interfaces.

Kamarani, Ali K.↗

NASA plans and programs in support of integrated ATC development

Consideration is given to the following areas in which NASA may contribute to the technology of an advanced national aviation system: (1) quiet, safe, fuel-efficient aircraft; (2) low-cost, reliable, digital avionics; (3) integrated controls technology; (4) human factors in civil and general aviation; (5) aircraft system technology validation and demonstration; and (6) satellite systems technology applications. Such specific projects as the Terminal Configured Vehicle, the Global Positioning System, and the Search and Rescue Satellite System are described.

Kramer, J. J.↗

Evidence Report, Risk of Inadequate Design of Human and Automation/Robotic Integration

The success of future exploration missions depends, even more than today, on effective integration of humans and technology (automation and robotics). This will not emerge by chance, but by design. Both crew and ground personnel will need to do more demanding tasks in more difficult conditions, amplifying the costs of poor design and the benefits of good design. This report has looked at the importance of good design and the risks from poor design from several perspectives: 1) If the relevant functions needed for a mission are not identified, then designs of technology and its use by humans are unlikely to be effective: critical functions will be missing and irrelevant functions will mislead or drain attention. 2) If functions are not distributed effectively among the (multiple) participating humans and automation/robotic systems, later design choices can do little to repair this: additional unnecessary coordination work may be introduced, workload may be redistributed to create problems, limited human attentional resources may be wasted, and the capabilities of both humans and technology underused. 3) If the design does not promote accurate understanding of the capabilities of the technology, the operators will not use the technology effectively: the system may be switched off in conditions where it would be effective, or used for tasks or in contexts where its effectiveness may be very limited. 4) If an ineffective interaction design is implemented and put into use, a wide range of problems can ensue. Many involve lack of transparency into the system: operators may be unable or find it very difficult to determine a) the current state and changes of state of the automation or robot, b) the current state and changes in state of the system being controlled or acted on, and c) what actions by human or by system had what effects. 5) If the human interfaces for operation and control of robotic agents are not designed to accommodate the unique points of view and operating environments of both the human and the robotic agent, then effective human-robot coordination cannot be achieved.

Zumbado, Jennifer Rochlis↗

Next Generation Flight Displays Using HTML5

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

Greenwood, Brian↗

Integrated Precision Landing Performance and Technology Assessments of a Human- Scale Mars Lander Using a Generalized Simulation Framework

Human-scale missions to Mars will likely require multiple landers delivered precisely to designated locations. The current NASA human Mars reference architecture assumes delivery of three 25 t payloads from a 1- or 5-Sol orbit to the surface with a landing precision of 50 m to ensure logistics are located near the habitat. While initial navigation estimates improve with on-orbit ground tracking, errors increase during post-deorbit coast. Likewise, Mars atmospheric variability and forecasting uncertainty means that the entry vehicle guidance, navigation, and control systems must be robust to accommodate landing during any time of day or Mars year, including during dust storms. Precision landing technologies are currently being assessed to determine if onboard navigation sensors are sufficient to enable the landing accuracy required or if additional navigation aids such as surface or orbiting beacons will be needed. This study evaluates the system performance requirements to meet the desired landing accuracy for the reference vehicle design and entry, descent, and landing concept of operations. A detailed six degree-of-freedom integrated performance simulation framework is used to perform the assessment and demonstrate that under current assumptions, onboard navigation sensors are sufficient to support precision landing.

Chen, Po-Ting↗

Integrated Waste Trade Study: Lunar Surface to Deep Space

The Logistics Reduction Project is one of NASA's technology development projects that is preparing humanity for deep space missions. Reducing the mass and volume of logistical supplies that must be carried from Earth to support the missions and their crews is the primary goal of the project. Effective ways to achieve this goal include reducing, reusing, or recycling wastes generated throughout the mission. Due to the goal of the project, waste processing technologies were analyzed for Lunar surface missions at various lengths and an 850-day Mars transit mission to evaluate the potential benefits of waste processing pertaining to each mission. The technologies assessed include trash compaction, trash-to-gas and human metabolic waste processing technologies, integrated with the baseline architectures of each mission’s habitat. The fully integrated systems were analyzed using an equivalent system mass, which is a metric that encompasses the mass, volume, power and cooling of a system, resulting in an estimate of launch mass and serving as a proxy for cost. Each system’s equivalent system mass was compared to that of the baseline waste processing system of the respective habitat, hand compaction with storage for Lunar surface missions and hand compaction with jettisoning for Mars transit, to evaluate whether the traded waste processing technology was beneficial. This analysis identifies a general trend that more sophisticated waste processing can be beneficial depending on the mission duration. For Lunar surface missions, the water recovery from waste processing can pay off over consecutive missions, due to offsetting the losses from the system via extravehicular activities. In contrast for Mars transit, the primary objective is mass removal from the spacecraft, so technologies like trash-to-gas are competitive with the baseline. Furthermore, the technologies which can recover resources from waste, such as water, may present additional advantages to an ever-changing Mars mission architecture.

Waste processing↗

Aviation safety/automation program overview

The goal is to provide a technology base leading to improved safety of the national airspace system through the development and integration of human-centered automation technologies for aircraft crews and air traffic controllers. Information on the problems, specific objectives, human-automation interaction, intelligent error-tolerant systems, and air traffic control/cockpit integration is given in viewgraph form.

Morello, Samuel A.↗

Integration Test and Evaluation (IT&E) Flight Test Series 6 Live Virtual Constructive - Distributed Environment (LVC-DE) Test Report

The goals of the Unmanned Aircraft Systems (UAS) Integration in the National Airspace System (NAS) (also UAS-NAS) Project are to reduce the barriers for UAS access and its integration into the NAS. The UAS-NAS project and industry stakeholders conducted a series of flight tests integrating technologies from the Modeling & Simulation (M&S), Human Systems Integration (HSI), and Communication and Control (C2), and Integration, Test & Evaluation (IT&E) research areas. The last of the flight test series, Flight Test Series 6 (FT6) was conducted in late 2019 and focused on evaluating the interaction of the airborne non-cooperative surveillance system and the Detect and Avoid (DAA) technology. The DAA system generated conflict alert and guidance for pilots using a Research Ground Control System (RGCS) to avoid intruder aircraft. The conflict alerting and guidance information was presented on the RGCS’s display using symbology developed by the human factors team. The objective of FT6 was to investigate the interoperability of Low Size, Weight, and Power (Low SWaP) sensors with the DAA alerting, guidance, and display requirements. To support this goal, the distributed test environments (DTE) were developed at Ames Research Center (ARC) and Armstrong Flight Research Center (AFRC) and securely linked over a Virtual Private Network (VPN). These environments took advantage of existing Live Virtual Constructive (LVC) technologies to support research observation at both Centers with the insertion of live UAS and manned intruder aircraft into a simulated NAS environment with Air Traffic Control (ATC) and constructive manned aircraft. The experiment was distributed between AFRC flight operations and research facilities and the Distributed Simulation Research Laboratory (DSRL) and Software Development Laboratory (SDL) in building N243 at ARC. The Air Traffic Controller and pseudo pilots operated from the DSRL and SDL, respectively, using the Multi-Aircraft Control System (MACS). The test subject and researchers operated from the Research Ground Control Station (RGCS) at AFRC using the Vigilant Spirit Control Station (VSCS) and associated DAA software and displays. Flight Operation for the unmanned aircraft (UA) and manned intruder traffic was conducted at AFRC. Virtual traffic was managed by ARC. Voice distribution was accomplished using a combination of disparate communication systems at ARC and AFRC. The purpose of this document is to record the development, design, and execution of activities in support of the FT6 efforts from the perspective of the ARC IT&E team. Furthermore, the Armstrong IT&E team has published a thorough FT6 Test Report, with emphasis on flight test support, facilities and vehicle development; this report complements the Armstrong report. Analysis of collected FT6 data will be conducted and reported by the M&S and HSI teams and will be published in separate reports.

UAS-NAS↗