Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Solution verification”

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.

442 records · Page 25

Low-Cost, Class D Testing of Spacecraft Photovoltaic Systems Can Reduce Risk

The end-to-end verification of a spacecraft photovoltaic power generation system requires light! A lowcost, portable, and end-to-end photovoltaic-system test appropriate for NASA's new generation of Class D missions is presented. High risk, low-cost, and quick-turn satellites rarely have the resources to execute the traditional approaches from higher-class (A-C) missions. The Class D approach, as demonstrated on the Lunar Atmospheric and Dust Environment Explorer (LADEE), utilizes a portable, metalhalide, theatre lamp for an end-to-end photovoltaic system test. While not as precise and comprehensive as the traditional Large Area Pulsed Solar Simulator (LAPSS) test, the LADEE method leverages minimal resources into an ongoing assessment program that can be applied through numerous stages of the mission. The project takes a true Class D approach in assessing the technical value of a costly, highfidelity performance test versus a simpler approach with less programmatic risk. The resources required are a fraction of that for a LAPSS test, and is easy to repeat due to its portability. Further, the test equipment can be handed down to future projects without building an on-site facility. At the vanguard of Class D missions, the LADEE team frequently wrestled with and challenged the status quo. The philosophy of risk avoidance at all cost, typical to Class A-C missions, simply could not be executed. This innovative and simple testing solution is contextualized to NASA Class D programs and a specific risk encountered during development of the LADEE Electrical Power System (EPS). Selection of the appropriate lamp and safety concerns are discussed, with examples of test results. Combined with the vendor's panellevel data and periodic inspection, the method ensures system integrity from Integration and Test (I&T) through launch. Following launch, mission operations tools are utilized to assess system performance based on a scant amount of available data.

power systems↗

Low-cost, Risk-Reduction Testing of Class D Spacecraft Photovoltaic Systems

The end-to-end verification of a spacecraft photovoltaic power generation system requires light! A low-cost, portable, and end-to-end photovoltaic-system test appropriate for NASAs new generation of Class D missions is presented. High risk, low-cost, and quick-turn satellites rarely have the resources to execute the traditional approaches from higher-class (A-C) missions. The Class D approach, as demonstrated on the Lunar Atmospheric and Dust Environment Explorer (LADEE), utilizes a portable, metal-halide, theatre lamp for an end-to-end photovoltaic system test. While not as precise and comprehensive as the traditional Large Area Pulsed Solar Simulator (LAPSS) test, the LADEE method leverages minimal resources into an ongoing assessment program that can be applied through numerous stages of the mission. The project takes a true Class D approach in assessing the technical value of a costly, high-fidelity performance test versus a simpler approach with less programmatic risk. The resources required are a fraction of that for a LAPSS test, and is easy to repeat due to its portability. Further, the test equipment can be handed down to future projects without building an on-site facility.At the vanguard of Class D missions, the LADEE team frequently wrestled with and challenged the status quo. The philosophy of risk avoidance at all cost, typical to Class A-C missions, simply could not be executed. This innovative and simple testing solution is contextualized to NASA Class D programs and a specific risk encountered during development of the LADEE Electrical Power System (EPS). Selection of the appropriate lamp and safety concerns are discussed, with examples of test results. Combined with the vendors panel-level data and periodic inspection, the method ensures system integrity from Integration and Test (IT) through launch. Following launch, mission operations tools are utilized to assess system performance based on a scant amount of available data.

photovoltaic↗

Evolution of the Preliminary Fault Management Architecture and Design for the Psyche Mission

The Psyche Mission presents the first opportunity toexplore the largest metal asteroid in the solar system, (16)Psyche, which is believed to be the exposed core of a largerplanetesimal that was stripped of its rocky mantle throughmultiple collisions during early solar system formation. Themission was selected in January 2017 for a 2022 launch as partof NASA’s Discovery Program and is uniquely enabled by theintegration of a Solar Electric Propulsion (SEP) Chassisdelivered by Maxar Space Solutions with JPL’s core deepspace avionics, flight software, and fault managementarchitectures. One of the key design tasks is the development ofa fault management system capable of being responsive to theunique elements of the combined JPL and Maxar spacecraftarchitecture. This new design leverages the strengths of eachorganization, with Maxar delivering its well-proven highvoltage power bus and low-thrust electric propulsionsubsystem from its GEO communications satellite product line,and JPL delivering its deep space mission expertise and thehardware and software most critical to deep space missiondesign. The development of a robust low-thrust mission andthe integration of design philosophies and hardware from twoorganizations is not without its challenges though.A key challenge in the development of the Psyche faultmanagement architecture and design is in the integration ofdesign philosophies and hardware from JPL and Maxar. Atthe architecture level, Maxar GEO communications satellitesare developed under the premise of highly responsive groundin the loop for the resolution of anomalies, and theimplementation takes a fail-operational approach to minimizedown time for its customers. In contrast, a deep space missionmust be able to maintain safety with long periods of groundcommunication outage. Additionally, with no time-criticalevents after launch, the Psyche spacecraft will generally failsafe in the presence of anomalous conditions; specialconsideration is being given to this approach, however, tominimize the loss of electric propulsion thrust time, which iscritical to low-thrust missions. At the hardware level, thedetailed definition of interfaces between JPL and Maxarhardware presents a unique challenge in the development andflowdown of fault management requirements, the developmentand implementation of fault monitors and responses, and thedevelopment and verification of fault containment boundaries.This paper describes the evolution of the Psyche faultmanagement architecture and design from the concept studyinto the preliminary design phase, with a focus on the uniquechallenges associated with flying GEO communicationssatellite hardware in deep space, implementing a robust lowthrust mission, and the integration of design philosophies andhardware from JPL and Maxar. Details regarding how thesechallenges are addressed in the fault management design inorder to maximize heritage, leverage the strengths of eachorganization, and minimize risk across the design are alsodiscussed.

Marsh, Danielle↗

Telescience Resource Kit (TReK)

Telescience Resource Kit (TReK) is one of the Huntsville Operations Support Center (HOSC) remote operations solutions. It can be used to monitor and control International Space Station (ISS) payloads from anywhere in the world. It is comprised of a suite of software applications and libraries that provide generic data system capabilities and access to HOSC services. The TReK Software has been operational since 2000. A new cross-platform version of TReK is under development. The new software is being released in phases during the 2014-2016 timeframe. The TReK Release 3.x series of software is the original TReK software that has been operational since 2000. This software runs on Windows. It contains capabilities to support traditional telemetry and commanding using CCSDS (Consultative Committee for Space Data Systems) packets. The TReK Release 4.x series of software is the new cross platform software. It runs on Windows and Linux. The new TReK software will support communication using standard IP protocols and traditional telemetry and commanding. All the software listed above is compatible and can be installed and run together on Windows. The new TReK software contains a suite of software that can be used by payload developers on the ground and onboard (TReK Toolkit). TReK Toolkit is a suite of lightweight libraries and utility applications for use onboard and on the ground. TReK Desktop is the full suite of TReK software -most useful on the ground. When TReK Desktop is released, the TReK installation program will provide the option to choose just the TReK Toolkit portion of the software or the full TReK Desktop suite. The ISS program is providing the TReK Toolkit software as a generic flight software capability offered as a standard service to payloads. TReK Software Verification was conducted during the April/May 2015 timeframe. Payload teams using the TReK software onboard can reference the TReK software verification. TReK will be demonstrated on-orbit running on an ISS provided T61p laptop. Target Timeframe: September 2015 -2016. The on-orbit demonstration will collect benchmark metrics, and will be used in the future to provide live demonstrations during ISS Payload Conferences. Benchmark metrics and demonstrations will address the protocols described in SSP 52050-0047 Ku Forward section 3.3.7. (Associated term: CCSDS File Delivery Protocol (CFDP)).

Lippincott, Jeff↗

NASA's Moon to Mars Autonomous Habitat Status

NASA is developing a strategy for sending humans to the Mars vicinity, known broadly as the Moon to Mars (M2M) Campaign. A critical part of this campaign is the development of in-space and surface habitation systems capable of substantially extending human presence beyond Low Earth Orbit (LEO). Mars missions feature an in-space transit habitat capable of supporting crews of four on ~850-1200-day missions, including transit to and from Mars and time in Mars orbit. Surface and transit habitats are complex elements which must keep crewmembers healthy and productive in deep-space environments with limited resources, long rescue times in contingency situations, and communication delays; all within constrained mass, volume, and power budgets. These habitats provide crew both living and workspace as well as most of the resources needed to support crew life. For deep space habitats, automation needs to be employed due to latency and for significant amounts of time when the habitats are uncrewed. Automation of systems is possible in space applications, but there are limitations. Outside of the Earth’s (or any) magnetosphere, radiation environments are harsh to both the physical hardware and the software components. Radiation (charged particles and ionizing electromagnetic waves) degrades and damages the hardware and causes single event upsets (SEUs) in software. If the hardware is damaged, data can be lost, or control actions not made. For software, SEUs cause algorithms to result in different solutions, or incorrect commands to be sent out. This means that algorithms and hardware used for deep space systems are different than what is used on Earth. Radiation-tolerant hardware is generations behind the current state-of-the-art hardware. Recent NASA missions, such as James Webb Space Telescope, continue to rely on older technologies such as the RAD750 processor, and the most advanced processors are still single core and less than 1.5 GHz. There have been attempts to use higher performance processors, but these often take multiple mitigation steps to handle the radiation environments, which limits the processing power and/or throughput. Current techniques for radiation mitigation have been redundancies, voting, physical separation of hardware, encasing materials, under-clocking hardware, and more. Some radiation mitigation techniques do provide benefits such as having a redundant system to improve the probability that a system will be available when needed. Autonomous software systems will have fewer interactions with humans on deep space missions and therefore need to be able to handle more off-nominal conditions. Microgravity also complicates the autonomous aspects of the mission because autonomous systems are usually built from known deterministic states, but microgravity causes physical objects to shift and move changing the location an autonomous system placed the object. Not only does the software need to be reliable and deterministic, losing resources due to a software error is not only costly but detrimental to reputation. The combination of having lower performance hardware and having to be able to verify and deterministically run software and an ever-changing environment makes deep space autonomous systems more complicated. Multiple gaps have been identified including verification of autonomous software algorithms (including artificial intelligence and machine learning), higher performance processors (graphics and general purpose), high speed networks (onboard and transmissions), memory, power distribution, data security, and variations from these. These gaps need to be closed for more advanced systems to be deployed and reduce the size, weight, and power impacts on the habitats.

Scott B. Tashakkor↗

A Fuzzy Logic Approach for Separation Assurance and Collision Avoidance for Unmanned Aerial Systems

In the coming years, operations in low altitude airspace will vastly increase as the capabilities and applications of small Unmanned Aerial Systems (sUAS) continue to multiply. Therefore, solutions to managing sUAS in highly congested airspace must be explored. In this study, a Fuzzy Logic based approach was used to help mitigate the risk of collisions between aircraft using separation assurance and collision avoidance techniques. The system was evaluated for its effectiveness to mitigate the risk of mid-air collisions between aircraft. This system utilizes only current state information and can resolve potential conflicts without knowledge of intruder intent. The avoidance logic was verified using formal methods and shown to select the correct action in all instances. Additionally, the Fuzzy Logic Controllers were shown to always turn the vehicles in the correct direction. Numerical testing demonstrated that the avoidance system was able to prevent a mid-air collision between two sUAS in all tested cases. Simulations were also performed in a three-dimensional environment with a heterogenous fleet of sUAS performing a variety of realistic missions. Simulations showed that the system was 99.98 effective at preventing mid-air collisions when separation assurance was disabled (unmitigated case) and 100 effective when enabled (mitigated case).

Verification & Validation of a Fuzzy Logic Control↗

The System Modeling and Analysis of Resiliency in STEReO (SMARt-STEReO)

Wildfire emergency response has remained rooted in relatively low-tech solutions for coordination between ground and aerial assets. These low-tech solutions are robust for the remote environments in which wildfires are usually fought, but limit strategic cross-organizational support and the ability to deploy and effectively utilize aerial assets. As aircraft become more advanced and new technology, including drones, become available to firefighters, a new, more modern method of asset coordination is needed. NASA is working on a project called ‘Scalable Traffic Management for Emergency Response Operations’ (STEReO) to integrate unmanned aerial systems (UAS)and UAS traffic management (UTM)into wildfire response. STEReO’s goals include simplifying the coordination of aerial assets, improving the existing UAS framework, and increasing the role of additional autonomous systems to reduce human risk and to increase system resilience. This paper describes the development of the ‘System Modeling and Analysis of Resiliency in STEReO’ (SMARt-STEReO) project, which aims to model wildfire response and to quantify the additional system resilience that STEReO technology provides firefighters. This paper verifies SMARt-STEReO and defines its scope; it includes experimental and statistical analysis of the impact that the addition of UAS has on both performance metrics and also on performance resiliency response to a given fault. SMARt-STEReO is a grid-based model of fire propagation that incorporates varying crew responses. Through the use of a Python package called ‘fmdtools’, the model easily allows for the addition of faults to the system. These faults allow analysts to investigate various response parameters. Factors including terrain, fuel type and wind speed can be modified to affect the fire propagation; additionally, the number of ground crews, engines, fixed wing aircraft, helicopters, and UAS can be changed to affect the crew response. The communication lines between actors mimic those used in real life situations. This paper explains the development of SMARt-STEReO including background research, verification and validation, and preliminary experimental analysis of system resilience to both a minor and major fault in systems with and without UAS.

Resiliency↗

SpaceCube v2.0 Space Flight Hybrid Reconfigurable Data Processing System

This paper details the design architecture, design methodology, and the advantages of the SpaceCube v2.0 high performance data processing system for space applications. The purpose in building the SpaceCube v2.0 system is to create a superior high performance, reconfigurable, hybrid data processing system that can be used in a multitude of applications including those that require a radiation hardened and reliable solution. The SpaceCube v2.0 system leverages seven years of board design, avionics systems design, and space flight application experiences. This paper shows how SpaceCube v2.0 solves the increasing computing demands of space data processing applications that cannot be attained with a standalone processor approach.The main objective during the design stage is to find a good system balance between power, size, reliability, cost, and data processing capability. These design variables directly impact each other, and it is important to understand how to achieve a suitable balance. This paper will detail how these critical design factors were managed including the construction of an Engineering Model for an experiment on the International Space Station to test out design concepts. We will describe the designs for the processor card, power card, backplane, and a mission unique interface card. The mechanical design for the box will also be detailed since it is critical in meeting the stringent thermal and structural requirements imposed by the processing system. In addition, the mechanical design uses advanced thermal conduction techniques to solve the internal thermal challenges.The SpaceCube v2.0 processing system is based on an extended version of the 3U cPCI standard form factor where each card is 190mm x 100mm in size The typical power draw of the processor card is 8 to 10W and scales with application complexity. The SpaceCube v2.0 data processing card features two Xilinx Virtex-5 QV Field Programmable Gate Arrays (FPGA), eight memory modules, a monitor FPGA with analog monitoring, Ethernet, configurable interconnect to the Xilinx FPGAs including gigabit transceivers, and the necessary voltage regulation. The processor board uses a back-to-back design methodology for common parts that maximizes the board real estate available. This paper will show how to meet the IPC 6012B Class 3A standard with a 22-layer board that has two column grid array devices with 1.0mm pitch. All layout trades such as stack-up options, via selection, and FPGA signal breakout will be discussed with feature size results. The overall board design process will be discussed including parts selection, circuit design, proper signal termination, layout placement and route planning, signal integrity design and verification, and power integrity results. The radiation mitigation techniques will also be detailed including configuration scrubbing options, Xilinx circuit mitigation and FPGA functional monitoring, and memory protection.Finally, this paper will describe how this system is being used to solve the extreme challenges of a robotic satellite servicing mission where typical space-rated processors are not sufficient enough to meet the intensive data processing requirements. The SpaceCube v2.0 is the main payload control computer and is required to control critical subsystems such as autonomous rendezvous and docking using a suite of vision sensors and object avoidance when controlling two robotic arms.

Xilinx FPGA↗

Design Evolution and Verification of the A-3 Chemical Steam Generator

Following is an overview of the Chemical Steam Generator system selected to provide vacuum conditions for a new altitude test facility, the A-3 Test Stand at Stennis Space Center (SSC) in Bay St. Louis, MS. A-3 will serve as NASA s primary facility for altitude testing of the J-2X rocket engine, to be used as the primary propulsion device for the upper stages of the Ares launch vehicles. The Chemical Steam Generators (CSGs) will produce vacuum conditions in the test cell through the production and subsequent supersonic ejection of steam into a diffuser downstream of the J-2X engine nozzle exit. The Chemical Steam Generators chosen have a rich heritage of operation at rocket engine altitude test facilities since the days of the Apollo program and are still in use at NASA White Sands Test Facility (WSTF) in New Mexico. The generators at WSTF have been modified to a degree, but are still very close to the heritage design. The intent for the A-3 implementation is to maintain this heritage design as much as possible, making minimal updates only where necessary to substitute for obsolete parts and to increase reliability. Reliability improvements are especially desired because the proposed system will require 27 generators, which is nine times the largest system installed in the 1960s. Improvements were suggested by the original design firm, Reaction Motors, by NASA SSC and NASA WSTF engineers, and by the A-3 test stand design contractor, Jacobs Technology, Inc. (JTI). This paper describes the range of improvements made to the design to date, starting with the heritage generator and the minor modifications made over time at WSTF, to the modernized configuration which will be used at A-3. The paper will discuss NASA s investment in modifications to SSC s E-2 test facility fire a full-scale Chemical Steam Generator in advance of the larger steam system installation at A-3. Risk mitigation testing will be performed in early 2009 at this test facility to verify that the CSGs operate as expected. The generator which will undergo this testing is of the most recent A-3 configuration, and will be instrumented far in excess of what is normally required for operation. The extra data will allow for easier troubleshooting and more complete knowledge of expected generator performance. In addition, the early testing will give SSC personnel experience in operating the CSG systems, which will expedite the process of installation and activation at A-3. Each Chemical Steam Generator is supported by a complement of valves, instruments, and flow control devices, with the entire assembly called a "module." The generators will be installed in groups of three, historically called "units". A module is so called because of its modular ability to be replaced or serviced without disturbing the other two modules installed on the same unit. A module is pictured in Figure 1, shown with its generator secured by white bands in its shipping (vs. installed) configuration. The heritage system at WSTF is composed of a single unit (three generator modules), pictured in Figure 2 as it was installed in 1965. In contrast, A-3 will have nine units operating in parallel to achieve vacuum conditions appropriate for testing the J-2X engine. Each of the combustors operates in two modes and achieves the so-called "full-steam" mode after all three of its stages ignite. Ignition of the first stage is achieved by exciting a spark plug; the second stage and main stage are lit by the flame front of the previous stage. The main stage burns approximately 97% of the total propellant flow and uses the heat energy to vaporize water into superheated steam. While the main stage remains unlit, the combustor is in so-called "idle" mode. In the WSTF system, this idle mode is not optimized for water usage, and does not need to be, as the water is pumped from a large reservoir. The water supply at A-3 will be contained in tanks with finite volume, so water optimization is preferred for the modnized configuration. Multiple solutions for this issue have been proposed, with the leading concept being a change to the operational definition of "idle mode," with the generator running in a lower heat flux condition.

Kirchner, Casey K.↗

R2U2 in Space: System and Software Health Management for Small Satellites

In order for small but complex systems like rovers, SmallSats, or Unmanned Aircraft (UAS) to operate autonomously, they must have a real-time solution for assessing their own system health. System and Software Health Management (SHM) enables better detection of faulty sensors and software problems, and enables better fault management including mitigation of unpredicted fault scenarios in the absence of a human on-board. In recent work, we have developed a Responsive, Realizable, Unobtrusive Unit (R2U2) for on-board SHM of autonomous UAS and demonstrated its ability to detect faults during flight time. These faults, from sensor failures, to software problems, to malicious security attacks, can present as transient temporal faults that even humans are challenged to find. An R2U2 congfiuration is a modular combination of multiple types of temporal logic runtime observers with fault-specic Bayesian Nets and sensor filters. R2U2 reasons about both on-board hardware and software components; R2U2 itself can be instantiated as an independent FPGA (Field-Programmable Gate Array)-based conguration or as a software component running independently from other software on-board. Small satellites, such as CubeSats, also require on-board SHM and failure mitigation, as limited telemetry bandwidth does not allow the transmission of the entire system state for ground-based health management. However, the autonomous operation of satellites brings a set of challenges different from UAS, including the effects of radiation on non-rad-hard, low-cost components, and the harsher environment of space. We surmise that a new extension of R2U2 could be adapted to help better detect, for example, radiation errors in cheaper COTS (Commercial Off the Shelf) (not rad-hard) components often used in small space systems. Since small satellites often operate in coordination, we will also examine new ways of distributed monitoring of their communication and cooperation and real-time detection of off-nominal situations utilizing multiple satellites. This talk will discuss preliminary work and ideas for building on terrestrial success of system and software health management for the harsher, and differently challenging, environment of space.

Runtime Verification & Validation↗