smart sensors and actuators for distributed fadec systems

7/30/2019 Smart Sensors and Actuators for Distributed FADEC Systems

1/11

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

Copyright 2011 by ISA

Smart Sensors and Actuators for Distributed FADEC Systems

Dr. Bhal Tulpule,[email protected], Embedded Systems LLC, Farmington, CT;

Dr. Alireza Behbahani,[email protected], 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 ofSmart 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 thedesign 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.

1 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 andother 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 FullAuthority Digital Engine Controls (FADEC) in the 1980s in response to the demand for more controlscapabilities 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 ofperformance and miniaturization of electronics resulting in the demand for more innovative solutions.

A typical FADEC system contains a central computer and interfacing electronics connected viadedicated 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 componenton the aircraft. These factors have limited or slowed down the transition of newer electronicstechnology into the FADEC. As a result todays FADEC systems contain electronics that lags behind

technology that is available in the commercial world.
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/11



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 FADECsystem. The redundant channels exchange sensor data, commands and health information over theCross 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 andweight 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 SystemDevelopment and Demonstration (SDD) investments and consequently to high cost of maintenanceIncluding 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 thepotential 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


3/11



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 challengesare 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 ofelectronics. 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 FADECcomputers 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 Low-

Observability (LO) have placed operational limits on the use of ram air as a heat sink leaving thesystem 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 ElectronicsThe single biggest obstacle to the deployment of distributed architectures has been the lack of anadequate 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 hasremained 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


4/11



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 forfuel cooling.

Among the available High Temperature technologies, Silicon On Insulator (SOI) technology basedelectronics 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 andperformance 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 thedistributed architecture.

1.2. Distributed Architecture FADECThe 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 closeproximity 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 areNodes 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 thisnotional 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 HighTemperature electronics are discussed in the next section.


5/11



Figure 3: Notional Distributed Architecture FADEC and Building Blocks

2. Issues and Challenges Beyond High Temperature ElectronicsA. IO Interface Requirements

The feasibility of implementing laboratory prototype building blocks of distributed architecture usingthe 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. Tobe 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 propulsionsystems. 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. Inthe 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


6/11



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 localsensors 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 withsensor and actuators. A simple Node would not probably involve a digital processor and no processingof 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 beeasier. 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 circuitryneeded 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 wouldhelp 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


7/11



Figure 5: Block Diagram of Smart Node

C. Bus Architecture, Protocol and Fault ToleranceA 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. Anestimate 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 veryhigh bandwidth data buses to be implemented in hardware with their associated complexity and designsize/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 informationnetwork 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 particularlyimportant 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 Nodeswherein 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


8/11



(application Specific Integrated Circuit) devices with lots of gates and are therefore beyond the

capabilities of todays SOI technology.

D. Redundancy ManagementBeyond 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 supervisoryFADEC 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 redundantchannels. 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 signalsand 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 thecontext 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, thisbenefit 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 maintenanceorganizations 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 powerfulCOTS (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 otherfunctions such as flight controls or mission computers.

The Engine developers and FADEC makers have been able to resist this pressure to move the FADECoff 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


9/11



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 atotal 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 approachin which the reliability and long term durability of IC components must be proven to a very highdegree 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 enginewould 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 DistributionThe 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 thereforepowered 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 theFADEC 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-enginepower 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 dedicatedlocal 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 abalance of physical constraints, cost and complexity issues, to name a few.

3. Preferred EmbodimentEmbedded Systems has investigated the issues and challenges described above in the context of thecapabilities 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 SmartNodes based architecture are described below.


10/11



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 signalconditioning 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 inFADEC systems. The processor periodically collects the sensor data and preprocesses it before sendingit 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 actuatorposition 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 forthe 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 architectureare 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


11/11



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. SummaryThe transition of propulsion control FADEC systems to distributed architectures has begun. The

development of High Temperature capable Smart sensor and actuator Nodes for distributedarchitecture 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 andactuators is presented.

5. References

1. Tulpule, Bhal , Behbahani, Alireza and Millar, Richard , Vision for Next Generation ModularAdaptive 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 numberF33615-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 EngineControl, AIAA Paper # 2008-5281, July 2008.

8. Hall B., Paulitsch M., Benson D., Behbahani A, Jet Engine Control Using Ethernet with aBRAIN, 44

thAIAA/ASME/SAE/ASEE Joint Propulsion Conference & Exhibit, AIAA-2008-

5291.

smart sensors and actuators for distributed fadec systems

Documents