Search NASA⌕ Search

SEARCH · Search NASA

Results for “Concurrent Engineering”

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.

416 records · Page 24

The VLBA correlator: Real-time in the distributed era

The correlator is the signal processing engine of the Very Long Baseline Array (VLBA). Radio signals are recorded on special wideband (128 Mb/s) digital recorders at the 10 telescopes, with sampling times controlled by hydrogen maser clocks. The magnetic tapes are shipped to the Array Operations Center in Socorro, New Mexico, where they are played back simultaneously into the correlator. Real-time software and firmware controls the playback drives to achieve synchronization, compute models of the wavefront delay, control the numerous modules of the correlator, and record FITS files of the fringe visibilities at the back-end of the correlator. In addition to the more than 3000 custom VLSI chips which handle the massive data flow of the signal processing, the correlator contains a total of more than 100 programmable computers, 8-, 16- and 32-bit CPUs. Code is downloaded into front-end CPU's dependent on operating mode. Low-level code is assembly language, high-level code is C running under a RT OS. We use VxWorks on Motorola MVME147 CPU's. Code development is on a complex of SPARC workstations connected to the RT CPU's by Ethernet. The overall management of the correlation process is dependent on a database management system. We use Ingres running on a Sparcstation-2. We transfer logging information from the database of the VLBA Monitor and Control System to our database using Ingres/NET. Job scripts are computed and are transferred to the real-time computers using NFS, and correlation job execution logs and status flow back by the route. Operator status and control displays use windows on workstations, interfaced to the real-time processes by network protocols. The extensive network protocol support provided by VxWorks is invaluable. The VLBA Correlator's dependence on network protocols is an example of the radical transformation of the real-time world over the past five years. Real-time is becoming more like conventional computing. Paradoxically, 'conventional' computing is also adopting practices from the real-time world: semaphores, shared memory, light-weight threads, and concurrency. This appears to be a convergence of thinking.

Wells, D. C.↗

Influence of Combined Whole-Body Vibration Plus G-Loading on Visual Performance

Recent engineering analyses of the integrated Ares-Orion stack show that vibration levels for Orion crews have the potential to be much higher than those experienced in Gemini, Apollo, and Shuttle vehicles. Of particular concern to the Constellation Program (CxP) is the 12 Hz thrust oscillation (TO) that the Ares-I rocket develops during the final ~20 seconds preceding first-stage separation, at maximum G-loading. While the structural-dynamic mitigations being considered can assure that vibration due to TO is reduced to below the CxP crew health limit, it remains to be determined how far below this limit vibration must be reduced to enable effective crew performance during launch. Moreover, this "performance" vibration limit will inform the operations concepts (and crew-system interface designs) for this critical phase of flight. While Gemini and Apollo studies provide preliminary guidance, the data supporting the historical limits were obtained using less advanced interface technologies and very different operations concepts. In this study, supported by the Exploration Systems Mission Directorate (ESMD) Human Research Program, we investigated display readability-a fundamental prerequisite for any interaction with electronic crew-vehicle interfaces-while observers were subjected to 12 Hz vibration superimposed on the 3.8 G loading expected for the TO period of ascent. Two age-matched groups of participants (16 general population and 13 Crew Office) performed a numerical display reading task while undergoing sustained 3.8 G loading and whole-body vibration at 0, 0.15, 0.3, 0.5, and 0.7 g in the eyeballs in/out (x-axis) direction. The time-constrained reading task used an Orion-like display with 10- and 14-pt non-proportional sans-serif fonts, and was designed to emulate the visual acquisition and processing essential for crew system monitoring. Compared to the no-vibration baseline, we found no significant effect of vibration at 0.15 and 0.3 g on task error rates (ER) or response times (RT). Significant degradations in both ER and RT, however, were observed at 0.5 and 0.7 g for 10-pt, and at 0.7 g for 14-pt font displays. These objective performance measures were mirrored by participants' subjective ratings. Interestingly, we found that the impact of vibration on ER increased with distance from the center of the display, but only for vertical displacements. Furthermore, no significant ER or RT aftereffects were detected immediately following vibration, regardless of amplitude. Lastly, given that our reading task required no specialized spaceflight expertise, our finding that effects were not statistically distinct between our two groups is not surprising. The results from this empirical study provide initial guidance for evaluating the display readability trade-space between text-font size and vibration amplitude. However, the outcome of this work should be considered preliminary in nature for a number of reasons: 1. The single 12 Hz x-axis vibration employed was based on earlier load-cycle models of the induced TO environment at the end of Ares-I first stage flight. Recent analyses of TO mitigation designs suggest that significant concurrent off-axis vibration may also occur. 2. The shirtsleeve environment in which we tested fails to capture the full kinematic and dynamic complexity of the physical interface between crewmember and the still-to-bematured helmet-suit-seat designs, and the impact these will have for vibration transmission and consequent performance. 3. By examining performance in this reading and number processing task, we are only assessing readability, a first and necessary step that in itself does not directly address the performance of more sophisticated operational tasks such as vehicle-health monitoring or manual control of the vehicle.

readability↗