Search NASA⌕ Search

SEARCH · Search NASA

Results for “software testing”

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 559 records · Page 31

Electrical Impedance Tomography Technology: 2013 Center Innovation Fund Final Report

Electrical impedance tomography is a medical noninvasive imaging technology which has advantages over other medical imaging technologies for medically safe long term real time internal imaging monitoring applications in human patients. The technology is much more compact, portable, low power and potentially more low cost compared to other medical image technologies, making it very well suited for medical aerospace and spaceflight applications. EIT technology’s main drawback has been low image resolution, and consequently improving EIT resolution is the primary research goal, as well as increasing imaging speed for real time animation imaging. In a relatively short time the BERL group has brought together design plans, technical resources and has built and tested hardware with the purpose of improving EIT imaging technology. EIT prototype system development plans and system designs have been made to target needed EIT technical improvement in electronic and computer hardware as well as EIT software technology. New hardware design and fabrication resources and technologies have been brought together through resourceful use of existing equipment and software at BERL, and a significant advance has been made in custom electronic hardware prototyping capabilities in collaboration with EFAL, for mutual benefit for both NASA KSC laboratories. BERL has gained significant EIT software capability and tested EIT imaging algorithm code through collaboration with an internationally recognized EIT software development and research forum. A new custom workstation has been developed, built and tested using internal resources, equipment and expertise, that includes a new state-of-the-art massively parallel technology that is commercially available. Custom prototype hardware has been designed and tested, a high priority electronic design, key to improving electronic performance and image quality, has been researched and tested in four designs, with a summary of test results of the selected design illustrated here. The selected design performance exceeds the developed EIT design hardware specifications.

Michael R Lapointe↗

CFS Test Framework

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

cfs↗

Flight and Integrated Vehicle Testing: Laying the Groundwork for the Next Generation of Space Exploration Launch Vehicles

Integrated vehicle testing will be critical to ensuring proper vehicle integration of the Ares I crew launch vehicle and Ares V cargo launch vehicle. The Ares Projects, based at Marshall Space Flight Center in Alabama, created the Flight and Integrated Test Office (FITO) as a separate team to ensure that testing is an integral part of the vehicle development process. As its name indicates, FITO is responsible for managing flight testing for the Ares vehicles. FITO personnel are well on the way toward assembling and flying the first flight test vehicle of Ares I, th Ares I-X. This suborbital development flight will evaluate the performance of Ares I from liftoff to first stage separation, testing flight control algorithms, vehicle roll control, separation and recovery systems, and ground operations. Ares I-X is now scheduled to fly in summer 2009. The follow-on flight, Ares I-Y, will test a full five-segment first stage booster and will include cryogenic propellants in the upper stage, an upper stage engine simulator, and an active launch abort system. The following flight, Orion 1, will be the first flight of an active upper stage and upper stage engine, as well as the first uncrewed flight of an Orion spacecraft into orbit. The Ares Projects are using an incremental buildup of flight capabilities prior to the first operational crewed flight of Ares I and the Orion crew exploration vehicle in 2015. In addition to flight testing, the FITO team will be responsible for conducting hardware, software, and ground vibration tests of the integrated launch vehicle. These efforts will include verifying hardware, software, and grou handling interfaces. Through flight and integrated testing, the Ares Projects will identify and mitigate risks early the United States prepares to take its next giant leaps to the Moon and beyond.

Taylor, Jim↗

Flight and Integrated Vehicle Testing: Laying the Groundwork for the Next Generation of Space Exploration Launch Vehicles

Integrated vehicle testing will be critical to ensuring proper vehicle integration of the Ares I crew launch vehicle and Ares V cargo launch vehicle. The Ares Projects, based at Marshall Space Flight Center in Alabama, created the Flight and Integrated Test Office (FITO) as a separate team to ensure that testing is an integral part of the vehicle development process. As its name indicates, FITO is responsible for managing flight testing for the Ares vehicles. FITO personnel are well on the way toward assembling and flying the first flight test vehicle of Ares I, the Ares I-X. This suborbital development flight will evaluate the performance of Ares I from liftoff to first stage separation, testing flight control algorithms, vehicle roll control, separation and recovery systems, and ground operations. Ares I-X is now scheduled to fly in summer 2009. The follow-on flight, Ares I-Y, will test a full five-segment first stage booster and will include cryogenic propellants in the upper stage, an upper stage engine simulator, and an active launch abort system. The following flight, Orion 1, will be the first flight of an active upper stage and upper stage engine, as well as the first uncrewed flight of an Orion spacecraft into orbit. The Ares Projects are using an incremental buildup of flight capabilities prior to the first operational crewed flight of Ares I and the Orion crew exploration vehicle in 2015. In addition to flight testing, the FITO team will be responsible for conducting hardware, software, and ground vibration tests of the integrated launch vehicle. These efforts will include verifying hardware, software, and ground handling interfaces. Through flight and integrated testing, the Ares Projects will identify and mitigate risks early as the United States prepares to take its next giant leaps to the Moon and beyond.

Taylor, J. L.↗

Evaluation of Visualization Software

Visualization software is widely used in scientific and engineering research. But computed visualizations can be very misleading, and the errors are easy to miss. We feel that the software producing the visualizations must be thoroughly evaluated and the evaluation process as well as the results must be made available. Testing and evaluation of visualization software is not a trivial problem. Several methods used in testing other software are helpful, but these methods are (apparently) often not used. When they are used, the description and results are generally not available to the end user. Additional evaluation methods specific to visualization must also be developed. We present several useful approaches to evaluation, ranging from numerical analysis of mathematical portions of algorithms to measurement of human performance while using visualization systems. Along with this brief survey, we present arguments for the importance of evaluations and discussions of appropriate use of some methods.

Globus, Al↗

Simulation of Non-Acoustic Combustion Instability in a Hybrid Rocket Motor

A transient model of a hybrid motor was formulated to study the cause and elimination of non-acoustic combustion instability. The transient model was used to simulate four key tests out of a series of seventeen hybrid motor tests conducted by Thiokol, Rocketdyne and Martin Marietta at NASA/Marshall Space Flight Center (NASA/MSFC). These tests were performed under the Hybrid Propulsion Technology for Launch Vehicle Boosters (HPTLVB) program. The first test resulted in stable combustion. The second test resulted in large-amplitude, 6.5 Hz chamber pressure oscillations that gradually damped away by the end of the test. The third test resulted in large-amplitude, 7.5 Hz chamber pressure oscillations that were sustained throughout the test. The seventh test resulted in the elimination of combustion instability with the installation of an orifice immediately upstream of the injector. The formulation and implementation of the model are the scope of this presentation. The current model is an independent continuation of modeling presented previously by joint Thiokol-Rocketdyne collaborators Boardman, Hawkins, Wassom, and Claflin. The previous model simulated an unstable IR&D hybrid motor test performed by Thiokol. There was very good agreement between the model and the test data. Like the previous model, the current model was developed using Matrix-x simulation software. However, the tests performed at NASA/MSFC under the HPTLVB program were actually simulated. In the current model, the hybrid motor consisting of the liquid oxygen (LOX) injector, the multi-port solid fuel grain and the nozzle was simulated. Also, simulated in the model was the LOX feed system consisting of the tank, venturi, valve and feed lines. All components of the hybrid motor and LOX feed system are treated by a lumped-parameter approach. Agreement between the results of the transient model and the actual test data was very good. This agreement between simulated and actual test data indicated that the combustion instability in the hybrid motor was due to two causes. The first cause was a LOX feed system of insufficient stiffness. The second cause was a LOX injector with an impedance or pressure drop that was too low to provide damping against the feed system oscillations. Also, it was discovered that testing with a new grain of solid fuel sustained the combustion instability. However, testing with a used grain of solid fuel caused the combustion instability to gradually decay.

Rocker, Marvin↗

Simulation of Non-Acoustic Combustion Instability in a Hybrid Rocket Motor

A transient model of a hybrid motor was formulated to study the cause and elimination of non-acoustic combustion instability. The transient model was used to simulate four key tests out of a series of seventeen hybrid motor tests conducted by Thiokol, Rocketdyne and Martin Marietta at NASA/Marshall Space Flight Center (NASAIMSFC). These tests were performed under the Hybrid Propulsion Technology for Launch Vehicle Boosters (HPTLVB) program. The first test resulted in stable combustion. The second test resulted in large-amplitude, 6.5 Hz chamber pressure oscillations that gradually damped away by the end of the test. The third test resulted in large-amplitude, 7.5 Hz chamber pressure oscillations that were sustained throughout the test. The seventh test resulted in the elimination of combustion instability with the installation of an orifice immediately upstream of the injector. The formulation and implementation of the model are the scope of this presentation. The current model is an independent continuation of modeling presented previously by joint Thiokol-Rocketdyne collaborators Boardman, Hawkins, Wassom, and Claflin. The previous model simulated an unstable IR&D hybrid motor test performed by Thiokol. There was very good agreement between the model and the test data. Like the previous model, the current model was developed using Matrix-x simulation software. However, the tests performed at NASA/MSFC under the HPTLVB program were actually simulated. In the current model, the hybrid motor consisting of the liquid oxygen (LOX) injector, the multi-port solid fuel grain and the nozzle was simulated. Also, simulated in the model was the LOX feed system consisting of the tank, venturi, valve and feed lines. All components of the hybrid motor and LOX feed system are treated by a lumped-parameter approach. Agreement between the results of the transient model and the actual test data was very good. This agreement between simulated and actual test data indicated that the combustion instability in the hybrid motor was due to two causes. The first cause was a LOX feed system of insufficient stiffness. The second cause was a LOX injector with an impedance or pressure drop that was too low to provide damping against the feed system oscillations. Also, it was discovered that testing with a new grain of solid fuel sustained the combustion instability. However, testing with a used grain of solid fuel caused the combustion instability to gradually decay.

Rocker, Marvin↗

Safety Characteristics in System Application of Software for Human Rated Exploration Missions for the 8th IAASS Conference

NASA and its industry and international partners are embarking on a bold and inspiring development effort to design and build an exploration class space system. The space system is made up of the Orion system, the Space Launch System (SLS) and the Ground Systems Development and Operations (GSDO) system. All are highly coupled together and dependent on each other for the combined safety of the space system. A key area of system safety focus needs to be in the ground and flight application software system (GFAS). In the development, certification and operations of GFAS, there are a series of safety characteristics that define the approach to ensure mission success. This paper will explore and examine the safety characteristics of the GFAS development. The GFAS system integrates the flight software packages of the Orion and SLS with the ground systems and launch countdown sequencers through the 'agile' software development process. A unique approach is needed to develop the GFAS project capabilities within this agile process. NASA has defined the software development process through a set of standards. The standards were written during the infancy of the so-called industry 'agile development' movement and must be tailored to adapt to the highly integrated environment of human exploration systems. Safety of the space systems and the eventual crew on board is paramount during the preparation of the exploration flight systems. A series of software safety characteristics have been incorporated into the development and certification efforts to ensure readiness for use and compatibility with the space systems. Three underlining factors in the exploration architecture require the GFAS system to be unique in its approach to ensure safety for the space systems, both the flight as well as the ground systems. The first are the missions themselves, which are exploration in nature, and go far beyond the comfort of low Earth orbit operations. The second is the current exploration system will launch only one mission per year even less during its developmental phases. Finally, the third is the partnered approach through the use of many different prime contractors, including commercial and international partners, to design and build the exploration systems. These three factors make the challenges to meet the mission preparations and the safety expectations extremely difficult to implement. As NASA leads a team of partners in the exploration beyond earth's influence, it is a safety imperative that the application software used to test, checkout, prepare and launch the exploration systems put safety of the hardware and mission first. Software safety characteristics are built into the design and development process to enable the human rated systems to begin their missions safely and successfully. Exploration missions beyond Earth are inherently risky, however, with solid safety approaches in both hardware and software, the boldness of these missions can be realized for all on the home planet.

capability↗

Developing High Performance Space Networking Capabilities for the International Space Station and Beyond

A performance optimized implementation of Delay Tolerant Networking (DTN) with the capacity of gigabit-per second rates is developed for the International Space Station (ISS) and missions demanding large amounts of communications bandwidth. An overview of the High-rate Delay Tolerant Networking (HDTN) architecture and support for different convergence layers is provided. This paper then presents an overview of the testing and integration efforts to evaluate interoperability and capability in relevant environments. The first was interoperability testing with DTN Marshall Enterprise (DTNME) which resulted in near-gigabit per second data rates. This was followed by ISS emulation testing with the Software Development and Integration Laboratory (SDIL) at the Lyndon B. Johnson Space Center (JSC) and local testing based on the ISS DTN network topology. The local tests resulted in the discovery of potential sources of performance loss in the network and demonstrated near-gigabit rates between HDTN and DTNME.

Daniel Raible↗

Cleanroom software development

The 'cleanroom' software development process is a technical and organizational approach to developing software with certifiable reliability. Key ideas behind the process are well structured software specifications, randomized testing methods and the introduction of statistical controls; but the main point is to deny entry for defects during the development of software. This latter point suggests the use of the term 'cleanroom' in analogy to the defect prevention controls used in the manufacturing of high technology hardware. In the 'cleanroom', the entire software development process is embedded within a formal statistical design, in contrast to executing selected tests and appealing to the randomness of operational settings for drawing statistical inferences. Instead, random testing is introduced as a part of the statistical design itself so that when development and testing are completed, statistical inferences are made about the operation of the system.

Dyer, M.↗

Software for Automated Image-to-Image Co-registration

The project objectives are: a) Develop software to fine-tune image-to-image co-registration, presuming images are orthorectified prior to input; b) Create a reusable software development kit (SDK) to enable incorporation of these tools into other software; d) provide automated testing for quantitative analysis; and e) Develop software that applies multiple techniques to achieve subpixel precision in the co-registration of image pairs.

Benkelman, Cody A.↗

NASA Operational Simulator for Small Satellites (NOS3)

The Simulation-to-Flight 1 (STF-1) CubeSat mission aims to demonstrate how legacy simulation technologies may be adapted for flexible and effective use on missions using the CubeSat platform. These technologies, named NASA Operational Simulator (NOS), have demonstrated significant value on several missions such as James Webb Space Telescope, Global Precipitation Measurement, Juno, and Deep Space Climate Observatory in the areas of software development, mission operationstraining, verification and validation (VV), test procedure development and software systems check-out. STF-1 will demonstrate a highly portable simulation and test platform that allows seamless transition of mission development artifacts to flight products. This environment will decrease development time of future CubeSat missions by lessening the dependency on hardware resources. In addition, through a partnership between NASA GSFC, the West Virginia Space Grant Consortium and West Virginia University, the STF-1 CubeSat will hosts payloads for three secondary objectives that aim to advance engineering and physical-science research in the areas of navigation systems of small satellites, provide useful data for understanding magnetosphere-ionosphere coupling and space weather, and verify the performance and durability of III-V Nitride-based materials.

modeling simulation↗

An Experimental System for Strategic Flight Path Management in Advanced Air Mobility

In the concept envisioned for Urban Air Mobility (UAM) operations, fleets of electric vertical takeoff and landing (eVTOL) vehicles would operate between vertiports distributed within a densely populated area. These operations would be largely independent from the existing air traffic control system and would place the responsibility for flight planning and aircraft separation on fleet operators. The fourth major level on the UAM Maturity Level scale, UML-4, relies on “collaborative and responsible” automation to enable operations in non-visual conditions with medium traffic density (hundreds of aircraft in one metropolitan region) and medium complexity. This level of service places many requirements on automation systems to assist the operators of these aircraft. NASA has developed the Autonomous Operations Planner (AOP), a reference prototype Flight Path Management automation system, and has modified AOP to support research of anticipated UML-4 operations. AOP creates a four-dimensional flight plan conforming to the constraints of these operations, evaluates and modifies the flight plan during flight as conditions and constraints evolve, and coordinates the flight plan with other airspace users and with service providers. This version of AOP has been integrated into the Sikorsky Autonomy Research Aircraft and used in a flight test activity. In this paper we discuss anticipated characteristics of UAM operations, modifications that were made to AOP to adapt to that environment or to support the flight test, and observations of software and aircraft performance during the flight test. The aircraft achieved four-dimensional conformance with the flight plan and AOP provided adequate planning in almost all cases. We discuss improvements that could be made to AOP to address deficiencies that were observed.

Autonomous Operations Planner↗

An Experimental System for Strategic Flight Path Management in Advanced Air Mobility

In the concept envisioned for Urban Air Mobility (UAM) operations, fleets of electric vertical takeoff and landing (eVTOL) vehicles would operate between vertiports distributed within a densely populated area. These operations would be largely independent from the existing air traffic control system and would place the responsibility for flight planning and aircraft separation on fleet operators. The fourth major level on the UAM Maturity Level scale, UML-4, relies on “collaborative and responsible” automation to enable operations in non-visual conditions with medium traffic density (hundreds of aircraft in one metropolitan region) and medium complexity. This level of service places many requirements on automation systems to assist the operators of these aircraft. NASA has developed the Autonomous Operations Planner (AOP), a reference prototype Flight Path Management automation system, and has modified AOP to support research of anticipated UML-4 operations. AOP creates a four-dimensional flight plan conforming to the constraints of these operations, evaluates and modifies the flight plan during flight as conditions and constraints evolve, and coordinates the flight plan with other airspace users and with service providers. This version of AOP has been integrated into the Sikorsky Autonomy Research Aircraft and used in a flight test activity. In this paper we discuss anticipated characteristics of UAM operations, modifications that were made to AOP to adapt to that environment or to support the flight test, and observations of software and aircraft performance during the flight test. The aircraft achieved four-dimensional conformance with the flight plan and AOP provided adequate planning in almost all cases. We discuss improvements that could be made to AOP to address deficiencies that were observed.

Autonomous Operations Planner↗

Software analysis handbook: Software complexity analysis and software reliability estimation and prediction

This handbook documents the three software analysis processes the Space Station Software Analysis team uses to assess space station software, including their backgrounds, theories, tools, and analysis procedures. Potential applications of these analysis results are also presented. The first section describes how software complexity analysis provides quantitative information on code, such as code structure and risk areas, throughout the software life cycle. Software complexity analysis allows an analyst to understand the software structure, identify critical software components, assess risk areas within a software system, identify testing deficiencies, and recommend program improvements. Performing this type of analysis during the early design phases of software development can positively affect the process, and may prevent later, much larger, difficulties. The second section describes how software reliability estimation and prediction analysis, or software reliability, provides a quantitative means to measure the probability of failure-free operation of a computer program, and describes the two tools used by JSC to determine failure rates and design tradeoffs between reliability, costs, performance, and schedule.

Computer systems design↗

Control Software for Advanced Video Guidance Sensor

Embedded software has been developed specifically for controlling an Advanced Video Guidance Sensor (AVGS). A Video Guidance Sensor is an optoelectronic system that provides guidance for automated docking of two vehicles. Such a system includes pulsed laser diodes and a video camera, the output of which is digitized. From the positions of digitized target images and known geometric relationships, the relative position and orientation of the vehicles are computed. The present software consists of two subprograms running in two processors that are parts of the AVGS. The subprogram in the first processor receives commands from an external source, checks the commands for correctness, performs commanded non-image-data-processing control functions, and sends image data processing parts of commands to the second processor. The subprogram in the second processor processes image data as commanded. Upon power-up, the software performs basic tests of functionality, then effects a transition to a standby mode. When a command is received, the software goes into one of several operational modes (e.g. acquisition or tracking). The software then returns, to the external source, the data appropriate to the command.

Howard, Richard T.↗

GeoLab: A Geological Workstation for Future Missions

The GeoLab glovebox was, until November 2012, fully integrated into NASA's Deep Space Habitat (DSH) Analog Testbed. The conceptual design for GeoLab came from several sources, including current research instruments (Microgravity Science Glovebox) used on the International Space Station, existing Astromaterials Curation Laboratory hardware and clean room procedures, and mission scenarios developed for earlier programs. GeoLab allowed NASA scientists to test science operations related to contained sample examination during simulated exploration missions. The team demonstrated science operations that enhance theThe GeoLab glovebox was, until November 2012, fully integrated into NASA's Deep Space Habitat (DSH) Analog Testbed. The conceptual design for GeoLab came from several sources, including current research instruments (Microgravity Science Glovebox) used on the International Space Station, existing Astromaterials Curation Laboratory hardware and clean room procedures, and mission scenarios developed for earlier programs. GeoLab allowed NASA scientists to test science operations related to contained sample examination during simulated exploration missions. The team demonstrated science operations that enhance the early scientific returns from future missions and ensure that the best samples are selected for Earth return. The facility was also designed to foster the development of instrument technology. Since 2009, when GeoLab design and construction began, the GeoLab team [a group of scientists from the Astromaterials Acquisition and Curation Office within the Astromaterials Research and Exploration Science (ARES) Directorate at JSC] has progressively developed and reconfigured the GeoLab hardware and software interfaces and developed test objectives, which were to 1) determine requirements and strategies for sample handling and prioritization for geological operations on other planetary surfaces, 2) assess the scientific contribution of selective in-situ sample characterization for mission planning, operations, and sample prioritization, 3) evaluate analytical instruments and tools for providing efficient and meaningful data in advance of sample return and 4) identify science operations that leverage human presence with robotic tools. In the first year of tests (2010), GeoLab examined basic glovebox operations performed by one and two crewmembers and science operations performed by a remote science team. The 2010 tests also examined the efficacy of basic sample characterization [descriptions, microscopic imagery, X-ray fluorescence (XRF) analyses] and feedback to the science team. In year 2 (2011), the GeoLab team tested enhanced software and interfaces for the crew and science team (including Web-based and mobile device displays) and demonstrated laboratory configurability with a new diagnostic instrument (the Multispectral Microscopic Imager from the JPL and Arizona State University). In year 3 (2012), the GeoLab team installed and tested a robotic sample manipulator and evaluated robotic-human interfaces for science operations.

Evans, Cynthia↗

NASA's Space Launch System Takes Shape

Major hardware and software for NASA's Space Launch System (SLS) began rolling off assembly lines in 2016, setting the stage for critical testing in 2017 and the launch of a major new capability for deep space human exploration. SLS continues to pursue a 2018 first launch of Exploration Mission 1 (EM-1). At NASA's Michoud Assembly Facility near New Orleans, LA, Boeing completed welding of structural test and flight liquid hydrogen tanks, and engine sections. Test stands for core stage structural tests at NASA's Marshall Space Flight Center, Huntsville, AL. neared completion. The B2 test stand at NASA's Stennis Space Center, MS, completed major structural renovation to support core stage green run testing in 2018. Orbital ATK successfully test fired its second qualification solid rocket motor in the Utah desert and began casting the motor segments for EM-1. Aerojet Rocketdyne completed its series of test firings to adapt the heritage RS-25 engine to SLS performance requirements. Production is under way on the first five new engine controllers. NASA also signed a contract with Aerojet Rocketdyne for propulsion of the RL10 engines for the Exploration Upper Stage. United Launch Alliance delivered the structural test article for the Interim Cryogenic Propulsion Stage to MSFC for tests and construction was under way on the flight stage. Flight software testing at MSFC, including power quality and command and data handling, was completed. Substantial progress is planned for 2017. Liquid oxygen tank production will be completed at Michoud. Structural testing at Marshall will get under way. RS-25 hotfire testing will verify the new engine controllers. Core stage horizontal integration will begin. The core stage pathfinder mockup will arrive at the B2 test stand for fit checks and tests. EUS will complete preliminary design review. This paper will discuss the technical and programmatic successes and challenges of 2016 and look ahead to plans for 2017.

Askins, Bruce↗