Framework for Distributed Engine Control System for

2216007

Framework for Distributed Engine Control System for Sampled-data Systems with Uncertain Time-varying Sampling Intervals and Delays with State Estimations

Rama K. Yedavalli1 , M.S. Zein-Sabatto2, and Alireza R. Behbahani3 1 Ohio State University 2 Tennessee State University 3 Air Force Research Laboratory

ABSTRACT Aircraft Propulsion Systems, in particular, the gas turbine engines have been traditionally designed with centralized control architecture. Recently, Distributed Architectures for Engine Control have been proposed which offer significant benefits over the centralized architecture in terms of reliability, modularity, adaptability and overall improved engine performance. Thus Distributed Engine Control and Simulation (DECS) has emerged as an important milestone in the future of aircraft turbine engine control, diagnostics, and health management strategies. However, to make these a reality, significant new challenges have to be met and thus considerable new research needs to be carried out in the above areas. This is due to the fact that the localization of the electronic control components in the distributed communication network changes the dynamic nature of the system. The communication signal in this localized network could suffer from transmission delays and occasional loss of data packets. In essence, the resulting overall system can be considered to be a discrete controller that relays commands to the local actuators at set intervals based on the incoming sampled data from the sensors. The underlying physical engine retains its continuous dynamics and the physics of the engine model does not vary. The coupling between the discrete controller, delay in transmission and uncertainties in engine dynamics lead to an uncertain sampled system with time delays. Thus analyzing and synthesizing control, diagnostics and health management strategies under the new paradigm of uncertain, sampled data, time delay systems becomes a challenging task. This paper is a contribution in this direction. With this backdrop, this paper presents an overview of the current collaborative research being carried out by the team of researchers from the Ohio State University and Tennessee State University with technical monitoring and support by the Air Force Research Laboratory. Specifically, new research results in state estimator design, distributed control design, and simulation are presented. 1.0 INTRODUCTION Advanced gas turbine engines have played an important role in establishing air dominance of the United States Armed Forces and have also greatly revolutionized air travel. In recent years, increasingly sophisticated electronics have been added to the engine control system for addressing the needs of increased performance, wider operability, and reduced life-cycle cost. Research is being carried out to

1 American Institute of Aeronautics and Astronautics

make aircraft propulsion systems more intelligent, reliable, self-diagnostic, self-prognostic, self-optimizing, and mission adaptable while also reducing engine acquisition and maintenance costs. This has driven the need for a new, advanced control system based on a distributed architecture. Distributed Engine Control (DEC) is extensively studied in the literature [1-5]. Reduction of engine control system weight, modularity, obsolescence reduction, scalability, and reduction in operational and maintenance cost are some of the perceived benefits of DEC. As the performance of the DEC becomes dependent on the performance of the communication networks an appropriate selection of communication architecture is becoming an important task of the development of control systems for turbine engines. Also, since aircraft engine control systems are safety-critical systems, the selected communication protocol should offer high reliability with fault tolerance and should be flight-certified. In this research, we have adapted the AFRL generic engine control system to the distributed architecture and subjected to network faults including time delays and data loss. The effect of these network faults on the engine control performance were evaluated through simulations performed using the Modular Aero-Propulsion System Simulation (MPASS-40k) turbine engine model.

Distributed turbine engine control architecture enables the use of advanced control algorithms along with achieving weight reduction, improvement in performance and lower life cycle cost. The performance of distributed engine control system is predominantly dependent on the performance of communication bus. Communication network faults like limited bandwidth, transmission delays and data loss can limit or even degrade the performance of distributed engine control system. What is required is to analyze and synthesize a robust distributed controller to guarantee desired engine performance under network faults for full envelope operation. Hence, the goal of the conducted research was to analyze and synthesize a robust distributed controller to guarantee desired engine performance under network faults for full envelope operation. Specifically the technical objective of the conducted research was to investigate the stability and performance of the turbine engine distributed systems under communication constraints like time delays, data loss and bandwidth limitations using hardware-in-loop simulation experiments. Four research tasks were identified and performed. The control methodologies were verified using the MAPSS Simulator of the Distribution Engine Control. We adapted the AFRL generic engine control system to the distributed architecture and subjected to network faults including time delays and data loss. The effects of these network faults on the engine control performance were evaluated through simulations performed using the MAPSS-40k engine simulator. The paper is organized as follows. In the next section (section 2) we briefly review the background material needed for the research results presented this paper. In section 3, we present the work carried out on the study of turbine engine over full flight envelope and the use of predictive control for information recovery of faulty communication networks in Distributed Networked Control Systems (DNCS). Then in section 4, we present results on robust control design under distributed architecture using AFRL turbine engine model. Finally section 5 offers a summary and conclusions drawn from this research Thus the paper presents useful results for Distributed Engine Control via Uncertain, Sampled Data, Time Delay Systems framework.

2.0 BACKGROUND OF THE RESEARCH WORK

In turbine engine control strategies, the centralized control architecture has been a legacy. This control architecture proved to be very successful with some concerns such as the total weight of the control system relative to the engine weight [6]. Currently, distributed control architectures are being explored as an alternative. The potential benefits of distributed engine control architectures in aero-engine are articulated in [7]. Such benefits are weight reduction, performance improvement and overall cost reduction. In this architecture however there are some technical challenges such as acquisition of high temperature electronics and real-time communication for coordination and synchronization of data. Despite the attention given to the distributed control architectures and their benefits, it has rarely been implemented in practice. Much of is due to maturity of the supporting technologies [8].


In the centralized control architecture weight is primarily driven by location of the control elements [9]. The weight of the controller is due to the design standard of utmost reliability which is attained by using dual-redundancy. Thus results to an increase in weight after the control elements are connected to the FADEC as a result of number of conductors needed. Currently, the weight is minimized by locating the FADEC as close to the control elements as possible [9]. It has been noted in [9] that the overall weight can be reduced by the transformation of the engine control from centralized to distributed architecture. It was further noted that in this transformation no new sensors or actuator are needed. The distribution of on-board electronics close to the sensing elements or actuator will reduce the number of conductors needed to enable communication between sensors and actuator of the engine controller. The importance of distributed architecture for turbine engine control is well discussed in the literature [10-13]. Distributed turbine engine control architecture enables the use of advanced control algorithms along with achieving weight reduction, improvement in performance and lower life cycle cost. The performance of distributed engine control system is predominantly dependent on the performance of communication bus. Communication network faults like limited bandwidth, transmission delays and data loss can limit or even degrade the performance of distributed engine control system. The proposing research teams at the Ohio State University and Tennessee State University have shown in their previous studies that network fault can cause the fan or core shaft speed or turbine inlet temperature to exceed their limits and developed a methodology to design a robust controller to achieve acceptable performance in the presence of those perturbations [14, 15, 16]. In this collaborative research effort several further advancements to the existing turbine engines control were achieved. In Section 3, a Distributed Networked Control System (DNCS) utilizing a predictive control strategy was developed and implemented on turbine engine simulation model. As result, the turbine engine distributed control system was implemented in the form of individual smart processing nodes. These smart nodes (local controllers) consisted of individual communication modules and processing units that allow for local control actions. Signals between the engine’s sensors and actuators are transmitted across a dedicated communication network. A predictive control strategy was also developed and implemented utilizing local state estimators providing the needed information for the individual feedback controllers. Three competing estimation strategies were developed and implemented, i.e., Kalman filter, parametric auto-regressive predictor and an artificial intelligent neuro-fuzzy inference approach. Detail development and implementation of the predictive control strategies are presented in this section. Test results obtained from the half (one side) and the full (two sides) implementation of the communication network of the distributed networked control system showed performance robustness against network effects and failures. The distributed network control system was able to maintain acceptable engine performance with failures in the communication network in the form of static and random transmission delay time. Such robustness of the engine performance under moderate and severe network failures was attributed to the success of the state estimator in estimating the needed engine states feedback information for the local distributed controller. We found that the neuro-fuzzy inference approach to predictive control provided superior performance, compared to the other two approaches, in estimating the missing/lost feedback information due to communication network failures. As a result, the adapted predictive control strategy utilizing the neuro-fuzzy inference system is the recommended technology for the future engine distributed network control system. This constitutes the main contribution and research finding of this part of the research effort. In Section 4, the research focus was to study the impact of network faults in the implementation of distributed engine control architecture on the engine full flight envelope. The approach to achieve this goal consisted of choosing control architecture; modify an existing engine to include the presence of network faults; simulating the engine at several different operating points throughout the flight envelope; and finally analyzing the results to help characterize the impact of network faults on future engines and their control systems. A controller was designed to take into account faults in the engine model. The controller used an observer to estimate the state values that were lost during network transmission failures. To test the controller’s ability to stabilize the system, the engine simulation was started with non-nominal operating conditions and had to slow the engine down to its set point. The system architecture worked well and the system was able to regulate the engine using only normal design methods. Using the observer designed above to account for transmission faults led to improved stability of the engine. It was observed that if the


transmission error continues past the maximum expected delay (MATI) of the network, then it will cause the engine model to become unstable. This instability caused by inaccuracies in the engine linear model. However, because the error was minimal, the controller was still able to stabilize the system from the initial perturbed state.

3.0 STUDY OF TURBINE ENGINE OVER FULL FLIGHT ENVELOP USING MAPSS TURBINE ENGINE MODEL In this section of the report we have addressed the limitation imposed by communication network failures in the distributed network control systems of turbine engines. A predictive control strategy is used in addressing this limitation and in the development of smart processing nodes as the adapted solution. The developed smart processing nodes are then used to construct a distributed networked control system for turbine engines with ability to maintain acceptable performance despite certain communication network failures. In Section 3.1 we present a brief review of the technical approach and the theoretical aspects used in the development of the distributed network control systems. Then, a detailed development of communication network for the distributed control system is reported along with the development steps of the different state estimators and the associated prediction strategies are all presented in Section 3.2. Finally, testing and performance evaluation of the distributed networked control system with predictive control strategy is conducted and the results are reported in Section 3.3. This part of the collaborative research effort was led by the TSU research team and assisted by the OSU group. 3.1 THEORETICAL FOUNDATION AND TECHNICAL APPROACH OF DNCS 3.1.1 COMMUNICATION NETWORKS IN DNCS Networked Control Systems (NCS) is an area of controls that expands the common control feedback structure to include distributed components implemented on physically separate hardware [17]. With the consideration of these networked interfaces as part of the control strategy, NCS become an integration of three areas of study: control systems, communication networks, and information theory [18]. Many challenges arise with this expansion of the control theory, and networked control systems are designed with these challenges in mind--some being more application--sensitive than others. Of current consideration is the inclusion of distributed control theory. Contrary to decentralized control strategies where all control efforts are processed on a single global processor, a distributed control system utilizes independently acting local control modules [19]. Local control units are specialized so that the feedback control strategy can be simplified to whatever grade the designer wishes by dividing the control efforts among many locally executed smart processing nodes. For full control system distribution, both the computational efforts and the control efforts will be distributed among these processing nodes. Distribution of the system control involves the reduction of control effort to only a subset of the I/O relations, rather than the complete combination of relations used in classical feedback control strategy. The system will retain the full-state feature, but looses the full control matrix structure. It is precisely this distributive property that transforms a network control system into a Distributed Networked Control System (DNCS). The general system architecture of DNCS is presented in Figure 1. In designing DNCS, two primary challenges arise that must be addressed in order to have an operationally stable control system. First, the design of a Full State Distributed Feedback Controller is necessary, given that only a subset of I/O feedback gain relations is typically realizable. In this regard, adequate consideration must be offered towards choosing a suitable I/O subset and then finding the best corresponding gains to achieve a desired system response. Second, compensation for Network Induced Delay(s) (NID) is a design requirement because NID occur when sensors, actuators, and controllers exchange information across shared networks. These induced delays can be constant, time varying, or even random. System latencies can degrade the performance of the actual control system if ignored during the design process and can even destabilize the system by introducing excessive phase lag. The focus of the paper will be mainly on addressing the challenge of maintaining stability and robustness of the distributed


networked control system in the presence of a faulty communication network, i.e., network delay(s) and packets drop out. The approach is to locally estimate the needed information at each control node in a distributed control system and use the information to achieve the designated control objectives.

Figure 1. Distributed Networked Control System Architecture

The type of communication network used within the distributed control systems is as vital to the success of the DNCS as the other components of the control system. For example, a network protocol, i.e., the User Datagram Protocol (UDP) or the Transmission Control Protocol (TCP) offers different quality of service (QoS) and hence has direct impact on the stability of the control system as explained in the next paragraph. Regardless, of the chosen network type, certain requirements must be met. The communication network in DNCS must achieve the following: (1) minimize data loss probability within the network, (2) allow for end-to-end connection of sensor-to-controller, controller-to-actuator through a shared network medium, and (3) maximize the integrity of information sent from transmitters to receivers. Three major attributes must be considered in selecting the type of communication network in DNCS; the network topology, the network transmission protocol, and the network distribution configuration [20, 21]. All communication networks have these attributes inherent to its operation, and modification to these attributes may affect the network performance. The network topology deals with the physical and logical arrangement of the nodes within the network. Physical topology dictates the geometrical arrangement of the various network nodes, while logical arrangement deals with media access control methods in the network. Some network topologies affect both the physical and logical arrangement of the network. For turbine engine controls, topology is highly application dependent, and relies greatly on the actual engine for implementation. The second attribute is the network transmission protocol. Data sent through the network is transmitted according to a set order of communication actions between two nodes. The communication actions (protocols) are similar to the actions in making calls with proper phone etiquette. Just as various cultures have unique phone etiquette, there exist multiple network transmission protocols. The third attribute is the network configuration, which determine the hardware used within the network and the connection type. To meet the network requirements of the distributed control systems, consideration must be given to the choices according to these attributes. The network topology is application dependent, and isn’t expected to have significant influence on the network performance so its effects on the distributed controller will not be considered in this work. Among the others, two alternatives are considered for network protocol; the User Datagram Protocol (UDP), and the Transmission Control Protocol (TCP). Each of these protocols offers different quality of service measures [22]. In this work, the Transmission Control Protocol is used for the network implementation within the DNCS. In the implementation, the TCP protocol is designed to minimize probability of packet loss by the use of packet re-transmit feature. Additionally the TCP uses system


acknowledgments to check for data arrival and accuracy. These two features qualified the TCP to meeting the network requirements of the DNCS. For network configuration selection, two network configuration are possible; the Personal Area Network (PAN/WPAN), and the Local Area Network (LAN/WLAN). Also known as Wi-Fi, the Wireless Local Area Network (Wireless LAN) is a set of low tier technologies for data communication. The IEEE standards for this configuration operate under the 2.4 GHz and 5 GHz ISM bands [23]. There are many variations of this configuration standard within the 802.11 bracket; such as 802.11a, 802.11b, 802.11g, and 802.11n. The most commonly used variant is the 802.11b. This is the used standard of the configuration alternative. Personal Area Networks and Wireless Personal Area Networks are utilized under various aliases. The most common WPAN networks are Bluetooth, and Zig-Bee. The set of WPAN systems operate under the IEEE 802.15 standards, having a wide array of applications and service measures. Bluetooth operates in the same 2.4 GHz range as some Wi-Fi (WLAN) networks, and Zig-Bee has operation in; 868 MHz, 915 MHz, and 2.4 GHz ISMs [23]. Based on analysis conducted on the turbine engine simulation model for determining minimum network requirements, the Local Area Network was selected as the most appropriate network configuration for this work. No significant distinctions exist between the selected network configurations when considering performance of the DNCS, as all the configurations proved to meet the network requirements of DNCS. Finally, communication within the DNCS is proposed to occur through a Local Area Network, Peer to Peer configuration. The system operates under IEEE 802.11b standards; meaning a transmission frequency of approximately 2.4 GHz, and a transmission propagation speed ranging from 1-11 Mbps. The system will utilize the Transmission Control Protocol in transmitting and receiving data packets transmitted through the network. This selected communication network serves to meet all the three network requirements; by minimizing the data loss probability, allowing end-to-end connectivity, and maximizing the data integrity.

3.1.2 PREDICTIVE CONTROL FOR INFORMATION RECOVERY OF FAULTY COMMUNICATION NETWORKS IN DNCS The stability and robust operation of turbine engine distributed networked controllers are highly dependent on the integrity of the feedback information provided by the communication network to the distributed control nodes. In case of network failures, the integrity of such feedback information is lost and its responsibility falls back on the processing/control nodes. A smart processing/control node must be capable of locally generating trustworthy necessary information to act on it. This leads to the concept of using predictive control strategy embedded in each processing and control node while implementing the distributed control laws. Such data recovery task can be realized in the processing/control nodes by states estimation algorithm. Hence, the state estimator will play a key role in the performance of the predictive control strategy to overcome adverse network effects. The state estimator must: (1) Successfully estimate the states of the closed loop system under imperfect transmission conditions, (2) Help the control system maintain stability at a static transmission delay greater than half the closed loop Minimum Allowable Transmission Interval (MATI), (3) Minimize the steady-state value error between the implemented networked control system and a base-line controller without communication network and, (4) The state estimator shall maintain accurate state recovery of the feedback signals required by individual processing and control nodes. In all of the above situations the communication network condition and parameters will be assumed to be known and utilized by the state estimator in propagating state estimates. Finally, the state estimator must function to keep transmission intervals well within the MATI time established for the engine distributed network controller. In the following, we considered three different approaches for design and implementation of state estimators for the smart processing and control nodes, i.e., a predictive model that is parametric and regressive. It is assumed that the estimation algorithm cannot rely solely on current input from the network in order to produce dependable state estimations. Rather, the algorithm shall utilize a combination of control signal and state feedback history to determine accurate future states. The aim is to locally predict the engine states prior to the signal entering the network communication. Various parametric and regressive system modeling alternatives exist of which; three are analyzed in the scope of this work.


Kalman Filter Predictor:- The Kalman filter has been subjected to extensive research and application, particularly in the areas of prediction and estimation. It is a set of mathematical equations that provide an efficient computational (recursive) means to estimate the state of a process, in a way that minimizes the mean of the squared error [24]. It supports estimation of past, present, and even future states. It can do so without precise knowledge of the system dynamics at hand. The design of a discrete Kalman filter is introduced in [24]. Two processing steps implemented by the Kalman filter; time update, and measurement update steps. The time update step is responsible for state prediction with use of a measurement corrected state and error co-variance value. The measurement update step corrects previous state prediction and co-variance values using the current state measurement. Parametric Auto-Regressive Predictor:- For any continuous time system, the input to output relationship can be considered a parametric equation whose variables are the historical I/O data. In system identification, it is desirable to find the governing coefficients that produce the next step output based on previous input and output information. The auto-regressive with exogenous input model captures the current output as a function of some order of parameters; depending on the input and output order. Artificial Neuro-Fuzzy Inference System:- The Adaptive-Neuro Fuzzy Inference System (ANFIS) combines two intelligent techniques; the artificial neural network and the fuzzy inference developed by Takagi and Sugeno [25, 26]. The ANFIS model is an adaptation of the fuzzy logic model to include neural network based learning function. In the model, the premise parameters determine the membership function type in the input layer. The model can ideally have any number of inputs and any number of membership functions for each input but must have only one output. Conventionally, ANFIS is designed to take an aggregation of inputs and make a single output decision. As a state estimator, ANFIS will take the state history as input and produce a single state estimation as output. Also, ANFIS offers high accuracy state prediction since it combines two artificial intelligence techniques. All the above discussed approaches to state estimation are; parametric and regressive by nature, serve to model linear and nonlinear systems, and offer tuning parameters to increase their estimation performance. However, ANFIS has been proven to perform well in state estimation and signal prediction without much dependence on accurate real-time information. This feature proves beneficial in order to compensate for the DNCS network delay effects. The three estimation approaches are implemented and tested in this research, and the results validate the use of the ANFIS for state estimation. As a result, the adapted predictive control strategy is implemented utilizing ANFIS as a local state estimator in the distributed controller nodes. Detail development and implementation information is presented in the next section. 3.2 SYSTEM DEVELOPMENT AND IMPLEMENTATION 3.2.1 DEVELOPMENT OF THE COMMUNICATION NETWORK Network implementation issues are at the center of successful implementation of networked control systems (NCS). Therefore, NCS have introduced considerable changes to the way control systems are implemented. Analysis of both the networked and network-free closed loop systems stability must be conducted in the design of NCS. The designer must find the minimum rate at which feedback information must be processed and used to close the control loop and maintain the controlled system stability [27]. This inherent minimum data rate of networked control systems is characterized by the Minimum Allowable Transmission Interval (MATI) of these systems [28]. For this class of networked control systems it is critical for the controller be designed with knowledge of the system’s MATI. Hence, in the following we cover the process of analyzing a discrete control system to find its MATI at which stability holds. The controller communication network must ensure signal transmission at a rate upholding this minimum interval. Consider the following closed-loop discrete LTI system. 𝑥𝑥(𝑡𝑡 + 𝛥𝛥𝛥𝛥) = (𝐴𝐴 + 𝐵𝐵𝐵𝐵)𝑥𝑥(𝑡𝑡) + 𝐵𝐵𝐵𝐵(𝑡𝑡) 𝑦𝑦(𝑡𝑡) = (𝐶𝐶 + 𝐷𝐷𝐷𝐷)𝑥𝑥(𝑡𝑡) + 𝐷𝐷𝐷𝐷(𝑡𝑡)


(1)

Where, Δt is the sampling interval of the discrete system. For such a system, with a sampling interval exceeding the MATI of the system, the controller pushes the system towards instability. The sampling boundary can be determined by trial and error using network simulator integrated with the controller. To perform such analysis we have used a distributed control system developed and implemented on the MAPSS turbine engine simulation model and it was reported in our previous work [29]. The following is a summary of the development of the distributed control system with presentation of its basic performance under network constraints. For a LTI system described by its state space model in the continuous time domain as in equation (2), a distributed controller is designed to force the dynamics of the controlled system to exhibit a desired behavior specified by the eigenvalues of the closed-loop system matrix “Acld” and meet the following constraints: (1) The controller parameters must be decentralized, and (2) The controller will be implemented in the form of distributed network control system. 𝑥𝑥̇ (𝑘𝑘) = 𝐴𝐴𝐴𝐴(𝑘𝑘) + 𝐵𝐵𝐵𝐵(𝑘𝑘)

𝑦𝑦(𝑘𝑘) = 𝐶𝐶𝐶𝐶(𝑘𝑘) + 𝐷𝐷𝐷𝐷(𝑘𝑘)

(2)

Using the feedback control law 𝑢𝑢(𝑘𝑘) = 𝐾𝐾𝐾𝐾(𝑘𝑘) + 𝐻𝐻𝐻𝐻(𝑘𝑘) and inserting it into the state space equation (2), a new closed loop control system is derived. 𝑥𝑥̇ (𝑘𝑘) = (𝐴𝐴 + 𝐵𝐵𝐵𝐵)𝑥𝑥(𝑘𝑘) + 𝐵𝐵𝐵𝐵𝐵𝐵(𝑘𝑘)

𝑦𝑦(𝑘𝑘) = (𝐶𝐶 + 𝐷𝐷𝐷𝐷)𝑥𝑥(𝑘𝑘) + 𝐷𝐷𝐷𝐷𝐷𝐷(𝑘𝑘)

(3)

The system with input 𝑢𝑢(𝑘𝑘) and output 𝑦𝑦(𝑘𝑘) is the “open-loop" system, and the system with input 𝑣𝑣(𝑘𝑘) and output 𝑦𝑦(𝑘𝑘) is the “closed-loop" system. To satisfy the constraint imposed on the control system, the controller matrix “K” must satisfy the following two conditions; the 𝑚𝑚𝑚𝑚𝑚𝑚 matrix K has full row rank, and must satisfy the equation (𝐶𝐶 + 𝐷𝐷𝐷𝐷)(𝐴𝐴 + 𝐵𝐵𝐵𝐵) = Λ(𝐶𝐶 + 𝐷𝐷𝐷𝐷) for some real 𝑚𝑚𝑚𝑚𝑚𝑚 matrix-𝛬𝛬[17]. Understanding that (𝐴𝐴 + 𝐵𝐵𝐵𝐵) = Λ, a controller matrix can be computed by. 𝐾𝐾 = 𝐵𝐵−1 (𝛬𝛬𝛬𝛬 − 𝐶𝐶𝐶𝐶)

(4)

Where, 𝐾𝐾 is 𝑚𝑚𝑚𝑚𝑚𝑚 controller matrix, and 𝛬𝛬 is the desired closed-loop system matrix. Matrix 𝐻𝐻 in equation (3) is important in ensuring a one-to-one relationship of input to output for the controlled system. Forcing the matrix K to be fully distributed and choosing, by use of Grammian interaction measure [30], a single nonzero value from each vector in the column space of the K matrix yields the following system of equations. 𝑘𝑘𝑖𝑖 = 𝑓𝑓�Λ − {V}�;

𝑓𝑓𝑓𝑓𝑓𝑓 𝑖𝑖 = 1 → 𝜍𝜍

(5)

where: 𝜍𝜍 = 𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟(𝐾𝐾), and {V} is set of parameters to solve for. Solving the above system of equations does not lead to a unique solution. For controller parameters optimization, first, the desired closed loop system behavior is specified, then selecting the elements of the closed loop characteristic matrix 𝛬𝛬 as search parameters, an optimization algorithm is used to find the elements of the matrix K (with elements Ki  K𝜍𝜍) that closest serve to meet the desired system behavior. The optimization algorithm is developed and implemented using MATLAB optimization Toolbox to minimize the following cost function.

𝑠𝑠. 𝑡𝑡.

where:

𝐽𝐽 = 𝑚𝑚𝑚𝑚𝑚𝑚𝑉𝑉 {𝑤𝑤1 𝑒𝑒1 (𝑡𝑡)2 + 𝑤𝑤2 𝑒𝑒2 (𝑡𝑡)2 } 𝑒𝑒1 (𝑡𝑡) =

max{𝑦𝑦2 (𝑡𝑡)}−𝑦𝑦2 (∞) 𝑦𝑦2 (∞) ∞

− 𝑜𝑜𝑜𝑜

𝑒𝑒2 (𝑡𝑡) = ∫0 |𝑦𝑦1 (𝑡𝑡) − 𝑦𝑦2 (𝑡𝑡)| 𝑑𝑑𝑑𝑑 + [|𝑦𝑦1 (𝑡𝑡∞ ) − 𝑦𝑦2 (𝑡𝑡∞ )|]

y1(t): desired system response y2(t): intermediate system response w1, w2 weight coefficients


(6.a)

(6.b) (6.c)

e1(t): overshoot error e2(t): steady state response error. The above procedure for designing a distributed controller is applied to a linearized model of turbine engine. Also, network implementation of the distributed controller is conducted to test the controller performance under communication network constraints. The following matrices A, B, C, and D are used in the design of the controller. They represent a linearized model of turbine engine at a specific operating point and extracted from the Modular Aero-Propulsion System Simulation (MAPSS) software [31]. The three state of the engine considered are: the low pressure spool speed (Xnl), the high pressure spool speed (Xnh), and the average hot section temperature (Tmpc). −0.214 A= � 0.026 0.0027

0.358 −0.144 −0.007

0.049 0.0274 �; −0.015

0.250 B= � 0.170 0.0127

4.493 1.52 −0.007

−0.685 0.4475 �; C= I(3), D=[0] −0.004

Choosing the structure of the distributed controller (K) as shown below, the controller gains are computed using optimization algorithm for the desired characteristics parameters of the closed-loop system as, 𝑜𝑜𝑜𝑜 = 5%, 𝑎𝑎𝑎𝑎𝑎𝑎 𝑡𝑡𝑝𝑝 = 2 𝑠𝑠𝑠𝑠𝑠𝑠. 0 𝑘𝑘 K=: � 1 0

𝑘𝑘2 0 0

0 0 �; 𝑘𝑘3

0 K = �−1.9301 0

0.1004 0 0

0 0 � 480.74

The above developed distributed controller for the turbine engine is implemented with communication network connecting the different elements of the controller with the engine sensors and actuators. The distributed networked control system is tested using the TrueTime network simulation software written under MATLAB/Simulink [32]. Two network conditions are tested. Run-1 represents moderate constrained network condition and, Run-2 represents network under extreme constrained conditions (network packet loss). The network and its simulation parameters are summarized in Table 1. Table 1. Network Implementation Parameters Network Parameters

Run-1 Moderate Constrained Network

Run-2 Severely Constrained Network

Controller Sampling Rate

20 (msec)

20(msec)

Network Type

CSMA/CD (Ethernet)

CSMA/CD (Ethernet)

Network Transmission Rate

10 (Mbps)

10 (Mbps)

Probability of Packet Loss

50%

85%


Figure 2 shows the system responses under the network implementation without predictive control strategy (without state estimation). The dashed lines indicate the responses without network effects, and the solid "blue" lines indicate the system response with network effects through packed loss constrain.

Xnl

Xnl

Xnh Xnh

Tmpc Tmpc

(b)

(a)

Figure 2. System Responses with Network Simulator (a) Moderate Constrained Network, (b) Severely Constrained Network In the above implementation of the distributed controller, the system’s sampling period is increased from an acceptable small value until system instability occurred. To determine the point of system instability, the system response is analyzed using Fourier transform. Typically, Fourier transform is used to extract the dominance of the frequency within a signal and is given by the following equation for a discrete signal f(n). 𝑗𝑗 𝑤𝑤𝑘𝑘 𝑛𝑛 ; F(𝑘𝑘) = ∑𝑁𝑁−1 𝑛𝑛=0 𝑓𝑓(𝑛𝑛) 𝑒𝑒

𝑤𝑤ℎ𝑒𝑒𝑒𝑒𝑒𝑒 𝑘𝑘 = 0, … , 𝑁𝑁 − 1 𝑎𝑎𝑎𝑎𝑎𝑎 𝑤𝑤𝑘𝑘 = 2𝜋𝜋𝜋𝜋/𝑁𝑁

(7)

Where, N is the total number of samples over finite time. By squaring the Fourier Transform values F(k), the Power Spectrum is computed as given in equation (8). Considering the engine model response, at stability the step response will tend towards a steady state value. At instability, the system will either tend towards an infinite pole, or oscillate between infinite asymptotes. Under stable conditions, the power spectrum of the system response indicates a dominant frequency matching the reference input frequency, with all other frequencies having very minimal to no power. When unstable, the input reference frequency loses its dominance in the system response and a different frequency becomes dominant. 𝐹𝐹(𝑘𝑘𝑑𝑑 )2

𝑃𝑃(𝑘𝑘𝑑𝑑 ) = ∑𝑁𝑁

2 𝑘𝑘 𝐹𝐹(𝑘𝑘)

∗ 100; 𝑓𝑓𝑓𝑓𝑓𝑓 𝑘𝑘 ≠𝑘𝑘𝑑𝑑

(8)

To find the MATI for stable system operation, the power of the dominance frequency of the reference input signal is determined as a percentage of total power within the system response P(kR) using equation (8), where kR is determined by the input reference frequency ωR. For multiple sample rate test, the point at which the input reference frequency is no longer dominant, within the system response, is the point of system instability. The corresponding sampling rate at that point is the Minimum Allowable Transmission Interval (MATI) for the linear system in the control loop.


3.2.2 DEVELOPMENT OF STATE ESTIMATORS Due to the intermittent nature of networked control systems, quality of the state feedback information may be compromised. To compensate for the occasional delay or loss of information that may occur between communication nodes, a state estimator can be used at the receiving node of the network. The estimator’s purpose is to recover or reconstruct the lost or over-delayed state feedback information to preserve continuity of the control efforts. In the following, a method of the model predictive control theory is highlighted from which the predictive control motivation arises. The proposed design makes use of state estimation with offline modeling technique. The three modeling options presented in the previous section are implemented and tested to validate the performance of the state estimation algorithm. Theoretical precepts and methodology for developing each estimator model are provided next.

Kalman Filter State Estimator: - A stochastic discrete control system can be described by its difference equation (9) and measurement output equation (10) as shown below.

xk = A xk−1 + B uk−1 + wk−1 zk = H xk + vk

(9) (10)

The variables wk and vk represent the process and measurement noise, respectively. In the case of a NCS, the uncertainty of data due to intermittency within network transmission can be represented by both the process and measurement noise. Three assumptions are made concerning the noise variables within the Kalman filter design: (1) They are independent, (2) They are random (white noise) with normal probability distribution, and (3) They are constant with each time step. Defining 𝑥𝑥�𝑘𝑘− as a priori state estimate (without knowledge of current process measurement zk), and 𝑥𝑥�𝑘𝑘 as the posteriori state estimate (with knowledge of the current process measurement), two estimation errors can be defined as: 𝑒𝑒𝑘𝑘− ≡ 𝑥𝑥𝑘𝑘 − 𝑥𝑥�𝑘𝑘− ;

𝑒𝑒𝑘𝑘 ≡ 𝑥𝑥𝑘𝑘 − 𝑥𝑥�𝑘𝑘

(11)

Where 𝑥𝑥𝑘𝑘 represent the true state of the system. The corresponding error covariance is found by the following equation. 𝑃𝑃𝑘𝑘− = E(𝑒𝑒𝑘𝑘− 𝑒𝑒𝑘𝑘− 𝑇𝑇 ) 𝑃𝑃𝑘𝑘 = E(ek 𝑒𝑒𝑘𝑘𝑇𝑇 )

(12)

Where, E[x] is the expected value of x against a normal distribution. During each sampling cycle of the discrete system Kalman filter performs a time update and a measurement update. Further details can be found in [24], but for brevity the equations for those updates are given below. The time update of the discrete Kalman filter is given by the following equation. 𝑥𝑥�𝑘𝑘− ≡ A 𝑥𝑥�𝑘𝑘−1 + 𝐵𝐵 𝑢𝑢𝑘𝑘−1

𝑃𝑃𝑘𝑘− = A 𝑃𝑃𝑘𝑘−1 𝐴𝐴𝑇𝑇 + Q


(13)

And the measurement update of the discrete Kalman filter is computed by the following equation Kk = 𝑃𝑃𝑘𝑘− H (H 𝑃𝑃𝑘𝑘− H + R) T

T

−1

𝑥𝑥�𝑘𝑘 = 𝑥𝑥�𝑘𝑘− + Kk (zk − H 𝑥𝑥�𝑘𝑘− ).

Pk = (I − Kk H) 𝑃𝑃𝑘𝑘−

Where I ϵ R

nxn

(14)

th

is the n order identity matrix.

Parametric Auto-Regressive State Estimator: - Parameter estimation is well-established theory with numerous methods exist to compute parameters of Auto-Regressive with eXternal input (ARX) models based on a finite array of continuous or discrete time data series. The least squares method is the most common method used for estimating the model parameters21. Consider the (modified) continuoustime ARX process n−1

n

(p + a1 p

m

+ · · · + an) y(t) = (b1p + b2 p

m-1

· · · + bm) u(t) + e(t)

(15)

where p denotes the differentiation operation, y(t) is the output, u(t) is the input, and e(t) is estimation error represented by continuous-time white noise source21. With substitution of derivatives by numerical approximations (pn ~ Dn) a new realization of equation (15) is derived [33]. ω(t) = φ (t) θ + e(t) T

(16)

where ω(t) = D y(t) n

φ (t)= [−D T

n−1

y(t) · · · −D y(t) D u(t) D 0

m

m−1

0

u(t) · · ·D u(t)]

θ= [a1 · · · a , b1 b2 · · · bm] where e(t) is the estimation error. This model can be viewed as a discrete-time linear regression. It is of interest to find an estimate θ� to the parameter vector θ. Using the least squares approach reported in21, the parameter estimate vector can be found by the following formula assuming that y(t) and its all derivatives Dn y(t) are uncorrelated with e(t). T −1 θ� = [E{φ(t) φ (t)}] [E{φ(t) ω(t)}]

(17)

Where E(·) denotes the covariance function. Inserting the estimate parameters θ� into equation (16), the linear ARX model is developed for the system whose history data are used to compose the φT(t) matrix. Adaptive Neuro-Fuzzy Inference System State Estimator: - For most cases, and in this design, the Gaussian type membership function show below is used for the ANFIS model development. μA(x) =

1+�

1

𝑥𝑥−𝑐𝑐 �2𝑏𝑏 𝑎𝑎

(18)

In equation 18, values for a, b, and c are the premise parameters to be optimized for a given system during the training of the ANFIS estimation model. Similarly the ANFIS model consists of consequent parameters, which are found in the fourth layer of the node output function. Every node in this layer has node function defined as


s.t.

Oi = 𝜔𝜔 �𝑖𝑖 fi = 𝜔𝜔 �𝑖𝑖 (gi x + qi y + r) 𝜔𝜔𝑖𝑖

𝜔𝜔 �𝑖𝑖 =∑

𝜔𝜔𝑖𝑖

;

for i = 1 → R

𝜔𝜔𝑖𝑖 = {(μ1(x1), μ2(x2), . . . , μj(xn)}

(19)

Where R is the number of rules within the fuzzy inference system, j is the number of membership functions, and n is the number of inputs. In most fuzzy inference systems, j is less than n, and does not exceed three (3) membership functions. These parameters are also optimized during the training of the ANFIS. Consequent parameters for this model are the values for g, q, and r. The single output decision of the ANFIS is found by summation of the output of the individual node functions. 𝑥𝑥� = ∑𝑖𝑖 O𝑖𝑖

(20)

In the final implementation, the distributed networked control system utilized a predictive control strategy by adding the state estimation to the control nodes as shown in Figure 3. The distributed feedback gains were designed, as explained in [29], for the MAPSS turbine engine linear models using an optimization process to generate desired step responses. Linear state space models were extracted for various operating points of the turbine engine. These quiescent points were arbitrarily chosen on the flight envelop of an aircraft. Additionally, discrete analysis is performed on the engine linear models to determine the Minimum Allowable Transmission Interval (MATI) for each operating region, and as a result for the entire turbine engine as a complete nonlinear system. The MATI time is used to determine network design parameters and to provide a threshold for the state estimation process during implementation and testing of the predictive control strategy. When the measured state transmission rate approaches the established MATI for the turbine engine, the state estimator is activated and the estimated state is utilized by the controller node instead of the transmitted state. For proof of concept simulation test results are presented in the next section.

Figure 3. Distributed Networked Control System with State Estimators

3.3 SYSTEM TESTING AND PERFORMANCE EVALUATION Linear models were developed for military grade turbine engine nonlinear model using the Modular Aero-Propulsion System Simulation (MAPSS) provided by NASA5. The MAPSS, developed in the MATLAB/Simulink environment, is a non-real time, multi-rate simulation of a modern high-pressure ratio,


dual-spool, low bypass, variable cycle, military-type engine, with a digital controller. The model has three operating conditions: Power Lever Angle (PLA), Flight Altitude (Alt), and Plane Mach number (Mac); three inputs: fuel flow, nozzle exit area, and bypass exit area; and three outputs: low and high pressure spool speeds, and the ambient core metal temperature. The third output is a function of multiple measurements from various temperature sensors within the engine. The three engine states are the low pressure spool speed (xnl), high pressure spool speed (xnh), and the system core metal temperature (Tmpc). The final implementation architecture of the above developed distributed networked control system (DNCS) is shown in Figure 4. The main simulation results using Matlab environment are shown in Figure 5. Testing on the linearized model of the MAPSS turbine engine is performed to verify the performance of the DNCS with predictive control implementation in the form of state estimator and the communication network in place. The results of this test are shown in Figure 5 for each individual predictive/estimation method. Four plots are shown on each graph; performance of the base-control system with no networked interface, the control system with networked interface but without state estimator, the control system with an estimator but without network interface, and the final and complete system implementation with networked interface and state estimator. Also, each predictive method is tested for three types of network delay; sample delay, static time delay, and variable (random) time delay. The aim is to consider the breadth of effect of the network health on the performance of the distributed controller. On each plot the red line indicates the DNCS design performance, while the blue line indicates the ideal performance objectives. Figure 5 depicts the ANFIS state estimator performance in minimizing the network effects on the control system using only one side of the communication network, i.e., sensor to controller. The other communication sides of the control nodes are implemented with ideal transmission. The ANFIS performed very well at tracking the base-control system output; offering a precise state estimate. Concerning system recovery, this estimation model also succeeded as did the other two sate estimation algorithms. Their performance is omitted here for brevity.

Because of the satisfactory results obtained from implementing the ANFIS state estimation model on one side of the communication network, a complete network implementation is conducted for the same system setup. The results are shown in Figure 6. In this test, the network transmission occurs on both ends of the distributed controller. With the full network implementation, the networked system with ANFIS state estimator performance still holds better than the networked system without a state estimator under all network delayed conditions.

Figure 4. DNCS Full Implementation Architecture


Xnl rpm

Xnl rpm

Time

Time

Xnl rpm

Xnl rpm

Time

Time

Figure 5. Performance of the DNCS with ANFIS and One Side Communication Network and One State Estimation (Xnl). a) No delay, b) Sample hold delay, c) Static time delay, and d) Random time delay.


Figure 6. Performance of the DNCS with ANFIS Estimator, Full Network Implementation and One State Estimation (Xnl). a) No delay, b) Sample hold delay, c) Static time delay, and d) Random time delay.

4.0 STUDY OF MODIFIED TURBINE ENGINE OVER FULL FLIGHT ENVELOPE In this section, we present the work carried out by the OSU research group on a modified turbine engine model to include some of the network characteristics and faults. In the task, the current real-time engine model developed by AFRL was subjected to investigation to include random, bounded time delays and data loss. The team modeled the random time delay and data loss on several candidate communication data bus including time-triggered protocols like TT-Ethernet, TTP/C, event triggered protocols like ARINC 825 and other protocols like Flexray. As a result, the engine model incorporated sensor and actuator delays and network delays between sensors and controllers. These network delays included transmission delays,


scheduling delays and other forms of delays due to communication network. The engine control model used on Di-FADEC was modified to include controller to actuator delay. 4.1 THEORETICAL FOUNDATION AND TECHNICAL APPROACH An aircraft engine is a continuous physical system with a digital control system which dictates that it is to be treated as a hybrid system. Sampled data systems are a special case of Hybrid systems in the sense that the discrete nature manifests only in the time variable. In the interest of the future of turbine engine control through distributed engine control systems, it has been shown that degradation of the engine and the constraints of the communication system such as time delays and packet dropouts can cause poor performance and even instabilities in the engine. This in turn leads to the potential need for imparting robustness in the control design methods to control future turbine engines. Thus, designing robust control systems for engine control is of paramount importance. However there has been little to no application of robust control techniques to turbine engine controller design in sampled data system framework. A logical step in understanding the behavior in sampled data framework is to evaluate and understand the application of robust controllers in the strictly continuous time domain which is much more mature and then treat this as a reference for designing sampled data controllers under communication constraints. The main goal of the research was to study the impact of network faults in the implementation of distributed engine control architecture. The approach to achieve this goal essentially consisted of choosing an architecture to implement, modify and existing engine and controller model to include the presence of network faults, to simulate the engine at several different operating points throughout the flight envelope, and to analyze the results to help characterize the impact network faults may have on future engines and there control systems. Below is the detailed technical approach. •

Choose a Distributed Engine Architecture to model. Partially distributed engine architecture with analog sensors and actuators communicating through wired connections to a data concentrator was selected. This was the first logical step in implementing distributed engine control.

•

Modify C-MAPSS40k to model network faults (random time delay and packet dropouts) for various communication protocols. This may be done through interfacing the beta Simulink Blockset known as TrueTime with C-MAPSS40k. Possible Protocols include: (1) SMA/CD (Ethernet), (2) CSMA/AMP (CAN), (3) TDMA (TTP), and (4) FlexRay.

•

Verify that any necessary modifications to C-MAPSS40k does not change its dynamics

•

Characterize the parameters of the communication protocol such as bit rates, slot sizes, etc.

•

Simulate the engine at a variety of operating points which covers a good portion of the flight envelop for one or several of the communication protocols mentioned above.

•

Make assessments of the stability and performance and the impact network faults have: Maximum overshoot, Settling time, Integral average error (IAE), Integral time average error (ITAE)

4.1.1 CONTROL SYSTEM ARCHITECTURE There are many possibilities when it comes to distributed engine control architectures. Some of these options implement is known as “smart nodes” which contain additional electronics for signal conditioning and encoding based on the communication protocol. Smart nodes are sensors and actuators with additional functionality which is removed from the centralized controller and placed in these components themselves. However due to the extreme environment of a gas turbine engine and the limitations of high temperature electronics, the used of smart sensors and actuators is further down the road. In fact the transition from a centralized control system to a fully distributed control system will occur in increments through a variety of partially distributed architectures. The first of such partially distributed architectures may consist of legacy analog sensors and actuators which connect via wired harnesses to a data concentrator. The data concentrator would perform some of the functions of the centralized controller such as signal conditioning


as well as A/D and D/A conversion. Then the data concentrator will transmit the data to a distributed FADEC module via a digital communication bus and receive commands back from the controller to be sent to the actuators. Figure 7 shows a schematic of the described control and communication architecture.

Figure 7. Dual-redundant partially distributed FADEC with data concentrator

For the purpose of this study, the partially distributed architecture mentioned above with legacy sensors and actuators was chosen. The reason for this selection was that it is the most relevant and the ease of real-world implementation versus the other possibilities makes it attractive. It may also be the simplest architecture to model given the available modeling tools. The available engine models have legacy sensors and actuators modeled. Smart nodes approach was followed and implemented by the TSU group of this collaborative effort and it was reported in the previous section of this paper.

4.1.2 ENGINE CONTROL MODEL MODIFICATION The engine model used for this study is the C-MAPSS40k. The C-MAPSS40k is a high-fidelity nonlinear model of a commercial gas turbofan engine with a maximum thrust of 40,000lb. C-MAPSS40k is a widely used engine model developed by NASA and it provides a variety of tools and options [34]. Unlike the AFRL model of the Rolls-Royce AE 3007 Turbofan engine used by the Global Hawk, the CMAPSS40k model does provide a flight envelope. This along with the author’s familiarity with CMAPSS40k and it’s much greater ease of use, C-MAPSS40k was chosen as the engine model in this study. The network modeling was done through taking advantage of the MATLAB/Simulink network simulator known as TrueTime which was developed by Anton Cervin, Dan Henriksson, and Martin Ohlin of Lund University in Sweden [35]. This package consists of a number of MATLAB functions, C/C++ files, mexfiles, a TrueTime Simulink library, and several examples and documentation. The network modelling is done through a set of Simulink s-function blocks with underlying MATLAB and C/C++ code. The purpose of this network simulating tool is to facilitate co-simulation of controller task execution in real-time kernels, network transmissions, and continuous plant dynamics. For more information the reader is referred to. Several modifications to the original C-MAPSS40k engine model had to be made to include the network faults in the simulation. The main challenge was getting C-MAPSS40k and TrueTime to work


properly together. The TrueTime Network blocks only appeared to work properly with a variable time step solver whereas C-MAPSS40k was developed to use a fixed time-step solver. If a fixed-time step solver was used with TrueTime then the data would not transmit from node to node. C-MAPSS40k will run with a continuous time step but problems were encountered within the digital controller of C-MAPSS40k when the TrueTime Network blocks were introduced. The common error which was prevalent was “Continuous sample time is not supported by block”. Sampling time was an issue for several blocks within the digital controller. The problem had to be reconciled. The solution included both changes to the C-MAPSS40k digital controller and the addition of TrueTime blocks to model the network.

4.2 NETWORKED CONTROL SYSTEM DEVELOPMENT AND IMPLEMENTATION As it was reported in the technical approach section 5.1, several modifications to the original AFRL engine model had to be made to include the network faults in the simulation. The main challenge was getting engine model and TrueTime to work properly together. The TrueTime Network blocks only appeared to work properly with a variable time step solver whereas the used engine model was developed to use a fixed time-step solver. If a fixed-time step solver was used with TrueTime then the data would not transmit from node to node. The engine model will run with a continuous time step but problems were encountered within the digital controller of engine model when the TrueTime Network blocks were introduced. The common error which was prevalent was “Continuous sample time is not supported by block”. As it was reported, sampling time was an issue for several blocks within the digital controller. The problem had to be reconciled. The solution included both changes to the engine model digital controller and the addition of TrueTime blocks to model the network. 4.2.1 ENGINE MODEL MODIFICATION AND PREPARATION FOR NETWORK TESTING The first action was to modify the engine model and verify its operation again. This was necessary to visualize and work with the entire control system including sensors and actuators. In the process, the sensor block was moved outside of the engine block and the actuator block was moved outside of the controller block. With this done the major components of the control system could be visualized on the top level of the model (engine, sensors, controller, and actuators). This action made it convenient to visualize and establish communication nodes. In the process of making these modifications no changes were made to the contents or operation of the engine model, it was simply re-arranged. Since the research effort was to focus on the full flight envelope in the design of controllers, the nonlinear engine model was linearized at various operating points. Thus, the problem that had to be addressed was to prepare the AFRL model in order to be able to produce a linearized model. A perturbation method was applied to the AFRL model using the equations shown below equations 22-25. In order to do this, perturbations were added to each state of the AFRL model. Matlab code was generated to perturb one state at a time and measure the change in rate of the states. Both positive and negative perturbations were used to provide more accurate results. The linearization allowed for up to 10 states, i.e., N1, N2, P3, P45, T25, T3, T4, T45, T5, and Tm. However, in comparing the linearized simulation to the nonlinear simulation it was noticed that the linear model was most accurate for only the first two states of the engine dynamics. The code also provided the user with the options to select the altitude, ambient temperature deviation, Mach number, and PLA that the program would use in the linearize process. 𝑥𝑥̇ 1,1 𝑢𝑢𝑢𝑢 −𝑥𝑥̇ 1,1 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

⎡ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑥𝑥 1 ⎢ 𝐴𝐴 = ⎢ ⋮ ⎢𝑥𝑥̇ 𝑛𝑛,1 𝑢𝑢𝑢𝑢 −𝑥𝑥̇ 𝑛𝑛,1 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ⎣ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑥𝑥𝑛𝑛

⋯

𝑥𝑥̇ 1,𝑛𝑛 𝑢𝑢𝑢𝑢 −𝑥𝑥̇ 1,𝑛𝑛 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

⎤ ⎥ ⋱ ⋮ ⎥ 𝑥𝑥̇ 𝑛𝑛,𝑛𝑛 𝑢𝑢𝑢𝑢 −𝑥𝑥̇ 𝑛𝑛,𝑛𝑛 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑⎥ ⋯ ⎦ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑥𝑥𝑛𝑛 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑥𝑥1


(22)

𝑦𝑦1,1 𝑢𝑢𝑢𝑢 −𝑦𝑦1,1 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

⎡ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑥𝑥1 𝐶𝐶 = ⎢ ⋮ ⎢𝑦𝑦𝑝𝑝,1 𝑢𝑢𝑢𝑢 −𝑦𝑦𝑛𝑛,1 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ⎣ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑥𝑥𝑛𝑛 𝑥𝑥̇ 1,1 𝑢𝑢𝑢𝑢 −𝑥𝑥̇ 1,1 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

⎡ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑢𝑢 1 ⎢ 𝐵𝐵 = ⎢ ⋮ ⎢𝑥𝑥̇ 𝑛𝑛,1 𝑢𝑢𝑢𝑢−𝑥𝑥̇ 𝑛𝑛,1 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ⎣ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑢𝑢𝑛𝑛

𝑦𝑦1,1 𝑢𝑢𝑢𝑢 −𝑦𝑦1,1 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

⎡ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑢𝑢1 𝐷𝐷 = ⎢ ⋮ ⎢𝑦𝑦𝑝𝑝,1 𝑢𝑢𝑢𝑢 −𝑦𝑦𝑛𝑛,1 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ⎣ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑢𝑢𝑛𝑛

⋯ ⋱

⋯ ⋯

𝑦𝑦1,𝑛𝑛 𝑢𝑢𝑢𝑢 −𝑦𝑦1,𝑛𝑛 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

⎤ ⎥ ⋮ 𝑦𝑦𝑝𝑝,𝑛𝑛 𝑢𝑢𝑢𝑢 −𝑦𝑦𝑛𝑛,𝑛𝑛 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ⎥ ⎦ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑥𝑥𝑛𝑛 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑥𝑥1

𝑥𝑥̇ 1,𝑛𝑛 𝑢𝑢𝑢𝑢 −𝑥𝑥̇ 1,𝑛𝑛 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

⋯

⎤ ⎥ ⎥ 𝑥𝑥̇ 𝑛𝑛,𝑛𝑛 𝑢𝑢𝑢𝑢 −𝑥𝑥̇ 𝑛𝑛,𝑛𝑛 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ⎥ ⎦ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑢𝑢𝑛𝑛

⋱

⋮

⋱

⋯ ⋯

2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑢𝑢1

⋮

𝑦𝑦1,𝑛𝑛 𝑢𝑢𝑢𝑢 −𝑦𝑦1,𝑛𝑛 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

⎤ ⎥ 𝑦𝑦𝑝𝑝,𝑛𝑛 𝑢𝑢𝑢𝑢 −𝑦𝑦𝑛𝑛,𝑛𝑛 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ⎥ ⎦ 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑢𝑢𝑛𝑛 2∗𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝_𝑢𝑢1

(23)

(24)

(25)

With the availability of an accurate linear model of the engine at any desired operating condition, several control strategies became available to handle packet dropouts. Several different control architectures were developed and tested against each other in a simplified simulation consisting of a linear model and time delays. Additionally, this linearization tool gave us a simplified engine dynamics that is much easier to analyze. Now we have the ability to check the stability of the open-loop engine model at different operating conditions and can easily be modified to check the closed-loop stability with different controller implementations. The control architectures were designed around the fact that the new distributed engine controller will be broken up into nodes, capable of doing computation, at each sensor and actuator. Based on the results of these simplified simulation a new architecture was applied to the AFRL engine model. Details on two of the simplified models are given below as well as the setup and results of the AFRL model implementation. Because a few of the engine’s sensors are located in places close to the actuators, such as the fuel flow meter and the turbine temperature sensor, the first implementation was to have each of the engine actuator paired with a sensor on a single node. In this partially distributed control architecture, nodes allow the implementation to perform simple calculations, such as A/D conversion. If these nodes were able to perform simple control calculations as well this would allow the actuator to still function even if the digital conversion operation of the node’s sensor is failed. This implantation was first tested with only time delays and no packet dropouts in a mock system simulation. The mock system simulation considered three states with a full state feedback and fixed time delays on the two sensors that were not implemented on the node. This setup was more of a baseline test to see if any unexpected complications may occur due to having different time delays for different sensor readings. As expected there was no significant detriment. The second setup expanded on the first by using an observer for each measured state. A useful setup would be to have the observers placed on each shared node that has an actuator. This was to allow further robustness by allowing the system to only require the sensor that was on the same node. This was tested to be viable by looking at a T100 engine and showing that the system only needs one sensor to be observable. The biggest problem with this setup was that for the structure to be stable it must have access to all of the actuator inputs when multivariable control is used. Because the actuators are on the communication line the only time this would become an issue is if an actuator and a sensors experienced a communication problem. Additional control work had to be done to find a way to account for this arrangement without increasing complexity of the calculations at the nodes. The final implementation was incorporated into the AFRL engine model. It was used to test an architecture that allows the controller to switch between using sensor values or estimated values based on the packet dropout condition. Most of the proposed communication networks have methods to detect when a packet dropout has occurred, which makes this method particularly useful. This implementation simulated packet dropout by having a set schedule of errors, as shown in Figure 8 below and having a sampling rate of 50Hz which is slightly conservative compared to an ARINC network protocol. Having packet dropouts done on a fixed schedule was useful as a control variable and allowed us to use the worst case scenario.


Future studies will use the more accurate network delay simulations that were covered in the previous update.

Figure 8. Implementation of Simulated Packet Dropout

4.2.2 MODIFICATIONS TO INCLUDE NETWORK IMPLEMENTATION The solution to reconciling TrueTime with engine model was to make the digital controller a triggered subsystem. By doing so the contents of the controller block would only be executed at specified intervals becomes realistic. Under ideal conditions the controller block would execute at sampling period of 0.015 sec but in the actual implementation with the TrueTime block the network blocks provide the trigger signal to tell the controller when to execute. The idea was basic but the solution was more involved as it will be discussed. As a result the modified controller had slightly better performance than expected. Based on the obtained results it was decided to move forward with the modified controller and to refocus on the modeling of the network communication system. The network modeling was accomplished using a variety of Simulink blocks, most notably the TrueTime network and stand-alone TrueTime “Send” and “Receive” blocks. The network consisted of two (2) nodes being the data concentrator node and the controller node. The data concentrator has 12 analog connections to 12 sensors on the engine which include: fan speed, core speed, inlet temperature, compressor temperature, inlet pressure, compressor exit pressure, turbine exit pressure, fuel flow rate, altitude, Mach number, ambient temperature difference, and the power lever angle (PLA). The data concentrator packages the data and sends it to the controller node. Before doing so a time delay is applied to account for data acquisition, signal conditioning, A/D conversion and other delays due to the duties delegated to the data concentrator node. The data concentrator node also receives 5 signals from the controller which includes the fuel flow, variable stator vane, and variable bleed valve commands and also the off-nominal values of the variable stator vane and variable bleed valve. Another time delay was applied by the data concentrator node after receiving this data to account for data acquisition, signal conditioning, D/A conversion and other possible tasks delegated to the data concentrator node. The signals were then sent through direct analog connections to the actuators. The controller node receives the 12 sensor values mentioned above and returns the 5 actuator commands mentioned above. The controller node also applies a delay to account for the computational time needed for the control law. Figures 9 and 10 show the Simulink subsystems of the data concentrator and controller nodes respectively.


Figure 9. Data Concentrator Node Subsystem

Figure 10. Controller Node Subsystem In the TrueTime network simulation, both network nodes (concentrator and controller) contain a “Send” block and a “Receive” block. The Send block allow the user to specify the network number (if there are multiply network in the simulation), sender ID, the data input port dimension, the receiver ID, the data length, message ID, and some advanced options such as priority if a CAN protocol is being used or the type of segment if FlexRay is being used. The Receive block allows for the specification of the network number, receiver ID, and the output port dimension for the data that is to be received. The dialog boxes for these blocks are shown in Figure 11.


Figure 11. Dialog Boxes for the TrueTime Send (Left) and Receiver (Right) Blocks

The final block needed from the network’s block-set was the TrueTime Network block shown in Figure 12 with its dialog box. This block was placed on the top level of the engine model. As shown this block allows for the several inputs including the network type, network number, the number of nodes, the data rate, the minimum frame size, the loss probability, and an initial seed for the determining when data loss occurs. Depending on the selected network type more options are available. The option available for the network type are CSMA/CD (Ethernet), CSMA/AMP (CAN), Round Robin, FDMA, TDMA, Switched Ethernet, FlexRay, PROFINET, and NCM. Several of the parameters mentioned in the last paragraph were allowed to vary in the study such as loss probability, and others such as the network number or sender ID were simply chosen uniquely. However some parameters such as the data rate, minimum frame size, and data lengths had to be chosen realistically with the application to a gas turbine engine in mind. Based on the actual information the data rate was chosen to be 47764, the minimum frame size was 16, the data length of the sensor data was 240 bits and the data length of the actuator commands was 160 bits. Note that in an actual engine control application several more sensors could be used by the controller or by an engine health management unit and redundancy will be present as well which will raise the requirements on the communication system. However the 12 sensor values and 5 commands were the only signals requiring communication in the engine model so the demands were not as high.


Figure 12. TrueTime Network Block and Associated Dialog Box

4.3 SYSTEM TESTING AND PERFORMANCE EVALUATION A two states, two outputs, single input linear controller was developed and used to control the nonlinear engine model. The states used were the low pressure spool speed, N1, and the high pressure spool speed, N2. The outputs used were the outputs of the spool speed sensors which measured as a percentage of the maximum designed spool speed. To calculate the states from the outputs, the inverse of the C-matrix was taken. The C-matrix is square and invertible because it is a diagonal matrix. The sensor values are subtracted from the nominal operating condition before the states are calculated, since the developed controller is a linear-based controller. The controller gains were calculated to make the poles about three times faster than the original poles of the system using the pole place command in MATLAB. Their locations can be changed based on the performance requirements of the turbine engine. The demand is calculated from the PLA position based on an approximation of what the real engine uses. The PLA adjustment also adds the nominal value to convert the fuel ratio from the linear model to the nonlinear dynamics. After this, the actuator limiter from the original centralized model was included to ensure that a flame-out does not happen. Figure 13 below shows version of the controller that has been designed to take into account faults in the engine model. This controller used an observer to estimate the state values that were lost during a transmission failure. In the first test, a single observer was used with the full linear model and had observer gains with poles ten times faster than the controller. The observer would be running constantly until a fault occurred. When the fault occurs, the controller holds the error measured between the observer and old sensor measurement value constant until a new sensor measurement value becomes available. This setup allows current states to be maintained under accurate models and low initial error.


Figure 13. Implementation of the Developed Controller with Observer at the Nodes

To test the controller’s ability to stabilize the system, the engine simulation was started with nonnominal operating conditions and had to slow the engine down to its set point. The system architecture worked well and the system could regulate the engine using only normal design methods, even though sensor faults lasted longer than the discrete time was designed for. Using the observer designed above to account for transmission faults led to improved stability. Figure 14 shows the error seen by the observer and how the real sensor values responded. The linear model was imperfect, so when a transmission fault is active, the actual sensor value floated away from the nominal value. It was observed that if the transmission error continues past the maximum expected delay (MATI), then it will cause the engine model to become unstable. This instability caused by inaccuracies in the engine linear model. However, because the error was minimal, the controller was still able to stabilize the system from the initial perturbed state. As a result, the research team developed the needed skills and ability to implement and test different networked control architectures and will continue in future work to developed methods and use innovative techniques to handle problems encountered by the networked engine distributed controllers. So far we have been able to use and implement different methods to maintain the engine stability for longer periods of time under packet dropouts out than traditional control design under the same set point conditions. Additional research is currently underway to maintain the engine stability during transient flight conditions where the engine is highly nonlinear system.


Figure 14. Test Results With and Without Observer

5.0 SUMMARY AND CONCLUSIONS The goal of the conducted research was to analyze and synthesize a robust distributed controller to guarantee desired engine performance under network faults for full envelope operation. Specifically the technical objective of the conducted research was to investigate the stability and performance robustness of turbine engine distributed control systems under communication constraints like time delays, data loss and bandwidth limitations. In the work, a distributed networked control system utilizing a predictive control strategy was developed and implemented on turbine engine simulation model. The distributed control system was implemented in the form of individual smart processing nodes. These smart nodes consisted of individual communication modules and processing units that allow for local control actions. In the first implementation, a predictive control strategy was developed and used utilizing local state estimators providing needed information for the individual feedback controllers. Also, in a second implementation the control utilized an observer to recover the lost information of the engine state due to communication network failures. Detail development and implementation of the completed control strategy was presented in the report. Test results obtained from implementation of the communication network of the distributed networked control system showed performance robustness against some of network effects and failures. The distributed network control system was able to maintain acceptable engine performance with failures


in the communication network in the form of static and random transmission delay time. Such robustness of the engine performance under moderate and severe network failures was attributed to the success of the state estimator and observer in estimating the needed engine states feedback information for the distributed controller. All the technical objectives of the proposed research work were accomplished. As a result, the research team developed the needed skills and ability to implement and test different networked control architectures and will continue in future work to developed methods and use innovative techniques to handle problems encountered by the networked engine distributed controllers. We have been able to use and implement different methods to maintain the engine stability for longer periods of time under packet dropouts than traditional control design under the same set point conditions. Additional research is needed to maintain the engine stability during transient flight conditions where the engine is highly nonlinear system.

ACKNOWLEDGEMENTS The research was a collaborative effort between Tennessee State University (TSU) and the Ohio State University (OSU) under the technical monitoring of researchers at the AFRL. The authors would like to thank the sponsors United Technologies Corporation for the financial support of this research.

REFERENCES 1.

Shaffer, P. L., Distributed Control System for Turbine Engines, J. Engineering for Gas Turbines and Power, Vol. 121, No. 1, pp. 102-107 January 1999. 2. Watson M.J., Sheldon J.S., Lee H., Byington C.S., Behbahani A., Distributed, Integrated PHM and Control via Smart Engine Accessories for Future Modern Aircraft, 46th AIAA/ASME/SAE /ASEE Joint Propulsion Conference & Exhibit, 25 - 28 July 2010, Nashville, TN. 3. Behbahani A., Tulpule B., Perspective for Distributed Intelligent Engine Controls of the Future, 46th AIAA/ASME/SAE/ASEE Joint Propulsion Conference & Exhibit, 25 July 2010, Nashville, TN 4. Merrill W., Kim J.-H., Lall S., Majerus S., Daniel Howe D., Behbahani A., Distributed Engine Control Design Considerations, 46th AIAA/ASME/SAE/ASEE Joint Propulsion Conference & Exhibit, 25 - 28 July 2010, Nashville, TN. 5. DeCastro J.A., Palmer C.A., Behbahani A., Meeting the Requirements of Distributed Engine Control via Decentralized, Modular Smart Sensing, 46th AIAA/ASME/SAE/ASEE Joint Propulsion Conference & Exhibit, 25 - 28 July 2010, Nashville, TN. 6. Link C. Jaw and Sanjay Garg, Propulsion Control Technology Development in United States: A Historical Perspective, NASA, Technical Manual TM-2005-213978, Glenn Research Center, Cleveland, Ohio, Scientific Monitoring, Inc., Scottsdale, Arizona, October, 2005. 7. Culley D., Thomas R., Saus J., Concepts for Distributed Engine Controls, NASA, Technical Manual TM-2007-214994, Glenn Research Center, Cleveland, Ohio, November, 2007. 8. Culley D., Paluszewski P., Storey W., and Smith B., The Case for Distributed Engine Control in Turbo-Shaft Engine Systems, NASA, Technical Manual TM-2009-215654, Glenn Research Center, Cleveland, Ohio, September, 2009. 9. Culley D., and Garg S., Distributed Control Architecture for Gas Turbine Engine, NASA, Glenn Research Center, Cleveland, Ohio. 10. Behbahani, A. R., Culley, D., Smith, B. J., Darouse, C., Millar, R. C., Wood, B., Krodel, J., Carpenter, S., Mailander, W., Mahoney, T. D., Quinn, R., Bluish, C. P., Hegwood, B., Battestin, G., Roney, W.,


11.

12.

13.

14.

15.

16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.

Rhoden, W., and Storey, W., Status, Vision, and Challenges of an Intelligent Distributed Engine Control Architecture, SAE Paper 2007-01-3859, Sept. 2007. Behbahani, A., Adaptive Distributed Intelligent Control Architecture for Future Propulsion Systems, 61st Meeting of the Society for Machinery Failure Prevention Technology, Virginia Beach, VA, April, 2007 Behbahani, A. R., Achieving AFRL Universal FADEC Vision with Open Architecture Addressing Capability and Obsolescence for Military and Commercial Applications, AIAA Paper 2006-4302, July 2006. Richard Mgaya, Saleh Zein-Sabatto, Mohammad Bodruzzaman, Sachin Shetty, and Alireza Behbahani, Distributed Control Architecture for Decentralized Control Design of Turbine Engines, 58th International Instrumentation Symposium IIS, San Diego, CA, June 4-7, 2012. Yedavalli, R., Belapurkar, R., Behbahani, A., Design of Distributed Engine Control Systems for Stability under Communication Packet Dropouts, AIAA Journal of Guidance, Control and Dynamics, Volume 32, Number 5. Saleh Zein-Sabatto, Richard Mgaya, Mohammad Bodruzzaman, and Alireza Behbahani, Modeling and Simulation Studies of a Decentralized Architecture for a Distributed Turbine Engine Controls, 47th AIAA/ASME/SAE/ASEE Joint Conference and Exhibit (JPC), San Diego, CA, July 25, 2011. Culley, D., Behbahani, A., Communication Needs Assessment for Distributed Turbine Engine Control, 44th AIAA Joint Propulsion Conference & Exhibit, AIAA 2008-5281. Baillieul, J. and, Antsaklis, P.J., Control and Communication Challenges in Networked Real-Time Systems, Proceedings of IEEE, vol. 95, No. 1, January 2007. Zhang, L., Branicky, M.S., and Phillips, S.M., Stability of Networked Control Systems, IEEE Control Systems Magazine, February 2001. Scattolini, R., Architectures for Distributed and Hierarchical Model Predictive Control, Journals of Process Control, pp. 723-731. May 2009. Wahlisch, M., Modeling the Network Topology, http://page.mi.fuberlin.de/waehl/papers/w-mnt10.pdf, July 2013. Halton, NRC., Basic Network Concepts, http://brweb.haltonrc.edu.on.ca/202204/ICE4/Networks/Networking Concepts.pdf, July 2013. Krishnan, K., SFWR 4CO3, Computer Networks and Computer Security,2004. Tjensvold, J.M., Comparison of the IEEE 802.11, 802.15.1, 802.15.4, and 802.15.6 wireless standards, 2007. Welch, G., and Bishop, G., An Introduction to the Kalman Filter, Technical report, University of North Carolina at Chapel Hill, 2006. Jyh-Shing, and Jang, R., ANFIS: Adaptive-Networked-Based Fuzzy Inference System, IEEE Transactions on systems, Man, and Cybernetics, 1993. Takagi, T., and Sugeno, M., Fuzzy Identification of Systems and Its Applications to Modeling and Control, IEEE Transactions on Systems, Man, and Cybernetics, 1985. Baillieul, P., Control and Communication Challenges in Networked Real-Time Systems, Proceedings of IEEE, 2007. Zhang, Branicky, and Phillips, Stability of Networked Control Systems, IEEE Control Systems Magazine, 2001. Adedokun, T. and, Zein-Sabatto, S., Distributed Control System for Turbine Engine Optimal Operations, IEEE SoutheastCon '13, Jacksonville, FL, April 4-7, 2013. Conley, A. , and Salgado, M.E. , Grammian Based Interaction Measure, Proceedings of the 39th Conference on Decision and Control, pp. 5020-5022, December 2000.


31. Parker, K.I. and, Melcher, K.J., The Modular Aero-Propulsion System Simulation (MAPSS) Users’ Guide, Glenn Research Center, National Aeronautics and Space Administration, March 2004. 32. Ohlin, M., Henriksson, D. and, Cervin, A., TrueTime 2.0 beta–Reference Manual, Department of Automatic Control, Lund University, June 2010. 33. Soderstrom, T., Fan, H., and Carlsson. B., Least Squares Parameter Estimation of ContinuousTime ARX Models from Discrete-Time Data, IEEE Transactions on Automatic Control, 1997. 34. Parker, K.I. and, Melcher, K.J., The Commercial Modular Aero-Propulsion System Simulation (CMAPSS) Users’ Guide, Glenn Research Center, National Aeronautics and Space Administration, March 2004. 35. Khary I. Parker, Development of a Turbofan Engine Simulation in a Graphical Simulation Environment, Technical report, NASA Glenn Research Center, 2003.
