Results for “topological tools” — Page 8

NASA NTRS1993

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.↗

NASA NTRSDate not supplied

Advances in Modeling Solar System Internet Structures and their Data Flows

With an ever-increasing presence in space, there is also an increasing burden on existing communications infrastructure. We are heading towards an inflection point where the traditional approach of scheduled, single-path communications for space will no longer be viable. One answer is Delay Tolerant Networking (DTN), which takes the once disparate system of point-to-point links and unifies them in a networked architecture, thereby making communications more scalable. However, much work remains for discovering and harnessing the underlying theory of DTN. For example, in the terrestrial setting the interplay between routing domains is well-understood, however this is not the case in DTNs. In this paper, we build up the fundamental foundations of DTN, with an emphasis on modeling time varying networks and data flows across them, with examples of cross-domain routing in a DTN. A lofty goal of DTN is to enable the so-called Solar System Internet (SSI), which implies a standardized and robust suite of protocols. These protocols include routing across disconnected networks using store, carry, and forward mechanisms, which is necessary due to the disconnections, delays, and mobility intrinsic to space networks. Due to these factors, each of which generalize traditional networking, there is a deep and rich theory of DTNs. Here we build off of past successes to broaden this theory while striving to keep actionable results a goal for future implementations and operations. The approach includes modeling the unicast, broadcast, and multicast communications using the language of hypergraphs, which capture the geometric properties of such networked communications algebraically. Also inherent to these networks is their time-varying nature, particularly given mobility, and hence we also cultivate modeling techniques that respect this time dependence. This leads us to develop models using tools from category theory and algebraic geometry, which provide a language well-suited to describing synchronization and optimization over such networks. We also introduce and study a novel generalization of curvature applicable to time-evolving networks, which provides quantitative controls on diffusion processes on the network. Because an interplanetary network would feature links with propagation delays the preclude discovery (feedback) mechanisms, they will always feature a scheduled component. However, it is beneficial to support discovery where possible. While DTNs do not yet have strong definitions for their analogues of autonomous systems or network areas, we show how to join dynamic and schedule-based routing domains, using the language of sheaves, which marks progress towards such definitions. We conclude with a discussion of the progress made, as well as suggestions for future work.

Delay Tolerant Networking↗

NASA NTRS2010

Streamlining Payload Integration

Payload integration onto space transport vehicles and the International Space Station (ISS) is a complex process. Yet, cargo transport is the sole reason for any space mission, be it for ferrying humans, science, or hardware. As the largest such effort in history, the ISS offers a wide variety of payload experience. However, for any payload to reach the Space Station under the current process, Payload Developers face a list of daunting tasks that go well beyond just designing the payload to the constraints of the transport vehicle and its stowage topology. Payload customers are required to prove their payload s functionality, structural integrity, and safe integration - including under less than nominal situations. They must also plan for or provide training, procedures, hardware labeling, ground support, and communications. In addition, they must deal with negotiating shared consumables, integrating software, obtaining video, and coordinating the return of data and hardware. All the while, they must meet export laws, launch schedules, budget limits, and the consensus of more than 12 panel and board reviews. Despite the cost and infrastructure overhead, payload proposals have increased. Just in the span from FY08 to FY09, the NASA Payload Space Station Support Office budget rose from $78M to $96M in attempt to manage the growing manifest, but the potential number of payloads still exceeds available Payload Integration Management manpower. The growth has also increased management difficulties due to the fact that payloads are more frequently added to a flight schedule late in the flow. The current standard ISS template for payload integration from concept to payload turn-over is 36 months, or 18 months if the payload already has a preliminary design. Customers are increasingly requiring a turn-around of 3 to 6-months to meet market needs. The following paper suggests options for streamlining the current payload integration process in order to meet customer schedule needs and reduce costs for both the integration support teams and the developers, without reducing quality or compromising safety. Issues for the key integration areas of planning, training, verification, and safety are presented in a Root-Cause Analysis study, with plausible solutions provided that involve technology and tools already available to the ISS community. Although based upon the ISS process, the payload integration techniques outlined herein also offer an integration template for any space transport endeavor.

Lufkin, Susan N.↗

NASA NTRS2023

Modeling and Simulation of the Angel Upper Limb Offload Device: Branching Into New Methods

BACKGROUND: The Active Response Gravity Offload System (ARGOS) provides an analog environment for extravehicular activity (EVA) testing and training. Discomfort has been observed during longer suited test sessions. While the subject’s core is offloaded during surface EVA evaluations, his/her arms experience full Earth gravity and can become overly fatigued, especially during suited tests which involve reaching and prolonged arm extensions. A device (ARGOS Negation of Gravitational Effects on the Limbs: ANGEL) to offload the weight of the arms and suit sleeves is being developed by JSC’s Flight Systems Branch of the Software, Robotics, and Simulation Division. Previously we have shared preliminary modeling of that device and kinematics based on motion capture data. Here we present an alternative approach to determine device kinematics by calculating ANGEL component angles with an OpenSim plugin. We compare calculated angles to inverse kinematics (IK) derived ones with the goal of validating the model. This new method can be further informative for device design and analytically testing different configurations to achieve desired reduced gravity conditions (e.g., lunar gravity (Lg) or Martian gravity (Mg)). We have compared calculated angles with IK-derived angles in tests with a shirt-sleeve subject positioned in a test stand with a Mark-III Hard Upper Torso (HUT) and Portable Life Support System (PLSS) mockup and arm weights to emulate the weight of the suit sleeve as well as a suited subject in ARGOS with a Mark-III suit. A variety of upper body tasks were completed in the former and full-body tasks in the latter. METHODS AND RESULTS: To model the offload device, we augment the OpenSim human model topology with the offload mechanism components and joints, using CAD models to represent the mechanism graphically. The joint angles of the device are calculated in the OpenSim plugin by modeling how the components configure themselves under the offloading spring tension given a particular IK-derived arm position. There are four ANGEL components with a total of 5 degrees of freedom (DOFs), each component has a single DOF except for the cuff which is modeled as 2 DOFs. The sickle/yaw bracket and cuff rotation angles are determined statically based on the assumptions that the sickle will track the attachment point of the cuff and that the cuff will rotate such that the attachment point is at its highest point. The cuff tilt, linker and V-bracket angles are then determined by optimizing their positions to approach a mechanical equilibrium. The calculated linker angle is compared to three different methods of determining the linker line-of-force kinematically (from V-bracket to center-cuff, cuff highest point or marker-derived position). Given the joint angles of the device, the spring force and resulting force on the arm is computed by the plugin and applied as an external load in inverse dynamics (ID) to enable study of overall shoulder joint torques as well as offload achieved. We verify the calculated joint angles by using the inverse kinematic data. The average difference in angles is the smallest for the V-bracket and linker, around 1 to 5 degrees for most trials. The resulting offload and shoulder torque are comparable between calculated and IK-derived angles. In summary, we have developed a method to calculate the joint angles of an exoskeleton-like upper limb offloading device currently in development. We have also developed a custom plugin which will be a valuable tool to optimize device configurations for a desired gravitational environment, probe the offload achieved for motions recorded outside of our test suite, and inform future design improvements.

L B Nilsson↗

NASA NTRS2023

Modeling and Simulation of The Angel Upper Limb Offload Device: Branching into New Methods

BACKGROUND: The Active Response Gravity Offload System (ARGOS) provides an analog environment for extravehicular activity (EVA) testing and training. Discomfort has been observed during longer suited test sessions. While the subject’s core is offloaded during surface EVA evaluations, his/her arms experience full Earth gravity and can become overly fatigued, especially during suited tests which involve reaching and prolonged arm extensions. A device (ARGOS Negation of Gravitational Effects on the Limbs: ANGEL) to offload the weight of the arms and suit sleeves is being developed by JSC’s Flight Systems Branch of the Software, Robotics, and Simulation Division. Previously we have shared preliminary modeling of that device and kinematics based on motion capture data. Here we present an alternative approach to determine device kinematics by calculating ANGEL component angles with an OpenSim plugin. We compare calculated angles to inverse kinematics (IK) derived ones with the goal of validating the model. This new method can be further informative for device design and analytically testing different configurations to achieve desired reduced gravity conditions (e.g., lunar gravity (Lg) or Martian gravity (Mg)). We have compared calculated angles with IK-derived angles in tests with a shirt-sleeve subject positioned in a test stand with a Mark-III Hard Upper Torso (HUT) and Portable Life Support System (PLSS) mockup and arm weights to emulate the weight of the suit sleeve as well as a suited subject in ARGOS with a Mark-III suit. A variety of upper body tasks were completed in the former and full-body tasks in the latter. METHODS AND RESULTS: To model the offload device, we augment the OpenSim human model topology with the offload mechanism components and joints, using CAD models to represent the mechanism graphically. The joint angles of the device are calculated in the OpenSim plugin by modeling how the components configure themselves under the offloading spring tension given a particular IK-derived arm position. There are four ANGEL components with a total of 5 degrees of freedom (DOFs), each component has a single DOF except for the cuff which is modeled as 2 DOFs. The sickle/yaw bracket and cuff rotation angles are determined statically based on the assumptions that the sickle will track the attachment point of the cuff and that the cuff will rotate such that the attachment point is at its highest point. The cuff tilt, linker and V-bracket angles are then determined by optimizing their positions to approach a mechanical equilibrium. The calculated linker angle is compared to three different methods of determining the linker line-of-force kinematically (from V-bracket to center-cuff, cuff highest point or marker-derived position). Given the joint angles of the device, the spring force and resulting force on the arm is computed by the plugin and applied as an external load in inverse dynamics (ID) to enable study of overall shoulder joint torques as well as offload achieved. We verify the calculated joint angles by using the inverse kinematic data. The average difference in angles is the smallest for the V-bracket and linker, around 1 to 5 degrees for most trials. The resulting offload and shoulder torque are comparable between calculated and IK-derived angles. In summary, we have developed a method to calculate the joint angles of an exoskeleton-like upper limb offloading device currently in development. We have also developed a custom plugin which will be a valuable tool to optimize device configurations for a desired gravitational environment, probe the offload achieved for motions recorded outside of our test suite, and inform future design improvements.

L B Nilsson↗

NASA NTRSDate not supplied

Distributed Spacecraft Autonomy - Development of Swarm Autonomy Capability and Scalability for Spacecraft

The Distributed Spacecraft Autonomy project is developing a suite of software tools that enable an operator to command and receive data from a swarm as a single entity, enable a swarm to autonomously coordinate its actions via distributed decision making and reactive closed-loop control, and model swarm behavior in the presence of anomalies or failures. Our use case is the mapping of the electron density of the ionosphere using radio tomography by coordinating the selection of appropriate GPS channels, and by recording Total Electron Count (TEC) measurements. DSA will be demonstrated onboard the NASA Ames Starling mission – a swarm of four small, LEO spacecraft, scheduled to launch in 2021. We will also perform a ground demonstration with simulated and hardware-in-the-loop elements, to validate the tools for controlling swarms of up to 100 assets. The capability to communicate autonomously between the swarm satellites is demonstrated via a sophisticated simulation architecture. Historical Plasmasphere TEC data obtained via dual-band Novatel GPS Receivers are utilized as a representative input dataset for the swarm. The representative TEC data and GPS satellite observability information is fed to the autonomous software package in place of a true real-time ground data collection process. The swarm satellites actively share status updates amongst one another and utilize multi-agent decision making to optimally identify regions of interest in the TEC distribution. The software, aware of the bandwidth limitations of the swarm satellites, prioritizes explorative measurements, which define the range of observability for the satellites, as well as exploitative measurements, which focus on maximizing the observance potential of regions with prolonged, elevated TEC density. The science of this study can ultimately be used to determine the dynamics and coupling of Earth’s magnetosphere, ionosphere, and atmosphere and their response to solar and terrestrial inputs. The findings can be applied to the imaging of critical, transient phenomena in the magnetosphere in later missions. Meanwhile, the swarm autonomy capabilities have far reaching potential in future satellite missions. As an experimental demonstration of the autonomous capabilities of the network, a message is first printed within a core Flight Executive (cFE) application. Two cFE applications that communicate with one another within the same core Flight System (cFS) are shown. Communication between mission applications on the internal cFE bus is extended to utilize Data Distribution Service (DDS) for vehicle-to-vehicle networking. The DDS middleware provides reliable delivery, routing, and topic subscription features over User Datagram Protocol (UDP). Leveraging Linux containerization, a networked set of satellite instances are generated by script to simulate swarm behavior. Swarm commanding and synchronization through the network is demonstrated under various topologies and data-loss conditions. Finally, autonomous swarm scalability from 2 satellites to 100 satellites is shown.

Distributed Autonomy↗

NASA NTRS2020

Distributed Spacecraft Autonomy (DSA): Development of Swarm Autonomy Capability and Scalability for Spacecraft

The Distributed Spacecraft Autonomy project is developing a suite of software tools that enable an operator to command and receive data from a swarm as a single entity, enable a swarm to autonomously coordinate its actions via distributed decision making and reactive closed-loop control, and model swarm behavior in the presence of anomalies or failures. Our use case is the mapping of the electron density of the ionosphere using radio tomography by coordinating the selection of appropriate GPS channels, and by recording Total Electron Count (TEC)measurements. DSA will be demonstrated on board the NASA Ames Starling mission a swarm of four small, LEO spacecraft, scheduled to launch in 2021. We will also perform a ground demonstration with simulated and hardware-in-the-loop elements, to validate the tools for controlling swarms of up to 100 assets.The capability to communicate autonomously between the swarm satellites is demonstrated via a sophisticated simulation architecture. Historical Plasma sphere TEC data obtained via dual-band Novatel GPS Receivers are utilized as a representative input data set for the swarm. The representative TEC data and GPS satellite observability information is fed to the autonomous software package in place of a true real-time ground data collection process. The swarm satellites actively share status updates amongst one another and utilize multi-agent decision making to optimally identify regions of interest in the TEC distribution. The software,aware of the bandwidth limitations of the swarm satellites, prioritizes explorative measurements,which define the range of observability for the satellites, as well as exploitative measurements,which focus on maximizing the observance potential of regions with prolonged, elevated TEC density. The science of this study can ultimately be used to determine the dynamics and coupling of Earth's magnetosphere, ionosphere, and atmosphere and their response to solar and terrestrial inputs. The findings can be applied to the imaging of critical, transient phenomena in the magnetosphere in later missions. Meanwhile, the swarm autonomy capabilities have far reaching potential in future satellite missions.As an experimental demonstration of the autonomous capabilities of the network, a message is first printed within a core Flight Executive (cFE) application. Two cFE applications that communicate with one another within the same core Flight System (cFS) are shown.Communication between mission applications on the internal cFE bus is extended to utilize Data Distribution Service (DDS) for vehicle-to-vehicle networking. The DDS middle ware provides reliable delivery, routing, and topic subscription features over User Data gram Protocol (UDP).Leveraging Linux containerization, a networked set of satellite instances are generated by script to simulate swarm behavior. Swarm commanding and synchronization through the network is demonstrated under various topologies and data-loss conditions. Finally, autonomous swarms calability from 2 satellites to 100 satellites is shown.

Fugate, Jason↗

NASA NTRS1999

Semiempirical Two-Dimensional Magnetohydrodynamic Model of the Solar Corona and Interplanetary Medium

We have developed a two-dimensional semiempirical MHD model of the solar corona and solar wind. The model uses empirically derived electron density profiles from white-light coronagraph data measured during the Skylub period and an empirically derived model of the magnetic field which is fitted to observed streamer topologies, which also come from the white-light coronagraph data The electron density model comes from that developed by Guhathakurta and coworkers. The electron density model is extended into interplanetary space by using electron densities derived from the Ulysses plasma instrument. The model also requires an estimate of the solar wind velocity as a function of heliographic latitude and radial component of the magnetic field at 1 AU, both of which can be provided by the Ulysses spacecraft. The model makes estimates as a function of radial distance and latitude of various fluid parameters of the plasma such as flow velocity V, effective temperature T(sub eff), and effective heat flux q(sub eff), which are derived from the equations of conservation of mass, momentum, and energy, respectively. The term effective indicates that wave contributions could be present. The model naturally provides the spiral pattern of the magnetic field far from the Sun and an estimate of the large-scale surface magnetic field at the Sun, which we estimate to be approx. 12 - 15 G. The magnetic field model shows that the large-scale surface magnetic field is dominated by an octupole term. The model is a steady state calculation which makes the assumption of azimuthal symmetry and solves the various conservation equations in the rotating frame of the Sun. The conservation equations are integrated along the magnetic field direction in the rotating frame of the Sun, thus providing a nearly self-consistent calculation of the fluid parameters. The model makes a minimum number of assumptions about the physics of the solar corona and solar wind and should provide a very accurate empirical description of the solar corona and solar wind Once estimates of mass density rho, flow velocity V, effective temperature T(sub eff), effective heat flux q(sub eff), and magnetic field B are computed from the model and waves are assumed unimportant, all other plasma parameters such as Mach number, Alfven speed, gyrofrequency, etc. can be derived as a function of radial distance and latitude from the Sun. The model can be used as a planning tool for such missions as Slar Probe and provide an empirical framework for theoretical models of the solar corona and solar wind The model will be used to construct a semiempirical MHD description of the steady state solar corona and solar wind using the SOHO Large Angle Spectrometric Coronagraph (LASCO) polarized brightness white-light coronagraph data, SOHO Extreme Ultraviolet Imaging Telescope data, and Ulysses plasma data.

Sittler, Edward C., Jr.↗

NASA NTRS1997

Cooperative Data Sharing: Simple Support for Clusters of SMP Nodes

Libraries like PVM and MPI send typed messages to allow for heterogeneous cluster computing. Lower-level libraries, such as GAM, provide more efficient access to communication by removing the need to copy messages between the interface and user space in some cases. still lower-level interfaces, such as UNET, get right down to the hardware level to provide maximum performance. However, these are all still interfaces for passing messages from one process to another, and have limited utility in a shared-memory environment, due primarily to the fact that message passing is just another term for copying. This drawback is made more pertinent by today's hybrid architectures (e.g. clusters of SMPs), where it is difficult to know beforehand whether two communicating processes will share memory. As a result, even portable language tools (like HPF compilers) must either map all interprocess communication, into message passing with the accompanying performance degradation in shared memory environments, or they must check each communication at run-time and implement the shared-memory case separately for efficiency. Cooperative Data Sharing (CDS) is a single user-level API which abstracts all communication between processes into the sharing and access coordination of memory regions, in a model which might be described as "distributed shared messages" or "large-grain distributed shared memory". As a result, the user programs to a simple latency-tolerant abstract communication specification which can be mapped efficiently to either a shared-memory or message-passing based run-time system, depending upon the available architecture. Unlike some distributed shared memory interfaces, the user still has complete control over the assignment of data to processors, the forwarding of data to its next likely destination, and the queuing of data until it is needed, so even the relatively high latency present in clusters can be accomodated. CDS does not require special use of an MMU, which can add overhead to some DSM systems, and does not require an SPMD programming model. unlike some message-passing interfaces, CDS allows the user to implement efficient demand-driven applications where processes must "fight" over data, and does not perform copying if processes share memory and do not attempt concurrent writes. CDS also supports heterogeneous computing, dynamic process creation, handlers, and a very simple thread-arbitration mechanism. Additional support for array subsections is currently being considered. The CDS1 API, which forms the kernel of CDS, is built primarily upon only 2 communication primitives, one process initiation primitive, and some data translation (and marshalling) routines, memory allocation routines, and priority control routines. The entire current collection of 28 routines provides enough functionality to implement most (or all) of MPI 1 and 2, which has a much larger interface consisting of hundreds of routines. still, the API is small enough to consider integrating into standard os interfaces for handling inter-process communication in a network-independent way. This approach would also help to solve many of the problems plaguing other higher-level standards such as MPI and PVM which must, in some cases, "play OS" to adequately address progress and process control issues. The CDS2 API, a higher level of interface roughly equivalent in functionality to MPI and to be built entirely upon CDS1, is still being designed. It is intended to add support for the equivalent of communicators, reduction and other collective operations, process topologies, additional support for process creation, and some automatic memory management. CDS2 will not exactly match MPI, because the copy-free semantics of communication from CDS1 will be supported. CDS2 application programs will be free to carefully also use CDS1. CDS1 has been implemented on networks of workstations running unmodified Unix-based operating systems, using UDP/IP and vendor-supplied high- performance locks. Although its inter-node performance is currently unimpressive due to rudimentary implementation technique, it even now outperforms highly-optimized MPI implementation on intra-node communication due to its support for non-copy communication. The similarity of the CDS1 architecture to that of other projects such as UNET and TRAP suggests that the inter-node performance can be increased significantly to surpass MPI or PVM, and it may be possible to migrate some of its functionality to communication controllers.

DiNucci, David C.↗