Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software asset”

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 73 records · Page 4

Lunar Asset Messaging and On Orbit Navigation

NASA has titled its 2020 thrust for the Moon, Artemis. The increased focus on the Moon as a destination for future human and robotic expeditions necessitates general purpose navigational and communications infrastructure reducing their complexity to help establish a sustained presence. A framework through which Lunar missions can relay communications and localize their positions shifts the burden from the individual mission and enables resource allocation tailored to mission-specific goals. During the summer of 2020, student interns under the Innovation to Flight (i2F) program at the National Aeronautics and Space Administration’s (NASA) Jet Propulsion Laboratory (JPL) in collaboration with the University of Colorado Boulder designed, built, and tested a prototype framework capable of providing surface assets with communication and positioning services. The team utilized the existing i2F CubeSat bus in addition to developing several CubeSat engineering development units (EDUs), a ground vehicle, and a ground station to simulate a scenario in which a lunar surface mission is supported by these services. A primary goal of the summer was to develop a method for localizing the ground vehicle through trilateration. Distances are inferred from the round-trip time of flight (ToF) of radio signals between an asset and several elements. Signals were sent and received using LimeSDR software defined radios on-board both the ground vehicle and the EDUs; ToF and trilateration were calculated on a Qualcomm Snapdragon development board located within the LA MOON payload data system. The ModalAI chipset on the Qualcomm was instrumental in executing visual based position estimation. Communications was facilitated through a bent-pipe approach addressing the NASA requirement to provide solutions for in communication denied locations. The ground vehicle relayed information to other surface assets in addition to its ground station through the supporting constellation. This project demonstrates the feasibility of a lunar CubeSat constellation for the support of surface assets and explores packaging and operations of the components critical to trilateration and bent-pipe communication into a standard CubeSat form factor. When implemented, this framework will open a door for new surface missions designed with lower power requirements and increased operational access.

Huang, Calvin↗

Verification of an Icosahedral Grid for Strategic Center for Networking, Communications, and Integration User Interface Spatial Capabilities

Spatial communication analysis tools are incredibly useful resources to have when planning a space mission. Every single mission that leaves Earth needs a way to get its data back down and every mission's requirements on how that will get accomplished is different. Being able to analyze how existing assets can provide services independent of a specific mission can be key in that process. Most current commercial software packages contain spatial analysis capabilities but go about the analysis in a way that is not the most efficient and can skew the results provided. NASA's Space Communication and Navigation (SCaN) Center for Engineering Networks, Integration, and Communications (SCENIC) seeks to solve this problem and provide analysis capabilities using both internally developed and open-source software. This allows incredible flexibility, customization and hugely reduces licensing costs. Using MATLAB® and Orbit Determination Toolbox created by Goddard Space Flight Center (GSFC), SCENIC is able to perform many node-based functions currently. Analysis utilizing the spatial tools in SCENIC allows a meaningful analysis of the capability of communication network assets in a way not seen in current commercial software packages. This paper discusses the verification activities associated with generating the spatial grid point definition utilized in these analysis capabilities, within the SCENIC user interface (UI).

Jasper, Lindsey A.↗

Technical Reference Suite Addressing Challenges of Providing Assurance for Fault Management Architectural Design

Research into complexities of software systems Fault Management (FM) and how architectural design decisions affect safety, preservation of assets, and maintenance of desired system functionality has coalesced into a technical reference (TR) suite that advances the provision of safety and mission assurance. The NASA Independent Verification and Validation (IVV) Program, with Software Assurance Research Program support, extracted FM architectures across the IVV portfolio to evaluate robustness, assess visibility for validation and test, and define software assurance methods applied to the architectures and designs. This investigation spanned IVV projects with seven different primary developers, a wide range of sizes and complexities, and encompassed Deep Space Robotic, Human Spaceflight, and Earth Orbiter mission FM architectures. The initiative continues with an expansion of the TR suite to include Launch Vehicles, adding the benefit of investigating differences intrinsic to model-based FM architectures and insight into complexities of FM within an Agile software development environment, in order to improve awareness of how nontraditional processes affect FM architectural design and system health management.

Fitz, Rhonda↗

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↗

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↗

Open Source Software Prevalence Ingest Tool

The OSSP Ingest Tool accepts user-input organizational information, ingests IT/OT asset lists in Excel format, and ingests the associated CycloneDX SBOM's. It then performs analytics demonstrating the ability to answer the follow research questions: o RQ1. Ability to identify all OSS services running on, and all OSS components present within, an OT device o RQ1a: Ability to differentiate multiple versions of the same OSS component within each OT device. o RQ1b: Ability to differentiate running from not-running OSS components. o RQ1c: Ability to differentiate based on the originator of the component, because a supplier may have modified it after retrieval from the upstream software source. o RQ2. Ability to correlate the identity of a single OSS component across multiple OT devices, mitigating common name variations such as differences in capitalization, '-' vs '_', and so on. o RQ3. Ability to perform subset analysis of OSS components across multiple OT devices o RQ3a: Ability to perform subset analysis across OSS libraries, generating density & distribution graphs to identify commonly-used libraries and outliers. o RQ3b: Ability to perform subset analysis of a single OSS library, generating density & distribution by CI sector, by device type, by device make/model, and/or by firmware version. o RQ3c: Ability to perform subset analysis by grouping OSS libraries according to programming language, then overlay with RQ4b. o RQ3d: Ability to perform subset analysis by OSS upstream source, providing insight into degree of modifications performed by suppliers. o RQ4. Ability to identify dependencies (transitive and direct) of each differentiated OSS library within each OT device, and enable RQ1,2,3 iteratively for dependencies. o RQ1. Ability to identify all OSS services running on, and all OSS components present within, an OT device o RQ1a: Ability to differentiate multiple versions of the same OSS component within each OT device. o RQ1b: Ability Page

Kapadia, Shayna [Lawrence Livermore National Labor↗

A Framework for Performing V&V within Reuse-Based Software Engineering

Verification and validation (V&V) is performed during application development for many systems, especially safety-critical and mission-critical systems. The V&V process is intended to discover errors, especially errors related to critical processing, as early as possible during the development process. Early discovery is important in order to minimize the cost and other impacts of correcting these errors. In order to provide early detection of errors, V&V is conducted in parallel with system development, often beginning with the concept phase. In reuse-based software engineering, however, decisions on the requirements, design and even implementation of domain assets can be made prior to beginning development of a specific system. In this case, V&V must be performed during domain engineering in order to have an impact on system development. This paper describes a framework for performing V&V within architecture-centric, reuse-based software engineering. This framework includes the activities of traditional application-level V&V, and extends these activities into domain engineering and into the transition between domain engineering and application engineering. The framework includes descriptions of the types of activities to be performed during each of the life-cycle phases, and provides motivation for the activities.

Addy, Edward A.↗

Evolution of the Space Shuttle Primary Avionics Software and Avionics for Shuttle Derived Launch Vehicles

As a result of recommendation from the Augustine Panel, the direction for Human Space Flight has been altered from the original plan referred to as Constellation. NASA s Human Exploration Framework Team (HEFT) proposes the use of a Shuttle Derived Heavy Lift Launch Vehicle (SDLV) and an Orion derived spacecraft (salvaged from Constellation) to support a new flexible direction for space exploration. The SDLV must be developed within an environment of a constrained budget and a preferred fast development schedule. Thus, it has been proposed to utilize existing assets from the Shuttle Program to speed development at a lower cost. These existing assets should not only include structures such as external tanks or solid rockets, but also the Flight Software which has traditionally been a "long pole" in new development efforts. The avionics and software for the Space Shuttle was primarily developed in the 70 s and considered state of the art for that time. As one may argue that the existing avionics and flight software may be too outdated to support the new SDLV effort, this is a fallacy if they can be evolved over time into a "modern avionics" platform. The technology may be outdated, but the avionics concepts and flight software algorithms are not. The reuse of existing avionics and software also allows for the reuse of development, verification, and operations facilities. The keyword is evolve in that these assets can support the fast development of such a vehicle, but then be gradually evolved over time towards more modern platforms as budget and schedule permits. The "gold" of the flight software is the "control loop" algorithms of the vehicle. This is the Guidance, Navigation, and Control (GNC) software algorithms. This software is typically the most expensive to develop, test, and verify. Thus, the approach is to preserve the GNC flight software, while first evolving the supporting software (such as Command and Data Handling, Caution and Warning, Telemetry, etc.). This can be accomplished by gradually removing the "support software" from the legacy flight software leaving only the GNC algorithms. The "support software" could be re-developed for modern platforms, while leaving the GNC algorithms to execute on technology compatible with the legacy system. It is also possible to package the GNC algorithms into an emulated version of the original computer (via Field Programmable Gate Arrays or FPGAs), thus becoming a "GNC on a Chip" solution where it could live forever to be embedded in modern avionics platforms.

Ferguson, Roscoe C.↗

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗

PV Operations Software Transparency: A PVMAC Industry Snapshot

The rapid growth of photovoltaic (PV) deployment has increased reliance on software platforms for monitoring, workflow automation, diagnostics, and performance analytics. As these tools play a central role in asset management and operations and maintenance (O&M), greater transparency in methodologies, data handling, and validation practices benefits the broader PV ecosystem. To better understand current practices and identify opportunities for improved clarity and interoperability, 24 software providers contributed detailed responses through the PV O&M Analytics Collaborative (PVMAC) initiative, the first structured questionnaire of its kind in the industry, covering onboarding, interoperability, data quality, diagnostics, AI/ML, and other operational categories. These providers represent over 1.1 TW of solar assets under management. The analysis shows broad adoption of digital twins, AI/ML, and API integrations, but also highlights challenges in onboarding processes, inconsistent definitions and methodologies, variability in key performance indicator (KPI) calculations, and limited independent validation. Greater standardization, clearer documentation, and stronger validation frameworks could improve transparency, comparability, and trust across PV operations software platforms.

14 SOLAR ENERGY↗

Improvements to Integrated Tradespace Analysis of Communications Architectures (ITACA) Network Loading Analysis Tool

NASA's SCENIC project aims to simplify and reduce the cost of space mission planning by replicating the analysis capabilities of commercially licensed software which are integrated with relevant analysis parameters specific to SCaN assets and SCaN supported user missions. SCENIC differs from current tools that perform similar analyses in that it 1) does not require any licensing fees, 2) will provide an all-in-one package for various analysis capabilities that normally requires add-ons or multiple tools to complete. As part of SCENIC's capabilities, the ITACA network loading analysis tool will be responsible for assessing the loading on a given network architecture and generating a network service schedule. ITACA will allow users to evaluate the quality of service of a given network architecture and determine whether or not the architecture will satisfy the mission's requirements. ITACA is currently under development, and the following improvements were made during the fall of 2017: optimization of runtime, augmentation of network asset pre-service configuration time, augmentation of Brent's method of root finding, augmentation of network asset FOV restrictions, augmentation of mission lifetimes, and the integration of a SCaN link budget calculation tool. The improvements resulted in (a) 25% reduction in runtime, (b) more accurate contact window predictions when compared to STK(Registered Trademark) contact window predictions, and (c) increased fidelity through the use of specific SCaN asset parameters.

analysis↗

Autonomous Navigation, Guidance, and Control Software in a Low SWaP Box

Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The autoNGC flight software is built on the plug-and-play architecture of the core Flight System (cFS) consisting of the standard cFS apps and newly developed autoNGC interface apps and libraries. The various apps cooperate through communication over the message-based software bus. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced to meet the needs of different missions, even after launch. The first flight software release of autoNGC is targeted for Summer 2024 to provide autonomous navigation at the Moon and beyond. It can perform sensor fusion of multiple measurement types including pseudo-range from a Global Navigation Satellite System (GNSS) receiver (including weak signal), 1-way and 2-way range and Doppler from ground stations (i.e., direct to Earth (DTE)), bearing and range from optical camera images, and accelerometer data. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are first extracted from optical images by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app. If the imaged body is far enough away that it appears as a pixel or cluster of pixels, then bearing angles to the body centroid can be provided. If the body is close enough and the shape is known coarsely, then bearing angles and range to the body centroid can be derived from the limb. Bearing angles to individual surface features can also be extracted (i.e., terrain relative navigation (TRN)). Onboard guidance and control capabilities are being developed for a future release to perform autonomous station-keeping and trajectory correction maneuvers in multiple orbital regimes. Capabilities to enable distributed systems missions and constellations, such as crosslink measurements, and onboard time management are being developed as well. The first hardware implementation of autoNGC is a minimal size, weight, and power (SWaP) design allowing for inclusion into CubeSats and SmallSat-size buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z are utilized for low SWaP while maintaining a high level of performance. The current enclosure design is 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. In order to accommodate a wide range of missions, the hardware interfaces are designed for flexibility with a variety of sensor inputs. Through comprehensive testing in the software-in-the-loop, processor-in-the-loop, and hardware-in-the-loop test beds that are concurrently being developed, autoNGC is expected to achieve TRL 6 by late 2024.

Sun Hur-Diaz↗

Regulators’ Financial Toolbox: Leveraging Software as a Service, Cloud Computing, and Artificial Intelligence in Electric Utilities

The rapid evolution of Software as a Service (SaaS), cloud computing, and artificial intelligence (AI) is transforming the electric utility industry, reshaping operations, customer engagement, and financial models. This webinar introduced how utilities can deploy advanced software solutions and AI-driven analytics to improve grid efficiency, optimize asset management, and accurately forecast demand.

Bartlett, Phillip↗

PHM Enabled Autonomous Propellant Loading Operations

The utility of Prognostics and Health Management (PHM) software capability applied to Autonomous Operations (AO) remains an active research area within aerospace applications. The ability to gain insight into which assets and subsystems are functioning properly, along with the derivation of confident predictions concerning future ability, reliability, and availability, are important enablers for making sound mission planning decisions. When coupled with software that fully supports mission planning and execution, an integrated solution can be developed that leverages state assessment and estimation for the purposes of delivering autonomous operations. The authors have been applying this integrated, model-based approach to the autonomous loading of cryogenic spacecraft propellants at Kennedy Space Center.

Walker, Mark↗

Principles for Architecting Autonomous Systems

This paper distills principles for developing autonomous systems based on experience and lessons learned from past efforts. The purpose of these principles is to establish a common understanding and knowledge of architectural elements to guide the development of next-generation multi-mission autonomous systems and ensure the safe and productive operation of space assets. An attempt has been made to ground these principles in fundamentals that should withstand the test of time while allowing for and enabling the advancement of technologies. They are not intended to prescribe a design nor a software representation. There may be multiple designs that can honor these principles. These principles are focused on autonomy for robotic assets. As such, they do not address autonomy for crewed assets nor autonomy that can collectively generate intelligent behavior without top-level system cognizance (e.g., intelligent swarm behavior). These areas would be a subject of future efforts.

Day, John↗

Link Analysis in the Mission Planning Lab

The legacy communications link analysis software currently used at Wallops Flight Facility involves processes that are different for command destruct, radar, and telemetry. There is a clear advantage to developing an easy-to-use tool that combines all the processes in one application. Link Analysis in the Mission Planning Lab (MPL) uses custom software and algorithms integrated with Analytical Graphics Inc. Satellite Toolkit (AGI STK). The MPL link analysis tool uses pre/post-mission data to conduct a dynamic link analysis between ground assets and the launch vehicle. Just as the legacy methods do, the MPL link analysis tool calculates signal strength and signal- to-noise according to the accepted processes for command destruct, radar, and telemetry assets. Graphs and other custom data are generated rapidly in formats for reports and presentations. STK is used for analysis as well as to depict plume angles and antenna gain patterns in 3D. The MPL has developed two interfaces with the STK software (see figure). The first interface is an HTML utility, which was developed in Visual Basic to enhance analysis for plume modeling and to offer a more user friendly, flexible tool. A graphical user interface (GUI) written in MATLAB (see figure upper right-hand corner) is also used to quickly depict link budget information for multiple ground assets. This new method yields a dramatic decrease in the time it takes to provide launch managers with the required link budgets to make critical pre-mission decisions. The software code used for these two custom utilities is a product of NASA's MPL.

McCarthy, Jessica A.↗

KSC Tech Transfer News, Volume 5, No. 1

In October 2011, the White House released a presidential memorandum titled "Accelerating Technology Transfer and Commercialization of Federal Research in Support of High-Growth Businesses." It emphasized the importance of technology transfer as a driver of successful innovation to fuel economic growth, create jobs, and make U.S. industries more competitive in a global market. In response to this memorandum, NASA developed a 5-year plan for accelerating its own technology transfer activities. This plan outlines key objectives for enhancing NASA's ability to increase the rate, volume, and quality of technology transfers to industry, academia, and other Government agencies. By doing so, we are increasing the economic impact and public benefit of Federal technology investments. In addition, NASA established technology transfer as a key element of one of its Agency High Priority Performance Goals: "Enable bold new missions and make new technologies available to Government agencies and U.S. industry."What does this mean to you? In the broadest sense, NASA defines technology transfer as the utilization of NASA's technological assets- technologies, innovations, unique facilities and equipment, and technical expertise- by public and private sectors to benefit the Nation. So, if your job involves developing new technologies, writing new software, creating innovative ways to do business, performing research, or developing new technical capabilities, you could be contributing to Kennedy Space Center's (KSC) technology transfer activities by creating the technological assets that may one day be used by external partners. Furthermore, anytime you provide technical expertise to external partners, you're participating in technology transfer. The single most important step you can take to support the technology transfer process is to report new technologies and innovations ro the Technology Transfer Office. This is the critical first step in fueling the technology transfer pipeline. This is also a requirement for all Federal employees (see NPD 2091.1 B) and most NASA contractors. Detailed information on when, where, and how ro report new technology is provided on the following page. In addition, it's important that all detailed-oriented discussions about technology between NASA and external partners are documented or that they occur under formal agreements such as Space Act Agreements and Nondisclosure Agreements. Our office can assist you in putting these agreements into place, protecting NASA's interests, and providing the means to accurately measure the Agency's technology transfer activities. Technology transfer is everyone's responsibility. We need your help to ensure that NASA remains the leader in Federal technology transfer, and that the great work done at KSC provides the maximum economic and societal benefit to the Nation.

Buckingham, Bruce↗