Search NASA⌕ Search

SEARCH · Search NASA

Results for “adaptive structures response to external stimulation remote or automatic command”

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 361 records · Page 20

TAILSIM Users Guide

The TAILSIM program uses a 4th order Runge-Kutta method to integrate the standard aircraft equations-of-motion (EOM). The EOM determine three translational and three rotational accelerations about the aircraft's body axis reference system. The forces and moments that drive the EOM are determined from aerodynamic coefficients, dynamic derivatives, and control inputs. Values for these terms are determined from linear interpolation of tables that are a function of parameters such as angle-of-attack and surface deflections. Buildup equations combine these terms and dimensionalize them to generate the driving total forces and moments. Features that make TAILSIM applicable to studies of tailplane stall include modeling of the reversible control System, modeling of the pilot performing a load factor and/or airspeed command task, and modeling of vertical gusts. The reversible control system dynamics can be described as two hinged masses connected by a spring. resulting in a fifth order system. The pilot model is a standard form of lead-lag with a time delay applied to an integrated pitch rate and/or airspeed error feedback. The time delay is implemented by a Pade approximation, while the commanded pitch rate is determined by a commanded load factor. Vertical gust inputs include a single 1-cosine gust and a continuous NASA Dryden gust model. These dynamic models. coupled with the use of a nonlinear database, allow the tailplane stall characteristics, elevator response, and resulting aircraft response, to be modeled. A useful output capability of the TAILSIM program is the ability to display multiple post-run plot pages to allow a quick assessment of the time history response. There are 16 plot pages currently available to the user. Each plot page displays 9 parameters. Each parameter can also be displayed individually. on a one plot-per-page format. For a more refined display of the results the program can also create files of tabulated data. which can then be used by other plotting programs. The TAILSIM program was written straightforwardly assuming the user would want to change the database tables, the buildup equations, the output parameters. and the pilot model parameters. A separate database file and input file are automatically read in by the program. The use of an include file to set up all common blocks facilitates easy changing of parameter names and array sizes.

Hiltner, Dale W.↗

Testing of Advanced Capabilities to Enable In-time Safety Management and Assurance for Future Flight Operations

In order to refine an initial Concept of Operations, explore Concepts of Use, and expose/validate requirements for future In-Time Aviation Safety Management Systems (IASMS), testing architectures were created, along with a set of capabilities and underlying information exchange protocols. These systems were conceived and developed based on hazards associated with two envisioned urban area flight domains: (1) highly autonomous small uncrewed aerial systems (sUAS) operating at low altitudes, and (2) highly autonomous air taxis. The initial scope of this development is described in [1]; this report provides an update, focusing on the subsequent developments and test activities. As stated in [1], it is important to note that there are many capabilities already in use by the industry (or soon to be in use) that will play critical roles in future IASMS designs. Those reported here were developed to address a gap in the current state-of-the-art regarding specific hazards/risks, and/or to allow for investigation of the interplay between and across hazard types — particularly regarding how overall safety risk can be reduced or managed effectively. Results of testing and development activities are organized by the operational phase wherein a particular capability would be employed (i.e., preflight, in-flight, and post-flight/off-line). Pre-flight: A set of capabilities were developed to help mitigate safety risk prior to flight (e.g., during flight and mission planning). Results of testing summarize (1) validation activities to raise the Technology Readiness Level (TRL) and (2) evaluation activities where the capabilities were applied to flight/mission planning procedures and used by operators/pilots. For the latter, flight plans were automatically assessed, and operators/pilots were notified of hazardous flight segments so as to enable adjustment of the flight plan and re-evaluation, and/or to better inform go/no-go decisions. Capabilities addressed hazards associated with power consumption, third-party risk, wind, navigation system performance, radiofrequency interference, and proximity to geo-spatial threats (e.g., buildings, trees, and no-fly zones). In-flight: Flight experiments tested capabilities that detect and respond to hazards encountered during flight. In the first series, safety hazards were monitored and assessed onboard, and system-generated mitigation maneuvers were recorded (but not acted upon by the vehicle). In the second series, mitigation maneuver commands directed the aircraft in response to safety hazards (i.e., auto-mitigation). The sUAS used for testing is described in full, as is the test architecture, which included commercial avionics, research avionics, and onboard software designed to detect, assess, and respond to hazards. The onboard system was designed as a run-time assurance framework, consistent with [2] and supportive of both supervisory and automated modes. The primary functions included: real-time risk assessment (RTRA), auto-pilot monitoring, constraint monitoring, and contingency select/triggering. RTRA performs integrated risk assessment considering data from several hazard-related monitors (e.g., battery, motors, navigation, communications, population density, and loss-of-control). Post-flight/off-line: Data monitored and recorded during flights can enable IASMS capabilities that execute after flights have completed (or “off-line”). These include: (1) the ability to identify anomalies and trends that may only be observable when comparing data spanning a number of similar flights; (2) the ability to update and validate pre-flight and in-flight capabilities and any underlying models to improve their performance; (3) the ability to report anomalies/off-nominals that may indicate design changes or maintenance actions are needed; and (4) the ability for humans involved in operations to report safety-relevant observations to help in understanding the flight data and/or the operational context of a flight. Progress on three such capabilities is summarized; the first investigates anomaly detection given a limited set of flight logs and applies an approach previously used for space operations. The second explores what could be identified using a larger set of flight logs, including from web-based forums where flight logs are posted by sUAS autopilot users. The third creates a new means of collecting information on UAS incidents and accidents via the Aviation Safety Reporting System (ASRS).

sUAS↗

Manual for automatic generation of finite element models of spiral bevel gears in mesh

The goal of this research is to develop computer programs that generate finite element models suitable for doing 3D contact analysis of faced milled spiral bevel gears in mesh. A pinion tooth and a gear tooth are created and put in mesh. There are two programs: Points.f and Pat.f to perform the analysis. Points.f is based on the equation of meshing for spiral bevel gears. It uses machine tool settings to solve for an N x M mesh of points on the four surfaces, pinion concave and convex, and gear concave and convex. Points.f creates the file POINTS.OUT, an ASCI file containing N x M points for each surface. (N is the number of node points along the length of the tooth, and M is nodes along the height.) Pat.f reads POINTS.OUT and creates the file tl.out. Tl.out is a series of PATRAN input commands. In addition to the mesh density on the tooth face, additional user specified variables are the number of finite elements through the thickness, and the number of finite elements along the tooth full fillet. A full fillet is assumed to exist for both the pinion and gear.

Bibel, G. D.↗

Global Positioning System Synchronized Active Light Autonomous Docking System

A Global Positioning System Synchronized Active Light Autonomous Docking System (GPSSALADS) for automatically docking a chase vehicle with a target vehicle comprises at least one active light emitting target which is operatively attached to the target vehicle. The target includes a three-dimensional array of concomitantly flashing lights which flash at a controlled common frequency. The GPSSALADS further comprises a visual tracking sensor operatively attached to the chase vehicle for detecting and tracking the target vehicle. Its performance is synchronized with the flash frequency of the lights by a synchronization means which is comprised of first and second internal clocks operatively connected to the active light target and visual tracking sensor, respectively, for providing timing control signals thereto, respectively. The synchronization means further includes first and second Global Positioning System receivers operatively connected to the first and second internal clocks, respectively, for repeatedly providing simultaneous synchronization pulses to the internal clocks, respectively. In addition, the GPSSALADS includes a docking process controller means which is operatively attached to the chase vehicle and is responsive to the visual tracking sensor for producing commands for the guidance and propulsion system of the chase vehicle.

Howard, Richard↗

Global Positioning System Synchronized Active Light Autonomous Docking System

A Global Positioning System Synchronized Active Light Autonomous Docking System (GPSSALADS) for automatically docking a chase vehicle with a target vehicle comprising at least one active light emitting target which is operatively attached to the target vehicle. The target includes a three-dimensional array of concomitantly flashing lights which flash at a controlled common frequency. The GPSSALADS further comprises a visual tracking sensor operatively attached to the chase vehicle for detecting and tracking the target vehicle. Its performance is synchronized with the flash frequency of the lights by a synchronization means which is comprised of first and second internal clocks operatively connected to the active light target and visual tracking sensor, respectively, for providing timing control signals thereto, respectively. The synchronization means further includes first and second Global Positioning System receivers operatively connected to the first and second internal clocks, respectively, for repeatedly providing simultaneous synchronization pulses to the internal clocks, respectively. In addition, the GPSSALADS includes a docking process controller means which is operatively attached to the chase vehicle and is responsive to the visual tracking sensor for producing commands for the guidance and propulsion system of the chase vehicle.

Howard, Richard T.↗

A traverse gravimeter for the lunar surface

A semi-automatic, self-levelling lunar gravimeter was designed for the purpose of measuring gravity at predetermined stops along the route of a lunar rover vehicle to obtain a gravity profile. The traverse gravimeter is completely self-contained and is powered by an internal battery. The gravity sensor is a vibrating string accelerometer (VSA) which is enclosed in a precision oven. Gravity data are obtained by initiating a measurement. After the gravimeter has levelled, the VSA difference frequency is counted down and a gate is generated to enable a crystal-controlled clock to a BCD counter. The BCD counter stores the data which are a measurement of gravity. These data, displayed upon command by the astronaut, are transmitted by voice back to earth. It is expected that the accuracy of the gravimeter will be better than one milligal. Low power, light weight, reliability, and simplicity of operation are major considerations in the design of the gravimeter.

Mamon, G.↗

Flight Deck Interval Management Avionics: Eye-Tracking Analysis

Interval Management (IM) is one NexGen method for achieving airspace efficiencies. In order to initiate IM procedures, Air Traffic Control provides an IM clearance to the IM aircraft's pilots that indicates an intended spacing from another aircraft (the target to follow - or TTF) and the point at which this should be achieved. Pilots enter the clearance in the flight deck IM (FIM) system; and once the TTF's Automatic Dependent Surveillance-Broadcast signal is available, the FIM algorithm generates target speeds to meet that IM goal. This study examined four Avionics Conditions (defined by the instrumentation and location presenting FIM information) and three Notification Methods (defined by the visual and aural alerts that notified pilots to IM-related events). Current commercial pilots flew descents into Dallas/Fort-Worth in a high-fidelity commercial flight deck simulation environment with realistic traffic and communications. All 12 crews experienced each Avionics Condition, where order was counterbalanced over crews. Each crew used only one of the three Notification Methods. This paper presents results from eye tracking data collected from both pilots, including: normalized number of samples falling within FIM displays, normalized heads-up time, noticing time, dwell time on first FIM display look after a new speed, a workload-related metric, and a measure comparing the scan paths of pilot flying and pilot monitoring; and discusses these in the context of other objective (vertical and speed profile deviations, response time to dial in commanded speeds, out-of-speed-conformance and reminder indications) and subjective measures (workload, situation awareness, usability, and operational acceptability).

Latorella, Kara↗

Scheduling and Operations of the ECOSTRESS Mission

This paper describes the development and use of an automated scheduling system for the National Aeronautics and Space Administration’s (NASA) ECOsystem Spaceborne Thermal Radiometer Experiment on Space Station (ECOSTRESS) mission. Key to the success of the ECOSTRESS mission has been the use of automated scheduling in mission analysis pre-launch, and in successful operations where automated scheduling was deployed to address several operational challenges. ECOSTRESS uses an adaptation of the Compressed Large-scale Activity Scheduling and Planning (CLASP) system to automatically select science observations respecting area and point target priorities as well as visibility, illumination, onboard storage, and radiation constraints to satisfy high-level prioritized science campaigns. The ECOSTRESS scheduler was used pre-launch to predict the effectiveness of alternative formulations of science campaign definitions accounting for the impact of data volume, keepout, and orbit/illumination/visibility constraints to derive the initial operational science campaign definitions and priorities. The scheduler was then used after instrument checkout for operations. ECOSTRESS has faced multiple operational challenges relating to instrument firmware and hardware, and the scheduler has been updated several times to address these challenges. The instrument Mass Storage Units (MSUs) had operational issues, requiring the scheduler to plan for and schedule commands to handle intricacies of data management. After many months of operations, both MSUs on the instrument became non-functioning and the firmware of the instrument was updated to bypass the MSUs. A further update to the ECOSTRESS scheduler enabled the scheduler to operate in this new operations mode. The ECOSTRESS scheduler has also been updated to improve handling of along-track uncertainty inherent in International Space Station operations. The flexibility and ease of updating of the automated scheduler has been a significant contributor to successful operations of the ECOSTRESS mission.

Padams, Jordan↗

A Demonstration of a Retrofit Architecture for Intelligent Control and Diagnostics of a Turbofan Engine

A retrofit architecture for intelligent turbofan engine control and diagnostics that changes the fan speed command to maintain thrust is proposed and its demonstration in a piloted flight simulator is described. The objective of the implementation is to increase the level of autonomy of the propulsion system, thereby reducing pilot workload in the presence of anomalies and engine degradation due to wear. The main functions of the architecture are to diagnose the cause of changes in the engine s operation, warning the pilot if necessary, and to adjust the outer loop control reference signal in response to the changes. This requires that the retrofit control architecture contain the capability to determine the changed relationship between fan speed and thrust, and the intelligence to recognize the cause of the change in order to correct it or warn the pilot. The proposed retrofit architecture is able to determine the fan speed setting through recognition of the degradation level of the engine, and it is able to identify specific faults and warn the pilot. In the flight simulator it was demonstrated that when degradation is introduced into an engine with standard fan speed control, the pilot needs to take corrective action to maintain heading. Utilizing the intelligent retrofit control architecture, the engine thrust is automatically adjusted to its expected value, eliminating yaw without pilot intervention.

Litt, Jonathan S.↗

A manned maneuvering unit proximity operations planning and flight guidance display and control system

This task concerns the design, development, testing, and evaluation of a new proximity operations planning and flight guidance display and control system for manned space operations. A forecast, derivative manned maneuvering unit (MMU) was identified as a candidate for the application of a color, highway-in-the-sky display format for the presentation of flight guidance information. A silicon graphics 4D/20-based simulation is being developed to design and test display formats and operations concepts. The simulation includes the following: (1) real-time color graphics generation to provide realistic, dynamic flight guidance displays and control characteristics; (2) real-time graphics generation of spacecraft trajectories; (3) MMU flight dynamics and control characteristics; (4) control algorithms for rotational and translational hand controllers; (5) orbital mechanics effects for rendezvous and chase spacecraft; (6) inclusion of appropriate navigation aids; and (7) measurement of subject performance. The flight planning system under development provides for: (1) selection of appropriate operational modes, including minimum cost, optimum cost, minimum time, and specified ETA; (2) automatic calculation of rendezvous trajectories, en route times, and fuel requirements; (3) and provisions for manual override. Man/machine function allocations in planning and en route flight segments are being evaluated. Planning and en route data are presented on one screen composed of two windows: (1) a map display presenting a view perpendicular to the orbital plane, depicting flight planning trajectory and time data attitude display presenting attitude and course data for use en route; and (2) an attitude display presenting local vertical-local horizontal attitude data superimposed on a highway-in-the-sky or flight channel representation of the flight planned course. Both display formats are presented while the MMU is en route. In addition to these displays, several original display elements are being developed, including a 3DOF flight detector for attitude commanding, a different flight detector for translation commands, and a pictorial representation of velocity deviations.

Gershzohn, Gary R.↗

Notional Airspace Operations Demonstration Plan

The airspace operations demonstration (AOD) is intended to show that the Access 5 Step 1 functional requirements can be met. The demonstration will occur in two phases. The initial on-range phase will be carried out in restricted airspace to demonstrate the cooperative collision avoidance (CCA) functional requirements and to provide risk-reduction for the AOD by allowing the test team to rehearse some elements of the demonstration mission. The CCA system to be used in these flights is based on Automatic Dependent Surveillance-Broadcast (ADS-B) which is a commercially-available system by which airplanes constantly broadcast their current position and altitude to other aircraft and ground resources over a dedicated radio datalink. The final phase will occur in the national airspace (NAS) and will be the formal demonstration of the remainder of the proposed functional requirements. The general objectives of the AOD are as follows: (1) Demonstrate that the UAS can aviate in the NAS (2) Demonstrate that the UAS can navigate in the NAS (3) Demonstrate that the UAS can communicate with the NAS (4) Demonstrate that the UAS can perform selected collision avoidance functions in the NAS (5) Demonstrate that the UAS can evaluate and avoid weather conflicts in the NAS (6) Demonstrate that the UAS can provide adequate command and control in the NAS In addition to the stated objectives, there are a number of goals for the flight demonstration. The demo can be accomplished successfully without achieving these goals, but these goals are to be used as a guideline for preparing for the mission. The goals are: (1) Mission duration of at least 24 hours (2) Loiter over heavy traffic to evaluate the data block issue identified during the Access 5 Airspace Operations Simulations (3) Document the contingency management process and lessons learned (4) Document the coordination process for Ground Control Stations (GCS) handoff (5) Document lessons learned regarding the process of flying in the NAS Preliminary planning for a notional mission to achieve the objectives and goals has been prepared. The planning is intended to serve as a guide for detailed planning of the AOD.

Trongale, Nicholas A.↗

Estimation of Stability and Control Derivatives of an F-15

A technique for real-time estimation of stability and control derivatives (derivatives of moment coefficients with respect to control-surface deflection angles) was used to support a flight demonstration of a concept of an indirect-adaptive intelligent flight control system (IFCS). Traditionally, parameter identification, including estimation of stability and control derivatives, is done post-flight. However, for the indirect-adaptive IFCS concept, parameter identification is required during flight so that the system can modify control laws for a damaged aircraft. The flight demonstration was carried out on a highly modified F-15 airplane (see Figure 1). The main objective was to estimate the stability and control derivatives of the airplane in nearly real time. A secondary goal was to develop a system to automatically assess the quality of the results, so as to be able to tell a learning neural network which data to use. Parameter estimation was performed by use of Fourier-transform regression (FTR) a technique developed at NASA Langley Research Center. FTR is an equation- error technique that operates in the frequency domain. Data are put into the frequency domain by use of a recursive Fourier transform for a discrete frequency set. This calculation simplifies many subsequent calculations, removes biases, and automatically filters out data beyond the chosen frequency range. FTR as applied here was tailored to work with pilot inputs, which produce correlated surface positions that prevent accurate parameter estimates, by replacing half the derivatives with predicted values. FTR was also set up to work only on a recent window of data, to accommodate changes in flight condition. A system of confidence measures was developed to identify quality-parameter estimates that a learning neural network could use. This system judged the estimates primarily on the basis of their estimated variances and of the level of aircraft response. The resulting FTR system was implemented in the Simulink software system and auto-coded in the C programming language for use on the Airborne Research Test System (ARTS II) computer installed in the F-15 airplane. The Simulink model was also used in a control room that utilizes the Ring Buffered Network Bus hardware and software, making it possible to evaluate test points during flights. In-flight parameter estimation was done for piloted and automated maneuvers, primarily at three test conditions. Figure 2 shows results for pitching moment due to symmetric stabilator actuations for a series of three pitch doublet maneuvers (in a doublet maneuver, a command to change attitude in a given direction by a given amount is followed immediately by a command to change attitude in the opposite direction by the same amount). A time window of 5 seconds was used. The portions of the curves shown in red are those that passed the confidence tests. The technique showed good convergence for most derivatives for both kinds of maneuvers - typically within a few seconds. The confidence tests were marginally successful, and it would be necessary to refine them for use in an IFCS.

Smith, Mark↗

Project: Apollo 15

The 12-day Apollo 15 mission, scheduled for launch on July 26 to carry out the fourth United States manned exploration of the Moon, will: Double the time and extend tenfold the range of lunar surface exploration as compared with earlier missions; Deploy the third in a network of automatic scientific stations; Conduct a new group of experiments in lunar orbit; and Return to Earth a variety of lunar rock and soil samples. Scientists expect the results will greatly increase man's knowledge both of the Moon's history and composition and of the evolution and dynamic interaction of the Sun-Earth system. This is so because the dry, airless, lifeless Moon still bears records of solar radiation and the early years of solar system history that have been erased from Earth. Observations of current lunar events also may increase understanding of similar processes on Earth, such as earthquakes. The Apollo 15 Lunar module will make its descent over the Apennine peaks, one of the highest mountain ranges on the Moon, to land near the rim of the canyon-like Hadley Rille. From this Hadley-Apennine lunar base, between the mountain range and the rille, Commander David R. Scott and Lunar Module Pilot James B. Irwin will explore several kilometers from the lunar module, driving an electric-powered lunar roving vehicle for the first time on the Moon. Scott and Irwin will leave the lunar module for three exploration periods to emplace scientific experiments on the lunar surface and to make detailed geologic investigations of formations in the Apennine foothills, along the Hadley Rille rim, and to other geologic structures. The three previous manned landings were made by Apollo 11 at Tranquillity Base, Apollo 12 in the Ocean of Storms and Apollo 14 at Fra Mauro.

Source record↗

Registering and resampling images in STSDAS

Registering different images can be difficult, especially if the images to be registered are images at different wavelengths, where features in one image may look entirely different or be absent from the second image. Using two new packages soon to be added to the STSDAS package, REGISTER and RESAMPLE, this job is done automatically. The REGISTER package allows the user to determine the amount of translation, rotation, and/or magnification needed to make two images, spectra, or time series congruent. The methods implemented to compute the registration parameters use: a set of the pixel coordinates of the same features identified in two files, or the FITS coordinate transformation parameters in the headers of two data files, or a single feature identified as the peak of a cross-correlation between two vectors. The coefficients describing the registration are defined by the equations (for a two-dimensional image): x = a + bx + cy, y = d + ex + fy, where (X,Y) are the pixel coordinates of a feature in the reference image, (x,y) are the pixel coordinates of a feature in the secondary image, and the computed coefficients are a, b, c, d, e, and f. Results may be produced by linking the output of REGISTER to RESAMPLE in a command language procedure. The output from REGISTER and the input to RESAMPLE consists of a matrix of coefficients (a through f above) fully specifying the registration. The RESAMPLE package resamples simple vector or image data for a given amount of translation, rotation (images only), and magnification, or reflection of the science data. Specific options included are: image rotation about the FITS reference pixel; scale changes, i.e. magnification or demagnification (for images, independently on both axes); simple translation; reflection (for images, about one or both axes); and resampling and registration to a reference data set. Output from the RESAMPLE task is the resampled image which may then be displayed and compared with the reference image.

Williamson, R. L., II↗

High-performance mass storage system for workstations

Reduced Instruction Set Computer (RISC) workstations and Personnel Computers (PC) are very popular tools for office automation, command and control, scientific analysis, database management, and many other applications. However, when using Input/Output (I/O) intensive applications, the RISC workstations and PC's are often overburdened with the tasks of collecting, staging, storing, and distributing data. Also, by using standard high-performance peripherals and storage devices, the I/O function can still be a common bottleneck process. Therefore, the high-performance mass storage system, developed by Loral AeroSys' Independent Research and Development (IR&D) engineers, can offload a RISC workstation of I/O related functions and provide high-performance I/O functions and external interfaces. The high-performance mass storage system has the capabilities to ingest high-speed real-time data, perform signal or image processing, and stage, archive, and distribute the data. This mass storage system uses a hierarchical storage structure, thus reducing the total data storage cost, while maintaining high-I/O performance. The high-performance mass storage system is a network of low-cost parallel processors and storage devices. The nodes in the network have special I/O functions such as: SCSI controller, Ethernet controller, gateway controller, RS232 controller, IEEE488 controller, and digital/analog converter. The nodes are interconnected through high-speed direct memory access links to form a network. The topology of the network is easily reconfigurable to maximize system throughput for various applications. This high-performance mass storage system takes advantage of a 'busless' architecture for maximum expandability. The mass storage system consists of magnetic disks, a WORM optical disk jukebox, and an 8mm helical scan tape to form a hierarchical storage structure. Commonly used files are kept in the magnetic disk for fast retrieval. The optical disks are used as archive media, and the tapes are used as backup media. The storage system is managed by the IEEE mass storage reference model-based UniTree software package. UniTree software will keep track of all files in the system, will automatically migrate the lesser used files to archive media, and will stage the files when needed by the system. The user can access the files without knowledge of their physical location. The high-performance mass storage system developed by Loral AeroSys will significantly boost the system I/O performance and reduce the overall data storage cost. This storage system provides a highly flexible and cost-effective architecture for a variety of applications (e.g., realtime data acquisition with a signal and image processing requirement, long-term data archiving and distribution, and image analysis and enhancement).

Chiang, T.↗

Developing Concepts of Operations Using Multi-Step Tool Techniques With Large Language Models

The National Aeronautics and Space Administration (NASA) Air Mobility Pathfinders (AMP) project is developing and evaluating concepts of operations (ConOps) for safe, secure, and scalable Urban Air Mobility (UAM) operations. The AMP project’s Operational Concepts, Architecture, and Requirements Integration (OCARI) Team is using a Model Based System Engineering (MBSE) approach for integration, interoperability, and traceability of Advanced Air Mobility (AAM) ecosystems centered around urban air taxi services. The team’s goal is to define structures and behaviors needed for system feasibility, readiness, and interoperability, establish a UAM knowledge base, and trace and validate assumptions and requirements relevant to AAM. NASA Langley Research Center (LaRC) is spearheading an innovative digital engineering approach to integrate, communicate, and facilitate the research of multi-modal transportation systems. The Knowledge-based Digital Platform (KbDP) is a concept being developed that ties the workflows of Project Managers (PM), Principal Investigators (PI), and System Engineers together across organizational boundaries. It does so through the management of an information database defined by mathematical, data science, and system engineering principles. Machine Learning (ML) algorithms play a key role in this concept by extracting meaningful knowledge from relational and graph databases, document repositories, and system artifacts, which the human user leverages to greatly improve the efficiency and effectiveness of their research. Recent advancements in the field of Large Language Models (LLMs), specifically models trained for tool use, such as Command-R , now allow for the reliable implementation of single-step and multi-step tool-centric systems. These techniques provide the LLM with a set of tools, in our case Python functions, that can be called on to answer a much wider range of questions compared to LLMs implemented using a traditional single-source or Retrieval Augmented Generation (RAG) approach. Through this method, the LLM can pull information from multiple data sources, such as relational or graph databases, document repositories, application programming interfaces (APIs), and SysML artifacts depending on the user’s question. The LLM can also output the information in a variety of different formats, using output generation tools, such as CSV, UML, or SysML artifacts. Additionally, tools can be assigned roles and can work together to provide answers to queries in an “agent” like approach, similar to that implemented by Microsoft’s AutoGen framework where different agents can converse with each other to accomplish tasks. Previously, our team developed a chatbot system with “agent like” functionality in the form of different “modes” the user could select from a user interface (UI), this architecture can be seen on the left in figure 1. Three different modes were implemented, the first mode allowed the LLM to utilize the structures and algorithms within a graph database to trace UAM requirements. The second mode gave the LLM access to a vector search capable of providing relevant information from thousands of document pages related to UAM ConOps and requirements. The third mode served as a general assistant where users could enter open-ended questions and custom prompts to utilize the LLM for different use-cases. This system improved the process surrounding generating and analyzing information related to UAM requirements, however, the implementation provided a clunky user experience. Users were required to know what mode to select within the UI in advance before entering their question to the selected tool. Moreover, the different tools were isolated from each other, they lacked bidirectional links that would allow for tools to collaborate to generate better responses. Our team is working on a new architecture, seen on the right in the below figure, with the goal to address many of the UX shortcomings of our original system while improving the accuracy and depth of responses from the LLM. This new system will automatically select the appropriate tool to use based off the user’s question. Each tool will be capable of calling on any of the other tools available to the LLM, resulting in a collaborative pipeline where tools can pass data between other tools until enough data is received to generate an answer to the user’s question. Using a locally deployed, open-source, LLM, the NASA OCARI team, in collaboration with Collins Aerospace, will implement a prototype application that will bridge knowledge across multiple sources to assist System Engineers (SEs) with requirements discovery and tracing, research question and use case identification, and assumption validation. Such a system will also allow SEs to more easily, and intuitively, explore the AAM ecosystem, ultimately improving the efficiency and effectiveness of the SE's research and decision-making processes surrounding ConOps development and validation. In this session, our team will provide a video demonstration of our new prototype architecture in action. We will also present an overview of our prototype system architecture and talk about its advantages over traditional LLM deployments along with how those advantages can provide additional value to the field of System Engineering.

systems engineering↗

Design Description of the X-33 Avionics Architecture

In this paper, we provide a design description of the X-33 avionics architecture. The X-33 is an autonomous Single Stage to Orbit (SSTO) launch vehicle currently being developed by Lockheed Martin for NASA as a technology demonstrator for the VentureStar Reusable Launch Vehicle (RLV). The X-33 avionics provides autonomous control of die vehicle throughout takeoff, ascent, descent, approach, landing, rollout, and vehicle safing. During flight the avionics provides communication to the range through uplinked commands and downlinked telemetry. During pre-launch and post-safing activities, the avionics provides interfaces to ground support consoles that perform vehicle flight preparations and maintenance. The X-33 Avionics is a hybrid of centralized and distributed processing elements connected by three dual redundant Mil-Std 1553 data buses. These data buses are controlled by a central processing suite located in the avionics bay and composed of triplex redundant Vehicle Mission Computers (VMCs). The VMCs integrate mission management, guidance, navigation, flight control, subsystem control and redundancy management functions. The vehicle sensors, effectors and subsystems are interfaced directly to the centralized VMCs as remote terminals or through dual redundant Data Interface Units (DIUs). The DIUs are located forward and aft of the avionics bay and provide signal conditioning, health monitoring, low level subsystem control and data interface functions. Each VMC is connected to all three redundant 1553 data buses for monitoring and provides a complete identical data set to the processing algorithms. This enables bus faults to be detected and reconfigured through a voted bus control configuration. Data is also shared between VMCs though a cross channel data link that is implemented in hardware and controlled by AlliedSignal's Fault Tolerant Executive (FTE). The FTE synchronizes processors within the VMC and synchronizes redundant VMCs to each other. The FTE provides an output-voting plane to detect, isolate and contain faults due to internal hardware or software faults and reconfigures the VMCs to accommodate these faults. Critical data in the 1553 messages are scheduled and synchronized to specific processing frames in order to minimize data latency. In order to achieve an open architecture, military and commercial off-the-shelf equipment is incorporated using common processors, standard VME backplanes and chassis, the VxWorks operating system, and MartixX for automatic code generation. The use of off-the-shelf tools and equipment helps reduce development time and enables software reuse. The open architecture allows for technology insertion, while the distributed modular elements allow for expansion to increased redundancy levels to meet the higher reliability goals of future RLVs.

Reichenfeld, Curtis J.↗

Wireless Integrated Microelectronic Vacuum Sensor System

NASA Stennis Space Center's (SSC's) large rocket engine test facility requires the use of liquid propellants, including the use of cryogenic fluids like liquid hydrogen as fuel, and liquid oxygen as an oxidizer (gases which have been liquefied at very low temperatures). These fluids require special handling, storage, and transfer technology. The biggest problem associated with transferring cryogenic liquids is product loss due to heat transfer. Vacuum jacketed piping is specifically designed to maintain high thermal efficiency so that cryogenic liquids can be transferred with minimal heat transfer. A vacuum jacketed pipe is essentially two pipes in one. There is an inner carrier pipe, in which the cryogenic liquid is actually transferred, and an outer jacket pipe that supports and seals the vacuum insulation, forming the "vacuum jacket." The integrity of the vacuum jacketed transmission lines that transfer the cryogenic fluid from delivery barges to the test stand must be maintained prior to and during engine testing. To monitor the vacuum in these vacuum jacketed transmission lines, vacuum gauge readings are used. At SSC, vacuum gauge measurements are done on a manual rotation basis with two technicians, each using a handheld instrument. Manual collection of vacuum data is labor intensive and uses valuable personnel time. Additionally, there are times when personnel cannot collect the data in a timely fashion (i.e., when a leak is detected, measurements must be taken more often). Additionally, distribution of this data to all interested parties can be cumbersome. To simplify the vacuum-gauge data collection process, automate the data collection, and decrease the labor costs associated with acquiring these measurements, an automated system that monitors the existing gauges was developed by Invocon, Inc. For this project, Invocon developed a Wireless Integrated Microelectronic Vacuum Sensor System (WIMVSS) that provides the ability to gather vacuum-gauge measurements automatically and wirelessly, in near-real time - using a low-maintenance, lowpower sensor mesh network. The WIMVSS operates by using a self-configuring mesh network of wireless sensor units. Mesh networking is a type of networking where each sensor or node can capture and disseminate its own data, but also serve as a relay to receive and transmit data from other sensors. Each sensor node can synchronize with adjacent sensors, and propagate data from one sensor to the next, until the destination is reached. In this case, the destination is a Network Interface Unit (NIU). The WIMVSS sensors are mounted on the existing vacuum gauges. Information gathered by the sensors is sent to the NIU. Because of the mesh networking, if a sensor cannot directly send the data to the NIU, it can be propagated through the network of sensors. The NIU requires antenna access to the sensor units, AC power, and an Ethernet connection. The NIU bridges the sensor network to a WIMVSS server via an Ethernet connection. The server is configured with a database, a Web server, and proprietary interface software that makes it possible for the vacuum measurements from vacuum jacketed fluid lines to be saved, retrieved, and then displayed from any Web-enabled PC that has access to the Internet. Authorized users can then simply access the data from any PC with Internet connection. Commands can also be sent directly from the Web interface for control and maintenance of the sensor network. The technology enabled by the WIMVSS decreases labor required for gathering vacuum measurements, increases access to vacuum data by making it available on any computer with access to the Internet, increases the frequency with which data points can be acquired for evaluating the system, and decreases the recurring cost of the sensors by using off-the-shelf components and integrating these with heritage vacuum gauges.

Krug, Eric↗