Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Guaranteed performance”

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.

327 records · Page 19
All sourcesNASA NTRSDOE OSTI
NASA NTRS1999

[Instrument Designs for SOFIA: FOCUS and FORCAST]

As a result of these studies a proposal for FORCAST was submitted to the SOFIA Announcement of Opportunity for Instruments. FORCAST, a facility instrument, was one of the winning proposals. A short description of FORCAST follows: (1) FORCAST is a dual-channel, high-sensitivity, wide-field camera designed to perform continuum imaging in the mid-infrared (4-8 microns) and far-infrared (16-40 microns). The pixels map to 0.75 sec. on the sky and the total field-of-view is 3.2 min. During normal operation a cold MgO dichroic allows imaging in two bands (16-25 and 25-40 microns) enabling high efficiency, simultaneous observations. For imaging at shorter wavelengths (4-8 microns), a mirror replaces the dichroic. FORCAST simultaneously operates two 256 x 256 Si BIB hybrid arrays from Boeing (formerly Rockwell). A Si:As BIB array is used for lambda less than 25 microns while a Si:Sb BIB array is use for lambda greater than 25 microns, FORCAST allows selection of the bandpass independently for each channel via filter wheels. Several specific filters are needed for the Pi science program. Selection of other filters will be based on input from the SOFIA science community. These can include filters to cover specific lines or dust features (such as the PAH features in the 4-8 microns regime). Future upgrades could include a polarimetric capability. The Pi team has extensive experience with all of the technologies used in FORCAST. FORCAST uses mature, low-risk, state-of-the-art technology ensuring highly reliability. In addition, FORCAST will be easy to set up for an observing run and easy to operate (with an intuitive graphical interface). We feel that we can virtually guarantee success on the first flight with FORCAST. FORCAST is designed to complement SIRTF (ISO will no longer be functional). While it cannot achieve the sensitivity levels of SIRTF, FORCAST covers sections of phase space not planned for SIRTF (30-40 microns imaging) and has significantly higher spatial resolution than SIRTF at all wavelengths.

Source record↗
NASA NTRS2022

Trajectory Specification Applied to Terminal Airspace

Despite major efforts to automate air traffic control (ATC), it is still performed by humans today. The complexity and safety-criticality of ATC makes it very difficult to safely automate, but it must be automated to increase airspace capacity (the density of traffic that can be safely managed) and airport throughput (the number of arrivals and departures that an airport can safely handle in a given period of time) beyond what is possible with human controllers. This paper presents the Trajectory Specification (TS) concept, which can help to safely automate ATC. TS is a method of specifying aircraft trajectories such that the position at any given time in flight is restricted to a precisely defined bounding space, removing all ambiguity as to where the flight is allowed to be. The bounding space or volume is determined by tolerances relative to a reference trajectory (position as a function of time). The tolerances are dynamic and are based on the aircraft navigation capabilities and the traffic situation. The tolerances can be a piecewise linear function of time or distance along the route, allowing the tolerances to vary as needed, typically increasing with time for departures and decreasing for arrivals. A Trajectory Specification Language (TSL) is proposed for communicating trajectories from aircraft to ATC as requests and from ATC to aircraft as assignments. The TS concept requires a new generation of airborne Flight Management Systems (FMS) that understand the TSL and can fly the assigned trajectories, but this paper focuses on the ATC functions and the prototype ATC algorithms and software that were developed to test the TS concept. Assuming conformance, TS can guarantee safe separation for an arbitrary length of time even in the event of an ATC system or communication outage. It can help to achieve the high level of safety and reliability needed for ATC automation, and it can also reduce the reliance on ATC backup systems for tactical conflict detection and resolution during normal operation. TS can be applied to any controlled airspace, including enroute, terminal, and urban airspace, but this paper presents algorithms and software for arrival spacing and conflict detection and resolution in the terminal airspace serving a major airport. In a fast-time simulation of a full day of traffic in a major terminal airspace, all conflicts were resolved in near real time, demonstrating the computational feasibility and the preliminary operational feasibility of the TS concept. This paper is a compilation of previous papers, and it adds significant information that was omitted from those papers due to length limitations. It also updates some of the results of those earlier papers due to algorithm refinements and corrections of minor software errors.

air traffic control, trajectory↗
NASA NTRS2004

Evaluation of Open-Source Hard Real Time Software Packages

Reliable software is, at times, hard to find. No piece of software can be guaranteed to work in every situation that may arise during its use here at Glenn Research Center or in space. The job of the Software Assurance (SA) group in the Risk Management Office is to rigorously test the software in an effort to ensure it matches the contract specifications. In some cases the SA team also researches new alternatives for selected software packages. This testing and research is an integral part of the department of Safety and Mission Assurance. Real Time operation in reference to a computer system is a particular style of handing the timing and manner with which inputs and outputs are handled. A real time system executes these commands and appropriate processing within a defined timing constraint. Within this definition there are two other classifications of real time systems: hard and soft. A soft real time system is one in which if the particular timing constraints are not rigidly met there will be no critical results. On the other hand, a hard real time system is one in which if the timing constraints are not met the results could be catastrophic. An example of a soft real time system is a DVD decoder. If the particular piece of data from the input is not decoded and displayed to the screen at exactly the correct moment nothing critical will become of it, the user may not even notice it. However, a hard real time system is needed to control the timing of fuel injections or steering on the Space Shuttle; a delay of even a fraction of a second could be catastrophic in such a complex system. The current real time system employed by most NASA projects is Wind River's VxWorks operating system. This is a proprietary operating system that can be configured to work with many of NASA s needs and it provides very accurate and reliable hard real time performance. The down side is that since it is a proprietary operating system it is also costly to implement. The prospect of replacing this somewhat costly implementation is the focus of one of the SA group s current research projects. The explosion of open source software in the last ten years has led to the development of a multitude of software solutions which were once only produced by major corporations. The benefits of these open projects include faster release and bug patching cycles as well as inexpensive if not free software solutions. The main packages for hard real time solutions under Linux are Real Time Application Interface (RTAI) and two varieties of Real Time Linux (RTL), RTLFree and RTLPro. During my time here at NASA I have been testing various hard real time solutions operating as layers on the Linux Operating System. All testing is being run on an Intel SBC 2590 which is a common embedded hardware platform. The test plan was provided to me by the Software Assurance group at the start of my internship and my job has been to test the systems by developing and executing the test cases on the hardware. These tests are constructed so that the Software Assurance group can get hard test data for a comparison between the open source and proprietary implementations of hard real time solutions.

Mattei, Nicholas S.↗