Search NASA⌕ Search

SEARCH · Search NASA

Results for “STEP system engineering”

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

A systems engineering initiative for NASA's space communications

In addition to but separate from the Red and Blue Teams commissioned by the NASA Administrator, NASA's Associate Administrator for Space Communications commissioned a Blue Team to review the Office of Space Communications (Code O) Core Program and determine how the program could be conducted faster, better, and cheaper, without compromising safety. Since there was no corresponding Red Team for the Code O Blue Team, the Blue Team assumed a Red Team independent attitude and challenged the status quo. The Blue Team process and results are summarized. The Associate Administrator for Space Communications subsequently convened a special management session to discuss the significance and implications of the Blue Team's report and to lay the groundwork and teamwork for the next steps, including the transition from engineering systems to systems engineering. The methodology and progress toward realizing the Code O Family vision and accomplishing the systems engineering initiative for NASA's space communications are presented.

Hornstein, Rhoda S.↗

A Process for Capturing the Art of Systems Engineering

There is both an art and a science to systems engineering. The science of systems engineering is effectively captured in processes and procedures, but the art is much more elusive. We propose that there is six step process that can be applied to any systems engineering organization to create an environment from which the "art" of that organization can be captured, be allowed to evolve collaboratively and be shared with all members of the organization. This paper details this process as it was applied to NASA Launch Services Program (LSP) Integration Engineering Branch during a pilot program of Confluence, a Commercial Off The Shelf (COTS) wiki tool.

Commercial Off The Shelf↗

Second Generation RLV Space Vehicle Concept

NASA has a long history of conducting development programs and projects in a consistent fashion. Systems Engineering within those programs and projects has also followed a given method outlined by such documents as the NASA Systems Engineering Handbook. The relatively new NASA Space Launch Initiative (SLI) is taking a new approach to developing a space vehicle, with innovative management methods as well as new Systems Engineering processes. With the program less than a year into its life cycle, the efficacy of these new processes has yet to be proven or disproven. At $776M for phase 1, SLI represents a major portion of the NASA focus; however, the new processes being incorporated are not reflected in the training provided by NASA to its engineers. The NASA Academy of Program and Project Leadership (APPL) offers core classes in program and project management and systems engineering to NASA employees with the purpose of creating a "knowledge community where ideas, skills, and experiences are exchanged to increase each other's capacity for strong leadership". The SLI program is, in one sense, a combination of a conceptual design program and a technology program. The program as a whole doesn't map into the generic systems engineering project cycle as currently, and for some time, taught. For example, the NASA APPL Systems Engineering training course teaches that the "first step in developing an architecture is to define the external boundaries of the system", which will require definition of the interfaces with other systems and the next step will be to "define all the components that make up the next lower level of the system hierarchy" where fundamental requirements are allocated to each component. Whereas, the SLI technology risk reduction approach develops architecture subsystem technologies prior to developing architectures. The higher level architecture requirements are not allowed to fully develop and undergo decomposition and allocation down to the subsystems before the subsystems must develop allocated requirements based on the highest level of requirements. In the vernacular of the project cycles prior to the mid 1990's, the architecture definition portion of the program appears to be at a generic Phase A stage, while the subsystems are operating at Phase B. Even the management structure of the SLI program is innovative in its approach to Systems Engineering and is not reflected in the APPL training modules. The SLI program has established a Systems Engineering office as an office separate from the architecture development or the subsystem technology development, while that office does have representatives within these other offices. The distributed resources of the Systems Engineering Office are co-located with the respective Project Offices. This template is intended to provide systems engineering as an integrated function at the Program Level. the program management of SLI and the MAT agree that "program/project managers and the systems engineering team must work closely together towards the single objective of delivering quality products that meet the customer needs". This paper will explore the differences between the methods being taught by NASA, which represent decades of ideas, and those currently in practice in SLI. Time will tell if the innovation employed by SLI will prove to be the model of the future. For now, it is suggested that the training of the present exercise the flexibility of recognizing the new processes employed by a major new NASA program.

Bailey, Michelle↗

Development of an expert system prototype for determining software functional requirements for command management activities at NASA Goddard

The development of an expert system prototype for software functional requirement determination for NASA Goddard's Command Management System, as part of its process of transforming general requests into specific near-earth satellite commands, is described. The present knowledge base was formulated through interactions with domain experts, and was then linked to the existing Knowledge Engineering Systems (KES) expert system application generator. Steps in the knowledge-base development include problem-oriented attribute hierarchy development, knowledge management approach determination, and knowledge base encoding. The KES Parser and Inspector, in addition to backcasting and analogical mapping, were used to validate the expert system-derived requirements for one of the major functions of a spacecraft, the solar Maximum Mission. Knowledge refinement, evaluation, and implementation procedures of the expert system were then accomplished.

Liebowitz, J.↗

Requirements to Design to Code: Towards a Fully Formal Approach to Automatic Code Generation

A general-purpose method to mechanically transform system requirements into a provably equivalent model has yet to appear. Such a method represents a necessary step toward high-dependability system engineering for numerous possible application domains, including sensor networks and autonomous systems. Currently available tools and methods that start with a formal model of a system and mechanically produce a provably equivalent implementation are valuable but not sufficient. The gap that current tools and methods leave unfilled is that their formal models cannot be proven to be equivalent to the system requirements as originated by the customer. For the classes of systems whose behavior can be described as a finite (but significant) set of scenarios, we offer a method for mechanically transforming requirements (expressed in restricted natural language, or in other appropriate graphical notations) into a provably equivalent formal model that can be used as the basis for code generation and other transformations.

Hinchey, Michael G.↗

Towards an Automated Development Methodology for Dependable Systems with Application to Sensor Networks

A general-purpose method to mechanically transform system requirements into a probably equivalent model has yet to appeal: Such a method represents a necessary step toward high-dependability system engineering for numerous possible application domains, including sensor networks and autonomous systems. Currently available tools and methods that start with a formal model of a system and mechanically produce a probably equivalent implementation are valuable but not su8cient. The "gap" unfilled by such tools and methods is that their. formal models cannot be proven to be equivalent to the system requirements as originated by the customel: For the classes of systems whose behavior can be described as a finite (but significant) set of scenarios, we offer a method for mechanically transforming requirements (expressed in restricted natural language, or in other appropriate graphical notations) into a probably equivalent formal model that can be used as the basis for code generation and other transformations.

Hinchey, Michael G.↗

A Formal Approach to Requirements-Based Programming

No significant general-purpose method is currently available to mechanically transform system requirements into a provably equivalent model. The widespread use of such a method represents a necessary step toward high-dependability system engineering for numerous application domains. Current tools and methods that start with a formal model of a system and mechanically produce a provably equivalent implementation are valuable but not sufficient. The "gap" unfilled by such tools and methods is that the formal models cannot be proven to be equivalent to the requirements. We offer a method for mechanically transforming requirements into a provably equivalent formal model that can be used as the basis for code generation and other transformations. This method is unique in offering full mathematical tractability while using notations and techniques that are well known and well trusted. Finally, we describe further application areas we are investigating for use of the approach.

Hinchey, Michael G.↗

Requirements to Design to Code: Towards a Fully Formal Approach to Automatic Code Generation

A general-purpose method to mechanically transform system requirements into a provably equivalent model has yet to appear. Such a method represents a necessary step toward high-dependability system engineering for numerous possible application domains, including distributed software systems, sensor networks, robot operation, complex scripts for spacecraft integration and testing, and autonomous systems. Currently available tools and methods that start with a formal model of a system and mechanically produce a provably equivalent implementation are valuable but not sufficient. The gap that current tools and methods leave unfilled is that their formal models cannot be proven to be equivalent to the system requirements as originated by the customer. For the classes of systems whose behavior can be described as a finite (but significant) set of scenarios, we offer a method for mechanically transforming requirements (expressed in restricted natural language, or in other appropriate graphical notations) into a provably equivalent formal model that can be used as the basis for code generation and other transformations.

Hinchey, Michael G.↗

Requirements to Design to Code: Towards a Fully Formal Approach to Automatic Code Generation

A general-purpose method to mechanically transform system requirements into a provably equivalent model has yet to appear. Such a method represents a necessary step toward high-dependability system engineering for numerous possible application domains, including distributed software systems, sensor networks, robot operation, complex scripts for spacecraft integration and testing, and autonomous systems. Currently available tools and methods that start with a formal model of a: system and mechanically produce a provably equivalent implementation are valuable but not sufficient. The "gap" that current tools and methods leave unfilled is that their formal models cannot be proven to be equivalent to the system requirements as originated by the customer. For the ciasses of systems whose behavior can be described as a finite (but significant) set of scenarios, we offer a method for mechanically transforming requirements (expressed in restricted natural language, or in other appropriate graphical notations) into a provably equivalent formal model that can be used as the basis for code generation and other transformations.

Hinchey, Michael G.↗

Cost effective launch operations of the SSME

The Space Shuttle Main Engine (SSME) represents the beginning of reusable rocket engine operations in the space transportation system (STS). Steps taken to reduce the overall cost of flight operations of the SSME by improving turnaround operations, extending the life of the engine, and improving the cost effectiveness of overhaul operations at the Canoga Park home plant are described. Ground certification testing to ensure safe launch operations is described, as well as certification extension testing that leads to a service life equivalent to 40 flights. The proven flight record of the SSME, which has demonstrated the utility of the SSME as a key component of America's space transportation system, is discussed.

Klatt, F. P.↗

Database Access Manager for the Software Engineering Laboratory (DAMSEL) user's guide

Operating instructions for the Database Access Manager for the Software Engineering Laboratory (DAMSEL) system are presented. Step-by-step instructions for performing various data entry and report generation activities are included. Sample sessions showing the user interface display screens are also included. Instructions for generating reports are accompanied by sample outputs for each of the reports. The document groups the available software functions by the classes of users that may access them.

Source record↗

A Scenario-Based Approach to Assess Continuity Gaps in Earth Observations

Decision analysis processes outlined in systems engineering references, such as the Systems Engineering Body of Knowledge [1] or the NASA Systems Engineering Handbook [2], recommend following a series of steps to support decision-making for engineering applications. These steps are consistent across the literature and typically involve defining objectives, defining relevant criteria against which candidate alternatives can be assessed, selecting an evaluation method, assessing alternatives, and making a recommendation based on this assessment. These approaches are well-suited to assess systems for which sets of common objectives and constraints can be identified. A vast body of literature describes their application to numerous engineering problems, and many methods have been developed since the middle of the 20th century to support the assessment of candidate alternatives for such systems [3, 4, 5, 6]. These approaches, however, show some limitations when decisions pertain to systems of systems. These collections of individual systems typically do not share a common set of objectives and constraints, tend to be highly complex, and the definition of assessable, high-value candidate alternatives poses a challenge due to interdependencies. The formulation, development, operation, and funding of Earth observing missions are such that gaps may occur between missions, therefore impacting the continuity of measurements. These Earth observing mission architectures constitute systems of systems for which a common set of objectives and constraints can be challenging to define. When tasked with assessing gaps that may occur for a series of spaceborne missions that address similar science parameters, the authors therefore proposed to depart from the traditional objective- and criteria-based approach and instead adopted a scenario-based approach. This approach does not require a prioritized set of common objectives; rather, it assesses the impact of possible decisions on the system-of-systems and characterizes its possible future states. It also offers the flexibility to adjust assumptions, update inputs, and refine supporting models over time, while enabling the rapid, early identification of challenges and key decision points. By simulating the impact of potential decisions on the entirety of the system-of-systems, the approach enables the synchronization of multiple decisions that typically occur at the level of the individual system. This paper provides an overview of the approach that was developed to assess continuity gaps for a series of operational and planned spaceborne Earth observing missions, a description of its application to the problem at hand, and a discussion of currently known limitations.

scenario earth observations continuity gaps↗

A Scenario-Based Approach to Assess Continuity Gaps in Earth Observations

Decision analysis processes outlined in systems engineering references, such as the Systems Engineering Body of Knowledge [1] or the NASA Systems Engineering Handbook [2], recommend following a series of steps to support decision-making for engineering applications. These steps are consistent across the literature and typically involve defining objectives, defining relevant criteria against which candidate alternatives can be assessed, selecting an evaluation method, assessing alternatives, and making a recommendation based on this assessment. These approaches are well-suited to assess systems for which sets of common objectives and constraints can be identified. A vast body of literature describes their application to numerous engineering problems, and many methods have been developed since the middle of the 20th century to support the assessment of candidate alternatives for such systems [3, 4, 5, 6]. These approaches, however, show some limitations when decisions pertain to systems of systems. These collections of individual systems typically do not share a common set of objectives and constraints, tend to be highly complex, and the definition of assessable, high-value candidate alternatives poses a challenge due to interdependencies. The formulation, development, operation, and funding of Earth observing missions are such that gaps may occur between missions, therefore impacting the continuity of measurements. These Earth observing mission architectures constitute systems of systems for which a common set of objectives and constraints can be challenging to define. When tasked with assessing gaps that may occur for a series of spaceborne missions that address similar science parameters, the authors therefore proposed to depart from the traditional objective- and criteria-based approach and instead adopted a scenario-based approach. This approach does not require a prioritized set of common objectives; rather, it assesses the impact of possible decisions on the system-of-systems and characterizes its possible future states. It also offers the flexibility to adjust assumptions, update inputs, and refine supporting models over time, while enabling the rapid, early identification of challenges and key decision points. By simulating the impact of potential decisions on the entirety of the system-of-systems, the approach enables the synchronization of multiple decisions that typically occur at the level of the individual system. This paper provides an overview of the approach that was developed to assess continuity gaps for a series of operational and planned spaceborne Earth observing missions, a description of its application to the problem at hand, and a discussion of currently known limitations.

scenario earth observations continuity gaps↗

Discovering Digital Engineering Needs Through Human-Centered Approaches

Digital engineering has the power to transform organizations in profound ways, but digitizing legacy workflows and infusing new technologies into existing practices may not yield the intended results or address the underlying problems or bottlenecks. This paper describes the human-centered approaches used to understand stakeholder challenges and identify digital engineering needs during the design-build-test portion of the systems development lifecycle. Through a series of interactive stakeholder workshops and need-finding activities, key stakeholder needs were identified to help guide the integration of digital engineering technologies. The overarching need was for downstream system development steps to be considered further upstream in the project lifecycle in a manner that allows for proactive and interactive co-constructive idea exploration, problem resolution, and requirements considerations in a collective engagement with engineers and technicians from multiple disciplines to increase efficiency and reduce risks while offering opportunities to improve the final engineered system. Supporting this need was a wide-ranging desire from stakeholders for digital and non-digital support structures for efficient rapid iteration during system development. This work yielded several improvements for system development processes and for digital engineering infusion.

Human-centered Design↗

Discovering Digital Engineering Needs Through Human-Centered Approaches

Digital engineering has the power to transform organizations in profound ways, but digitizing legacy workflows and infusing new technologies into existing practices may not yield the intended results or address the underlying problems or bottlenecks. This paper describes the human-centered approaches used to understand stakeholder challenges and identify digital engineering needs during the design-build-test portion of the systems development lifecycle. Through a series of interactive stakeholder workshops and need-finding activities, key stakeholder needs were identified to help guide the integration of digital engineering technologies. The overarching need was for downstream system development steps to be considered further upstream in the project lifecycle in a manner that allows for proactive and interactive co-constructive idea exploration, problem resolution, and requirements considerations in a collective engagement with engineers and technicians from multiple disciplines to increase efficiency and reduce risks while offering opportunities to improve the final engineered system. Supporting this need was a wide-ranging desire from stakeholders for digital and non-digital support structures for efficient rapid iteration during system development. This work yielded several improvements for system development processes and for digital engineering infusion.

Design Science↗

Robotic Processing Of Rocket-Engine Nozzles

Automated manufacturing cell containing computer-controlled robotic processing system developed to implement some important related steps in fabrication of rocket-engine nozzles. Performs several tedious and repetitive fabrication, measurement, adjustment, and inspection processes and subprocesses now performed manually. Offers advantages of reduced processing time, greater consistency, excellent collection of data, objective inspections, greater productivity, and simplified fixturing. Also affords flexibility: by making suitable changes in hardware and software, possible to modify process and subprocesses. Flexibility makes work cell adaptable to fabrication of heat exchangers and other items structured similarly to rocket nozzles.

Gilbert, Jeffrey L.↗

Goals Analysis Procedure Guidelines for Applying the Goals Analysis Process

One of the key elements to successful project management is the establishment of the "right set of requirements", requirements that reflect the true customer needs and are consistent with the strategic goals and objectives of the participating organizations. A viable set of requirements implies that each individual requirement is a necessary element in satisfying the stated goals and that the entire set of requirements, taken as a whole, is sufficient to satisfy the stated goals. Unfortunately, it is the author's experience that during project formulation phases' many of the Systems Engineering customers do not conduct a rigorous analysis of the goals and objectives that drive the system requirements. As a result, the Systems Engineer is often provided with requirements that are vague, incomplete, and internally inconsistent. To complicate matters, most systems development methodologies assume that the customer provides unambiguous, comprehensive and concise requirements. This paper describes the specific steps of a Goals Analysis process applied by Systems Engineers at the NASA Langley Research Center during the formulation of requirements for research projects. The objective of Goals Analysis is to identify and explore all of the influencing factors that ultimately drive the system's requirements.

Motley, Albert E., III↗

Ring Buffered Network Bus

This report describes the research effort to demonstrate the integration of a data sharing technology, Ring Buffered Network Bus, in development by Dryden Flight Research Center, with an engine simulation application, the Java Gas Turbine Simulator, in development at the University of Toledo under a grant from the Glenn Research Center. The objective of this task was to examine the application of the RBNB technologies as a key component in the data sharing, health monitoring and system wide modeling elements of the NASA Aviation Safety Program (AVSP) [Golding, 1997]. System-wide monitoring and modeling of aircraft and air safety systems will require access to all data sources which are relative factors when monitoring or modeling the national airspace such as radar, weather, aircraft performance, engine performance, schedule and planning, airport configuration, flight operations, etc. The data sharing portion of the overall AVSP program is responsible for providing the hardware and software architecture to access and distribute data, including real-time flight operations data, among all of the AVSP elements. The integration of an engine code capable of numerically "flying" through recorded flight paths and weather data using a software tool that allows for distributed access of data to this engine code demonstrates initial steps toward building a system capable of monitoring and modeling the National Airspace.

Source record↗