57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

Smart Sensors and Actuators for Distributed FADEC Systems

Dr. Bhal Tulpule, bhaltulpule@comcast.net, Embedded Systems LLC, Farmington, CT; Dr. Alireza Behbahani, al.behbahani@wpafb.af.mil, Air Force Research Laboratory, Wright-Patterson AFB, OH

Key words: distributed engine control, high temperature electronics, smart sensor, smart actuator, digital networks, 3. Bus Architecture, Protocol and Fault Tolerance
Abstract: This paper examines the issues and challenges involved in the development of a network of Smart Sensors and Actuators for the next generation of distributed propulsion control systems. The status of the current generation of propulsion system controllers is examined and the demands for transitioning to distributed architectures are analyzed. The issues, challenges and tradeoffs in the design of building blocks and architecture for the next generation of affordable, flexible and reliable FADEC systems are presented. Finally a preferred embodiment of the Smart Node for interfacing with sensors and actuators in a future distributed FADEC systems architecture is described.

ARCHITECTURE OF PRESENT AND FUTURE FADEC SYSTEMS

The developments in the field of electronics and controls over the last 25 years have given rise to emergence of digital electronic controls for managing complex control systems in the aerospace and other fields. The best example of this can be found in the development and evolution of propulsion engine control systems. Digital Engine Controls which were introduced in the 1970s evolved into Full Authority Digital Engine Controls (FADEC) in the 1980s in response to the demand for more controls capabilities made feasible by the increasing capabilities of electronics. This trend has continued and in fact accelerated in recent years where the need for increasing capabilities in terms of performance, reliability, maintainability and physical attributes has been propelled by increasing expectations of performance and miniaturization of electronics resulting in the demand for more innovative solutions. A typical FADEC system contains a central computer and interfacing electronics connected via dedicated cable harnesses to its associated control sensors and actuators. The FADEC receives the pilot throttle commands, electrical power and fuel from the aircraft and provides control signals and information to the on-aircraft systems and the pilot via communication channels. A block diagram of a typical centralized FADEC system and its interfaces are shown in Fig. 1. A significant part of the size, weight and cost of a FADEC system is the wiring harness which connects the sensors and actuators with the FADEC computer. The FADEC system must operate in the harshest, hottest environment found on the aircraft/ engine. The FADEC system is also the single most critical electronic component on the aircraft. These factors have limited or slowed down the transition of newer electronics technology into the FADEC. As a result todays FADEC systems contain electronics that lags behind technology that is available in the commercial world.

Copyright 2011 by ISA

57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

FADEC systems are usually implemented as dual redundant channels with identical FADEC computers and dual redundant sensors and actuators wherein each channel is fully capable of controlling the engine. A block diagram of a dual channel central FADEC computer is shown in Fig. 2. It consists of three major sections, namely, a processor section which implements all control laws, an IO hardware section which contains sensor and actuator signal conditioning interfaces and data bus interfaces, and a power supply section which conditions the aircraft power for use by the FADEC system. The redundant channels exchange sensor data, commands and health information over the Cross Channel Data Links (CCDL) for fail safe signal selection and Redundancy Management (RM).

Figure 1: Block Diagram of Centralized FADEC System and Interface The FADEC systems must meet stringent requirements for performance, cost and physical size and weight constraints. As a result todays FADEC is a centralized, highly optimized controller unique in its design and suited only for a specific engine and its specific compliment of sensors and actuators. The highly optimized nature of the FADEC system leads to lack of reusability and large System Development and Demonstration (SDD) investments and consequently to high cost of maintenance Including continuous obsolescence management due to the use of older, commercial electronic components. In addition to hardware, obsolescence of the FADEC also requires software changes both of which are very costly. These significant disadvantages of centralized FADEC systems and the potential benefits of distributed architecture FADEC where the major elements of the FADEC are distributed around the engine and interconnected via a network of data buses have been discussed in

Copyright 2011 by ISA

57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

the literature {1, 2}. However, the successful transition to a distributed architecture FADEC system requires the resolution of all of the technical issues and design challenges in order to achieve an affordable, reusable and modular architecture and set of building blocks. These issues and challenges are discussed in the next section.

Figure 2: Dual Channel Centralized FADEC and Functions The need for transitioning to distributed architectures is also being driven by the need for eliminating or at least reducing the thermal cooling of the FADEC computers. This is because system designers are looking at distributed architectures as a potential solution for reducing the need for fuel cooling of electronics. The current generations of FADEC computers designed using commercial/ industrial electronic devices have a max operating limit of 1250 C which is well below the ambient temperature around the engine. Commercial engine FADEC systems are air cooled while military FADEC computers normally require fuel cooling due to their higher performance capabilities and heat loads. These thermal loads have been increasing rapidly and are projected to be much larger for next generation military aircrafts. The combination of high thermal loads and the demand for LowObservability (LO) have placed operational limits on the use of ram air as a heat sink leaving the system designers to increasingly rely on fuel as the primary heat sink. However, using the fuel as a heat sink increases its temperature resulting in unacceptable limitations on air and ground operations. 1.1. High Temperature Electronics

The single biggest obstacle to the deployment of distributed architectures has been the lack of an adequate portfolio of High temperature capable electronic devices. The Government has long recognized this need and paved the way for the technology development of High Temperature electronics {3}. However the market potential of these devices for distributed FADEC applications has remained elusive. More recently the Government has sponsored SBIR (Small Business Innovative Research) programs to evaluate and demonstrate the capabilities of available High Temperature electronics. In 2007 the Scientific Advisory Board (SAB) recommended {4} the development and

Copyright 2011 by ISA

57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

deployment of High Temperature Electronics in order to reduce the need for cooling of electronic systems. Availability of a rich portfolio of High Temperature (~2250 C) electronic components would enable the implementation of distributed architecture FADEC and reduce or eliminating the need for fuel cooling. Among the available High Temperature technologies, Silicon On Insulator (SOI) technology based electronics seems most appropriate for control system applications in terms of feasibility, cost, industrial infrastructure and long term durability. However, our studies have shown that the SOI technology and portfolio of components have several gaps in the scope, level of integration and performance of functions available. SOI components are expensive because of market size. Therefore there is strong need for eliminating these limitations and develop more capable components and higher levels of integration of functions in order to reduce the cost and size of the building blocks of the distributed architecture. 1.2. Distributed Architecture FADEC

The block diagram of a notional distributed architecture FADEC is shown in Fig. 3. This hierarchical architecture consists of, building blocks or Nodes that could be distributed around the engine in close proximity to the sensors and actuators to the extent possible in order to minimize the size of wire harnesses. The building blocks are interconnected with the help of data buses which carry information and commands to and from the various building blocks. At the lowest echelon of the network are Nodes which are connected to dedicated set of sensors and actuators. The data Concentrators in this architecture are responsible for, as a minimum, collecting and distributing data received from the Nodes and passing it on to the supervisory FADEC which, is responsible for implementing the control laws and managing the propulsion system as a whole. Clearly a number of variations of this notional architecture are possible depending on the functional partitioning of the FADEC. This partitioning of the FADEC involves the resolution of multiple architectural issues and technology limitations which can have a profound impact on the characteristics of the various building blocks. These issues which transcend the availability and capabilities issues relating to the portfolio of High Temperature electronics are discussed in the next section.

Copyright 2011 by ISA

57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

Figure 3: Notional Distributed Architecture FADEC and Building Blocks 2. Issues and Challenges Beyond High Temperature Electronics A. IO Interface Requirements The feasibility of implementing laboratory prototype building blocks of distributed architecture using the increasingly available High Temperature capable SOI technology devices has been demonstrated under Government sponsored SBIR projects {5, 6}. However, going forward, it would be unaffordable to custom design and qualify Nodes capable of interfacing to a specific set of sensors and actuators. To be affordable these modules must be flexible and capable of interfacing with multiple different sensors and actuators so that they can be used by different FADEC developers for multiple applications. However this is a major challenge because the number and types of sensors and actuators associated with a FADEC have been growing in quantity over the years, particularly in the military propulsion systems. These increases are driven by a combination of the need to derive more performance, manage complexity and improve diagnostics capabilities. Not withstanding these increases, the diversity of the types and interface requirements for sensors and actuators requires a common design approach so that the Nodes can be of reconfigured and used for interfacing with a wide class of sensors and actuators. In the absence of such a flexible design, each Node would become a custom design with highly customized interfaces and would be not affordable or maintainable. B. Smart Vs Dumb Terminals

Copyright 2011 by ISA

57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

The second question in the architectural partitioning of the FADEC functionality is the level of intelligence or information processing that should be performed at each level in the hierarchy. Specifically, what types of processing should be done at the Node level? At one end of the spectrum would be a Smart Node that locally performs most, if not all of the tasks associated with the local sensors and actuators. A Dumb or simple Node on the other hand would essentially be a data converter capable of converting information between a data bus and the analog signals associated with sensor and actuators. A simple Node would not probably involve a digital processor and no processing of the data would be locally performed. A block diagram of these two extreme cases is shown in Fig. 4 and 5 respectively. These extreme versions have their advantages and disadvantages. A simple Node would be very easy to construct and the verification of the firmware (as opposed to software) would be easier. However such a Node may not remain simple because it must include complex (i.e. custom) circuitry to perform the reconfiguration of the signal conditioning interfaces. Otherwise even simple tasks such as calibration or source error correction would have to be performed at the Data Concentrator level. The Smart Node on the other hand would contain a processor and other circuitry needed to perform all of the data processing locally. The Node would acquire and distribute data to and from the sensors and actuators and send it to over the data bus to the data Concentrator and beyond. Calibration, source correction and configuration management would be locally performed and would help reduce the cost of diagnostics and the logistics trail would be shortened. The tradeoff of these issues must be performed in the context of the capability of High Temperature electronic devices available and the near term implementation feasibility in order to realize an affordable Node design for the future.

Figure 4: Block Diagram of Simple Node

Copyright 2011 by ISA

57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

Figure 5: Block Diagram of Smart Node C. Bus Architecture, Protocol and Fault Tolerance

A direct consequence of the level of smartness embedded in the Node will be felt in the amount of information that will have to be transferred to and from the Nodes. While a smart Node will need to be commanded only periodically, a simple Node will require large amount of real time data transfers. An estimate of the large bandwidth needed to support such date transfers in a simple Node based system was performed in {7}. In any case, this need for large data amount of data will in turn require very high bandwidth data buses to be implemented in hardware with their associated complexity and design size/cost. A review of the capabilities of current generation High Temperature SOI devices indicates that it will be very difficult and expensive to implement high bandwidth data buses in hardware. Data buses with low bandwidth would be the preferred solution at this time. Beyond the issues of hardware implementation, this choice of the bus will also require us to address the synchronization and fault tolerance aspects of the communication architecture of the information network that must be put together to connect all these Nodes and manage them. Powerful distributed Network architectures such as the one deployed by Honeywell {8} might be required to manage the large amount of data associated with simple Nodes where as low speed serial data buses may be adequate for networking the Smart Nodes. The issue of fault tolerance for the Network is particularly important in this context because of the highly critical nature of propulsion systems. In a complex distributed Network the deterministic management of events and data and the ability to provide fault tolerance of the Network is absolutely critical. High speed, hard-real time buses such as TTP, CAN and Fabric that have the potential for meeting these challenges may be appropriate in case of simple Nodes wherein the fault tolerance of the system may be managed by the Data Concentrator in the network. However, preliminary studies have shown that these buses require very large custom ASIC

Copyright 2011 by ISA

57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

(application Specific Integrated Circuit) devices with lots of gates and are therefore beyond the capabilities of todays SOI technology. D. Redundancy Management Beyond the fault tolerance of the Network, the designers of FADEC systems must also deal with the redundancy of the hardware. Most FADEC systems are usually dual in nature containing dual sets of sensors, actuators and computers. Information from the dual sensors is managed in a time synchronous, fault tolerant manner by the FADEC computers and used to control redundant sets of actuators in the presence of failures. Going forward, in a distributed system how and where the Redundancy Management (RM) is performed can have significant impact of the characteristics of the communication Network that connects these Smart Nodes, Data Concentrators and supervisory FADEC computers. This is particularly true in case on Nodes associated with redundant channel actuators. The fault tolerant management of such actuators requires the voting (selection) of best actuator position signal among the redundant channels, closing of the command-to-feedback-loop and generation of the dual redundant position command for the actuator drive circuitry in the redundant channels. In a simple Node based system these actuator RM functions would have to be performed in the Data Concentrators requiring significant additional bandwidth for sending the loop closure signals and position commands. In high performance actuation systems requiring loop closures at 10-20 Hz, many of the inner loops are required to be closed at 500 to 1000+ Hz placing a very large burden on the data buses associated with the simple Nodes. This burden on the data bus network increases with the number of (redundant) actuators in the system and may therefore become unsustainable in the context of the technology capabilities of the current generation of High Temperature SOI devices. In a Smart Node based FADEC many if not all of these actuator RM functions can be performed locally thereby avoiding any need to increase the bandwidth of the serial data buses in the system. Clearly, this benefit will come at the cost of more complexity in the Smart Node and therefore must be traded off against limited capabilities of the High Temperature electronics to implement complex, high bandwidth fault tolerant data buses. E. Where does the FADEC Reside? The location of the FADEC in the harsh, High Temperature on-engine environment has always been a topic of discussion in the engine control community consisting of Government procurement organizations, Engine OEMS and FADEC developers. The procurement and maintenance organizations would prefer the FADEC to be located somewhere else away from the harsh, high temperature environment of the engine. They contend that the FADEC would benefit in terms of reliability and capability from being in a cooler environment by using many of the latest powerful COTS (Commercial Off The Shelf) electronic devices. The FADEC could also be constructed with plug in modules permitting the easy upgrades or changes of modules or devices required due to obsolescence or design upgrades etc. Still others, particularly the aircraft and missile developers, pressed by the need to reduce size or weight would like to combine the FADEC function with other functions such as flight controls or mission computers. The Engine developers and FADEC makers have been able to resist this pressure to move the FADEC off the engine, for a variety of good reasons. First, moving the FADEC off engine would require all those cable harnesses to be extended by many feet resulting in significantly increased weight and cost

Copyright 2011 by ISA

57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

and reduced system reliability. Second, the issue of where to place the FADEC on the aircraft would require the cooperation of air framers and engine developers. From a business standpoint, this would be inconsistent with established procurement processes in the Govt. and commercial world. Todays FADEC are an integral part of the engine and aircraft makers provide plug-in alternate engines as a total package. Finally, moving the FADEC off the engine is not going to speed up the insertion of more capable commercial COTS technology because this process requires an systematic, deliberate approach in which the reliability and long term durability of IC components must be proven to a very high degree of certainty regardless of whether the FADEC is on the engine or not. In a distributed architecture system it would be at least technically feasible to move the supervisory FADEC off the engine into a more benign environment and improve its performance capability by populating it with commercial electronics. The decision to move the supervisory FADEC off engine would then depend on other issues such the platform involved (missile Vs aircraft) or procurement practices and so on. As for the Nodes, they would have to be implemented using High Temperature electronics and would have to remain on the engine in as close proximity to the sensors and actuators as possible. F. Power Distribution The FADEC is the most critical electronic component responsible for the safe and reliable operation of the engine and propulsion systems and consequently for the air vehicle. The FADAC is therefore powered from multiple sources of power including, the Integrated Drive Generator (IDG) that runs off the engine, Auxiliary Power Unit (APU) which may be on or off the engine, Permanent Magnet Alternator (PMA) and in some cases (e.g. UAVs) even batteries. The management and conditioning of these power sources has been traditionally done on the engine. In a distributed architecture, if the FADEC is moved off the engine and/or integrated with other control systems, the question of how to power the sensor and actuators must be addressed. Specifically, the power needed by the (Smart or simple) Nodes would preferably be conditioned on the engine in order to avoid any critical breaks in the delivery of this power. However this must be traded against the weight and cost of a 2nd on-engine power generation system that can be avoided by an integrated off-engine power generation and distribution system. The type of relatively low voltage DC power required by the sensors and majority of actuators may be provided by an aircraft power bus such as Mil-Std-704 as opposed to dedicated local power supplies on the engine. It is noted that while this issue may appear secondary in nature to the implementation of distributed FADEC architectures, it has significant impact on the reliability of the overall FADEC system and deserves special attention and a careful tradeoff in order to achieve a balance of physical constraints, cost and complexity issues, to name a few. 3. Preferred Embodiment Embedded Systems has investigated the issues and challenges described above in the context of the capabilities of High Temperature SOI technology and devices available and feasible in the near future. These investigations and prototype designs have led us to the conclusion that a Smart Node (as opposed to a simple Node) based distributed architecture FADEC system is both feasible and affordable. The essential features of and requirements for the preferred embodiment of this Smart Nodes based architecture are described below.

Copyright 2011 by ISA

57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

The block diagram of preferred embodiment of the Smart Node, shown in Fig. 6 is built around a digital processor and associated memory, and A to D Converter all of which are available as High Temperature SOI technology devices. The processor interfaces with a collection of sensor signal conditioning interfaces. These signal conditioning interfaces are reconfigurable so that they can be used to interface with a wide variety of sensors and actuators as appropriate. The Node also consists of reconfigurable actuator drive interfaces capable of interfacing with most typical actuators found in FADEC systems. The processor periodically collects the sensor data and preprocesses it before sending it to the host, i.e. Data Concentrator or a supervisory FADEC (see Fig. 3) for further processing. The preprocessing tasks involve calibration, source error correction and any other computations that are required and can be to be performed on the sensor data. The Smart Node also acquires the actuator position signal and preprocesses it before sending it to the host computer. The Smart Node is capable of receiving redundant sensor data and performing RM operations locally before sending the selected signal data to the host. The Smart Node can be programmed to locally perform the actuator loop computations including RM and Built-In Tests (BIT) and command the local actuator drive circuitry. Since the actuator commands are generated at a much slower rate ( < 120 Hz) as compared to the rate at which the actuator control loop calculations are performed (> 500 Hz), doing all these computations locally does not require the use of the serial buses and therefore requires no additional bandwidth for the serial data bus. The Smart Node design therefore can be implemented using the available or near term feasible sets of High Temperature SOI devices. Our analysis shows that a simple standard serial data bus such as RS-485 can adequately meet these bandwidth needs of a Smart Node.

Figure 6: Preferred Embodiment of Smart Node Clearly a number of variations of this notional Smart Node configuration based distributed architecture are possible. For instance, the number of sensors and actuators managed by the Node may be adjusted from 1 to N depending on the application. Alternately, several of the building blocks in the Node or even entire Nodes may be incorporated in the Data Concentrator making it a super Node for managing multiple sensors and actuators. As for the distribution of software functions, they can be allocated to

Copyright 2011 by ISA

57th International Instrumentation Symposium, St Louis, MO; 20 June 2011 through 24 June 2011

the Smart Nodes, Data Concentrators or even the supervisory FADEC or a combination of all these depending on the application and the bandwidth of the data buses involved and the criticality of the propulsion system. 4. Summary The transition of propulsion control FADEC systems to distributed architectures has begun. The development of High Temperature capable Smart sensor and actuator Nodes for distributed architecture FADEC involves the consideration of multiple issues, challenges and tradeoff of alternate configurations. This paper has presented a review of the architecture of present and future generations of FADEC systems and examined the rationale for the transition to distributed architectures. The various issues and challenges that must be addressed in order to arrive at an affordable and reliable distributed FADEC system have been examined. A preferred embodiment of the Smart Node for sensors and actuators is presented.

5. References

1. Tulpule, Bhal , Behbahani, Alireza and Millar, Richard , Vision for Next Generation Modular Adaptive Generic Integrated Controls (MAGIC) for Military/Commercial Turbine Engines, American Institute of Aeronautics and Astronautics, JPC 2007. 2. Behbahani, Adaptive Distributed Intelligent Control Architecture for Future Propulsion Systems, MFPT Conference, Virginia Beach, April 2007. 3. DARPA HiTeC program final report, dated August 24, 1999, Air Force Agreement number F33615-96-2.2618). 4. Scientific Advisory Board Report, # SAB-TR-07-05-NP, August 2007. 5. SBIR Topic N07-175, Intelligent Sensor for Distributed Engine Control for Advanced Propulsion System Application. 6. SBIR Topic N05-012, Generic Electronic Interface Module for High Temperature Actuators, Oct. 2004. 7. Culley, D. and Behbahani, A., Communication Needs Assessment for Distributed Turbine Engine Control, AIAA Paper # 2008-5281, July 2008. 8. Hall B., Paulitsch M., Benson D., Behbahani A, Jet Engine Control Using Ethernet with a BRAIN, 44th AIAA/ASME/SAE/ASEE Joint Propulsion Conference & Exhibit, AIAA-20085291.

Copyright 2011 by ISA