Frequency domain compensation of a DYNGEN turbofan engine model
Explore the source record for details and available documents.
Schafer, R. M.↗
SEARCH · Search NASA
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.
Formalization and visualization of domain-specific software architectures
This paper describes a domain-specific software design system based on the concepts of software architectures engineering and domain-specific models and languages. In this system, software architectures are used as high level abstractions to formulate a domain-specific software design. The software architecture serves as a framework for composing architectural fragments (e.g., domain objects, system components, and hardware interfaces) that make up the knowledge (or model) base for solving a problem in a particular application area. A corresponding software design is generated by analyzing and describing a system in the context of the software architecture. While the software architecture serves as the framework for the design, this concept is insufficient by itself for supplying the additional details required for a specific design. Additional domain knowledge is still needed to instantiate components of the architecture and develop optimized algorithms for the problem domain. One possible way to obtain the additional details is through the use of domain-specific languages. Thus, the general concept of a software architecture and the specific design details provided by domain-specific languages are combined to create what can be termed a domain-specific software architecture (DSSA).
Bailor, Paul D.↗
The Application of 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 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 reuse-based software engineering, decisions on the requirements, design and even implementation of domain assets can can be made prior to beginning development of a specific system. in order to bring the effectiveness of V&V to bear within reuse-based software engineering. V&V must be incorporated within the domain engineering process.
Addy, Edward↗
Semantically-Rigorous Systems Engineering Modeling Using Sysml and OWL
The Systems Modeling Language (SysML) has found wide acceptance as a standard graphical notation for the domain of systems engineering. SysML subsets and extends the Unified Modeling Language (UML) to define conventions for expressing structural, behavioral, and analytical elements, and relationships among them. SysML-enabled modeling tools are available from multiple providers, and have been used for diverse projects in military aerospace, scientific exploration, and civil engineering. The Web Ontology Language (OWL) has found wide acceptance as a standard notation for knowledge representation. OWL-enabled modeling tools are available from multiple providers, as well as auxiliary assets such as reasoners and application programming interface libraries, etc. OWL has been applied to diverse projects in a wide array of fields. While the emphasis in SysML is on notation, SysML inherits (from UML) a semantic foundation that provides for limited reasoning and analysis. UML's partial formalization (FUML), however, does not cover the full semantics of SysML, which is a substantial impediment to developing high confidence in the soundness of any conclusions drawn therefrom. OWL, by contrast, was developed from the beginning on formal logical principles, and consequently provides strong support for verification of consistency and satisfiability, extraction of entailments, conjunctive query answering, etc. This emphasis on formal logic is counterbalanced by the absence of any graphical notation conventions in the OWL standards. Consequently, OWL has had only limited adoption in systems engineering. The complementary strengths and weaknesses of SysML and OWL motivate an interest in combining them in such a way that we can benefit from the attractive graphical notation of SysML and the formal reasoning of OWL. This paper describes an approach to achieving that combination.
Web Ontology Language (OWL)↗
Finite difference time domain modeling of steady state scattering from jet engines with moving turbine blades
The approach chosen to model steady state scattering from jet engines with moving turbine blades is based upon the Finite Difference Time Domain (FDTD) method. The FDTD method is a numerical electromagnetic program based upon the direct solution in the time domain of Maxwell's time dependent curl equations throughout a volume. One of the strengths of this method is the ability to model objects with complicated shape and/or material composition. General time domain functions may be used as source excitations. For example, a plane wave excitation may be specified as a pulse containing many frequencies and at any incidence angle to the scatterer. A best fit to the scatterer is accomplished using cubical cells in the standard cartesian implementation of the FDTD method. The material composition of the scatterer is determined by specifying its electrical properties at each cell on the scatterer. Thus, the FDTD method is a suitable choice for problems with complex geometries evaluated at multiple frequencies. It is assumed that the reader is familiar with the FDTD method.
Ryan, Deirdre A.↗
Domain-Specific Languages and Diagram Customization for a Concurrent Engineering Environment
A major open question for advocates of Model-Based Systems Engineering (MBSE) is the question of how system and subsystem engineers will work together. The Systems Modeling Language (SysML), like any language intended for a large audience, is in tension between the desires for simplicity and for expressiveness. In order to be more expressive, many specialized language elements may be introduced, which will unfortunately make a complete understanding of the language a more daunting task. While this may be acceptable for systems modelers, it will increase the challenge of including subsystem engineers in the modeling effort. One possible answer to this situation is the use of Domain-Specific Languages (DSL), which are fully supported by the Unified Modeling Language (UML). SysML is in fact a DSL for systems engineering. The expressive power of a DSL can be enhanced through the use of diagram customization. Various domains have already developed their own schematic vocabularies. Within the space engineering community, two excellent examples are the propulsion and telecommunication subsystems. A return to simple box-and-line diagrams (e.g., the SysML Internal Block Diagram) are in many ways a step backward. In order allow subsystem engineers to contribute directly to the model, it is necessary to make a system modeling tool at least approximate in accessibility to drawing tools like Microsoft PowerPoint and Visio. The challenge is made more extreme in a concurrent engineering environment, where designs must often be drafted in an hour or two. In the case of the Jet Propulsion Laboratory's Team X concurrent design team, a subsystem is specified using a combination of PowerPoint for drawing and Excel for calculation. A pilot has been undertaken in order to meld the drawing portion and the production of master equipment lists (MELs) via a SysML authoring tool, MagicDraw. Team X currently interacts with its customers in a process of sharing presentations. There are several inefficiencies that arise from this situation. The first is that a customer team must wait two weeks to a month (which is 2-4 times the duration of most Team X studies themselves) for a finalized, detailed design description. Another is that this information must be re-entered by hand into the set of engineering artifacts and design tools that the mission concept team uses after a study is complete. Further, there is no persistent connection to Team X or institutionally shared formulation design tools and data after a given study, again reducing the direct reuse of designs created in a Team X study. This paper presents the underpinnings of subsystem DSLs as they were developed for this pilot. This includes specialized semantics for different domains as well as the process by which major categories of objects were derived in support of defining the DSLs. The feedback given to us by the domain experts on usability, along with a pilot study with the partial inclusion of these tools is also discussed.
Cole, Bjorn↗
Toward a Model-Based Approach to Flight System Fault Protection
Fault Protection (FP) is a distinct and separate systems engineering sub-discipline that is concerned with the off-nominal behavior of a system. Flight system fault protection is an important part of the overall flight system systems engineering effort, with its own products and processes. As with other aspects of systems engineering, the FP domain is highly amenable to expression and management in models. However, while there are standards and guidelines for performing FP related analyses, there are not standards or guidelines for formally relating the FP analyses to each other or to the system hardware and software design. As a result, the material generated for these analyses are effectively creating separate models that are only loosely-related to the system being designed. Development of approaches that enable modeling of FP concerns in the same model as the system hardware and software design enables establishment of formal relationships that has great potential for improving the efficiency, correctness, and verification of the implementation of flight system FP. This paper begins with an overview of the FP domain, and then continues with a presentation of a SysML/UML model of the FP domain and the particular analyses that it contains, by way of showing a potential model-based approach to flight system fault protection, and an exposition of the use of the FP models in FSW engineering. The analyses are small examples, inspired by current real-project examples of FP analyses.
Day, John↗
JPL's Foundry Furnace: Web-Based Concurrent Engineering for Formulation
The Jet Propulsion Laboratory’s Innovation Foundry is an enterprise tasked with shepherding space mission concepts through the formulation lifecycle. It oversees a number of “virtual teams” for the various stages of formulation. Among these is Team X, which has had considerable success over its more than 20-year history. In a Team X study, domain experts (including engineers devoted to the various spacecraft subsystems) work concurrently and collaboratively over several days to arrive at a feasible point design with a reasonable cost estimate. They use a set of linked Excel workbooks, each developed and approved by a responsible “line organization” within JPL. This toolset has served Team X well over the years, and has evolved since its inception. At the same time, the Innovation Foundry’s portfolio of formulation teams has expanded, and so has the scope of the design challenges they face. The A-Team runs workshop-like architecture studies to focus science investigations, generate mission concepts, assess feasibility, and explore trade spaces. Team Xc performs rapid point design in the style of Team X, but for CubeSats and small spacecraft, using a different toolset. Proposal teams further mature concepts to the point where they can be proposed. Recognizing the importance of trade space modeling combined with new IT services for providing and integrating data, JPL is developing the Foundry Furnace web-based software infrastructure. It will support A-Team, Team Xc, and Team X, providing study management, a catalog of hardware components, a library of re-usable analyses, and a design environment. It is a modernization of JPL’s concurrent engineering infrastructure, embracing the core concepts of Model-Based Systems Engineering, and built with modern software design philosophies.
Murphy, Jonathan↗
Development of a Human Systems Integration Plan
NASA defines Human Systems Integration (HSI) as part of the overall systems engineering and acquisition strategy for space systems. The HSI Plan defines how HSI activities will be implemented across the lifecycle of the mission, as required by NPR 7123.1C, NASA Systems Engineering Processes and Requirements, and NPR 8705.2C Human-Rating Requirements for Space Systems. The goal of this presentation is to share with government and industry how an HSI Plan can be implemented. The presentation will cover HSI implementation for flight systems, vehicle processing, and interfaces. These are divided into six NASA HSI Domains: human factors engineering, operations resources, safety, training, maintainability and supportability, habitability and environment. HSI activities go across the mission’s lifecycle from pre-formulation and acquisition through design, development, operations, maintenance, and decommissioning. The HSI Plan includes a description of the HSI activities and products that are essential for human rating, operability, maintainability, supportability, and affordability of the mission systems. It also describes the role of the HSI Team required as part of the Human Rating process. The HSI Plan utilizes the operational expertise within NASA to ensure designs and testing are successful, leading to acceptable human spaceflight vehicles.
Jackelynne Silva-Martinez↗
Data Science and the Knowledge Discovery Adventure
This talk will cover the important steps involved in the data science and knowledge discovery process: • Initial fact gathering (interview domain experts, review reports, articles, state-of-the-art) • Identify the problem (prediction, classification, statistical analysis, etc.) • Survey supporting data sources • Understand the data (numerical, categorical, text, sampling rate, data quality issues, etc.) • Selecting relevant features and sources • Acquire the data (set up agreements with the data stewards, APIs to download, etc.) • Merge data sources (temporal, spatial, common key, other ontologies...) • Feature Engineering (non linear domain knowledge or physics-based relationships) • Build data processing pipeline (may need to tap into data stream, develop parallel processing algorithm, federated learning etc.) • Build model and test (tune hyper-parameters, cross validation.) • Analyze/Validate results (do the results make sense. Does it answer the original question). • Deploy/Publish (Monitor and assess benefits)
Data science↗
The SEL Adapts to Meet Changing Times
Since 1976, the Software Engineering Laboratory (SEL) has been dedicated to understanding and improving the way in which one NASA organization, the Flight Dynamics Division (FDD) at Goddard Space Flight Center, develops, maintains, and manages complex flight dynamics systems. It has done this by developing and refining a continual process improvement approach that allows an organization such as the FDD to fine-tune its process for its particular domain. Experimental software engineering and measurement play a significant role in this approach. The SEL is a partnership of NASA Goddard, its major software contractor, Computer Sciences Corporation (CSC), and the University of Maryland's (LTM) Department of Computer Science. The FDD primarily builds software systems that provide ground-based flight dynamics support for scientific satellites. They fall into two sets: ground systems and simulators. Ground systems are midsize systems that average around 250 thousand source lines of code (KSLOC). Ground system development projects typically last 1 - 2 years. Recent systems have been rehosted to workstations from IBM mainframes, and also contain significant new subsystems written in C and C++. The simulators are smaller systems averaging around 60 KSLOC that provide the test data for the ground systems. Simulator development lasts up to 1 year. Most of the simulators have been built in Ada on workstations. The SEL is responsible for the management and continual improvement of the software engineering processes used on these FDD projects.
Pajerski, Rose S.↗
TARGET's role in knowledge acquisition, engineering, validation, and documentation
We investigate the use of the TARGET task analysis tool for use in the development of rule-based expert systems. We found TARGET to be very helpful in the knowledge acquisition process. It enabled us to perform knowledge acquisition with one knowledge engineer rather than two. In addition, it improved communication between the domain expert and knowledge engineer. We also found it to be useful for both the rule development and refinement phases of the knowledge engineering process. Using the network in these phases required us to develop guidelines that enabled us to easily translate the network into production rules. A significant requirement for TARGET remaining useful throughout the knowledge engineering process was the need to carefully maintain consistency between the network and the rule representations. Maintaining consistency not only benefited the knowledge engineering process, but also has significant payoffs in the areas of validation of the expert system and documentation of the knowledge in the system.
Levi, Keith R.↗
Data Mining and Optimization Tools for Developing Engine Parameters Tools
This project was awarded for understanding the problem and developing a plan for Data Mining tools for use in designing and implementing an Engine Condition Monitoring System. Tricia Erhardt and I studied the problem domain for developing an Engine Condition Monitoring system using the sparse and non-standardized datasets to be available through a consortium at NASA Lewis Research Center. We visited NASA three times to discuss additional issues related to dataset which was not made available to us. We discussed and developed a general framework of data mining and optimization tools to extract useful information from sparse and non-standard datasets. These discussions lead to the training of Tricia Erhardt to develop Genetic Algorithm based search programs which were written in C++ and used to demonstrate the capability of GA algorithm in searching an optimal solution in noisy, datasets. From the study and discussion with NASA LeRC personnel, we then prepared a proposal, which is being submitted to NASA for future work for the development of data mining algorithms for engine conditional monitoring. The proposed set of algorithm uses wavelet processing for creating multi-resolution pyramid of tile data for GA based multi-resolution optimal search.
Dhawan, Atam P.↗
Implementation of Human Systems Integration Technical and Management Process for the Lunar Gateway Program
NASA recognizes Human Systems Integration (HSI) as part of the overall systems engineering and acquisition strategy for space systems. The Lunar Gateway Program is implementing HSI technical and management process across the lifecycle of the mission, as required by NPR 7123.1C NASA Systems Engineering Processes and Requirements, and led by the Gateway HSI team as required by NPR 8705.2C Human-Rating Requirements for Space Systems, now HEOMD-003 Crewed Deep Space Systems Human Rating Certification Requirements and Standards for NASA Missions. NASA has been using HSI principles for many years and has applied them to many of its previous human spaceflight Programs. As NASA returns to the Moon in a more sustainable manner, the Gateway Program is maturing the application of HSI by implementing it more visibly as part of Artemis, with guidance from the NASA/SP-20210010952 NASA HSI Handbook. This paper discusses how HSI is being implemented in the Gateway Program, challenges faced with its implementation during the development phase, and strategies/approaches used to overcome those. The paper also covers HSI implementation for flight systems, vehicle processing, and interfaces across the six identified NASA HSI Domains: human factors engineering, operations, safety, training, maintainability and supportability, habitability and environment. The goal is to provide an overview of the implementation process of HSI in the Gateway Program as an example for other Programs/Projects/Missionsthat are looking to implement HSI.
Jackelynne Silva-Martinez↗
The Need for V&V in Reuse-Based Software Engineering
V&V is currently 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 entire' domain or product line rather than a critical processing, as early as possible during the development process. The system application provides the context under which the software artifacts are validated. engineering. This paper describes a framework that extends V&V from an individual application system to a product line of systems that are developed within an architecture-based software engineering environment. This framework includes the activities of traditional application-level V&V, and extends these activities 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 activities.
Addy, Edward A.↗
Description of an oscillating flow test program
A description of the University of Minnesota Oscillating Flow Test Program is presented. The rationale for isolating the oscillating flow effect for separate study, the objectives of the test program, and the program design criteria are presented along with a description of the test facility and the test plan. The program test domain covers almost the entire operating domain of Stirling engine heat exchangers expressed in terms of the appropriate dimensionless parameters. Phenomena important to Stirling engine performance which are not simulated in the test program are also discussed. Computer analysis results are used to predict apparatus performance.
Seume, J. R.↗
An overview of very high level software design methods
Very High Level design methods emphasize automatic transfer of requirements to formal design specifications, and/or may concentrate on automatic transformation of formal design specifications that include some semantic information of the system into machine executable form. Very high level design methods range from general domain independent methods to approaches implementable for specific applications or domains. Applying AI techniques, abstract programming methods, domain heuristics, software engineering tools, library-based programming and other methods different approaches for higher level software design are being developed. Though one finds that a given approach does not always fall exactly in any specific class, this paper provides a classification for very high level design methods including examples for each class. These methods are analyzed and compared based on their basic approaches, strengths and feasibility for future expansion toward automatic development of software systems.
Asdjodi, Maryam↗
Strategies for adding adaptive learning mechanisms to rule-based diagnostic expert systems
Rule-based diagnostic expert systems can be used to perform many of the diagnostic chores necessary in today's complex space systems. These expert systems typically take a set of symptoms as input and produce diagnostic advice as output. The primary objective of such expert systems is to provide accurate and comprehensive advice which can be used to help return the space system in question to nominal operation. The development and maintenance of diagnostic expert systems is time and labor intensive since the services of both knowledge engineer(s) and domain expert(s) are required. The use of adaptive learning mechanisms to increment evaluate and refine rules promises to reduce both time and labor costs associated with such systems. This paper describes the basic adaptive learning mechanisms of strengthening, weakening, generalization, discrimination, and discovery. Next basic strategies are discussed for adding these learning mechanisms to rule-based diagnostic expert systems. These strategies support the incremental evaluation and refinement of rules in the knowledge base by comparing the set of advice given by the expert system (A) with the correct diagnosis (C). Techniques are described for selecting those rules in the in the knowledge base which should participate in adaptive learning. The strategies presented may be used with a wide variety of learning algorithms. Further, these strategies are applicable to a large number of rule-based diagnostic expert systems. They may be used to provide either immediate or deferred updating of the knowledge base.
Stclair, D. C.↗