Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “domain 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
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Medical System Foundation Overview for Long-Duration Lunar Orbit and Surface Operations Missions

The Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has developed a Medical System Foundation for Level of Care IV, as defined by NASA’s space flight human-system standards, for long-duration lunar orbit and surface operation missions by employing a systems engineering approach using model-based systems engineering tools. This Foundation model includes a concept of operations; functional decomposition; clinical content (medical conditions, capabilities, and resources); associated functional, interface and non-functional technical requirements; and traces to the current versions of NASA standards documents and parent-level (Program- and Vehicle habitat system level) requirements. Collectively, these components constitute a foundation that serves as a starting point for a medical system that meets the Level of Care IV requirement. The Foundation was developed by a multidisciplinary team consisting of systems engineers, scientists, and clinicians across NASA, and information is presented in an easily accessible format that is understandable across disciplines. Stakeholders can use the Foundation to analyze the traces between medical capabilities, medical conditions, medical resources, and requirements and to identify medical system interfaces with other vehicle systems/subsystems. It can also be used as a basis for performing trades on risks vs. medical system mass and volume allocation. This discussion will focus on the processes through which the Medical System Foundation was developed, how the Foundation builds a bridge between the medical and engineering domains and facilitates communication between these communities, and how these processes can be applied more broadly to a crew health and performance system and other system domains. The presentation also discusses Foundation modifications based on the recently updated versions of the NASA 3001 Standards.

S. Lumpkins↗
NASA NTRSDate not supplied

Long Duration Medical System Foundation for Lunar Orbital and Lunar Surface Exploration Missions

For long-duration lunar orbital and lunar surface (LDLOS) exploration missions, the NASA Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has developed a medical system foundation through which clinical considerations may be represented via a systems engineering-based model. Components of the Long Duration Medical System Foundation model include a concept of operations (ConOps), functional decomposition, medical conditions to be addressed, clinical capabilities and resources, technical requirements, and traces of requirements to NASA standards documents and parent-level (Program- and Vehicle habitat system-level) requirements. The Foundation model offers the means to present information in a readily accessible format that is understandable across all clinical, engineering, scientific, and managerial disciplines. Collectively, these components constitute a foundation that serves future programs with similar long duration mission profiles as a starting point for medical system design. The Foundation was developed by a multidisciplinary team of systems engineers, scientists, and clinicians across NASA. The process started with ConOps development, subsequently decomposed into the functionalities needed to diagnose, treat, and prevent medical conditions. The clinical team identified medical conditions most likely needed to be diagnosed and treated during a long-duration lunar exploration mission. Through these approaches, requirements were codified for the LDLOS medical system. These requirements were then traced to NASA standards, medical conditions, medical capabilities, and medical resources, facilitating stakeholders’ use of the Foundation model to analyze traces and to identify medical system interfaces with other vehicle systems or subsystems. In addition, the Foundation may be used as a basis for performing risk trades on medical system mass and volume allocation. This discussion will focus on the processes through which the LDLOS Medical System Foundation was developed, how the Foundation builds a bridge between the medical and engineering domains, and how these processes may be applied more broadly to a crew health and performance system and other system domains.

Jay Lemery↗
NASA NTRS1987

Using hybrid expert system approaches for engineering applications

In this paper, the use of hybrid expert system shells and hybrid (i.e., algorithmic and heuristic) approaches for solving engineering problems is reported. Aspects of various engineering problem domains are reviewed for a number of examples with specific applications made to recently developed prototype expert systems. Based on this prototyping experience, critical evaluations of and comparisons between commercially available tools, and some research tools, in the United States and Australia, and their underlying problem-solving paradigms are made. Characteristics of the implementation tool and the engineering domain are compared and practical software engineering issues are discussed with respect to hybrid tools and approaches. Finally, guidelines are offered with the hope that expert system development will be less time consuming, more effective, and more cost-effective than it has been in the past.

Allen, R. H.↗
NASA NTRS2000

Supporting Development of Satellite's Guidance Navigation and Control Software: A Product Line Approach

The NASA Goddard Space Flight Center Flight Software Branch (FSB) is developing a Guidance, Navigation, and Control (GNC) Flight Software (FSW) product line. The demand for increasingly more complex flight software in less time while maintaining the same level of quality has motivated us to look for better FSW development strategies. The GNC FSW product line has been planned to address the core GNC FSW functionality very similar on many recent low/near Earth missions in the last ten years. Unfortunately these missions have not accomplished significant drops in development cost since a systematic approach towards reuse has not been adopted. In addition, new demands are continually being placed upon the FSW which means the FSB must become more adept at providing GNC FSW functionality's core so it can accommodate additional requirements. These domain features together with engineering concepts are influencing the specification, description and evaluation of FSW product line. Domain engineering is the foundation for emerging product line software development approaches. A product line is 'A family of products designed to take advantage of their common aspects and predicted variabilities'. In our product line approach, domain engineering includes the engineering activities needed to produce reusable artifacts for a domain. Application engineering refers to developing an application in the domain starting from reusable artifacts. The focus of this paper is regarding the software process, lessons learned and on how the GNC FSW product line manages variability. Existing domain engineering approaches do not enforce any specific notation for domain analysis or commonality and variability analysis. Usually, natural language text is the preferred tool. The advantage is the flexibility and adapt ability of natural language. However, one has to be ready to accept also its well-known drawbacks, such as ambiguity, inconsistency, and contradictions. While most domain analysis approaches are functionally oriented, the idea of applying the object-oriented approach in domain analysis is not new. Some authors propose to use UML as the notation underlying domain analysis. Our work is based on the same idea of merging UML and domain analysis. Further, we propose a few extensions to UML in order to express variability, and we define precisely their semantics so that a tool can support them. The extensions are designed to be implemented on the API of a popular industrial CASE tool, with obvious advantages in cost and availability of tool support. The paper outlines the product line processes and identifies where variability must be addressed. Then it describes the product line products with respect to how they accommodate variability. The Celestial Body subdomain is used as a working example. Our results to date are summarized and plans for the future are described.

McComas, David↗
NASA NTRS1992

Generic domain models in software engineering

This paper outlines three research directions related to domain-specific software development: (1) reuse of generic models for domain-specific software development; (2) empirical evidence to determine these generic models, namely elicitation of mental knowledge schema possessed by expert software developers; and (3) exploitation of generic domain models to assist modelling of specific applications. It focuses on knowledge acquisition for domain-specific software development, with emphasis on tool support for the most important phases of software development.

Maiden, Neil↗
NASA NTRS1992

Domain and Specification Models for Software Engineering

This paper discusses our approach to representing application domain knowledge for specific software engineering tasks. Application domain knowledge is embodied in a domain model. Domain models are used to assist in the creation of specification models. Although many different specification models can be created from any particular domain model, each specification model is consistent and correct with respect to the domain model. One aspect of the system-hierarchical organization is described in detail.

Iscoe, Neil↗
NASA NTRS2006

The Advanced Modeling, Simulation and Analysis Capability Roadmap Vision for Engineering

This paper summarizes a subset of the Advanced Modeling Simulation and Analysis (AMSA) Capability Roadmap that was developed for NASA in 2005. The AMSA Capability Roadmap Team was chartered to "To identify what is needed to enhance NASA's capabilities to produce leading-edge exploration and science missions by improving engineering system development, operations, and science understanding through broad application of advanced modeling, simulation and analysis techniques." The AMSA roadmap stressed the need for integration, not just within the science, engineering and operations domains themselves, but also across these domains. Here we discuss the roadmap element pertaining to integration within the engineering domain, with a particular focus on implications for future observatory missions. The AMSA products supporting the system engineering function are mission information, bounds on information quality, and system validation guidance. The Engineering roadmap element contains 5 sub-elements: (1) Large-Scale Systems Models, (2) Anomalous Behavior Models, (3) advanced Uncertainty Models, (4) Virtual Testing Models, and (5) space-based Robotics Manufacture and Servicing Models.

Zang, Thomas↗
NASA NTRS1994

Collaborative engineering-design support system

Designing engineering objects requires many engineers' knowledge from different domains. There needs to be cooperative work among engineering designers to complete a design. Revisions of a design are time consuming, especially if designers work at a distance and with different design description formats. In order to reduce the design cycle, there needs to be a sharable design describing the engineering community, which can be electronically transportable. Design is a process of integrating that is not easy to define definitively. This paper presents Design Script which is a generic engineering design knowledge representation scheme that can be applied in any engineering domain. The Design Script is developed through encapsulation of common design activities and basic design components based on problem decomposition. It is implemented using CLIPS with a Windows NT graphical user interface. The physical relationships between engineering objects and their subparts can be constructed in a hierarchical manner. The same design process is repeatedly applied at each given level of hierarchy and recursively into lower levels of the hierarchy. Each class of the structure can be represented using the Design Script.

Lee, Dong HO↗
NASA NTRS2012

Policy-Based Negotiation Engine for Cross-Domain Interoperability

A successful policy negotiation scheme for Policy-Based Management (PBM) has been implemented. Policy negotiation is the process of determining the "best" communication policy that all of the parties involved can agree on. Specifically, the problem is how to reconcile the various (and possibly conflicting) communication protocols used by different divisions. The solution must use protocols available to all parties involved, and should attempt to do so in the best way possible. Which protocols are commonly available, and what the definition of "best" is will be dependent on the parties involved and their individual communications priorities.

Vatan, Farrokh↗
NASA NTRS2020

Strategic Perspectives on the Future of Systems Engineering at NASA

NASA’s Model-Based Systems Engineering (MBSE) Infusion and Modernization Initiative (MIAMI) chartered a strategy group comprising early to mid-career NASA subject matter experts with diverse experiences to look into the future of systems engineering at NASA. The purpose of the group was to provide a vision for the future state of systems engineering practices and to develop a strategic plan to enable the evolution of the art up to 20 years in the future. The group used a design thinking approach to gather ideas and obtained insight into current engineering processes and domain outlook by interviewing engineers of varying expertise and experiences who had worked on teams of different sizes for missions large and small. The group built a roadmap to highlight future needs, projected capabilities, and technology and competency gaps and developed a strategic plan to ensure the expedient introduction of these capabilities. The resulting strategic plan recommends capability development and workforce strategies and provides guidance for Agency-wide SE policy. Artifacts, details, and raw data from the strategy team’s work are contained in NASA/TM-20205002911/SUPPL, Strategic Perspectives on the Future of Systems Engineering at NASA: Supplemental Information: Appendixes A to K.

Anupa R Bajwa↗
NASA NTRS1995

Computing Propagation Of Sound In Engine Ducts

Frequency Domain Propagation Model (FREDOM) computer program accounts for acoustic loads applied to components of engines. Models propagation of noise through fluids in ducts between components and through passages within components. Used not only to analyze hardware problems, but also for design purposes. Updated version of FREQPL program easier to use. Devised specifically for use in analyzing acoustic loads in rocket engines. Underlying physical and mathematical concepts implemented also applicable to acoustic propagation in other enclosed spaces; analyzing process plumbing and ducts in industrial buildings with view toward reducing noise in work areas.

Saylor, Silvia↗
NASA NTRS1992

Modeling software systems by domains

The Software Architectures Engineering (SAE) Project at the Software Engineering Institute (SEI) has developed engineering modeling techniques that both reduce the complexity of software for domain-specific computer systems and result in systems that are easier to build and maintain. These techniques allow maximum freedom for system developers to apply their domain expertise to software. We have applied these techniques to several types of applications, including training simulators operating in real time, engineering simulators operating in non-real time, and real-time embedded computer systems. Our modeling techniques result in software that mirrors both the complexity of the application and the domain knowledge requirements. We submit that the proper measure of software complexity reflects neither the number of software component units nor the code count, but the locus of and amount of domain knowledge. As a result of using these techniques, domain knowledge is isolated by fields of engineering expertise and removed from the concern of the software engineer. In this paper, we will describe kinds of domain expertise, describe engineering by domains, and provide relevant examples of software developed for simulator applications using the techniques.

Dippolito, Richard↗
NASA NTRS1994

Using Induction to Refine Information Retrieval Strategies

Conceptual information retrieval systems use structured document indices, domain knowledge and a set of heuristic retrieval strategies to match user queries with a set of indices describing the document's content. Such retrieval strategies increase the set of relevant documents retrieved (increase recall), but at the expense of returning additional irrelevant documents (decrease precision). Usually in conceptual information retrieval systems this tradeoff is managed by hand and with difficulty. This paper discusses ways of managing this tradeoff by the application of standard induction algorithms to refine the retrieval strategies in an engineering design domain. We gathered examples of query/retrieval pairs during the system's operation using feedback from a user on the retrieved information. We then fed these examples to the induction algorithm and generated decision trees that refine the existing set of retrieval strategies. We found that (1) induction improved the precision on a set of queries generated by another user, without a significant loss in recall, and (2) in an interactive mode, the decision trees pointed out flaws in the retrieval and indexing knowledge and suggested ways to refine the retrieval strategies.

Baudin, Catherine↗
NASA NTRS1987

Using output to evaluate and refine rules in rule-based expert systems

The techniques described provide an effective tool which knowledge engineers and domain experts can utilize to help in evaluating and refining rules. These techniques have been used successfully as learning mechanisms in a prototype adaptive diagnostic expert system and are applicable to other types of expert systems. The degree to which they constitute complete evaluation/refinement of an expert system depends on the thoroughness of their use.

St.clair, D. C.↗
NASA NTRS1991

The Ames-Lockheed orbiter processing scheduling system

A general purpose scheduling system and its application to Space Shuttle Orbiter Processing at the Kennedy Space Center (KSC) are described. Orbiter processing entails all the inspection, testing, repair, and maintenance necessary to prepare the Shuttle for launch and takes place within the Orbiter Processing Facility (OPF) at KSC, the Vehicle Assembly Building (VAB), and on the launch pad. The problems are extremely combinatoric in that there are thousands of tasks, resources, and other temporal considerations that must be coordinated. Researchers are building a scheduling tool that they hope will be an integral part of automating the planning and scheduling process at KSC. The scheduling engine is domain independent and is also being applied to Space Shuttle cargo processing problems as well as wind tunnel scheduling problems.

Zweben, Monte↗
NASA NTRS1988

Knowledge-based requirements analysis for automating software development

We present a new software development paradigm that automates the derivation of implementations from requirements. In this paradigm, informally-stated requirements are expressed in a domain-specific requirements specification language. This language is machine-understable and requirements expressed in it are captured in a knowledge base. Once the requirements are captured, more detailed specifications and eventually implementations are derived by the system using transformational synthesis. A key characteristic of the process is that the required human intervention is in the form of providing problem- and domain-specific engineering knowledge, not in writing detailed implementations. We describe a prototype system that applies the paradigm in the realm of communication engineering: the prototype automatically generates implementations of buffers following analysis of the requirements on each buffer.

Markosian, Lawrence Z.↗
NASA NTRS1977

Frequency domain compensation of a DYNGEN turbofan engine model

Following Rosenbrock's ideas regarding the advantages of dominance in linear multivariable control systems, a new graphical technique is used for the design of compensators that achieve dominance. The technique is illustrated with an application to the problem of designing compensators for a linear turbofan-engine model. The resulting design is put into perspective by examining it in the light of two other multivariable frequency-domain methods. One, MacFarlane's method of characteristic loci, is used to realize a final design for stability and low interaction. The other is a direct technique based upon the algebraic expansion of the determinant of the return difference in terms of it's elements. Results from simulations carried out on the NASA DYNGEN software are included.

Schafer, R. M.↗