Results for “execution architecture” — Page 10

NASA NTRS2019

Bumper: A Tool for Analyzing Spacecraft Micrometeoroid and Orbital Debris Risk

“Bumper” is NASA’s computer program for analyzing spacecraft micrometeoroid and orbital debris (MMOD) risk. Bumper was developed in the late-1980s and has been continuously used and maintained since. The user base has grown from a few government entities to now include numerous commercial entities as well. The NASA Johnson Space Center (JSC) Hypervelocity Impact Technology (HVIT) Team is responsible for all aspects of the Bumper software. Bumper has been used to characterize MMOD risk on hundreds of spacecraft. All of the International Space Station (ISS) modules, visiting vehicles and numerous external components and systems have been analyzed. Bumper was used to analyze each of the Space Shuttle missions since STS-50. The Orion Multi-Purpose Crew Vehicle (MPCV) MMOD shielding is being developed using Bumper as well. Bumper has also been used on numerous telescopes (Hubble, James Webb, and Fermi Gamma-ray Space Telescopes), scientific probes (Stardust, New Horizons, Parker Solar Probe), and Earth observation satellites (Landsat, Joint Polar Satellite System). Bumper is also being used to analyze the micrometeoroid risk and support design of the Deep Space Gateway (DSG) and Mars Sample Return (MSR) missions. The HVIT Bumper Configuration Control Board (CCB) ensures that all changes to the code are approved, reviewed, and documented. Most of the changes are made to add new MMOD damage “ballistic limit equations” (BLEs). BLEs are typically added in response to completion of a hypervelocity impact (HVI) test series and development of an associated BLE. Other less frequent changes include updates of the debris or meteoroid environment models, feature enhancements, and feature retirement. Some BLEs are commercially sensitive and/or proprietary, so the CCB also manages code user-version control and software distribution. The current version – “Bumper 3” – is a FORTRAN executable that utilizes a 64-bit architecture. Bumper 3 has numerous features that make it a powerful tool for analyzing spacecraft MMOD risk. Bumper uses the latest orbital debris and micrometeoroid environment models. Bumper also easily processes large spacecraft geometry models, recognizes hidden surfaces, permits BLE assignment by name or number, and conducts quality checks of the spacecraft geometry model. Bumper 3 can also be used to estimate the effects of particle penetration through thin, high-standoff distance hardware components such as solar arrays and radiators. This is done using a special HVIT-developed technique know as the “3-Part Analysis.” The paper introduces the Bumper 3 MMOD risk analysis code and provides an example MMOD risk assessment showing Bumper’s role in the overall MMOD protection design process.

Lear, Dana M.↗

NASA NTRS2021

BUMPER: A Tool for Analyzing Spacecraft Micrometeoroid and Orbital Debris Risk

“Bumper” is a computer program for analyzing spacecraft micrometeoroid and orbital debris (MMOD) risk. Bumper was developed in the late-1980s and has been continuously maintained and used since. The user base has grown from a few government entities now include numerous commercial entities as well. The National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC) Hypervelocity Impact Technology (HVIT) group is responsible for all aspects of the Bumper software. Bumper has been used to characterize MMOD risk on many spacecraft. All of the International Space Station (ISS) modules, visiting vehicles and numerous external components and systems have been analyzed. Bumper was used to analyze the Space Shuttle, Orion, and many space probes, telescopes and satellites. Bumper is also being used to analyze future spacecraft such as the Deep Space Gateway (DSG) and Mars Sample Return (MSR) missions. The Bumper Configuration Control Board (CCB) ensures that all changes to the code are approved, reviewed, and documented. The current Bumper version – “Bumper 3” – is a Fortran executable that utilizes a 64-bit architecture. Bumper has numerous features that make it a powerful tool for analyzing spacecraft MMOD risk. Bumper uses the latest orbital debris and meteoroidenvironment models. Bumper also has a large library of ballistic limit “damage” equations available that can be used for a wide variety of MMOD shielding configurations. Bumper can also handle large spacecraft finite elementmodels (FEMs) and conducts checks of the model. This paper introduces Bumper and the MMOD risk analysis process using a simplified cube-shaped spacecraft model

hypervelocity↗

NASA NTRSDate not supplied

Gateway Autonomy for Enabling Deep Space Exploration

The Gateway spacecraft is an important stepping-stone to exploration of the solar system, integrating commercial and international partners into a tightly coupled system, enabling cislunar activities, and implementing key technologies for missions to Mars. Autonomy is a capability area necessary to handle long communication outages where intervention from Earth is impossible, to prepare to operate with long communication delays that will be common in interplanetary travel, and to make spaceflight more affordable and accessible by reducing sustaining operations costs. The Gateway Concept of Operations states that one of Gateway’s goals is to “focus on infrastructure and systems that will allow autonomous operations aboard the Gateway with robotics, automated systems, advanced communications, and distributed computing.” Gateway’s Vehicle Systems Manager (VSM) and associated Autonomous Spacecraft Management Architecture (ASMA) are key products towards delivering autonomous capability. The primary functions of the control architecture are Mission Management and Timeline Execution, Resource Management, Fault Management, and Vehicle Control and Operation (VCO). In each of these areas, there is an initial level of capability to be delivered at launch, with plans to continue development and grow to greater capability. The initial deployment of VSM will focus on maintaining vehicle safety by focusing on full fault management capabilities and deploying only enough resource and timeline planning functionality to support that. The final deployment of VSM will add significant planning and control optimization functionality to support nominal operations for up to 21 days without ground support, even accommodating fault and failure conditions. While the VSM is the vehicle-level representation of autonomous reasoning, distributed automation is essential to provide the right scope and abstraction of information to process. Module and system support of automation and simplicity of interfaces are two important design paradigms that Gateway is focusing on to garner a systems approach to autonomy. Distribution of reasoning can increase complexity, so Gateway is also taking a strict hierarchical approach to information flow and decision making. VSM is not the only capability necessary to achieve an autonomous spacecraft. Robotics support for maintenance of the spacecraft will be essential to provide continued vehicle functionality even when crew is not present. Technical and programmatic challenges exist when implementing autonomous robotics operations. These challenges include sufficient network flexibility to support data transfer to the rest of the vehicle to coordinate module-to-module robotic walk-offs and finding the proper interfaces to allow sufficient dexterity. Communication system upgrades planned for Gateway include Delay Tolerant Networking to best utilize the complex network of relays that will be part of mature cislunar operations. Distributed computing and management will provide failure tolerance, robustness, and growth of capabilities while still allowing significant reuse of heritage software on heritage systems as well as reuse of common applications across a spacecraft to minimize new development, but this requires adherence to key standards and interfaces. The Gateway program has demonstrated significant progress towards these capabilities and has identified challenges other spacecraft developers should be aware of from the start.

Molly Anderson↗

NASA NTRSDate not supplied

Gateway Autonomy for Enabling Deep Space Exploration

The Gateway spacecraft is an important stepping-stone to exploration of the solar system, integrating commercial and international partners into a tightly coupled system, enabling cislunar activities, and implementing key technologies for missions to Mars. Autonomy is a capability area necessary to handle long communication outages where intervention from Earth is impossible, to prepare to operate with long communication delays that will be common in interplanetary travel, and to make spaceflight more affordable and accessible by reducing sustaining operations costs. The Gateway Concept of Operations states that one of Gateway’s goals is to “focus on infrastructure and systems that will allow autonomous operations aboard the Gateway with robotics, automated systems, advanced communications, and distributed computing.” Gateway’s Vehicle Systems Manager (VSM) and associated Autonomous Spacecraft Management Architecture (ASMA) are key products towards delivering autonomous capability. The primary functions of the control architecture are Mission Management and Timeline Execution, Resource Management, Fault Management, and Vehicle Control and Operation (VCO). In each of these areas, there is an initial level of capability to be delivered at launch, with plans to continue development and grow to greater capability. The initial deployment of VSM will focus on maintaining vehicle safety by focusing on full fault management capabilities and deploying only enough resource and timeline planning functionality to support that. The final deployment of VSM will add significant planning and control optimization functionality to support nominal operations for up to 21 days without ground support, even accommodating fault and failure conditions. While the VSM is the vehicle-level representation of autonomous reasoning, distributed automation is essential to provide the right scope and abstraction of information to process. Module and system support of automation and simplicity of interfaces are two important design paradigms that Gateway is focusing on to garner a systems approach to autonomy. Distribution of reasoning can increase complexity, so Gateway is also taking a strict hierarchical approach to information flow and decision making. VSM is not the only capability necessary to achieve an autonomous spacecraft. Robotics support for maintenance of the spacecraft will be essential to provide continued vehicle functionality even when crew is not present. Technical and programmatic challenges exist when implementing autonomous robotics operations. These challenges include sufficient network flexibility to support data transfer to the rest of the vehicle to coordinate module-to-module robotic walk-offs and finding the proper interfaces to allow sufficient dexterity. Communication system upgrades planned for Gateway include Delay Tolerant Networking to best utilize the complex network of relays that will be part of mature cislunar operations. Distributed computing and management will provide failure tolerance, robustness, and growth of capabilities while still allowing significant reuse of heritage software on heritage systems as well as reuse of common applications across a spacecraft to minimize new development, but this requires adherence to key standards and interfaces. The Gateway program has demonstrated significant progress towards these capabilities and has identified challenges other spacecraft developers should be aware of from the start.

Molly Anderson↗

NASA NTRS2018

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospaceâ€"TM"s command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for userâ€"TM"s to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS 'App Store'. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

McComas, David↗

NASA NTRS2018

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for users to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS "App Store".. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

Computer Programming and Software↗

NASA NTRSDate not supplied

Mission Design Considerations for a Low-Thrust Spacecraft

Developing an executable low-thrust trajectory for use in a spaceflight mission requires the design and optimization of a deterministic trajectory as well as the validation that the selected architecture is robust to some set of uncertainties, execution errors, and potential contingencies. Uncertainty in the ability of the spacecraft and its launch vehicle to execute a trajectory as well as potential deviations such as in-flight anomalies combine with design-to constraints and requirements to complicate the optimization problem. The approach by which robust mission design was accomplished for the initial capability of NASA’s Gateway is presented as well as associated results.

NRHO↗

NASA NTRSDate not supplied

Mission Design Considerations for a Low-Thrust Spacecraft

Developing an executable low-thrust trajectory for use in a spaceflight mission requires the design and optimization of a deterministic trajectory as well as the validation that the selected architecture is robust to some set of uncertainties, execution errors, and potential contingencies. Uncertainty in the ability of the spacecraft and its launch vehicle to execute a trajectory as well as potential deviations such as in-flight anomalies combine with design-to constraints and requirements to complicate the optimization problem. The approach by which robust mission design was accomplished for the initial capability of NASA’s Gateway is presented as well as associated results.

mission design↗

NASA NTRS1990

MARBLE: A system for executing expert systems in parallel

This paper details the MARBLE 2.0 system which provides a parallel environment for cooperating expert systems. The work has been done in conjunction with the development of an intelligent computer-aided design system, ICADS, by the CAD Research Unit of the Design Institute at California Polytechnic State University. MARBLE (Multiple Accessed Rete Blackboard Linked Experts) is a system of C Language Production Systems (CLIPS) expert system tool. A copied blackboard is used for communication between the shells to establish an architecture which supports cooperating expert systems that execute in parallel. The design of MARBLE is simple, but it provides support for a rich variety of configurations, while making it relatively easy to demonstrate the correctness of its parallel execution features. In its most elementary configuration, individual CLIPS expert systems execute on their own processors and communicate with each other through a modified blackboard. Control of the system as a whole, and specifically of writing to the blackboard is provided by one of the CLIPS expert systems, an expert control system.

Myers, Leonard↗

NASA NTRS1995

DREAMS and IMAGE: A Model and Computer Implementation for Concurrent, Life-Cycle Design of Complex Systems

Computing architectures are being assembled that extend concurrent engineering practices by providing more efficient execution and collaboration on distributed, heterogeneous computing networks. Built on the successes of initial architectures, requirements for a next-generation design computing infrastructure can be developed. These requirements concentrate on those needed by a designer in decision-making processes from product conception to recycling and can be categorized in two areas: design process and design information management. A designer both designs and executes design processes throughout design time to achieve better product and process capabilities while expanding fewer resources. In order to accomplish this, information, or more appropriately design knowledge, needs to be adequately managed during product and process decomposition as well as recomposition. A foundation has been laid that captures these requirements in a design architecture called DREAMS (Developing Robust Engineering Analysis Models and Specifications). In addition, a computing infrastructure, called IMAGE (Intelligent Multidisciplinary Aircraft Generation Environment), is being developed that satisfies design requirements defined in DREAMS and incorporates enabling computational technologies.

Hale, Mark A.↗

NASA NTRS2017

CARACaS multi-agent maritime autonomy for unmanned surface vehicles in the Swarm II harbor patrol demonstration

This paper describes new autonomy technology that enabled a team of unmanned surface vehicles (USVs) to execute cooperative behaviors in the USV Swarm II harbor patrol demonstration and provides a description of autonomy performance in the event. The new developments extend the NASA Jet Propulsion Laboratory’s CARACaS (Control Architecture for Robotic Agent Command and Sensing) autonomy architecture, which pro- vides foundational software infrastructure, core executive functions, and several default robotic technology mod- ules. In Swarm II, CARACaS demonstrated higher levels of autonomy and more complex cooperation than previous on-water exercises, using full-sized vehicles and real-world sensing and communication. The core au- tonomous behaviors to support the harbor patrol scenario included Patrol, Track, Inspect, and Trail, providing the capability of finding all vessels entering the patrol area, keeping track of them, inspecting them to infer intent, and trailing suspect vessels. Significantly, CARACaS assumed responsibility for not only executing tasks safely and efficiently but also recognizing what tasks needed to be accomplished, given the current state of the world. Since the heterogeneous USV teams shared world model that evolved, such as due to (dis)appearance of vessels in the area or a change in health or availability of a USV, CARACaS replanned to generate and reallocate the new task list. Thus, human intervention was never required in the loop to task USVs during mission execution, though a supervisory role was supported in the autonomy system for mission monitoring and exception handling. Finally, CARACaS also ensured the USVs avoided hazards and obeyed the applicable rules of the road, using its local motion planning modules.

Sandoval, Michael↗

NASA NTRSDate not supplied

Gateway at the Crossroads of Sustainable Lunar Exploration

The Gateway Program has made substantial design and development progress toward delivering a small, human-tended lunar space station purposefully designed to enable sustainable human exploration. The Program integrates partners and providers organizationally and physically as part of the spacecraft. The Power and Propulsion Element (PPE) and the Habitation and Logistics Outpost (HALO) with the European System Providing Refueling, Infrastructure and Telecommunications (ESPRIT) HALO Lunar Communications System (HLCS) have begun manufacturing the long lead components and will be launched first as a Co-Manifested Vehicle (CMV). The International Habitat (I-Hab) and ESPRIT Refueling Module (ERM) are passing life cycle milestones and include capabilities key for human crewmembers, such as windows, private sleeping quarters, and galley functions. The Logistics Module (LM) may provide a variety of services to Gateway depending on each mission. Requirements for the airlock have been developed, including requests that it support the integrated spacecraft with functions like augmenting heat rejection capabilities, and interfaces with new spacesuits will soon be developed in more detail. As a critical element of the architecture for solar system exploration, Gateway implements key tenets and features of international interoperability standards necessary to operate with multiple visiting vehicles and lunar assets, especially avionics, communications, and docking. Specific choices such as software architecture and standards, power standards, and robotics standards make it possible to utilize heritage or proprietary technology, yet still operate as one spacecraft. Engineering teams are evaluating many possible future missions to be executed at or utilizing the Gateway. The system architecture protects for an evolvable, extensible, and flexible capability. Designing systems robust enough to serve as a cornerstone of exploration activities for decades while remaining adaptable is not without its challenges. The detailed integration activities have revealed challenges and the need to mature key technologies. Refueling is a key component of achieving long life for Gateway, with unique operations to plan, safety concerns to mitigate, and risk reduction activities to conduct to better understand the system. The constraints and impacts of the design of visiting vehicles is also an important concern, with orientation constraints, control of attitude and orbit of the Gateway with docked visiting vehicles. Tradeoffs between robust maintainable systems and lightweight, compact systems must be balanced. Opportunities still exist for adding additional advanced capabilities to increase and extend Gateway’s benefits, such as intravehicular robotics, autonomous Guidance Navigation and Control (GN&C), and augmented control propulsion, heat rejection, or other services.

Molly S Anderson↗

NASA NTRSDate not supplied

Gateway at the Crossroads of Sustainable Lunar Exploration

The Gateway Program has made substantial design and development progress toward delivering a small, human-tended lunar space station purposefully designed to enable sustainable human exploration. The Program integrates partners and providers organizationally and physically as part of the spacecraft. The Power and Propulsion Element (PPE) and the Habitation and Logistics Outpost (HALO) with the European System Providing Refueling, Infrastructure and Telecommunications (ESPRIT) HALO Lunar Communications System (HLCS) have begun manufacturing the long lead components and will be launched first as a Co-Manifested Vehicle (CMV). The International Habitat (I-Hab) and ESPRIT Refueling Module (ERM) are passing life cycle milestones and include capabilities key for human crewmembers, such as windows, private sleeping quarters, and galley functions. The Logistics Module (LM) may provide a variety of services to Gateway depending on each mission. Requirements for the airlock have been developed, including requests that it support the integrated spacecraft with functions like augmenting heat rejection capabilities, and interfaces with new spacesuits will soon be developed in more detail. As a critical element of the architecture for solar system exploration, Gateway implements key tenets and features of international interoperability standards necessary to operate with multiple visiting vehicles and lunar assets, especially avionics, communications, and docking. Specific choices such as software architecture and standards, power standards, and robotics standards make it possible to utilize heritage or proprietary technology, yet still operate as one spacecraft. Engineering teams are evaluating many possible future missions to be executed at or utilizing the Gateway. The system architecture protects for an evolvable, extensible, and flexible capability. Designing systems robust enough to serve as a cornerstone of exploration activities for decades while remaining adaptable is not without its challenges. The detailed integration activities have revealed challenges and the need to mature key technologies. Refueling is a key component of achieving long life for Gateway, with unique operations to plan, safety concerns to mitigate, and risk reduction activities to conduct to better understand the system. The constraints and impacts of the design of visiting vehicles is also an important concern, with orientation constraints, control of attitude and orbit of the Gateway with docked visiting vehicles. Tradeoffs between robust maintainable systems and lightweight, compact systems must be balanced. Opportunities still exist for adding additional advanced capabilities to increase and extend Gateway’s benefits, such as intravehicular robotics, autonomous Guidance Navigation and Control (GN&C), and augmented control propulsion, heat rejection, or other services.

Molly S Anderson↗

DOE OSTI2022

Software Architecture and Hardware Organization in Mu2e Solenoid Field Mapping System

Herein, the Mu2e field mapping system is designed to produce high accuracy field maps of the detector solenoid used in the experiment. The data acquisition system is mobile and uses a self-propelled mapper with rotating arms equipped with 3D Hall probes. The measurements require not only accurate magnetic field readouts, but also accurate locations of all Hall probes while measuring data. The latter is accomplished by using the laser tracker to measure positions of several retroreflectors on the field mapper during data acquisition. The measurement process requires scanning the whole space inside the large solenoid and takes many hours to complete, which necessitates its full automation. The automation software includes control of the mapper, readout of Hall and NMR probes and control of a laser tracker, including prediction of retroreflector positions and execution of quality control checks. The software architecture and data acquisition hardware of the field mapping system are described, with special attention given to control of the laser tracker and its integration with the rest of the system.

3d hall probes↗

NASA NTRS2008

Updates to the NASA Space Telecommunications Radio System (STRS) Architecture

This paper describes an update of the Space Telecommunications Radio System (STRS) open architecture for NASA space based radios. The STRS architecture has been defined as a framework for the design, development, operation and upgrade of space based software defined radios, where processing resources are constrained. The architecture has been updated based upon reviews by NASA missions, radio providers, and component vendors. The STRS Standard prescribes the architectural relationship between the software elements used in software execution and defines the Application Programmer Interface (API) between the operating environment and the waveform application. Modeling tools have been adopted to present the architecture. The paper will present a description of the updated API, configuration files, and constraints. Minimum compliance is discussed for early implementations. The paper then closes with a summary of the changes made and discussion of the relevant alignment with the Object Management Group (OMG) SWRadio specification, and enhancements to the specialized signal processing abstraction.

Kacpura, Thomas J.↗

NASA NTRS1995

The relation of scalability and execution time

Scalability has been used extensively as a de facto performance criterion for evaluating parallel algorithms and architectures. However, for many, scalability has theoretical interests only since it does not reveal execution time. In this paper, the relation between scalability and execution time is carefully studied. Results show that the isospeed scalability well characterizes the variation of execution time: smaller scalability leads to larger execution time, the same scalability leads to the same execution time, etc. Three algorithms from scientific computing are implemented on an Intel Paragon and an IBM SP2 parallel computer. Experimental and theoretical results show that scalability is an important, distinct metric for parallel and distributed systems, and may be as important as execution time in a scalable parallel and distributed environment.

Sun, Xian-He↗

NASA NTRS2014

The International Space Station 2B Photovoltaic Thermal Control System (PVTCS) Leak: An Operational History

As early as 2004, the Photovoltaic Thermal Control System (PVTCS) for the International Space Station's 2B electrical power channel began slowly leaking ammonia overboard. Initially, the operations strategy was "feed the leak," a strategy successfully put into action via Extra Vehicular Activity (EVA) during the STS-134 Space Shuttle mission. This recharge was to have allowed for continued power channel operation into 2014 or 2015, at which point another EVA would have been required. In mid-2012, the leak rate increased from 1.5lbm/year to approximately 5lbm/year. As a result, an EVA was planned and executed within a 5 week timeframe to drastically alter the architecture of the PVTCS via connection to an adjacent dormant thermal control system. This EVA, US EVA 20, was successfully executed on November 1, 2012 and left the 2B PVTCS in a configuration where the system was now being adequately cooled via a different radiator than what the system was designed to utilize. Data monitoring over the next several months showed that the isolated radiator had not been leaking, and the system itself continued to leak steadily until May 9th, 2013. It was on this day that the ISS crew noticed the visible presence of ammonia crystals escaping from the 2B channel's truss segment, signifying a rapid acceleration of the leak from 5lbm/year to 5lbm/day. Within 48 hours of the crew noticing the leak, US EVA 21 was in progress to replace the coolant pump - the only remaining replaceable leak source. This was successful, and telemetry monitoring has shown that indeed the coolant pump was the leak source and was thus isolated from the running 2B PVTCS. This paper will explore the management of the 2B PVTCS leak from the operations perspective.

Vareha, Anthony N.↗

NASA NTRS1981

High speed cylindrical roller bearing analysis. SKF computer program CYBEAN. Volume 2: User's manual

CYBEAN (CYlindrical BEaring ANalysis) was created to detail radially loaded, aligned and misaligned cylindrical roller bearing performance under a variety of operating conditions. Emphasis was placed on detailing the effects of high speed, preload and system thermal coupling. Roller tilt, skew, radial, circumferential and axial displacement as well as flange contact were considered. Variable housing and flexible out-of-round outer ring geometries, and both steady state and time transient temperature calculations were enabled. The complete range of elastohydrodynamic contact considerations, employing full and partial film conditions were treated in the computation of raceway and flange contacts. The practical and correct implementation of CYBEAN is discussed. The capability to execute the program at four different levels of complexity was included. In addition, the program was updated to properly direct roller-to-raceway contact load vectors automatically in those cases where roller or ring profiles have small radii of curvature. Input and output architectures containing guidelines for use and two sample executions are detailed.

Dyba, G. J.↗