Search NASA⌕ Search

SEARCH · Search NASA

Results for “legacy software”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

Web-Based Environment for Maintaining Legacy Software

Advanced Tool Integration Environment (ATIE) is the name of both a software system and a Web-based environment created by the system for maintaining an archive of legacy software and expertise involved in developing the legacy software. ATIE can also be used in modifying legacy software and developing new software. The information that can be encapsulated in ATIE includes experts documentation, input and output data of tests cases, source code, and compilation scripts. All of this information is available within a common environment and retained in a database for ease of access and recovery by use of powerful search engines. ATIE also accommodates the embedment of supporting software that users require for their work, and even enables access to supporting commercial-off-the-shelf (COTS) software within the flow of the experts work. The flow of work can be captured by saving the sequence of computer programs that the expert uses. A user gains access to ATIE via a Web browser. A modern Web-based graphical user interface promotes efficiency in the retrieval, execution, and modification of legacy code. Thus, ATIE saves time and money in the support of new and pre-existing programs.

Tigges, Michael↗
DOE OSTI2018

The ATLAS Trigger Simulation with Legacy Software

Physics analyses at the LHC require accurate simulations of the detector response and the event selection processes, generally done with the most recent software releases. The trigger response simulation is crucial for determination of overall selection efficiencies and signal sensitivities and should be done with the same software release with which data were recorded. This requires potentially running with software dating many years back, the so-called legacy software, in which algorithms and configuration may differ from their current implementation. Therefore having a strategy for running legacy software in a modern environment becomes essential when data simulated for past years start to present a sizeable fraction of the total. The requirements and possibilities for such a simulation scheme within the ATLAS software framework were examined and a proof-of-concept simulation chain has been successfully implemented. One of the greatest challenges was the choice of a data format which promises long term compatibility with old and new software releases. Over the time periods envisaged, data format incompatibilities are also likely to emerge in databases and other external support services. Software availability may become an issue, when e.g. the support for the underlying operating system might stop. The encountered problems and developed solutions will be presented, and proposals for future development will be discussed. Some ideas reach beyond the retrospective trigger simulation scheme in ATLAS as they also touch more generally aspects of data preservation.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1994

Reengineering legacy software to object-oriented systems

NASA has a legacy of complex software systems that are becoming increasingly expensive to maintain. Reengineering is one approach to modemizing these systems. Object-oriented technology, other modem software engineering principles, and automated tools can be used to reengineer the systems and will help to keep maintenance costs of the modemized systems down. The Software Technology Branch at the NASA/Johnson Space Center has been developing and testing reengineering methods and tools for several years. The Software Technology Branch is currently providing training and consulting support to several large reengineering projects at JSC, including the Reusable Objects Software Environment (ROSE) project, which is reengineering the flight analysis and design system (over 2 million lines of FORTRAN code) into object-oriented C++. Many important lessons have been learned during the past years; one of these is that the design must never be allowed to diverge from the code during maintenance and enhancement. Future work on open, integrated environments to support reengineering is being actively planned.

Pitman, C.↗
NASA NTRS1994

Evolving software reengineering technology for the emerging innovative-competitive era

This paper reports on a multi-tool commercial/military environment combining software Domain Analysis techniques with Reusable Software and Reengineering of Legacy Software. It is based on the development of a military version for the Department of Defense (DOD). The integrated tools in the military version are: Software Specification Assistant (SSA) and Software Reengineering Environment (SRE), developed by Computer Command and Control Company (CCCC) for Naval Surface Warfare Center (NSWC) and Joint Logistics Commanders (JLC), and the Advanced Research Project Agency (ARPA) STARS Software Engineering Environment (SEE) developed by Boeing for NAVAIR PMA 205. The paper describes transitioning these integrated tools to commercial use. There is a critical need for the transition for the following reasons: First, to date, 70 percent of programmers' time is applied to software maintenance. The work of these users has not been facilitated by existing tools. The addition of Software Reengineering will also facilitate software maintenance and upgrading. In fact, the integrated tools will support the entire software life cycle. Second, the integrated tools are essential to Business Process Reengineering, which seeks radical process innovations to achieve breakthrough results. Done well, process reengineering delivers extraordinary gains in process speed, productivity and profitability. Most importantly, it discovers new opportunities for products and services in collaboration with other organizations. Legacy computer software must be changed rapidly to support innovative business processes. The integrated tools will provide commercial organizations important competitive advantages. This, in turn, will increase employment by creating new business opportunities. Third, the integrated system will produce much higher quality software than use of the tools separately. The reason for this is that producing or upgrading software requires keen understanding of extremely complex applications which is facilitated by the integrated tools. The radical savings in the time and cost associated with software, due to use of CASE tools that support combined Reuse of Software and Reengineering of Legacy Code, will add an important impetus to improving the automation of enterprises. This will be reflected in continuing operations, as well as in innovating new business processes. The proposed multi-tool software development is based on state of the art technology, which will be further advanced through the use of open systems for adding new tools and experience in their use.

Hwang, Phillip Q.↗
NASA NTRS2013

Multicore Considerations for Legacy Flight Software Migration

In this paper we will discuss potential benefits and pitfalls when considering a migration from an existing single core code base to a multicore processor implementation. The results of this study present options that should be considered before migrating fault managers, device handlers and tasks with time-constrained requirements to a multicore flight software environment. Possible future multicore test bed demonstrations are also discussed.

legacy flight software↗
DOE OSTI2025

High-Performance Computing Based EMT Simulation: Power Grid with IBRs

Electromagnetic transient (EMT) simulation of power grids with high-fidelity models of inverter-based resources (IBRs) is time-consuming and difficult to scale. The necessity for high-fidelity models of IBRs that incorporate the dynamics of individual inverters within IBRs has been showcased in recent studies. These studies focused on events with partial power reduction in each IBR during a transmission line fault in the power grid. These types of events have been documented in multiple North American Electric Reliability Council (NERC) reports in the past decade. It is imperative then to find solutions to speed-up EMT simulations and scale the size of the region with IBRs studied in EMT simulations. In this paper, a combination of numerical simulation algorithms with high-performance computing techniques are employed in discretization and linear solvers employed in the proposed RE-INTEGRATE EMT simulation platform for power grid with IBRs. For ease of scalability, modular and object-oriented programming is used as these techniques are implemented. Additionally, automation software is developed to convert legacy software codes to the proposed RE-INTEGRATE EMT simulation platform. Thereafter, this platform is evaluated on multi-core central processing units (CPUs). Finally, scale-up tests are performed to showcase the scalability that is possible.

Marthi, Phani Ratna Vanamali [ORNL] (ORCID:0000000↗
DOE OSTI2025

Python STXM Control (pystxmcontrol) v0.1

The software is a complete solution for controlling scanning microscopes. It provides a low level interface to device hardware via drivers, communication and coordination layers for managing scan execution and data acquisition, a graphical interface and scripting interface for user interaction. With optimized hardware drivers and low software overhead this software is 10 times faster than the legacy software it is replacing.

Shapiro, David [Lawrence Berkeley National Laborat↗
NASA NTRS2014

Section 508 Electronic Information Accessibility Requirements for Software Development

Section 508 Subpart B 1194.21 outlines requirements for operating system and software development in order to create a product that is accessible to users with various disabilities. This portion of Section 508 contains a variety of standards to enable those using assistive technology and with visual, hearing, cognitive and motor difficulties to access all information provided in software. The focus on requirements was limited to the Microsoft Windows® operating system as it is the predominant operating system used at this center. Compliance with this portion of the requirements can be obtained by integrating the requirements into the software development cycle early and by remediating issues in legacy software if possible. There are certain circumstances with software that may arise necessitating an exemption from these requirements, such as design or engineering software using dynamically changing graphics or numbers to convey information. These exceptions can be discussed with the Section 508 Coordinator and another method of accommodation used.

Pathways↗
DOE OSTI2022

Improved Uncertainty Quantification with Advanced Reactor Application

This document provides an overview of the economic and technical challenges related to bringing small modular reactors to market and then presents an outline for how to address the new challenges. The purpose of this project was to proactively design software for its intended use to provide a strategic positioning for work in the future. This project seeks to augment the short-term stop-gap approach of trying to use legacy software well outside of its range of applicability.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2024

ORNL Package Testing Program Software Quality Assurance Plan

The Oak Ridge National Laboratory (ORNL) Package Testing Program (PTP) uses commercial off-the-shelf (COTS) software in performing data collection of thermal test results for package designs that contain radioactive materials. Specifically, this software is used to collect temperature data from the furnace, packages, and ambient air to prepare and execute the thermal test specified in 10 CFR 71.73, “Thermal Test.” This software quality assurance (SQA) plan sets forth the guidelines, standards, and procedures that shall be used to provide SQA for PTP software applications. This is a living document that will be maintained for the lifecycle of the PTP program. The SQA plan follows the requirements set forth in ORNL Standards Based Management System (SBMS): Information Technology; Subject Area: Software Quality Assurance. When applicable to the requirements as described in ORNL SBMS, Software Quality Assurance, the software shall be listed in the ORNL Software Registration System (SRS). Exemptions to this SBMS are COTS and firmware that are not modified; spreadsheet applications and personal productivity tools that do not have a utility or safety application, research applications, legacy software, system software, vendor-supplied software used to interface with the vendor’s services, software used within the organization to facilitate processing or management of information, and software developed for applications not specific to the US Department of Energy (DOE).

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2008

Challenges and Demands on Automated Software Revision

In the past three decades, automated program verification has undoubtedly been one of the most successful contributions of formal methods to software development. However, when verification of a program against a logical specification discovers bugs in the program, manual manipulation of the program is needed in order to repair it. Thus, in the face of existence of numerous unverified and un- certified legacy software in virtually any organization, tools that enable engineers to automatically verify and subsequently fix existing programs are highly desirable. In addition, since requirements of software systems often evolve during the software life cycle, the issue of incomplete specification has become a customary fact in many design and development teams. Thus, automated techniques that revise existing programs according to new specifications are of great assistance to designers, developers, and maintenance engineers. As a result, incorporating program synthesis techniques where an algorithm generates a program, that is correct-by-construction, seems to be a necessity. The notion of manual program repair described above turns out to be even more complex when programs are integrated with large collections of sensors and actuators in hostile physical environments in the so-called cyber-physical systems. When such systems are safety/mission- critical (e.g., in avionics systems), it is essential that the system reacts to physical events such as faults, delays, signals, attacks, etc, so that the system specification is not violated. In fact, since it is impossible to anticipate all possible such physical events at design time, it is highly desirable to have automated techniques that revise programs with respect to newly identified physical events according to the system specification.

Bonakdarpour, Borzoo↗
NASA NTRS2003

Standards-and Component-Based Mission Operations Architecture at NASA's Goddard Space Flight Center

NASA Goddard Space Flight Center (GSFC) manages many of NASA s earth and space science satellite missions. A wide variety of commercial products and GSFC-developed software components are typically integrated into a unique system configuration for each mission. Independent development of the many mission operations center systems has led to systems that are expensive to integrate, difficult to infuse with new capabilities developed for other programs, and cumbersome to maintain. This traditional approach becomes even more problematic as NASA moves towards satellite constellations, new operations concepts, and even further budgets reductions. The GSFC Mission Services Evolution Center (GMSEC) is creating a new architecture for future missions at GSFC. Instead of selecting the best-in-class components and creating a standard control center system, GMSEC is developing component interface standards so that multiple products can plug-and-play into the configuration. Missions can then select the best components based on the merits of the product and not simply based on recent integration history at NASA. The GMSEC system utilizes a publish/subscribe information bus and standard XML-based key message interfaces. Functional components can either match directly to the interface standard, or adapters can be developed to match the product's interface to the GMSEC standard with out impacting the source product. Applications Program Interfaces (API's) are being developed to isolate the underlying middleware from the applications software and to allow the middleware product to be switched if necessary. Interface Control Documents (ICDs) between each pair of communicating components is replaced by a single message/API specification document. New applications must simply match to the information bus standards and need not worry about all of the other applications in the system. For legacy software, adapters can be developed to facilitate communications between the application and the information bus. As the approach has matured, it has become apparent that it can provide innovative solutions to some of the multi-satellite challenges facing GSFC.

Smith, Danford↗
DOE OSTI2026

Digitizing Today’s Buildings in the Real World: Lessons from Field Demonstrations

Digital twins, created by generating a virtual replica of a building, enable safe evaluation of operational scenarios and applications like fault detection and diagnosis and advanced controls. However, a prerequisite is the creation of a machine-readable digital representation of a building, currently hindered by fragmented information scattered across mechanical drawings, point lists, and natural language sequences. As a result, digital twin development remains labor-intensive, error-prone, and difficult to validate. To address these challenges, two efforts from ASHRAE aim to support the digitalization of buildings. ASHRAE s223 establishes a semantic model of buildings, representing system components, configuration, and data sources. ASHRAE s231 defines a vendor-neutral programming language for expressing their control logic. As the industry evaluates implementing them in their products, understanding the challenges that vendors and implementers may face is crucial. In this paper, we present findings and lessons learned from field demonstrations in five buildings that implemented control applications using ASHRAE s223 and s231. The demonstrations highlight how semantic modeling and formalized control descriptions can significantly reduce software development time, manual point mapping, and hard-coding. Beyond time efficiency, they enable reliable automation by minimizing human interpretation and providing a means for consistency across projects. We describe the processes and best practices for model creation and model usage, from translating heterogeneous building documentation into semantic representations to implementing control logic in real-world systems. Finally, we discuss the challenges that persist, including integration with legacy software environments, gaps in interoperability, and the level of expertise still required to effectively leverage semantic models.

Prakash, Anand Krishnan↗
NASA NTRS2006

Three Years of Global Positioning System Experience on International Space Station

The International Space Station global positioning system (GPS) receiver was activated in April 2002. Since that time, numerous software anomalies surfaced that had to be worked around. Some of the software problems required waivers, such as the time function, while others required extensive operator intervention, such as numerous power cycles. Eventually enough anomalies surfaced that the three pieces of code included in the GPS unit have been re-written and the GPS units upgraded. The technical aspects of the problems are discussed, as well as the underlying causes that led to the delivery of a product that has had so many problems. The technical aspects of the problems included physical phenomena that were not well understood, such as the affect that the ionosphere would have on the GPS measurements. The underlying causes were traced to inappropriate use of legacy software, changing requirements, inadequate software processes, unrealistic schedules, incorrect contract type, and unclear ownership responsibilities..

Gomez, Susan↗
NASA NTRS2005

Three Years of Global Positioning System Experience on International Space Station

The International Space Station global positioning systems (GPS) receiver was activated in April 2002. Since that time, numerous software anomalies surfaced that had to be worked around. Some of the software problems required waivers, such as the time function, while others required extensive operator intervention, such as numerous power cycles. Eventually, enough anomalies surfaced that the three pieces of code included in the GPS unit have been re-written and the GPS units were upgraded. The technical aspects of the problems are discussed, as well as the underlying causes that led to the delivery of a product that has had numerous problems. The technical aspects of the problems included physical phenomena that were not well understood, such as the affect that the ionosphere would have on the GPS measurements. The underlying causes were traced to inappropriate use of legacy software, changing requirements, inadequate software processes, unrealistic schedules, incorrect contract type, and unclear ownership responsibilities.

Gomez, Susan↗