Search NASA⌕ Search

SEARCH · Search NASA

Results for “controller hardware-in-the-loop”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

SPARTAN: A High-Fidelity Simulation for Automated Rendezvous and Docking Applications

bd Systems (a subsidiary of SAIC) has developed the Simulation Package for Autonomous Rendezvous Test and ANalysis (SPARTAN), a high-fidelity on-orbit simulation featuring multiple six-degree-of-freedom (6DOF) vehicles. SPARTAN has been developed in a modular fashion in Matlab/Simulink to test next-generation automated rendezvous and docking guidance, navigation,and control algorithms for NASA's new Vision for Space Exploration. SPARTAN includes autonomous state-based mission manager algorithms responsible for sequencing the vehicle through various flight phases based on on-board sensor inputs and closed-loop guidance algorithms, including Lambert transfers, Clohessy-Wiltshire maneuvers, and glideslope approaches The guidance commands are implemented using an integrated translation and attitude control system to provide 6DOF control of each vehicle in the simulation. SPARTAN also includes high-fidelity representations of a variety of absolute and relative navigation sensors that maybe used for NASA missions, including radio frequency, lidar, and video-based rendezvous sensors. Proprietary navigation sensor fusion algorithms have been developed that allow the integration of these sensor measurements through an extended Kalman filter framework to create a single optimal estimate of the relative state of the vehicles. SPARTAN provides capability for Monte Carlo dispersion analysis, allowing for rigorous evaluation of the performance of the complete proposed AR&D system, including software, sensors, and mechanisms. SPARTAN also supports hardware-in-the-loop testing through conversion of the algorithms to C code using Real-Time Workshop in order to be hosted in a mission computer engineering development unit running an embedded real-time operating system. SPARTAN also contains both runtime TCP/IP socket interface and post-processing compatibility with bdStudio, a visualization tool developed by bd Systems, allowing for intuitive evaluation of simulation results. A description of the SPARTAN architecture and capabilities is provided, along with details on the models and algorithms utilized and results from representative missions.

Turbe, Michael A.↗
NASA NTRS2004

Automated Rendezvous and Capture System Development and Simulation for NASA

The United States does not have an Automated Rendezvous and Capture/Docking (AR and C) capability and is reliant on manned control for rendezvous and docking of orbiting spacecraft. This reliance on the labor intensive manned interface for control of rendezvous and docking vehicles has a significant impact on the cost of the operation of the International Space Station (ISS) and precludes the use of any U.S. expendable launch capabilities for Space Station resupply. The Soviets have the capability to autonomously dock in space, but their system produces a hard docking with excessive force and contact velocity. Automated Rendezvous and Capture/Docking has been identified as a key enabling technology for the Space Launch Initiative (SLI) Program, DARPA Orbital Express and other DOD Programs. The development and implementation of an AR&C capability can significantly enhance system flexibility, improve safety, and lower the cost of maintaining, supplying, and operating the International Space Station. The Marshall Space Flight Center (MSFC) has conducted pioneering research in the development of an automated rendezvous and capture (or docking) (AR and C) system for U.S. space vehicles. This AR&C system was tested extensively using hardware-in-the-loop simulations in the Flight Robotics Laboratory, and a rendezvous sensor, the Video Guidance Sensor was developed and successfully flown on the Space Shuttle on flights STS-87 and STS-95, proving the concept of a video- based sensor. Further developments in sensor technology and vehicle and target configuration have lead to continued improvements and changes in AR&C system development and simulation. A new Advanced Video Guidance Sensor (AVGS) with target will be utilized on the Demonstration of Autonomous Rendezvous Technologies (DART) flight experiment in 2004.

Roe, Fred D.↗
NASA NTRS2018

Orion Optical Navigation Progress Toward Exploration: Mission 1

Optical navigation of human spacecraft was proposed on Gemini and implemented successfully on Apollo as a means of autonomously operating the vehicle in the event of lost communication with controllers on Earth. It shares a history with the "method of lunar distances" that was used in the 18th century and gained some notoriety after its use by Captain James Cook during his 1768 Pacific voyage of the HMS Endeavor. The Orion emergency return system utilizing optical navigation has matured in design over the last several years, and is currently undergoing the final implementation and test phase in preparation for Exploration Mission 1 (EM-1) in 2019. The software development is being worked as a Government Furnished Equipment (GFE) project delivered as an application within the Core Flight Software of the Orion camera controller module. The mathematical formulation behind the initial ellipse fit in the image processing is detailed in Christian. The non-linear least squares refinement then follows the technique of Mortari as an estimation process of the planetary limb using the sigmoid function. The Orion optical navigation system uses a body fixed camera, a decision that was driven by mass and mechanism constraints. The general concept of operations involves a 2-hour pass once every 24 hours, with passes specifically placed before all maneuvers to supply accurate navigation information to guidance and targeting. The pass lengths are limited by thermal constraints on the vehicle since the OpNav attitude generally deviates from the thermally stable tail-to-sun attitude maintained during the rest of the orbit coast phase. Calibration is scheduled prior to every pass due to the unknown nature of thermal effects on the lens distortion and the mounting platform deformations between the camera and star trackers. The calibration technique is described in detail by Christian, et al. and simultaneously estimates the Brown-Conrady coefficients and the Star Tracker/Camera interlock angles. Accurate attitude information is provided by the star trackers during each pass. Figure 1 shows the various phases of lunar return navigation when the vehicle is in autonomous operation with lost ground communication. The midcourse maneuvers are placed to control the entry interface conditions to the desired corridor for safe landing. The general form of optical navigation on Orion is where still images of the Moon or Earth are processed to find the apparent angular diameter and centroid in the camera focal plane. This raw data is transformed into range and bearing angle measurements using planetary data and precise star tracker inertial attitude. The measurements are then sent to the main flight computer's Kalman filter to update the onboard state vector. The images are, of course, collected over an arc to converge the state and estimate velocity. The same basic technique was used by Apollo to satisfy loss-of-comm, but Apollo used manual crew sightings with a vehicle-integral sextant instead of autonomously processing optical imagery. The software development is past its Critical Design Review, and is progressing through test and certification for human rating. In support of this, a hardware-in-the-loop test rig was developed in the Johnson Space Center Electro-Optics Lab to exercise the OpNav system prior to integrated testing on the Orion vehicle. Figure 2 shows the rig, which the test team has dubbed OCILOT (Orion Camera In the Loop Optical Testbed). Analysis performed to date shows a delivery that satisfies an allowable entry corridor as shown in Figure 3.

Holt, Greg N.↗
NASA NTRS2002

A Closed-Loop Hardware Simulation of Decentralized Satellite Formation Control

In recent years, there has been significant interest in the use of formation flying spacecraft for a variety of earth and space science missions. Formation flying may provide smaller and cheaper satellites that, working together, have more capability than larger and more expensive satellites. Several decentralized architectures have been proposed for autonomous establishment and maintenance of satellite formations. In such architectures, each satellite cooperatively maintains the shape of the formation without a central supervisor, and processing only local measurement information. The Global Positioning System (GPS) sensors are ideally suited to provide such local position and velocity measurements to the individual satellites. An investigation of the feasibility of a decentralized approach to satellite formation flying was originally presented by Carpenter. He extended a decentralized linear-quadratic-Gaussian (LQG) framework proposed by Speyer in a fashion similar to an extended Kalman filter (EKE) which processed GPS position fix solutions. The new decentralized LQG architecture was demonstrated in a numerical simulation for a realistic scenario that is similar to missions that have been proposed by NASA and the U.S. Air Force. Another decentralized architecture was proposed by Park et al. using carrier differential-phase GPS (CDGPS). Recently, Busse et al demonstrated the decentralized CDGPS architecture in a hardware-in-the-loop simulation on the Formation Flying TestBed (FFTB) at Goddard Space Flight Center (GSFC), which features two Spirent Cox 16 channel GPS signal generator. Although representing a step forward by utilizing GPS signal simulators for a spacecraft formation flying simulation, only an open-loop performance, in which no maneuvers were executed based on the real-time state estimates, was considered. In this research, hardware experimentation has been extended to include closed-loop integrated guidance and navigation of multiple spacecraft formations using GPS receivers and real-time vehicle telemetry. A hardware closed-loop simulation has been performed using the decentralized LQG architecture proposed by Carpenter in the GPS test facility at the Center for Space Research (CSR). This is the first presentation using this type of hardware for demonstration of closed-loop spacecraft formation flying.

Ebimuma, Takuji↗
NASA NTRS2018

Orion Optical Navigation Progress Toward Exploration Mission 1

Optical navigation of human spacecraft was proposed on Gemini and implemented successfully on Apollo as a means of autonomously operating the vehicle in the event of lost communication with controllers on Earth. The Orion emergency return system utilizing optical navigation has matured in design over the last several years, and is currently undergoing the final implementation and test phase in preparation for Exploration Mission 1 (EM-1) in 2019. The software development is past its Critical Design Review, and is progressing through test and certification for human rating. The filter architecture uses a square-root-free UDU covariance factorization. Linear Covariance Analysis (LinCov) was used to analyze the measurement models and the measurement error models on a representative EM-1 trajectory. The Orion EM-1 flight camera was calibrated at the Johnson Space Center (JSC) electro-optics lab. To permanently stake the focal length of the camera a 500 mm focal length refractive collimator was used. Two Engineering Design Unit (EDU) cameras and an EDU star tracker were used for a live-sky test in Denver. In-space imagery with high-fidelity truth metadata is rare so these live-sky tests provide one of the closest real-world analogs to operational use. A hardware-in-the-loop test rig was developed in the Johnson Space Center Electro-Optics Lab to exercise the OpNav system prior to integrated testing on the Orion vehicle. The software is verified with synthetic images. Several hundred off-nominal images are also used to analyze robustness and fault detection in the software. These include effects such as stray light, excess radiation damage, and specular reflections, and are used to help verify the tuning parameters chosen for the algorithms such as earth atmosphere bias, minimum pixel intensity, and star detection thresholds.

Holt, Greg N.↗
NASA NTRS2014

Propulsion Electric Grid Simulator (PEGS) for Future Turboelectric Distributed Propulsion Aircraft

NASA Glenn Research Center, in collaboration with the aerospace industry and academia, has begun the development of technology for a future hybrid-wing body electric airplane with a turboelectric distributed propulsion (TeDP) system. It is essential to design a subscale system to emulate the TeDP power grid, which would enable rapid analysis and demonstration of the proof-of-concept of the TeDP electrical system. This paper describes how small electrical machines with their controllers can emulate all the components in a TeDP power train. The whole system model in Matlab/Simulink was first developed and tested in simulation, and the simulation results showed that system dynamic characteristics could be implemented by using the closed-loop control of the electric motor drive systems. Then we designed a subscale experimental system to emulate the entire power system from the turbine engine to the propulsive fans. Firstly, we built a system to emulate a gas turbine engine driving a generator, consisting of two permanent magnet (PM) motors with brushless motor drives, coupled by a shaft. We programmed the first motor and its drive to mimic the speed-torque characteristic of the gas turbine engine, while the second motor and drive act as a generator and produce a torque load on the first motor. Secondly, we built another system of two PM motors and drives to emulate a motor driving a propulsive fan. We programmed the first motor and drive to emulate a wound-rotor synchronous motor. The propulsive fan was emulated by implementing fan maps and flight conditions into the fourth motor and drive, which produce a torque load on the driving motor. The stator of each PM motor is designed to travel axially to change the coupling between rotor and stator. This feature allows the PM motor to more closely emulate a wound-rotor synchronous machine. These techniques can convert the plain motor system into a unique TeDP power grid emulator that enables real-time simulation performance using hardware-in-the-loop (HIL).

electric power grid emulator↗
NASA NTRS2008

Ares I and Ares V First Stage - Powering Exploration

The National Aeronautics and Space Administration (NASA) Ares Projects Office (APO) is continuing to make progress toward the final design of the first stage propulsion system for the Ares I crew launch vehicle and the Ares V cargo launch vehicle. Ares I and Ares V will provide the space launch capabilities needed to fulfill NASA' s exploration strategy of sending human beings to the Moon, Mars, and beyond. As primary propulsion for the Ares launch vehicles, the Space Shuttle-derived Reusable Solid Rocket Motor (RSRM) is one of the first and most important components to be tested. The first flight of Ares I, called Ares I-X, will occur in April 2009, with booster integration to begin at Kennedy Space Center (KSC) by autumn 2008. The Ares I-X flight will use a combination of flight and simulation hardware to obtain data on controlling the long and narrow crew launch vehicle configuration. The test will use a four-segment RSRM from the Shuttle inventory and a fifth spacer segment to simulate the size and weight of the operational five-segment motor to be used on later flights. The upper stage, Orion crew exploration vehicle, and launch abort system will all be replaced with simulator hardware. Manufacturing work has begun on the spacer segment, as well as the new forward hardware for the booster. Atlas V avionics will be adapted to control Ares I-X' s first stage. That hardware is undergoing hardware-in-the-loop testing in a contractor-provided systems integration laboratory (SIL); a critical design review (CDR) was completed in December 2007. Drogue and main parachute drop tests have also been conducted successfully at Yuma Proving Grounds, allowing the First Stage team to begin fabricating parachutes for Ares I-X. The Ares I-X flight test will be the first flight test for the parachutes. A series of preliminary design technical interchange meetings is being conducted prior to the Ares I-X CDR in January 2007 to ensure readiness for the flight. Much of the First Stage activity in 2007 has focused on a series of preliminary design (PDR) activities associated with each booster subsystem. These events will culminate in a formal preliminary design review in 2008, where subsystems and component specifications will be developed and associated analyses and drawings will be evaluated for technical adequacy. The first stage also has been undergoing a series of trade studies to determine means for upgrading booster performance and reducing operational costs. Performance improvement studies have included changing from polybutadiene acrylonitrile (PBAN) propellant to hydroxyl-terminated polybutadiene (HTPB); replacing aluminum with composite motor casings; and optimizing or upgrading the propellant grain and nozzle structures. Some or all of these changes could result in a block upgrade to the Ares I first stage, after becoming the standard configuration for the Ares V. The cost reduction studies included a change from reusable or recoverable boosters to completely expendable boosters; changing from hydrazine-powered to more environmentally friendly electrohydrostatic actuators (EHAs) on the thrust vector control (TVC) system; and changing the location of the separation plane to reduce the likelihood of recontact upon booster separation. The expendability trade study resulted in a decision to keep the recoverable boosters, as the new hardware costs significantly outweighed the potential operational cost savings due to reduced ground operations. Likewise, due to cost considerations, the team continued using existing hydrazine-powered actuators for the TVC system. The separation plane location for Ares I is still being studied, with results to be announced in 2008. In short, the Ares launch vehicles' first stage is building upon NASA's close familiarity with this Shuttle-derived system, while continuing to seek out improvements for long-term exploration.

Priskos, Alex S.↗
NASA NTRS2000

X-38 Experimental Controls Laws

X-38 Experimental Control Laws X-38 is a NASA JSC/DFRC experimental flight test program developing a series of prototypes for an International Space Station (ISS) Crew Return Vehicle, often called an ISS "lifeboat." X- 38 Vehicle 132 Free Flight 3, currently scheduled for the end of this month, will be the first flight test of a modem FCS architecture called Multi-Application Control-Honeywell (MACH), originally developed by the Honeywell Technology Center. MACH wraps classical P&I outer attitude loops around a modem dynamic inversion attitude rate loop. The dynamic inversion process requires that the flight computer have an onboard aircraft model of expected vehicle dynamics based upon the aerodynamic database. Dynamic inversion is computationally intensive, so some timing modifications were made to implement MACH on the slower flight computers of the subsonic test vehicles. In addition to linear stability margin analyses and high fidelity 6-DOF simulation, hardware-in-the-loop testing is used to verify the implementation of MACH and its robustness to aerodynamic and environmental uncertainties and disturbances.

Munday, Steve↗
NASA NTRS2003

First Results from a Hardware-in-the-Loop Demonstration of Closed-Loop Autonomous Formation Flying

A closed-loop system for the demonstration of formation flying technologies has been developed at NASA s Goddard Space Flight Center. Making use of a GPS signal simulator with a dual radio frequency outlet, the system includes two GPS space receivers as well as a powerful onboard navigation processor dedicated to the GPS-based guidance, navigation, and control of a satellite formation in real-time. The closed-loop system allows realistic simulations of autonomous formation flying scenarios, enabling research in the fields of tracking and orbit control strategies for a wide range of applications. A sample scenario has been set up where the autonomous transition of a satellite formation from an initial along-track separation of 800 m to a final distance of 100 m has been demonstrated. As a result, a typical control accuracy of about 5 m has been achieved which proves the applicability of autonomous formation flying techniques to formations of satellites as close as 50 m.

Gill, E.↗
NASA NTRS2007

The Autonomous Precision Landing and Hazard Detection and Avoidance Technology (ALHAT)

As NASA plans to send humans back to the Moon and develop a lunar outpost, technologies must be developed to place humans and cargo safely, precisely, repeatedly, on the lunar surface with the capability to avoid surface hazards. Exploration Space Architecture Study requirements include the need for global lunar surface access with safe, precise landing without lighting constraints on terrain that may have landing hazards for human scale landing vehicles. Landing accuracies of perhaps 1,000 meters for sortie crew missions to 10 s of meters for Outpost class missions are required. The Autonomous precision Landing Hazard Avoidance Technology (ALHAT) project will develop the new and unique descent and landing Guidance, Navigation and Control (GNC) hardware and software technologies necessary for these capabilities. The ALHAT project will qualify a lunar descent and landing GNC system to a Technology Readiness Level (TRL) of 6 capable of supporting lunar crewed, cargo, and robotic missions. The (ALHAT) development project was chartered by NASA Headquarters in October 2006. The initial effort to write a project plan and define an ALHAT Team was followed by a fairly aggressive research and analysis effort to determine what technologies existed that could be developed and applied to the lunar landing problems indicated above. This paper describes the project development, research, analysis and concept evolution that has occurred since the assignment of the project. This includes the areas of systems engineering, GNC, sensors, sensor algorithms, simulations, fielding testing, laboratory testing, Hardware-In-The-Loop testing, system avionics and system certification concepts.

Epp, Chirold D.↗
NASA NTRS2009

Modeling and Simulation of Variable Mass, Flexible Structures

The advent of the new Ares I launch vehicle has highlighted the need for advanced dynamic analysis tools for variable mass, flexible structures. This system is composed of interconnected flexible stages or components undergoing rapid mass depletion through the consumption of solid or liquid propellant. In addition to large rigid body configuration changes, the system simultaneously experiences elastic deformations. In most applications, the elastic deformations are compatible with linear strain-displacement relationships and are typically modeled using the assumed modes technique. The deformation of the system is approximated through the linear combination of the products of spatial shape functions and generalized time coordinates. Spatial shape functions are traditionally composed of normal mode shapes of the system or even constraint modes and static deformations derived from finite element models of the system. Equations of motion for systems undergoing coupled large rigid body motion and elastic deformation have previously been derived through a number of techniques [1]. However, in these derivations, the mode shapes or spatial shape functions of the system components were considered constant. But with the Ares I vehicle, the structural characteristics of the system are changing with the mass of the system. Previous approaches to solving this problem involve periodic updates to the spatial shape functions or interpolation between shape functions based on system mass or elapsed mission time. These solutions often introduce misleading or even unstable numerical transients into the system. Plus, interpolation on a shape function is not intuitive. This paper presents an approach in which the shape functions are held constant and operate on the changing mass and stiffness matrices of the vehicle components. Each vehicle stage or component finite element model is broken into dry structure and propellant models. A library of propellant models is used to describe the distribution of mass in the fuel tank or Solid Rocket Booster (SRB) case for various propellant levels. Based on the mass consumed by the liquid engine or SRB, the appropriate propellant model is coupled with the dry structure model for the stage. Then using vehicle configuration data, the integrated vehicle model is assembled and operated on by the constant system shape functions. The system mode shapes and frequencies can then be computed from the resulting generalized mass and stiffness matrices for that mass configuration. The rigid body mass properties of the vehicle are derived from the integrated vehicle model. The coupling terms between the vehicle rigid body motion and elastic deformation are also updated from the constant system shape functions and the integrated vehicle model. This approach was first used to analyze variable mass spinning beams and then prototyped into a generic dynamics simulation engine. The resulting code was tested against Crew Launch Vehicle (CLV-)class problems worked in the TREETOPS simulation package and by Wilson [2]. The Ares I System Integration Laboratory (SIL) is currently being developed at the Marshall Space Flight Center (MSFC) to test vehicle avionics hardware and software in a hardware-in-the-loop (HWIL) environment and certify that the integrated system is prepared for flight. The Ares I SIL utilizes the Ares Real-Time Environment for Modeling, Integration, and Simulation (ARTEMIS) tool to simulate the launch vehicle and stimulate avionics hardware. Due to the presence of vehicle control system filters and the thrust oscillation suppression system, which are tuned to the structural characteristics of the vehicle, ARTEMIS must incorporate accurate structural models of the Ares I launch vehicle. The ARTEMIS core dynamics simulation models the highly coupled nature of the vehicle flexible body dynamics, propellant slosh, and vehicle nozzle inertia effects combined with mass and flexible body properties that vary significant with time during the flight. All forces that act on the vehicle during flight must be simulated, including deflected engine thrust force, spatially distributed aerodynamic forces, gravity, and reaction control jet thrust forces. These forces are used to excite an integrated flexible vehicle, slosh, and nozzle dynamics model for the vehicle stack that simulates large rigid body translations and rotations along with small elastic deformations. Highly effective matrix math operations on a distributed, threaded high-performance simulation node allow ARTEMIS to retain up to 30 modes of flex for real-time simulation. Stage elements that separate from the stack during flight are propagated as independent rigid six degrees of freedom (6DOF) bodies. This paper will present the formulation of the resulting equations of motion, solutions to example problems, and describe the resulting dynamics simulation engine within ARTEMIS.

Tobbe, Patrick A.↗
NASA NTRS2010

Portable Health Algorithms Test System

A document discusses the Portable Health Algorithms Test (PHALT) System, which has been designed as a means for evolving the maturity and credibility of algorithms developed to assess the health of aerospace systems. Comprising an integrated hardware-software environment, the PHALT system allows systems health management algorithms to be developed in a graphical programming environment, to be tested and refined using system simulation or test data playback, and to be evaluated in a real-time hardware-in-the-loop mode with a live test article. The integrated hardware and software development environment provides a seamless transition from algorithm development to real-time implementation. The portability of the hardware makes it quick and easy to transport between test facilities. This hard ware/software architecture is flexible enough to support a variety of diagnostic applications and test hardware, and the GUI-based rapid prototyping capability is sufficient to support development execution, and testing of custom diagnostic algorithms. The PHALT operating system supports execution of diagnostic algorithms under real-time constraints. PHALT can perform real-time capture and playback of test rig data with the ability to augment/ modify the data stream (e.g. inject simulated faults). It performs algorithm testing using a variety of data input sources, including real-time data acquisition, test data playback, and system simulations, and also provides system feedback to evaluate closed-loop diagnostic response and mitigation control.

Melcher, Kevin J.↗
NASA NTRS2010

Use of ILTV Control Laws for LaNCETS Flight Research

A report discusses the Lift and Nozzle Change Effects on Tail Shock (LaNCETS) test to investigate the effects of lift distribution and nozzle-area ratio changes on tail shock strength of an F-15 aircraft. Specific research objectives are to obtain inflight shock strength for multiple combinations of nozzle-area ratio and lift distribution; compare results with preflight prediction tools; and update predictive tools with flight results. The objectives from a stability and control perspective are to ensure adequate aircraft stability for the changes in lift distribution and plume shape, and ensure manageable transient from engaging and disengaging the ILTV research control laws. In order to change the lift distribution and plume shape of the F-15 aircraft, a decade-old Inner Loop Thrust Vectoring (ILTV) research control law was used. Flight envelope expansion was performed for the test configuration and flight conditions prior to the probing test points. The approach for achieving the research objectives was to utilize the unique capabilities of NASA's NF-15B-837 aircraft to allow the adjustment of the nozzle-area ratio and/or canard positions by engaging the ILTV research control laws. The ILTV control laws provide the ability to add trim command biases to canard positions, nozzle area ratios, and thrust vectoring through the use of datasets. Datasets consist of programmed test inputs (PTIs) that define trims to change the nozzle-area ratio and/or canard positions. The trims are applied as increments to the normally commanded positions. A LaNCETS non-linear, six-degrees-of-freedom simulation capable of realtime pilot-in-the-loop, hardware-in-the-loop, and non-real-time batch support was developed and validated. Prior to first flight, extensive simulation analyses were performed to show adequate stability margins with the changes in lift distribution and plume shape. Additionally, engagement/disengagement transient analysis was also performed to show manageable transients.

Moua, Cheng↗
NASA NTRS2014

UAS-Systems Integration, Validation, and Diagnostics Simulation Capability

As part of the Phase 1 efforts of NASA's UAS-in-the-NAS Project a task was initiated to explore the merits of developing a system simulation capability for UAS to address airworthiness certification requirements. The core of the capability would be a software representation of an unmanned vehicle, including all of the relevant avionics and flight control system components. The specific system elements could be replaced with hardware representations to provide Hardware-in-the-Loop (HWITL) test and evaluation capability. The UAS Systems Integration and Validation Laboratory (UAS-SIVL) was created to provide a UAS-systems integration, validation, and diagnostics hardware-in-the-loop simulation capability. This paper discusses how SIVL provides a robust and flexible simulation framework that permits the study of failure modes, effects, propagation paths, criticality, and mitigation strategies to help develop safety, reliability, and design data that can assist with the development of certification standards, means of compliance, and design best practices for civil UAS.

Buttrill, Catherine W.↗
NASA NTRS2013

SILHIL Replication of Electric Aircraft Powertrain Dynamics and Inner-Loop Control for V&V of System Health Management Routines

Software-in-the-loop and Hardware-in-the-loop testing of failure prognostics and decision making tools for aircraft systems will facilitate more comprehensive and cost-effective testing than what is practical to conduct with flight tests. A framework is described for the offline recreation of dynamic loads on simulated or physical aircraft powertrain components based on a real-time simulation of airframe dynamics running on a flight simulator, an inner-loop flight control policy executed by either an autopilot routine or a human pilot, and a supervisory fault management control policy. The creation of an offline framework for verifying and validating supervisory failure prognostics and decision making routines is described for the example of battery charge depletion failure scenarios onboard a prototype electric unmanned aerial vehicle.

Verification and Validation↗
NASA NTRS2016

NASA Operational Simulator for Small Satellites: Tools for Software Based Validation and Verification of Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of tools to aid in areas such as software development, integration test (IT), mission operations training, verification and validation (VV), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, an operator interface-ground station, dynamics and environment simulations, and software-based hardware models. NOS3 enables the development of flight software (FSW) early in the project life cycle, when access to hardware is typically not available. For small satellites there are extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETU). Considering the difficulty of providing a hardware test-bed to each developer tester, hardware models are modeled based upon characteristic data or manufacturers data sheets for each individual component. The fidelity of each hardware models is such that FSW executes unaware that physical hardware is not present. This allows binaries to be compiled for both the simulation environment, and the flight computer, without changing the FSW source code. For hardware models that provide data dependent on the environment, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulation) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for VV of larger missions such as James Webb Space Telescope (JWST). As hardware is procured, drivers can be added to the environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. The open-source operator interface used in NOS3 is COSMOS from Ball Aerospace. For testing, plug-ins are implemented in COSMOS to control the NOS3 simulations, while the command and telemetry tools available in COSMOS are used to communicate with FSW. NOS3 is actively being used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat. As NOS3 matures, hardware models have been added for common CubeSat components such as Novatel GPS receivers, ClydeSpace electrical power systems and batteries, ISISpace antenna systems, etc. In the future, NASA IVV plans to distribute NOS3 to other CubeSat developers and release the suite to the open-source community.

Verification↗
NASA NTRS2018

Sensor Data Quality and Angular Rate Down-Selection Algorithms on SLS EM-1

The NASA Space Launch System Block 1 launch vehicle is equipped with an Inertial Navigation System (INS) and multiple Rate Gyro Assemblies (RGA) that are used in the Guidance, Navigation, and Control (GN&C) algorithms. The INS provides the inertial position, velocity, and attitude of the vehicle along with both angular rate and specific force measurements. Additionally, multiple sets of co-located rate gyros supply angular rate data. The collection of angular rate data, taken along the launch vehicle, is used to separate out vehicle motion from flexible body dynamics. Since the system architecture uses redundant sensors, the capability was developed to evaluate the health (or validity) of the independent measurements. A suite of Sensor Data Quality (SDQ) algorithms is responsible for assessing the angular rate data from the redundant sensors. When failures are detected, SDQ will take the appropriate action and disqualify or remove faulted sensors from forward processing. Additionally, the SDQ algorithms contain logic for down-selecting the angular rate data used by the GNC software from the set of healthy measurements. This paper explores the trades and analyses that were performed in selecting a set of robust fault-detection algorithms included in the GN&C flight software. These trades included both an assessment of hardware-provided health and status data as well as an evaluation of different algorithms based on time-to-detection, type of failures detected, and probability of detecting false positives. We then provide an overview of the algorithms used for both fault-detection and measurement down selection. We next discuss the role of trajectory design, flexible-body models, and vehicle response to off-nominal conditions in setting the detection thresholds. Lastly, we present lessons learned from software integration and hardware-in-the-loop testing.

Park, Thomas↗
NASA NTRS2014

LADEE Multi-Domain Simulation

The Lunar Atmosphere Dust Environment Explorer (LADEE) was a small explorer class spacecraft that was launched on Sept 7, 2013 and that was de-orbited and successfully impacted the Moons surface on April 17, 2014 after completing all of the mission objectives. The low-cost rapidly prototyped hardware design used for the spacecraft was extend to the development of the software base. To achieve this goal, a Model Based Design approach was utilized to develop the onboard flight software, and out of this development a model based multipurpose simulator was created of the LADEE spacecraft and its mission environment. This simulator extended the traditional function of propagating the vehicle's kinematic and rotational states and included the electrical and thermal states propagation. Traditionally, these domains are handled by domain specific high fidelity simulations that use the states histories from other domains as input. By reducing the fidelity and abstracting the relevant features being monitored and controlled by the flight software, it was possible to model the coupling across these domains resulting in more accurate overall system behavior. A faster than real-time workstation (WSIM) version of the LADEE simulator was used to develop and test the software control algorithms in the Simulink environment. To maximize the performance of the simulation, modeling knobs were introduced to reduce the resolution of the some of the domains models when the effects of that domain were not significant for the scope of that simulation. The automatic code generation feature in Simulink was used to port the simulation to several real-time environments to support Processor-in-the-Loop (PIL) and Hardware-in-the-Loop (HIL) testing, verification and validation. The real-time environment required that the design of each of the domain models be deterministic as possible in the time required to perform all of the calculations to update its states. The simulation interface was designed to be compatible with the command interface employed by the LADEE mission operation team. The WSIM, PIL, and HIL simulators thus used a common interface and thus were used for flight software testing, for mission operations personnel training (nominal and off-nominal operations) prior to the mission and to perform command sequence verification during the mission. This presentation will look at the modeling strategies used to create a common interface to the simulator and to model and couple multiple domains within the simulation, the results of those strategies, and the lessons learned.

Multi-Domain↗