SEARCH · Engineering Papers

Results for “trigger concepts and systems”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

63 records · Page 4

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Systemic Risk From the Perspective of Climate, Environmental and Disaster Risk Science and Practice

Understanding and managing systemic risk is more important than ever due to our immense global connectivity (e.g., between sectors, such as food-health-water-energy, countries and continents, down to individuals). Despite the fact that the notion of systemic risk is several decades old, the term is used in diverse ways across different disciplines (e.g., financial systems, medicine, earth system sciences, disaster risk research and climate science). Triggered by the repercussions of the global financial crisis of the late 2000s, and more recently the COVID-19 pandemic, which are clear realization of systemic risk, the perception of systemic risk has often been focused on global and catastrophic or even existential risks. Systemic risk, however, can be seen as a feature of systems at all possible scales (e.g., global, national, regional, local) with system boundaries varying depending on the context. Addressing current societal challenges, such as climate change, in terms of systemic risk requires integrating different systems perspectives and fostering system thinking, while implementing key intergovernmental agendas, such as the Paris Agreement, the Sendai Framework for Disaster Risk Reduction and the Sustainable Development Goals. Based on insights gained and knowledge collected from an expert workshop, literature review and expert elicitation, we give an integrated perspective of climate, environmental and disaster risk science and practice on systemic risk as summarized in a Briefing Note to the International Science Council. We provide an overview of concepts of systemic risk that have evolved over time and identify commonalities across terminologies and perspectives associated with systemic risk used in different contexts. Key attributes of systemic risk are outlined without prescribing a single definition, and information and data requirements are discussed that are essential for a better and more actionable understanding of the systemic nature of risk. Finally, the opportunities to connect research and policy for addressing systemic risk are highlighted.

systemic risk↗

NASA NTRS2016

The LOFT Mission Concept - A Status Update

The Large Observatory For x-ray Timing (LOFT) is a mission concept which was proposed to ESA as M3 and M4 candidate in the framework of the Cosmic Vision 2015-2025 program. Thanks to the unprecedented combination of effective area and spectral resolution of its main instrument and the uniquely large field of view of its wide field monitor, LOFT will be able to study the behaviour of matter in extreme conditions such as the strong gravitational field in the innermost regions close to black holes and neutron stars and the supra-nuclear densities in the interiors of neutron stars. The science payload is based on a Large Area Detector (LAD, is greater than 8m2 effective area, 2-30 keV, 240 eV spectral resolution, 1 degree collimated field of view) and a Wide Field Monitor (WFM, 2-50 keV, 4 steradian field of view, 1 arcmin source location accuracy, 300 eV spectral resolution). The WFM is equipped with an on-board system for bright events (e.g., GRB) localization. The trigger time and position of these events are broadcast to the ground within 30 s from discovery. In this paper we present the current technical and programmatic status of the mission.

Silicon detectors↗

NASA NTRS1986

The Central Nervous Connections Involved in the Vomiting Reflex

The vomiting reflex may be elicited by a number of different types or classes of stimuli involving many varieties of receptor structures and considerable diversity in afferent pathways and central connections. Central relay or mediating structures thus may vary widely according to the type of initial emetic stimulus. The emetic circuits which have been most completely delineated to date are probably those in which the Chemoreceptor Trigger Zone (CTZ) in the Area Postrema (AP) functions as a key mediating structure. Even in this system, however, there are large gaps in our knowledge of the nerve tracts and central nervous connections involved. Knowledge of most other emetic circuits subserving the emetic reflex resulting from many diverse types of stimuli such, for example, as emotional stress (e.g. psychogenic vomiting, Wruble et al. 1982), pain (e.g. testicular trauma), and chemical or mechanical irritation of the gastrointestinal tract or urinary tract is quite incomplete at this time, thus precluding any very adequate description of their central connections at present. One physiological system, however, which has received considerable attention recently in relation to the vomiting reflex elicited by motion stimuli is the vestibular system. Due to the paucity of data on central nervous connections of several or the non-vestibular types of emetic stimuli cited above, we will devote most of our attention in this brief review to the central connections of the vestibular system which seem likely to be involved in the vomiting response to motion stimuli. However, the latter part of the review will be concerned with the concept of the reticular vomiting centre in relation to the ParviCellular Reticular Formation (PCRF), and will thus probably pertain to all of the many classes of emetic stimuli since it will address the question of the final common emetic pathway.

Brizzee, K. R.↗

NASA NTRS1994

A new communication protocol family for a distributed spacecraft control system

In this paper we describe the concepts behind and architecture of a communication protocol family, which was designed to fulfill the communication requirements of ESOC's new distributed spacecraft control system SCOS 2. A distributed spacecraft control system needs a data delivery subsystem to be used for telemetry (TLM) distribution, telecommand (TLC) dispatch and inter-application communication, characterized by the following properties: reliability, so that any operational workstation is guaranteed to receive the data it needs to accomplish its role; efficiency, so that the telemetry distribution, even for missions with high telemetry rates, does not cause a degradation of the overall control system performance; scalability, so that the network is not the bottleneck both in terms of bandwidth and reconfiguration; flexibility, so that it can be efficiently used in many different situations. The new protocol family which satisfies the above requirements is built on top of widely used communication protocols (UDP and TCP), provides reliable point-to-point and broadcast communication (UDP+) and is implemented in C++. Reliability is achieved using a retransmission mechanism based on a sequence numbering scheme. Such a scheme allows to have cost-effective performances compared to the traditional protocols, because retransmission is only triggered by applications which explicitly need reliability. This flexibility enables applications with different profiles to take advantage of the available protocols, so that the best rate between sped and reliability can be achieved case by case.

Baldi, Andrea↗

NASA NTRS2004

Multifunctional Inflatable Structure Being Developed for the PowerSphere Concept

NASA has funded a collaborative team of The Aerospace Corporation, ILC Dover, Lockheed Martin, and NASA Glenn Research Center to develop the Multifunctional Inflatable Structure (MIS) for a "PowerSphere" concept through a NASA Research Announcement. This power system concept has several advantages, including a high collection area, low weight and stowage volume, and the elimination of all solar array pointing mechanisms. The current 3-year effort will culminate with the fabrication and testing of a fully functional engineering development unit. The baseline design of the Power-Sphere consists of two opposing semispherical domes connected to a central spacecraft. Each semispherical dome consists of hexagonal and pentagonal solar cell panels that together form a geodetic sphere. Inflatable ultraviolet (UV) rigidizable tubular hinges between the solar cell panels and UV rigidizable isogrid center columns with imbedded flex circuitry form the MIS. The reference configuration for the PowerSphere is a 0.6-m-diameter (fully deployed) spacecraft with a total mass budget of 4 kg (1 kg for PowerSphere, 3 kg for spacecraft) capable of producing 29 W of electricity with 10-percent-efficient thin-film solar cells. In a stowed configuration, the solar cell panels will be folded sequentially to the outside of the instrument decks. The center column will be z-folded between the instrument decks and the spacecraft housing for packaging. The instrument panel will secure the z-folded stack with launch ties. After launch, once the release tie is triggered, the center column and hinge tubes will inflate and be rigidized in their final configurations by ultraviolet radiation. The overall PowerSphere deployment sequence is shown pictorially in the following illustration.

Peterson, Todd T.↗

NASA NTRS2011

Tracking Object Existence From an Autonomous Patrol Vehicle

An autonomous vehicle patrols a large region, during which an algorithm receives measurements of detected potential objects within its sensor range. The goal of the algorithm is to track all objects in the region over time. This problem differs from traditional multi-target tracking scenarios because the region of interest is much larger than the sensor range and relies on the movement of the sensor through this region for coverage. The goal is to know whether anything has changed between visits to the same location. In particular, two kinds of alert conditions must be detected: (1) a previously detected object has disappeared and (2) a new object has appeared in a location already checked. For the time an object is within sensor range, the object can be assumed to remain stationary, changing position only between visits. The problem is difficult because the upstream object detection processing is likely to make many errors, resulting in heavy clutter (false positives) and missed detections (false negatives), and because only noisy, bearings-only measurements are available. This work has three main goals: (1) Associate incoming measurements with known objects or mark them as new objects or false positives, as appropriate. For this, a multiple hypothesis tracker was adapted to this scenario. (2) Localize the objects using multiple bearings-only measurements to provide estimates of global position (e.g., latitude and longitude). A nonlinear Kalman filter extension provides these 2D position estimates using the 1D measurements. (3) Calculate the probability that a suspected object truly exists (in the estimated position), and determine whether alert conditions have been triggered (for new objects or disappeared objects). The concept of a probability of existence was created, and a new Bayesian method for updating this probability at each time step was developed. A probabilistic multiple hypothesis approach is chosen because of its superiority in handling the uncertainty arising from errors in sensors and upstream processes. However, traditional target tracking methods typically assume a stationary detection volume of interest, whereas in this case, one must make adjustments for being able to see only a small portion of the region of interest and understand when an alert situation has occurred. To track object existence inside and outside the vehicle's sensor range, a probability of existence was defined for each hypothesized object, and this value was updated at every time step in a Bayesian manner based on expected characteristics of the sensor and object and whether that object has been detected in the most recent time step. Then, this value feeds into a sequential probability ratio test (SPRT) to determine the status of the object (suspected, confirmed, or deleted). Alerts are sent upon selected status transitions. Additionally, in order to track objects that move in and out of sensor range and update the probability of existence appropriately a variable probability detection has been defined and the hypothesis probability equations have been re-derived to accommodate this change. Unsupervised object tracking is a pervasive issue in automated perception systems. This work could apply to any mobile platform (ground vehicle, sea vessel, air vehicle, or orbiter) that intermittently revisits regions of interest and needs to determine whether anything interesting has changed.

Wolf, Michael↗

NASA NTRS2018

Using the cFS Command and Data Dictionary (CCDD) to Automate Software Development on Habulous

Final paper is attached. The NASA developed Core Flight System (cFS) is a reusable software architecture that has been used on multiple spaceflight missions. By using this framework, missions are able to reuse code from other missions, as well as leverage deployment onto similar computer architectures (i.e. not "reinvent the wheel" on each new mission). The success in the cFS concept can be seen in the large number of projects using cFS at FSW-2018. The Habulous project is an Earth-based testbed, used for hardware and software that may one day be used on a future space habitat unit, with many participating groups from various NASA centers and aerospace organizations around the country. The distributed nature of the various teams mean that defining (and following) an interface definition is critical on the project. Additionally, since various groups use various types of computer hardware (32/64-bit, big/little endian, Linux/VxWorks/Windows) many additional complications exist in interfacing all the various components into a final integrated system. cFS is used on the majority the flight software (FSW) in running in Habulous. But some subsystems have elected to not use cFS, and use a software bridge (called SBN_lib) to interact with the other cFS nodes in Habulous. In order to most efficiently develop the FSW, a central database is used to define and store each message sent by cFS. A Command and Data Dictionary (CDD) is something nearly universal on spacecraft, but as a team we worked to develop the CDD before the SW development was complete, and not treat it like "as built" documentation. To manage the CDD, the cFS Command and Data Dictionary (CCDD) tool was chosen (available from NASA as open source software). The CCDD tool has successfully been used to automate/autocode a large amount of software used on Habulous, as we are hoping to use it to define even more items in the future (time-triggered Ethernet (TTE) network maps, CPU scheduling). Additionally, Habulous has been exploring the use of cFS on wildly heterogeneous CPUs, and how to coordinate all those various machines using/extending the software bus â€“ network (SBN) application in cFS, as well as TTE to coordinate message passing between various synchronized machines. The major topics to be covered in the presentation are: (1) Updating to the CCSDS_v2 extended headers (and using CPU# as subsystem ID). (2) Managing all the message identification numbers for each cFS message sent/received on any of the various CPUs. (3) Using the CCDD information to automatically generate the C-header files that define the structure for all software bus (SB) commands/telemetry messages. (4) Using the CCDD to automatically generate XML Telemetry and Command Exchange (XTCE) files, which streams display production/integration/testing in a web based display architecture (5) Extending/customizing SBN to pass messages among computers on multiple networks. (6) Using "Protobetter" inside SBN to manage different endian-ness/architectures. (7) Using SBN_lib to allow non-cFS node to communicate with cFS nodes. (8) Developing TTE network and schedule tables for all the various CPUs to use.

Hirsh, Robert L.↗

NASA NTRS2007

Loss-of-Control-Inhibitor Systems for Aircraft

Systems to provide improved tactile feedback to aircraft pilots are being developed to help the pilots maintain harmony between their control actions and the positions of aircraft control surfaces, thereby helping to prevent loss of control. A system of this type, denoted a loss-of-control-inhibitor system (LOCIS) can be implemented as a relatively simple addition to almost any pre-existing flight-control system. The LOCIS concept offers at least a partial solution to the problem of (1) keeping a pilot aware of the state of the control system and the aircraft and (2) maintaining sufficient control under conditions that, as described below, have been known to lead to loss of control. Current commercial aircraft exhibit uneven responses of primary flight-control surfaces to aggressive pilot control commands, leading to deterioration of pilots ability to control their aircraft. In severe cases, this phenomenon can result in loss of control and consequent loss of aircraft. For an older aircraft equipped with a purely mechanical control system, the loss of harmony between a pilot s command action and the control- surface response can be attributed to compliance in the control system (caused, for example, by stretching of control cables, flexing of push rods, or servo-valve distortion). In a newer aircraft equipped with a fly-by-wire control system, the major contributions to loss of harmony between the pilot and the control surfaces are delays attributable to computer cycle time, control shaping, filtering, aliasing, servo-valve distortion, and actuator rate limiting. In addition, a fly-by-wire control system provides no tactile feedback that would enable the pilot to sense such features of the control state as surface flutter, surface jam, position limiting, actuator rate limiting, and control limiting imposed by the aircraft operational envelope. Hence, for example, when a pilot is involved in aggressive closed-loop maneuvering, as when encountering a wake-vortex upset on final landing approach, the control-surface delay can lead to loss of control. Aggressive piloting can be triggered and exacerbated by control-system anomalies, which the pilot cannot diagnose because of the lack of symptoms caused by the absence of feedback through the controls. The purpose served by a LOCIS is to counteract these adverse effects by providing real-time feedback that notifies the pilot that the aircraft is tending to lag the pilot s commands. A LOCIS (see figure) includes cockpit control input-position sensors, control-surface output-position sensors, variable dampers (for example, shock absorbers containing magneto-rheological fluids such that the damping forces can be varied within times of the order of milliseconds by varying applied magnetic fields) attached to the cockpit control levers, electromagnet coils to apply the magnetic fields, and feedback control circuits to drive the electromagnet coils. The feedback control gains are chosen so that the current applied to each electromagnet coil results in a damping force that increases in a suitable nonlinear manner (e.g., exponentially) with the difference between the actual and commanded positions of the affected control surface. The increasing damping force both alerts the pilot to the onset of a potentially dangerous situation and resists the pilot s effort to command a control surface to change position at an excessive rate

AHarrah, Ralph C.↗

NASA NTRSDate not supplied

Using Open Standards and NASA Open Source Simulation Tools to Model Artemis Base Camp Mission Timelines

The United States’ National Aeronautics and Space Administration (NASA) has announced that the Artemis Program will return humans to the Moon, establishing a persistent presence with the Artemis Base Camp (ABC), and extend human exploration to Mars. The NASA Exploration Systems Simulations (NExSyS) team at NASA’s Johnson Space Center is using internationally developed simulation interoperability standards and NASA open source simulation tools to support Artemis concept, analysis, designs, development, training, and ultimately operations. The NExSyS team has been tasked to support early ABC architecture and mission analysis using mission time lines developed by the crew operations mission planning team. The NExSyS team is developing a distributed simulation framework with initial Artemis element implementations to model the ABC mission timelines using the international simulation interoperability standard High Level Architecture (HLA), the Simulation Interoperability Standards Organization’s Space Reference Federation Object Model (SpaceFOM), the NASA open source Trick Simulation Environment, and another NASA open source interface package called TrickHLA. The ABC architecture is composed of a number of key surface elements and resources. Some examples of modeled elements (also known as entities) are landers, habitats, rovers, logistics carriers, and astronauts. Some examples of modeled transferable and consumable resources are power, water, oxygen, nitrogen, scientific samples, and food. These entities and resources are modeled in a collection of individual simulations called Federates. A coordinated collection of interoperable federates is called a Federation and when these federates are tied together in a coordinated simulation run, it is referred to as a Federation Execution. The federates communicate through HLA using data exchange formats defined by a collection of machine readable files called Federation Object Models (FOMs). These FOM files are based on extensions to the SpaceFOM. This enables the instantiation and sharing of objects and interactions between federates in the federation. These provide for entity and resource tracking, object transfer, and data collection. Federate interactions are used to trigger events and notify federates of entity or resource transfers. For the initial implementation, the constituent federates are Trick-based simulations that use TrickHLA to provide the required HLA-base interoperability. These Trick-based simulations provide the required modeling for the individual Artemis elements along with the associated element resources. These federates provide a means to explore traverses between surface elements and exploration sites as scheduled in a mission timeline and explore the affects traverse times have on the overall mission timeline. The mission time lines are modeled using a Trick input file event handling capabilities. Each timeline operation is handled as individual simulation events, and triggered based on previous event status, time of operation, and simulated task completions. In addition, the ABC Federation can be used to perform Monte Carlo analysis. The Monte Carlo tool can vary the inputs, timings, and malfunctions to show how various contingencies in the mission can affect the mission timeline.

Keaton Craig Dodd↗