Search NASA⌕ Search

SEARCH · Search NASA

Results for “Interface 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 379 records · Page 21
All sourcesNASA NTRSDOE OSTI
NASA NTRS2009

Engine Gimbal Requirements for Ground Testing of J-2X

Based on the Apollo-era J-2 that powered the second and third stages of the Saturn V, the current J-2X is the liquid hydrogen and oxygen high-altitude rocket engine in development for both the Ares I Upper Stage and Ares V Earth Departure Stage. During my summer 2009 internship, J-2X was at a stage in its design maturity where verification testing needed to be considered for the benefit of adequate test facility preparation. My task was to focus on gimbal requirements and gimbal related hot-fire test plans. Facility capabilities were also of interest, specifically for hot-fire testing slated to occur at test stands A-1, A-2, and A-3 at Stennis Space Center(SSC) in Bay St. Louis, Mississippi. Gimbal requirements and stage interface conditions were investigated by applying a top-to-bottom systems engineering approach, which involved system level requirements, engine level requirements from both government and engine contractor perspectives, component level requirements, and the J-2X to Upper Stage and Earth Departure Stage interface control documents. Previous hydrogen and oxygen liquid rocket engine gimbal verification methods were researched for a glimpse at lessons learned. Discussion among the J-2X community affected by gimballing was organized to obtain input relative to proper verification of their respective component. Implementing suggestions such as gimbal pattern, angulated dwell time, altitude testing options, power level, and feed line orientation, I was able to match tests to test stands in the A Complex at SSC. Potential test capability gaps and risks were identified and pursued. The culmination of all these efforts was to coordinate with SSC to define additional facility requirements for both the A-3 altitude test stand that is currently under construction and the A-1 sea level test stand which is being renovated

Kovalcik, Julia↗
NASA NTRS2010

GLobal Integrated Design Environment (GLIDE): A Concurrent Engineering Application

The GLobal Integrated Design Environment (GLIDE) is a client-server software application purpose-built to mitigate issues associated with real time data sharing in concurrent engineering environments and to facilitate discipline-to-discipline interaction between multiple engineers and researchers. GLIDE is implemented in multiple programming languages utilizing standardized web protocols to enable secure parameter data sharing between engineers and researchers across the Internet in closed and/or widely distributed working environments. A well defined, HyperText Transfer Protocol (HTTP) based Application Programming Interface (API) to the GLIDE client/server environment enables users to interact with GLIDE, and each other, within common and familiar tools. One such common tool, Microsoft Excel (Microsoft Corporation), paired with its add-in API for GLIDE, is discussed in this paper. The top-level examples given demonstrate how this interface improves the efficiency of the design process of a concurrent engineering study while reducing potential errors associated with manually sharing information between study participants.

McGuire, Melissa L.↗
NASA NTRS2000

Structural Modeling Using "Scanning and Mapping" Technique

Supported by NASA Glenn Center, we are in the process developing a structural damage diagnostic and monitoring system for rocket engines, which consists of five modules: Structural Modeling, Measurement Data Pre-Processor, Structural System Identification, Damage Detection Criterion, and Computer Visualization. The function of the system is to detect damage as it is incurred by the engine structures. The scientific principle to identify damage is to utilize the changes in the vibrational properties between the pre-damaged and post-damaged structures. The vibrational properties of the pre-damaged structure can be obtained based on an analytic computer model of the structure. Thus, as the first stage of the whole research plan, we currently focus on the first module - Structural Modeling. Three computer software packages are selected, and will be integrated for this purpose. They are PhotoModeler-Pro, AutoCAD-R14, and MSC/NASTRAN. AutoCAD is the most popular PC-CAD system currently available in the market. For our purpose, it plays like an interface to generate structural models of any particular engine parts or assembly, which is then passed to MSC/NASTRAN for extracting structural dynamic properties. Although AutoCAD is a powerful structural modeling tool, the complexity of engine components requires a further improvement in structural modeling techniques. We are working on a so-called "scanning and mapping" technique, which is a relatively new technique. The basic idea is to producing a full and accurate 3D structural model by tracing on multiple overlapping photographs taken from different angles. There is no need to input point positions, angles, distances or axes. Photographs can be taken by any types of cameras with different lenses. With the integration of such a modeling technique, the capability of structural modeling will be enhanced. The prototypes of any complex structural components will be produced by PhotoModeler first based on existing similar components, then passed to AutoCAD for modification and correction of any discrepancies seen in the Photomodeler version of the 3Dmodel. These three software packages are fully compatible. The DXF file can be used to transfer drawings among those packages. To begin this entire process, we are using a small replica of an actual engine blade as a test object. This paper introduces the accomplishment of our recent work.

Amos, Courtney L.↗
NASA NTRS1982

Stirling Laboratory Research Engine: Preprototype configuration report

The concept of a simple Stirling research engine that could be used by industrial, university, and government laboratories was studied. The conceptual and final designs, hardware fabrication and the experimental validation of a preprototype stirling laboratory research engine (SLRE) were completed. Also completed was a task to identify the potential markets for research engines of this type. An analytical effort was conducted to provide a stirling cycle computer model. The versatile engine is a horizontally opposed, two piston, single acting stirling engine with a split crankshaft drive mechanism; special instrumentation is installed at all component interfaces. Results of a thermodynamic energy balance for the system are reported. Also included are the engine performance results obtained over a range of speeds, working pressures, phase angles and gas temperatures. The potential for a stirling research engine to support the laboratory requirements of educators and researchers was demonstrated.

Hoehn, F. W.↗
NASA NTRS1985

COSMIC/NASTRAN-PATRAN Interface

A three dimensional solid modeling and finite element pre and postprocessing program, PATRAN, uses the latest interactive computer graphics technology, provides a visual means to define a finite element model and its environment, and reviews its resultant model behavior. The capabilities provided by the PATRAN-COSMIC/NASTRAN interface are discussed. While the translator capabilities give some indication of the interface quality between the two programs, there are other attributes to be considered. The ideal interface would be a user transparent union of the two programs so that the engineer could move from one program to the other fluently and naturally. Hence, a valid assessment of the interface completeness must consider how close the current capabilities are to the idealized case. An example problem is presented to demonstrate how COSMIC/NASTRAN and PATRAN can be used together to meet the requirements of an actual engineering application.

Libby, D. H.↗
NASA NTRS2005

Introduction to Flight Test Engineering [Introduction Aux Techniques Des Essais En Vol]

Flight test is at the core of what organizations must do in order to validate the operation and systems on an aircraft. While the AGARDograph series 300 and 160 series deal with aspects of this testing, this volume pulls it all together as an introduction to the process required to do effective flight test engineering. This volume was originally published in 1995. Its utility has been proven in that many flight test organizations and universities have requested copies for their engineers and students. It was felt that re-issuing it in a new format designed for electronic publication would be valuable to the community. This second printing changes none of the text, but rather reformats it. All the original references to AGARD (instead of RTO) are left in place so that none of the flavor of the original publication is lost. This is the Introductory Volume to the Flight Test Techniques Series. It is a general introduction to the various activities and aspects of Flight Test Engineering that must be considered when planning, conducting, and reporting a flight test program. Its main intent is to provide a broad overview to the novice engineer or to other people who have a need to interface with specialists within the flight test community. The first two Sections provide some insight into the question of why flight test and give a short history of flight test engineering. Sections 3 through 10 deal with the preparation for flight testing. They provide guidance on the preliminary factors that must be considered; the composition of the test team; the logistic support requirements; the instrumentation and data processing requirements; the flight test plan; the associated preliminary ground tests; and last, but by no means least, discuss safety aspects. Sections 11 through 27 describe the various types of flight tests that are usually conducted during the development and certification of a new or modified aircraft type. Each Section offers a brief introduction to the topic under consideration, and the nature and the objectives of the tests to be conducted. It lists the test instrumentation (and, where appropriate, other test equipment and facilities) required, describes the test maneuvers to be executed, and indicates the way in which the test data is selected, analyzed, and presented. The various activities that should take place between test flights are presented next. Items that are covered are: who to debrief; what type of reports to send where: types of data analysis required for next flight; review of test data to make a comparison to predicted data and some courses of action if there is not good agreement; and comments on selecting the next test flight. The activities that must take place upon completion of the test program are presented. The types of reports and briefings that should take place and a discussion of some of the uses of the flight test data are covered. A brief forecast is presented of where present trends may be leading.

Test facilities↗
NASA NTRSDate not supplied

The Death of Airmanship: The Urgent Need to Understand Pilot Skills and Knowledge

Aviation awards a special name—airmanship—for the quality of being highly competent in foundational piloting skills, which seem to comprise primarily judgment, decision making, stick-and-rudder skills, and a bit of intuition. The term, which has a mystical quality, has historically resisted analysis; airmanship is acquired solely through experience. The graying of the Boomers and the extreme turbulence of the last few years in commercial aviation have led to a significant loss of those pilots who started out in simpler, round-dial airplanes and made a tortured transition to glass. Those pilots were comfortable disengaging the autopilot at any time, and more importantly, they continued to stay mentally engaged with flight and systems management even as automation continued to encroach on traditional pilot roles. As an industry, we need to prepare for the loss of these pilots by understanding the elements of airmanship and finding a way to replace the competency. The goal is to eliminate “airmanship” by understanding it...by demystifying it. Human factors/cognitive engineering offers tools and methods to develop a system interface that supports skilled performance from the human/technology team. In this presentation, I will talk about my efforts to understand the elements of skilled performance so that they can be trained, or supported by the interface in a seamless manner Specific topics will include the limits of SOP, monitoring for flight path management, alerting non-normals, and autoflight/mode confusion.

pilot skills↗
NASA NTRSDate not supplied

Aero-Engines AI - A Machine-Learning App for Aircraft Engine Concepts Assessment

Effective deployment of machine-learning (ML) models could drive a high level of efficiency in aircraft engine conceptual design. Aero-Engines AI is a user-friendly app that has been created to deploy trained machine-learning (ML) models to assess aircraft engine concepts. It was created using tkinter, a GUI (graphical user interface) module that is built into the standard Python library. Employing tkinter greatly facilitates the sharing of ML application as an executable file which can be run on Windows machines (without the need to have Python or any library installed). The app gets user input for a turbofan design, preprocesses the input data, and deploys trained ML models to predict turbofan thrust specific fuel consumption (TSFC), engine weight, core size, and turbomachinery stage-counts. The ML predictive models were built by employing supervised deep-learning and K-nearest neighbor regression algorithms to study patterns in an existing open-source database of production and research turbofan engines. They were trained, cross-validated, and tested in Keras, an open-source neural networks API (application programming interface) written in Python, with TensorFlow (Google open-source artificial intelligence library) serving as the backend engine. The smooth deployment of these ML models using the app shows that Aero-Engines AI is an easy-touse and a time-saving tool for aircraft engine design-space exploration during the conceptual design stage. Current version of the app focuses on the performance prediction of conventional turbofans. However, the scope of the app can easily be expanded to include other engine types (such as turboshaft and hybrid-electric systems) after their ML models are developed. Overall, the use of a machine-learning app for aircraft engine concept assessment represents a promising area of development in aircraft engine conceptual design.

machine learning↗
NASA NTRS2023

Aero-Engines AI - A Machine-Learning App for Aircraft Engine Concepts Assessment

Effective deployment of machine-learning (ML) models could drive a high level of efficiency in aircraft engine conceptual design. Aero-Engines AI is a user-friendly app that has been created to deploy trained machine-learning (ML) models to assess aircraft engine concepts. It was created using tkinter, a GUI (graphical user interface) module that is built into the standard Python library. Employing tkinter greatly facilitates the sharing of ML application as an executable file which can be run on Windows machines (without the need to have Python or any library installed). The app gets user input for a turbofan design, preprocesses the input data, and deploys trained ML models to predict turbofan thrust specific fuel consumption (TSFC), engine weight, core size, and turbomachinery stage-counts. The ML predictive models were built by employing supervised deep-learning and K-nearest neighbor regression algorithms to study patterns in an existing open-source database of production and research turbofan engines. They were trained, cross-validated, and tested in Keras, an open-source neural networks API (application programming interface) written in Python, with TensorFlow (Google open-source artificial intelligence library) serving as the backend engine. The smooth deployment of these ML models using the app shows that Aero-Engines AI is an easy-touse and a time-saving tool for aircraft engine design-space exploration during the conceptual design stage. Current version of the app focuses on the performance prediction of conventional turbofans. However, the scope of the app can easily be easily expanded to include other engine types (such as turboshaft and hybrid-electric systems) after their ML models are developed. Overall, the use of a machine-learning app for aircraft engine concept assessment represents a promising area of development in aircraft engine conceptual design.

machine learning↗
NASA NTRS2014

A Modular Framework for Modeling Hardware Elements in Distributed Engine Control Systems

Progress toward the implementation of distributed engine control in an aerospace application may be accelerated through the development of a hardware-in-the-loop (HIL) system for testing new control architectures and hardware outside of a physical test cell environment. One component required in an HIL simulation system is a high-fidelity model of the control platform: sensors, actuators, and the control law. The control system developed for the Commercial Modular Aero-Propulsion System Simulation 40k (C-MAPSS40k) provides a verifiable baseline for development of a model for simulating a distributed control architecture. This distributed controller model will contain enhanced hardware models, capturing the dynamics of the transducer and the effects of data processing, and a model of the controller network. A multilevel framework is presented that establishes three sets of interfaces in the control platform: communication with the engine (through sensors and actuators), communication between hardware and controller (over a network), and the physical connections within individual pieces of hardware. This introduces modularity at each level of the model, encouraging collaboration in the development and testing of various control schemes or hardware designs. At the hardware level, this modularity is leveraged through the creation of a Simulink(R) library containing blocks for constructing smart transducer models complying with the IEEE 1451 specification. These hardware models were incorporated in a distributed version of the baseline C-MAPSS40k controller and simulations were run to compare the performance of the two models. The overall tracking ability differed only due to quantization effects in the feedback measurements in the distributed controller. Additionally, it was also found that the added complexity of the smart transducer models did not prevent real-time operation of the distributed controller model, a requirement of an HIL system.

numerical simulation↗
NASA NTRS2015

A Modular Framework for Modeling Hardware Elements in Distributed Engine Control Systems

Progress toward the implementation of distributed engine control in an aerospace application may be accelerated through the development of a hardware-in-the-loop (HIL) system for testing new control architectures and hardware outside of a physical test cell environment. One component required in an HIL simulation system is a high-fidelity model of the control platform: sensors, actuators, and the control law. The control system developed for the Commercial Modular Aero-Propulsion System Simulation 40k (C-MAPSS40k) provides a verifiable baseline for development of a model for simulating a distributed control architecture. This distributed controller model will contain enhanced hardware models, capturing the dynamics of the transducer and the effects of data processing, and a model of the controller network. A multilevel framework is presented that establishes three sets of interfaces in the control platform: communication with the engine (through sensors and actuators), communication between hardware and controller (over a network), and the physical connections within individual pieces of hardware. This introduces modularity at each level of the model, encouraging collaboration in the development and testing of various control schemes or hardware designs. At the hardware level, this modularity is leveraged through the creation of a SimulinkR library containing blocks for constructing smart transducer models complying with the IEEE 1451 specification. These hardware models were incorporated in a distributed version of the baseline C-MAPSS40k controller and simulations were run to compare the performance of the two models. The overall tracking ability differed only due to quantization effects in the feedback measurements in the distributed controller. Additionally, it was also found that the added complexity of the smart transducer models did not prevent real-time operation of the distributed controller model, a requirement of an HIL system.

propulsion simulation↗
NASA NTRS2002

High-Temperature Gas Sensor Array (Electronic Nose) Demonstrated

The ability to measure emissions from aeronautic engines and in commercial applications such as automotive emission control and chemical process monitoring is a necessary first step if one is going to actively control those emissions. One single sensor will not give all the information necessary to determine the chemical composition of a high-temperature, harsh environment. Rather, an array of gas sensor arrays--in effect, a high-temperature electronic "nose"--is necessary to characterize the chemical constituents of a diverse, high-temperature environment, such as an emissions stream. The signals produced by this nose could be analyzed to determine the constituents of the emission stream. Although commercial electronic noses for near-room temperature applications exist, they often depend significantly on lower temperature materials or only one sensor type. A separate development effort necessary for a high-temperature electronic nose is being undertaken by the NASA Glenn Research Center, Case Western Reserve University, Ohio State University, and Makel Engineering, Inc. The sensors are specially designed for hightemperature environments. A first-generation high-temperature electronic nose has been demonstrated on a modified automotive engine. This nose sensor array was composed of sensors designed for hightemperature environments fabricated using microelectromechanical-systems- (MEMS-) based technology. The array included a tin-oxide-based sensor doped for nitrogen oxide (NOx) sensitivity, a SiC-based hydrocarbon (CxHy) sensor, and an oxygen sensor (O2). These sensors operate on different principles--resistor, diode, and electrochemical cell, respectively--and each sensor has very different responses to the individual gases in the environment. A picture showing the sensor head for the array is shown in the photograph on the left and the sensors installed in the engine are shown in the photograph on the right. Electronics are interfaced with the sensors for temperature control and signal conditioning, and packaging designed for high temperatures is necessary for the array to survive the engine environment.

Hunter, Gary W.↗
NASA NTRSDate not supplied

Presenting Model-Based Systems Engineering Information to Non-Modelers

NASA’s Human Research Program’s (HRP) Exploration Medical Capability (ExMC) Element adopted Systems Engineering (SE) principles and Model Based Systems Engineering (MBSE) tools to capture the system functions, system architecture, requirements, interfaces, and clinical capabilities for a future exploration medical system. There are many different stakeholders who may use the information in the model: systems engineers, requirement engineers, clinicians (doctors, nurses, and pharmacists), scientists, and program managers. Many of these individuals do not have access to MBSE modeling toolsor have never used these tools. Many of these individuals (clinicians, scientists, even program managers)may have no experience with SE in general let alone interpreting a systems model. The challenge faced by ExMC was how to present the content in the model to non-modelers in a way they could understand with limited to no training in MBSE or the Systems Modeling Language (SysML) without using the modeling tool. Therefore, from the model, ExMC created an HTML report that is accessible to anyone with a browser. When creating the HTML report, the ExMC SE team talked to stakeholders and received their feedback on what content they wanted and how to display this content. Factoring in feedback, the report arranges the content in a way that not only directs readers through the SE process taken to derive the requirements, but also helps them to understand the fundamental steps in an SE approach. The report includes links to source information (i.e., NASA documentation that describes levels of care) and other SE deliverables (e.g., Concept of Operations). These links were provided to aid in the understanding of how the team created this content through a methodical SE approach. This paper outlines the process used to develop the model, the data chosen to share with stakeholders, many of the model elements used in the report, the review process stakeholders followed, the comments received from the stakeholders, and the lessons ExMC learned through producing this HTML report.

Jeff Cohen↗
NASA NTRSDate not supplied

Presenting Model-Based Systems Engineering Information to Non-Modelers

NASA’s Human Research Program’s (HRP) Exploration Medical Capability (ExMC) Element adopted Systems Engineering (SE) principles and Model Based Systems Engineering (MBSE) tools to capture the system functions, system architecture, requirements, interfaces, and clinical capabilities for a future exploration medical system. There are many different stakeholders who may use the information in the model: systems engineers, clinicians (physicians, nurses, and pharmacists), scientists, and program managers. Many of these individuals do not have access to MBSE modeling tools or have never used these tools. Many of these individuals (clinicians, scientists, even program managers) may have no experience with SE in general let alone interpreting a systems model. The challenge faced by ExMC was how to present the content in the model to non-modelers in a way they could understand with limited to no training in MBSE or the Systems Modeling Language (SysML) without using the modeling tool. Therefore, from the model, ExMC created an HTML report that is accessible to anyone with a browser. When creating the HTML report, the ExMC SE team talked to stakeholders and received their feedback on what content they wanted and how to display this content. Factoring in feedback, the report arranges the content in a way that not only directs readers through the SE process taken to derive the requirements, but also helps them to understand the fundamental steps in an SE approach. The report includes links to source information (i.e., NASA documentation that describes levels of care) and other SE deliverables (e.g., Concept of Operations). These links were provided to aid in the understanding of how the team created this content through a methodical SE approach. This paper outlines the process used to develop the model, the data chosen to share with stakeholders, many of the model elements used in the report, the review process stakeholders followed, the comments received from the stakeholders, and the lessons ExMC learned through producing this HTML report.1Trade names and trademarks are used in this report for identification only. Their usage does not constitute an official endorsement, either expressed or implied, by the National Aeronautics and Space Administration.

Jeffrey R. Cohen↗
NASA NTRSDate not supplied

How ExMC Communicates a System Model to Non-Modelers

NASA’s Human Research Program (HRP) Exploration Medical Capability (ExMC) Element adopted Systems Engineering (SE) principles and Model Based Systems Engineering (MBSE) tools to capture the system functions, system architecture, requirements, interfaces, and clinical capabilities for a future exploration medical system. There are many different stakeholders who may use the information in the model: systems engineers, clinicians (physicians, nurses, and pharmacists), scientists, and mission planners. Many of these stakeholders have neither access to MBSE modeling tools nor experience with SE modeling techniques. The challenge faced by ExMC SE team was how to present the content in the model to non-modelers in a way they would understand the content with limited training in MBSE and without using the modeling tool. ExMC SE team created a Hypertext Markup Language (HTML) report that shows key model content and is accessible to anyone with a browser. When creating the HTML report, the ExMC SE received stakeholder feedback on what content they wanted and how to display this content. Incorporating this feedback, the report arranges the content in a way that directs readers through the SE process taken to derive the requirements and helps them to understand the fundamental steps in an SE approach. The report includes links to source information (e.g., NASA documentation that describes levels of care) and other SE products (e.g., Concept of Operations). These links were provided to aid in the understanding of how the team created this content through a methodical SE approach. This presentation outlines the process used to develop the model, the data chosen to share with stakeholders, many of the model elements used in the report, the review process stakeholders followed, the comments received from the stakeholders, and the lessons ExMC learned through producing this HTML report.

J. Cohen↗
NASA NTRSDate not supplied

Presenting Model-Based Systems Engineering Information to Non-Modelers

NASA’s Human Research Program’s (HRP) Exploration Medical Capability (ExMC) Element adopted Systems Engineering (SE) principles and Model Based Systems Engineering (MBSE) tools to capture the system functions, system architecture, requirements, interfaces, and clinical capabilities for a future exploration medical system. There are many different stakeholders who may use the information in the model: systems engineers, clinicians (physicians, nurses, and pharmacists), scientists, and program managers. Many of these individuals do not have access to MBSE modeling tools or have never used these tools. Many of these individuals (clinicians, scientists, even program managers) may have no experience with SE in general let alone interpreting a systems model. The challenge faced by ExMC was how to present the content in the model to non-modelers in a way they could understand with limited to no training in MBSE or the Systems Modeling Language (SysML) without using the modeling tool. Therefore, from the model, ExMC created an HTML report that is accessible to anyone with a browser. When creating the HTML report, the ExMC SE team talked to stakeholders and received their feedback on what content they wanted and how to display this content. Factoring in feedback, the report arranges the content in a way that not only directs readers through the SE process taken to derive the requirements, but also helps them to understand the fundamental steps in an SE approach. The report includes links to source information (i.e., NASA documentation that describes levels of care) and other SE deliverables (e.g., Concept of Operations). These links were provided to aid in the understanding of how the team created this content through methodical SE approach. This paper outlines the process used to develop the model, the data chosen to share with stakeholders, many of the model elements used in the report, the review process stakeholders followed, the comments received from the stakeholders, and the lessons ExMC learned through producing this HTML report.

Jeffrey R. Cohen↗
NASA NTRS2011

Portable Life Support System: PLSS 101

This presentation reviewed basic interfaces and considerations necessary for prototype suit hardware integration from an advanced spacesuit engineer perspective during the early design and test phases. The discussion included such topics such as the human interface, suit pass-throughs, keep-out zones, hardware form factors, subjective feedback from suit tests, and electricity in the suit.

Thomas, Gretchen A.↗
NASA NTRS2014

A Modular Framework for Modeling Hardware Elements in Distributed Engine Control Systems

Progress toward the implementation of distributed engine control in an aerospace application may be accelerated through the development of a hardware-in-the-loop (HIL) system for testing new control architectures and hardware outside of a physical test cell environment. One component required in an HIL simulation system is a high-fidelity model of the control platform: sensors, actuators, and the control law. The control system developed for the Commercial Modular Aero-Propulsion System Simulation 40k (40,000 pound force thrust) (C-MAPSS40k) provides a verifiable baseline for development of a model for simulating a distributed control architecture. This distributed controller model will contain enhanced hardware models, capturing the dynamics of the transducer and the effects of data processing, and a model of the controller network. A multilevel framework is presented that establishes three sets of interfaces in the control platform: communication with the engine (through sensors and actuators), communication between hardware and controller (over a network), and the physical connections within individual pieces of hardware. This introduces modularity at each level of the model, encouraging collaboration in the development and testing of various control schemes or hardware designs. At the hardware level, this modularity is leveraged through the creation of a Simulink (R) library containing blocks for constructing smart transducer models complying with the IEEE 1451 specification. These hardware models were incorporated in a distributed version of the baseline C-MAPSS40k controller and simulations were run to compare the performance of the two models. The overall tracking ability differed only due to quantization effects in the feedback measurements in the distributed controller. Additionally, it was also found that the added complexity of the smart transducer models did not prevent real-time operation of the distributed controller model, a requirement of an HIL system.

numerical simulation↗