Search NASA⌕ Search

SEARCH · Search NASA

Results for “reengineering”

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 37 records · Page 2

The development and technology transfer of software engineering technology at NASA. Johnson Space Center

The United State's big space projects of the next decades, such as Space Station and the Human Exploration Initiative, will need the development of many millions of lines of mission critical software. NASA-Johnson (JSC) is identifying and developing some of the Computer Aided Software Engineering (CASE) technology that NASA will need to build these future software systems. The goal is to improve the quality and the productivity of large software development projects. New trends are outlined in CASE technology and how the Software Technology Branch (STB) at JSC is endeavoring to provide some of these CASE solutions for NASA is described. Key software technology components include knowledge-based systems, software reusability, user interface technology, reengineering environments, management systems for the software development process, software cost models, repository technology, and open, integrated CASE environment frameworks. The paper presents the status and long-term expectations for CASE products. The STB's Reengineering Application Project (REAP), Advanced Software Development Workstation (ASDW) project, and software development cost model (COSTMODL) project are then discussed. Some of the general difficulties of technology transfer are introduced, and a process developed by STB for CASE technology insertion is described.

Pitman, C. L.↗

Development of a case tool to support decision based software development

A summary of the accomplishments of the research over the past year are presented. Achievements include: made demonstrations with DHC, a prototype supporting decision based software development (DBSD) methodology, for Paramax personnel at ODU; met with Paramax personnel to discuss DBSD issues, the process of integrating DBSD and Refinery and the porting process model; completed and submitted a paper describing DBSD paradigm to IFIP '92; completed and presented a paper describing the approach for software reuse at the Software Reuse Workshop in April 1993; continued to extend DHC with a project agenda, facility necessary for a better project management; completed a primary draft of the re-engineering process model for porting; created a logging form to trace all the activities involved in the process of solving the reengineering problem, and developed a primary chart with the problems involved by the reengineering process.

Wild, Christian J.↗

Reinvention/reengineering of business and technical processes

The changing marketplace as evidenced by global competition is requiring American organizations to rethink, regroup, and redesign their processes. The umbrella of total quality management (TQM) includes many quality methods, techniques, tools, and approaches. There is no right way for every situation or circumstance. Adaptability and experimentation of several tools is necessary. Process management when properly applied can lead to continuous quality improvements. But some processes simply need to be discarded and new ones developed. This reengineering often results in vertical compression and job redesign and restructuring. Work activities must be designed around processes, not processes around work activities. Reengineering and process management do not stand alone--they support each other. Senior executive leadership and empowerment of workers at all organizational levels is vital for both short-term and long-term success.

Olsen, Eugene A.↗

Scheduling System Assessment, and Development and Enhancement of Re-engineered Version of GPSS

The objective of this project is two-fold. First to provide an evaluation of a commercially developed version of the ground processing scheduling system (GPSS) for its applicability to the Kennedy Space Center (KSC) ground processing problem. Second, to work with the KSC GPSS development team and provide enhancement to the existing software. Systems reengineering is required to provide a sustainable system for the users and the software maintenance group. Using the LISP profile prototype code developed by the GPSS reverse reengineering groups as a building block, we have implemented the resource deconfliction portion of GPSS in common LISP using its object oriented features. The prototype corrects and extends some of the deficiencies of the current production version, plus it uses and builds on the classes from the development team's profile prototype.

Loganantharaj, Rasiah↗

Applied Research Study

The purpose of this project was to study the feasibility of reusing major components of a software system that had been used to control the operations of a spacecraft launched in the 1980s. The study was done in the context of a ground data processing system that was to be rehosted from a large mainframe to an inexpensive workstation. The study concluded that a systematic approach using inexpensive tools could aid in the reengineering process by identifying a set of certified reusable components. The study also developed procedures for determining duplicate versions of software, which were created because of inadequate naming conventions. Such procedures reduced reengineering costs by approximately 19.4 percent.

Leach, Ronald J.↗

Right on Time, Radically

Back in the early 1990s, reengineering was all the rage. All of the corporations and their CEOs got excited about the prospect of having to streamline and reorganize, reengineering their organizations in an effort to improve the bottom line. NASA Goddard Space Flight Center was no exception to that rule. Some folks in upper management wanted to take advantage of this new paradigm and they turned their attention to the Hubble Space Telescope ground system. The objective was to reduce the operating cost of the system by at least 50 percent. This was a noble objective, as Hubble would likely be around for another ten to fifteen years at least.

Lehtonen, Ken↗

Lessons Learned from Engineering a Multi-Mission Satellite Operations Center

NASA's Small Explorers (SMEX) satellites have surpassed their designed science-lifetimes and their flight operations teams are now facing the challenge of continuing operations with reduced funding. At present, these missions are being reengineered into a fleet-oriented ground system at Goddard Space Flight Center (GSFC). When completed, this ground system will provide command and control of four SMEX missions and will demonstrate fleet automation and control concepts. As a path-finder for future mission consolidation efforts, this ground system will also demonstrate new ground-based technologies that show promise of supporting longer mission lifecycles and simplifying component integration. One of the core technologies being demonstrated in the SMEiX Mission Operations Center is the GSFC Mission Services Evolution Center (GMSEC) architecture. The GMSEC architecture uses commercial Message Oriented Middleware with a common messaging standard to realize a higher level of component interoperability, allowing for interchangeable components in ground systems. Moreover, automation technologies utilizing the GMSEC architecture are being evaluated and implemented to provide extended lights-out operations. This mode of operation will provide routine monitoring and control of the heterogeneous spacecraft fleet. The operational concepts being developed will reduce the need for staffed contacts and is seen as a necessity for fleet management. This paper will describe the experiences of the integration team throughout the reengineering effort of the SMEX ground system. Additionally, lessons learned will be presented based on the team s experiences with integrating multiple missions into a fleet-based automated ground system.

Madden, Maureen↗

Transforming Our SMEX Organization by Way of Innovation, Standardization, and Automation

NASA's Small Explorer (SMEX) Flight Operations Team (FOT) is currently tackling the challenge of supporting ground operations for several satellites that have surpassed their designed lifetime and have a dwindling budget. At Goddard Space Flight Center (GSFC), these missions are presently being reengineered into a fleet-oriented ground system. When complete, this ground system will provide command and control of four SMEX missions, and will demonstrate fleet automation and control concepts as a pathfinder for additional mission integrations. A goal of this reengineering effort is to demonstrate new ground-system technologies that show promise of supporting longer mission lifecycles and simplifying component integration. In pursuit of this goal, the SMEX organization has had to examine standardization, innovation, and automation. A core technology being demonstrated in this effort is the GSFC Mission Services Evolution Center (GMSEC) architecture. The GMSEC architecture focuses on providing standard interfaces for ground system applications to promote application interoperability. Building around commercial Message Oriented Middleware and providing a common messaging standard allows GMSEC to provide the capabilities necessary to support integration of new software components into existing missions and increase the level of interaction within the system. For SMS, GMSEC has become the technology platform to transform flight operations with the innovation and automation necessary to reduce operational costs. The automation technologies supported in SMEX are built upon capabilities provided by the GMSEC architecture that allows the FOT to further reduce the involvement of the console, operator. Initially, SMEX is automating only routine operations, such as safety and health monitoring, basic commanding, and system recovery. The operational concepts being developed here will reduce the need for staffed passes and are a necessity for future fleet management. As this project continues to evolve, additional innovations beyond GMSEC and automation have, and will continue to be developed. The team developed techniques for migrating ground systems of existing on-orbit assets. The tools necessary to monitor and control software failures were integrated and tailored for operational environments. All this was done with a focus of extending fleet operations to mission beyond SMU. The result of this work is the foundation for a broader fleet-capable ground system that will include several missions supported by the Space Science Mission Operations Project.

Madden, Maureen↗

Integrating Automation into a Multi-Mission Operations Center

NASA Goddard Space Flight Center's Space Science Mission Operations (SSMO) Project is currently tackling the challenge of minimizing ground operations costs for multiple satellites that have surpassed their prime mission phase and are well into extended mission. These missions are being reengineered into a multi-mission operations center built around modern information technologies and a common ground system infrastructure. The effort began with the integration of four SMEX missions into a similar architecture that provides command and control capabilities and demonstrates fleet automation and control concepts as a pathfinder for additional mission integrations. The reengineered ground system, called the Multi-Mission Operations Center (MMOC), is now undergoing a transformation to support other SSMO missions, which include SOHO, Wind, and ACE. This paper presents the automation principles and lessons learned to date for integrating automation into an existing operations environment for multiple satellites.

Surka, Derek M.↗

EOS Operations Systems: EDOS Implemented Changes to Reduce Operations Costs

The authors describe in this paper the progress achieved to-date with the reengineering of the Earth Observing System (EOS) Data and Operations System (EDOS), the experience gained in the process and the ensuing reduction of ground systems operations costs. The reengineering effort included a major methodology change, applying to an existing schedule driven system, a data-driven system approach.

Cordier, Guy R.↗

Is Equipment Management Really Necessary

This workshop is designed to foster an initiative for intelligent Equipment Management employing the advances in information systems and opportunities uncovered by the reengineering process. The guiding concept behind the initiative is that both contributions and benefits must be equitable and balanced for all participants.

reengineering equipment management acquisition↗

Developing the JPL Engineering Processes

This paper briefly recounts the recent history of process reengineering at the NASA Jet Propulsion Laboratory, with a focus on the engineering processes. The JPL process structure is described and the process development activities of the past several years outlined. The main focus of the paper is on the current process structure, the emphasis on the flight project life cycle, the governance approach that lead to Flight Project Practices, and the remaining effort to capture process knowledge at the detail level of the work group.

reengineering↗

Biological Design of Lemnaceae aquatic plants for biodiesel production (Final Technical Report)

Support from this award enabled us to expand critical genomic and epigenomic resources available for the study and engineering of duckweeds, and to complete design-build-test-learn cycles that culminated in the engineering of high oil duckweeds. We shared our findings with the public and scientific community in a series of peer-reviewed publications highlighted within. We successfully reengineered metabolism, dramatically increasing oil content by diverting a substantial portion of accumulated carbon from starch. This sets the stage for the use of fast growing aquatic duckweeds as robust, highly productive sources of biodiesel, with the capacity to outperform soybean oil crops.

09 BIOMASS FUELS↗

From Modular ADMS to Plug-and-Play Ops: Distribution Grid Operations with Platform-Level Orchestration to Enable Ambitious App Hosting

The core function of the distribution grid is to provide electricity to consumers affordably, reliably, and securely. In pursuing these core objectives, distribution utilities are accountable to customers, regulators, and in some cases, shareholders. Other third parties such as aggregators and microgrids can also have a stake in the smooth operation of the grid. Each of these stakeholders has economic, business, and/or governance objectives that inform their expectations of the distribution grid. This multi-objective, multi-stakeholder environment creates tension that must be reconciled to successfully design and operate the distribution grid. Innovative companies are competing to bring high-tech solutions to electric utilities and their customers that address each of these objectives. Many developers of advanced distribution management systems (ADMS) and distributed energy resource management systems (DERMS) have adopted a modular architecture that allows grid operators to select functions and features according to their individual system needs. A modular platform also allows the solution provider to develop and integrate specific new product modules; however, the need to pursue multiple objectives with a fixed set of controllable devices makes integration expensive whether it is done at the product development stage or the deployment stage. This cost creates a significant barrier to adoption and can lengthen the product to market time of new solutions. To fundamentally address the complexity of system integration for distribution grid operations, the U.S. Department of Energy Office of Electricity has funded the GridAPPS-D project at PNNL, which streamlines integration by contributing to standards development, defining system architecture, applying advanced mathematics, and developing open-source software to demonstrate the concept of an open data-integration platform for distribution operations. The open data-integration platform concept enables system operators and solution providers to deploy ambitious, best-of-breed applications (or apps) without continually reengineering for integration. Ambitious apps developed by different solution providers will inevitably attempt to achieve different control objectives with the same set of controllable devices. If the open platform itself can resolve these conflicts in a way that achieves the best available outcomes for all apps, doesn’t restrict the ambitious design of apps, and ensures safe and secure operations, apps will be able to plug-and-play with the platform at the same time as other ambitious apps. In this paper, we describe a framework called App Deconfliction that empowers a platform to assign setpoints to controllable devices based on the values preferred by different apps (and even external stakeholder entities like customers or aggregators). The App Deconfliction framework is compatible with several methods for determining setpoint values. We present two methods based on game theory that provide a subtle built-in incentive structure for developers to adapt their apps to the fact that they will be operating in a moderated multi-app environment and to favor device setpoints that have the most effect on their objectives over those that have the least effect. Our simulation-based demonstrations have shown that game-theory-based deconfliction can lead to a 7% improvement in control space utilization compared to design-based methods.

24 POWER TRANSMISSION AND DISTRIBUTION↗

Medically related activities of application team program

Application team methodology identifies and specifies problems in technology transfer programs to biomedical areas through direct contact with users of aerospace technology. The availability of reengineering sources increases impact of the program on the medical community and results in broad scale application of some bioinstrumentation systems. Examples are given that include devices adapted to the rehabilitation of neuromuscular disorders, power sources for artificial organs, and automated monitoring and detection equipment in clinical medicine.

Source record↗

HIDEC F-15 adaptive engine control system flight test results

NASA-Ames' Highly Integrated Digital Electronic Control (HIDEC) flight test program aims to develop fully integrated airframe, propulsion, and flight control systems. The HIDEC F-15 adaptive engine control system flight test program has demonstrated that significant performance improvements are obtainable through the retention of stall-free engine operation throughout the aircraft flight and maneuver envelopes. The greatest thrust increase was projected for the medium-to-high altitude flight regime at subsonic speed which is of such importance to air combat. Adaptive engine control systems such as the HIDEC F-15's can be used to upgrade the performance of existing aircraft without resort to expensive reengining programs.

Smolka, James W.↗

Developing Software For A Flight-Control System

Improved process for development of flight-control software devised by integrating conventional software-development process with conventional control-system-analysis process. Reduces costs of development, eliminates need for reengineering, and almost eliminates production errors. Concept applicable to design of other control systems and of complicated hardware-and-software systems in general.

Murray, Jonathan↗

Towards automated support for extraction of reusable components

A cost effective introduction of software reuse techniques requires the reuse of existing software developed in many cases without aiming at reusability. This paper discusses the problems related to the analysis and reengineering of existing software in order to reuse it. We introduce a process model for component extraction and focus on the problem of analyzing and qualifying software components which are candidates for reuse. A prototype tool for supporting the extraction of reusable components is presented. One of the components of this tool aids in understanding programs and is based on the functional model of correctness. It can assist software engineers in the process of finding correct formal specifications for programs. A detailed description of this component and an example to demonstrate a possible operational scenario are given.

Abd-El-hafiz, S. K.↗