7th Annual Conference on Systems Engineering Research 2009 (CSER 2009)
Distributed Control Systems for Aero Gas Turbine Engines: A wicked problem for systems engineering? D. Bourne1, R. Dixon2 and A. Horne3 1
Loughborough University/Aero Engine Controls (A Rolls-Royce plc and Goodrich Corporation Joint Venture), UK,
[email protected] 2 Loughborough University, UK,
[email protected] 3 Aero Engine Controls (A Rolls-Royce plc and Goodrich Corporation Joint Venture), UK,
[email protected]
Abstract Present day jet engines are controlled and monitored by a series of hydraulic, fueldraulic, electrical and pneumatic sub-systems known as the Full Authority Digital Engine Controller (FADEC). At the heart of the FADEC lies a centralised Electronic Engine Controller (EEC) responsible for control and safety of the wider engine system. It has long been postulated that a distributed EEC would contribute to improvements in control system performance and life-cycle costs which the aerospace industry demands. Despite an extensile list of potential benefits and the belief that the obtrusion of distributed control systems is inevitable, such systems have yet to become commonplace in large civil gas turbine engines. This paper proposes that distributed control system development is complex problem with difficulties well beyond the challenge of designing, implementing and proving technology. Distributed systems hosting present day functionality are unlikely to contribute the life-cycle savings necessary to overcome these risks; their role as a platform for new technologies which may increase fuel efficiency and engine ‘intelligence’ complicates viability assessment. Beyond commercial factors, the technical design problem is inherently complex. The flexibility and scalability of distributed systems are undoubtedly major benefits, yet such flexibility presents a vast range of design options that complicates design, realisation and assessment of optimal solutions. This paper presents a framework for the design and analysis of distributed control system for gas turbine control. The understanding behind the framework was derived form an analysis of distributed control system design as a wicked problem. Keywords: Distributed Control System, FADEC, Genetic Algorithm, Wicked Problem, Framework 1 Introduction Jet engines for large civil aircraft are commonly controlled and sustained during flight by a Full Authority Digital Engine Controller (FADEC). The FADEC comprises the fuel, oil, hydraulic, pneumatic, fueldraulic and electrical sub-systems under the control and supervision of an Electronic Engine Controller (EEC). The EEC is a dual redundant computing system hosting engine control, monitoring and safety functions. Each channel has an independent power supply, computing platform and interface circuitry all residing in a single physical unit. The EEC interprets the pilot thrust demand and controls the engine subsystems to achieve the desired performance. Furthermore, the EEC is responsible for the prompt shutdown of the engine in the event of an over-speed or over-pressure condition which could otherwise compromise the engine or airframe. The sensors and actuators associated with the engine sub-systems are located across the engine chassis and connected to the EEC by wiring harnesses. It is commonplace that the EEC is mounted on the engine fancase to protect the electronics from the extreme heat and vibration of the compressor, combustor and turbine stages. Distributed Control Systems (DCSs) involve the division of a centralised control system into individual sub-systems comprising of smart sensors, actuators and controllers; each
separate sub-system is known as a node and contains processing capability. The nodes reside in different physical locations and communicate via a shared data network. The sensors and actuators may exist as independent network nodes or be directly coupled to a controller node. A typical DCS architecture is shown in Figure 1. The concept has been fuelled by the proliferation of low cost microcontrollers for distributed processing and developments in real-time network. a1
s1
c1
a2
s2
c2
a3
s3
c3
Command Module
Figure 1 – A typical distributed control system architecture. 'c’ denotes a controller node, ‘s’ a sensor node and ‘a’ an actuator node. The bold line represents a digital communications bus. Distributed control systems may take many architectural forms.
Loughborough University – 20th - 23rd April 2009
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) It has long been postulated that a distributed EEC may provide substantial benefits for engine controller performance and contribute to the reduction in life-cycle costs the aerospace industry strives for. Furthermore, it is anticipated that current FADEC systems would be incapable of meeting the increased burden imposed by the advanced intelligent propulsion system concepts proposed for future engines. A number of research and demonstration projects such as Rolls-Royce High Performance Engine Control System (HiPECS) have considered distributed control systems for use in aero-engines, yet none have been commercially realised. Despite this, the introduction of DCSs is seen as an inevitable technological advance. This work described in this paper stemmed from a research project conceived by Aero Engine Controls (A Rolls-Royce and Goodrich Corporation Joint Venture Company) to investigate Distributed Control systems for application on large civil jet engines. It was proposed that the research work would investigate the following important areas… • Partitioning • Safety • Fault detection and accommodation • Reliability • Life-cycle cost • Development Cost By taking a systems approach, it has been possible to better understand the nature of the project and the DCS problem the notion of a “wicked problem” has been used as a tool to facilitate a wider and more structured understanding of the constraints. This understanding has been used to propose a way forward in order to demonstrate the technical and business case for DCS on aero-engines. By using a systems approach to analyse the problem, the stakeholder requirements and constraints, the authors propose a framework to facilitate the design and analysis of real-time distributed systems. In this regard, the aim is to build models within this framework so that candidate distributed control architectures may be evaluated. Once the models have been constructed, it is hoped that a genetic algorithm may be used to optimise distributed architectures to meet both technical and commercial constraints. 1.1 Structure of the paper The remainder of this section presents some of the background on why the authors believe a systems approach is necessary. Section 2 reviews some of the key works on DCS with particular focus on application to gas turbine engines. In section 3 the benefits and technological constraints are discussed. Section 4 discusses the use of the wicked problem to help understand the issues associated with DCS application in aero engines and section 5 identifies the need for a framework by which to describe and evaluate distributed EEC systems. By using a systems approach to analyse the design problem, the stakeholder requirements and constraints, the authors intend to build and verify a framework to facilitate the design and analysis of real-time distributed systems. The framework consists of four different views of the distributed EEC system – an architectural view, a functional view, a commercial Loughborough University – 20th - 23rd April 2009
viability view and a life-cycle view. The aim of the research is to build dynamic models within these views so that candidate distributed control architectures may be evaluated. Once the models have been constructed, it is hoped that a genetic algorithm may be used to optimise distributed architectures to meet both technical and commercial constraints. Section 6 introduces the framework proposed and section 7 the application of genetic algorithms to tackling the design problem. The approach uses knowledge gained using a classical systems approach to build the basis of for a system science solution. It is hoped that the framework and optimisation technique will allow all stakeholders to discuss the distributed control system design from a common basis. 2 Previous work There is a surprising lack of academic and popular literature relating to the design and implementation of real time distributed control systems for safety critical applications. Much of the research broadly related to distributed systems has focused on dynamic task allocation and communications scheduling for parallel computing platforms where absolute determinism is non-essential [1]. In 1983, Mok published material highlighting the fundamental technical design problems related to software and communications design for real time distributed systems and proposed enhancements to an abstract model for designing distributed applications from textual requirements [2]. There have been continued efforts to develop the real-time communications technologies required for DCS implementation. Papers such as Kopetz et al [3], Koptez et al [4] and Yedavalli et al (2008) [5] focus on clock synchronisation and temporal firewalls which are features of modern real-time communications technologies such as the Time-Triggered Protocol (TTP) [6] and FlexRay. Furthermore, many academics have considered the stability of distributed control systems under data rate constraints, packet loss and network failure. (see [7] [8] [9] for example). Perhaps the most everyday application of distributed control systems has been in the automotive industry where controller area networks (CAN) have been used extensively to permit communication between distributed processing elements located throughout the car. Work in this area has focused on increasing the determinism of the CAN network through the application of Time-Triggered CAN to “bywire” systems. Papers from Short and Pont [10] and Fuhrer et al. [11] address the issue of determinism and fault tolerance of TTCAN and the wider application to distributed control. However, the environment and nature of distribution in the jet engine is very different from the automotive applications – the functionality is very highly coupled and almost wholly dependant on real-time communications. Therefore, lessons learned in the automotive sector provide a stimulus for discussion rather than a direct contribution to application in jet engine control.
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) Literature discussing the design of distributed systems from a systems engineering perspective is limited. This is equally true of literature discussing the difficulties of architecting such systems and ensuring their safety. Hermann Kopetz’s book [4] is one of the few texts addressing distributed control system design with a holistic perspective. In response to industrial and research interest, NASA formed the Distributed Engine Controls Working Group (DECWG). The working group is a collaboration between NASA research staff and industrial representatives. The DECWG has published a number of papers discussing the potential befits and challenges faced by DCS designers in the aerospace industry and further discussion on communications technologies and the development of the High Temperature Electronic Devices (HiTEDs) necessary to realise such systems[12] [13]. A principle aim of the DECWG is to agree and establish an open communications standard for distributed FADEC applications; they acknowledge the commercial challenges of such a proposal. At the time of writing, the DECWG, have not yet published literature explaining how they intend to approach or solve this problem. Benefits and Technical Constraints of Distributed Control Systems for Large Civil Jet Engines Whilst engineers consider the obtrusion of distributed control systems ostensibly beneficial, the endowments of such systems are seldom collated and discussed. Perhaps the most touted benefit of DCS (yet not necessarily the most important) is the potential to reduce the amount of harnessing which `dresses' the engine. Harnessing is not only complicated to manage, expensive and potentially fault prone, but innately heavy. A typical dual-channel centralised controller for large civil get engine would require 10 harness each composed of up to 30 wires for sensor and actuator signals, with additional interfaces for power and connection to the airframe data network. Harnessing on a modern engine may weigh in excess of 80Kg and the centralised EEC a further 20Kg. With distributed nodes connected by a two-wire network and power supply cables alone, a significant weight reduction is anticipated. A ring network topology would give a considerable reduction in harness length when compared to the current star configuration required for a centralised system. Furthermore, as the weight and length of harnessing is reduced, so is the substantiality and number of mounting points and fixings required on the engine casing; associated savings may include part count, assembly time and ease of replacement. Harness faults are notoriously difficult to detect during operation and frequently result in the unnecessary removal of operative sub-systems during maintenance and repair actions.
reusable elements without extensive redesign. Careful design should permit modules to be used across different engine platforms and reduce certification and testing costs. Deterministic time-triggered communications protocols should allow nodes to be fully developed and tested in isolation prior to integration if controlled by a suitably defined schedule. Functional segregation of the system should engender functionally simpler units - this offers a potential decrease in software complexity and subsequent increase in testability and reliability. The communications interface should allow both design assurance and product assurance testing of individual nodes to be undertaken using data directly from models rather than requiring complex test rigs to generate sensor measurements and actuator responses, thus saving test-rig commissioning time and improving fault isolation. Moreover, the data network engenders a level of abstraction between individual nodes; therefore, obsolescence control may be achieved by updating the underlying node hardware without affecting other elements of the network. This in turn would prevent the need for lifetime purchase of components, application-specific components and would promote use of up-to-date hardware as a platform for new capability.
3
Modularity, composability and extensibility are interrelated key attributes of distributed systems. From the perspective of the system developer, modular design would reduce time-to-market as systems could be assembled from
From the perspective of the operator and engine manufacturer, modularity allows new functionality to be added after the system has been commissioned. Providing each node were suitably accessible to service technicians, faulty elements could be easily removed and replaced without having to remove the entire EEC. Natural segregation offers potential improvements in fault isolation thus reducing the number of “fault-not-found" removals. Replacement parts may be individually cheaper. As the notion of distinct redundant channels could be lost in a distributed system, it may be possible for the number of Time Limited Despatch (TLD) configurations to be increased; sensors and actuators may no longer be specific to a single channel but readily dual redundant to the whole network. It is desirable to isolate control and safety functionality to avoid common faults. The use of dissimilar network topologies for the primary and secondary redundant network would allow the surviving elements of each to continue data flow between nodes even if elements of both networks were damaged. Modularisation permits functionality to be distributed around the engine for protection against engine debris, or in the military case, combat damage. There are of course technical constraints: Owing to the harsh operating environments of the gas turbine engine, many proposed technologies require HiTECs for realisation. Because devices capable of withstanding such environments are not readily available, companies refrain from undertaking the wider systems engineering projects required to design and introduce the new capability which requires them. However, a vicious cycle is closed as an apparent lack of demand perturbs high-temperature component manufactures from researching and developing technologies for which they perceive there is a limited Loughborough University – 20th - 23rd April 2009
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) market. Upon initial consideration, the design problem is straight forward; not without complexity, but apparently achievable and no more complex to define or achieve than many other systems engineering challenges. All levels of stakeholder appear to benefit and the scope of the system seems highly contained. So, given the number of the potential technical benefits, plausible cost savings and the lack of stabile constraints, why have DCSs not achieved prevalence? 4
Wider constraints to Distributed System Implementation Whilst previous work focused on the more technical aspects of their design, the reasons why distributed systems have failed to become commercially viable are perhaps less tangible. By following a systems engineering approach the author has attempted to analyse the design problem and the stakeholder requirements. Many requirements from lower tier stakeholders are represented through the four prime stakeholders identified – the system developer’s commercial perspective, the system developer’s technical perspective, those maintaining the system’s capability throughout its 25 year life-cycle and the engine manufacturer. For example, the views of airlines and airframer are wholly represented through the engine manufacturer and the role of legislation and certification requirements through all the aforementioned parties. Taking the benefits, commercial constraints and legislation together, it is difficult for the designers and advocates of distributed systems to make a sound case for the introduction of the technology. To better understand the broader constraints, this research has used the notions of “wicked problem” as a tool for analysis. Wicked problems [14] [15]are difficult or impossible to solve because of incomplete, contradictory, and changing requirements and may be chararcterised by ten criteria. The emergence and design of distributed EEC systems have many features in common with wicked problems. The five most pertinent commonalities are discussed presently…
4.1 The problem cannot be easily defined The need for distributed control systems is notional, not clearly defined. Distributed systems lack a clear operational objective and have been conceived from technical possibility rather than distinct customer requirement. There is a lack of imminent or pending proposals for which distributed systems are an absolute necessity. However, the potential for contributing significant benefits justifies the effort of exploration. It is unclear whether the principle aim of DCSs is to provide a platform for new technology, a lowweight control system, a modular platform for more efficient system design, a modular platform to facilitate interchangeability of parts whilst in-service, or a platform for improved control and health monitoring systems. An obvious retort asserts that a systems approach should aim to achieve all of these, but a true evaluation of any proposed design would be implausible without first prioritising the design objectives. Almost certainly, the balance of these Loughborough University – 20th - 23rd April 2009
objectives will change over time as new engine technologies are realised and distributed systems mature. Despite the large number of benefits, distributed control systems lack a `headline' benefit with direct and visible cost savings. By contrast, technologies such as active combustion control may yield a 2% fuel saving [16], resulting in readily quantifiable financial and environmental gains. The structure of the aerospace industry makes calculating the life-cycle value of DCSs practically impossible. Accurately associating the costs to the airline, airframer and engine manufacturer of the engine control system performance presents considerable difficulty. The objectives above not only represent different priorities in design, but the priorities of different stakeholders. In contrast to a mass-market environment, the ultimate customer does not necessarily drive development. 4.2 No opportunity to learn by trial and error Whatever the potential benefits, DCSs will only be accepted if they are shown to increase life-cycle value. Speculation forecasts that the greatest increase in life-cycle value would be realised by a highly-distributed system with nodes for each sensor and actuator. However, even if the appropriate HiTECs were readily available, the pervasive conservatism and competitive mechanics would not permit a paradigm shift to such a novel design. Therefore, a number of iterative design stages would be required to demonstrate the viability and safety of such systems. It is likely that lower levels of distribution would not add sufficient life-cycle value to justify the inherent risk. A logical approach to aid progressive development would be to devise a “blue-sky" optimal solution to maximise lifecycle value without considering risk adversity. A series of intermediate steps could be devised to show the progression from the current centralised systems to the optimal distributed system. However, each iteration would be required to offer substantiated life-cycle savings over the previous stage. If these criteria were not met, distributed systems would progress no further and the optimal solution rendered un-obtainable. The scenario is further complicated by the inevitable changes in technology and engine control which will change the optimal design itself. Consequentially, the iterative steps would have to be `mapped' to the optimal design in such a way that they would change as it did. An obvious way to disperse the uncertainty surrounding distributed systems would be to conduct research and demonstrator projects. From a purely technical perspective, trial and error is a permissible evolutionary strategy commercially, it is implausible and unrealistic. 4.3 Solutions are not true or false No distributed architecture will prove a panacea. Furthermore, architectures will change rapidly with advances in technology, control system design and turbinemachinery. The extensibility of distributed systems offers a multitude of configurations and design options not available to the designers of existing systems. Whilst the extensibility of DCSs is a notable benefit, this extensibility complicates
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) design. It is inevitable that solutions may favour one stakeholder more so than others. Commercial mechanics mean that the stakeholders who realise the greatest financial returns from distributed systems are unlikely to be those who access or dictate their availability. Problem is not understood until a solution is proposed Designers will learn to exploit the benefits of distributed systems as their designs mature and evolve. Only once candidate architectures are proposed will the full impact of architectural features such as design for redundancy and fault detection be fully understood. Understanding these features will give a better understanding of the potential benefits of distributed control systems and the effect they may have on control system Life-Cycle Value.
functionality is more open to the system designer as illustrated in Figure 3. Should the interface circuitry be on the sensor or node? Should the conditioning and/or fault detection be undertaken on the sensor (forming a smart sensor), on a node local to the sensor, or as part of a central controller node?
4.4
3. Sample
s
4. Condition
2. Filter/pre sampling conditioning
5. Fault Detection
1. Interface
4.5 Constraints and resources change over time The nature of distributed systems will certainly change with advances in technology and engine control. Perhaps more important will be the changes in attitude towards them with increasing demonstration and proof of the basic design concepts. Proving the performance and reliability of hightemperature components should make the concept more tangible and increase the industry's willingness to consider such systems. If preliminary systems are able to deliver the anticipated life-cycle savings, the scope of distributed systems will broaden and their wider potential will become increasingly accessible. Furthermore, the technical capability will increase considerably as components and devices capable of withstanding the extreme engine environment become available. Advances in engine control functionality and technological will drive the need for distributed engine control systems. 4.6 Technical Design Complexity The flexibility offered by distributed control systems makes the technical design problem challenging. Modularity can take many forms and functionality may be moved and split at will. An example of the technical design challenging the basic assumptions of centralised system design is given below. In a centralised system, the signal conditioning for a typical analogue sensor follows a canonical form as shown in Figure 2. The various circuit and processing elements commonly reside the same enclosure, share the same circuit board and therefore, power supplies and processing resources.
Figure 2- The chain of functionality associated with the acquisition and processing of an analogue sensor measurement. The sensor is denoted by the triangle marked ‘s’. The flexibility of a distributed system allows this hardware chain to be spatially distributed. The blocks must still maintain the same order, yet the location of the
Figure 3 – In a distributed system, the location of basic functionality becomes a challenging optimisation problem. It would be easy to treat these decisions as trivial, yet their consequences may have considerable impact on life-cycle value, testability and maintainability of the system. How to distribute functionality and modularise design requires careful comparison of a vast range of possibilities. 5 The need for a framework and optimisation At present, opinions on distributed system are disparate and varied. A surprising outcome of stakeholder analysis was the degree of emotive response and wide range of opinion; from strong advocates, through to the majority who believe the shift is inevitable but not imminent, to those who have strong objections to the concept. A facet of distributed system design is the close coupling between the technical system and business case which determines their viability. A system may be constructed from three generic nodes which have been developed, tested and certified. If the development of a fourth generic node is required at a later stage, the business case changes disproportionately to the technical change. A principle business advantage of centralised systems is the ability to confine the system to a fixed number of units or development streams. It is not necessarily distributed control systems as a concept that meet resentment, but the shear number of design choices which are required and the lack of quantitative measures of their impact. Trade-offs must be made in order that the system exists, yet without a mature platform as a starting point, the extent of the trade-offs seems unfathomable. Ascertaining the differences in life-cycle value of two architectures is very difficult and there is a legitimate concern that initial design decisions could have far wider long-term consequences. The location of functionality and computing elements will dictate the number of nodes, the number of nodes will depend on the number of sensors and their distribution across the engine, the distribution of those nodes will depend on the engine environment and location of existing hardware etc, etc. The
Loughborough University – 20th - 23rd April 2009
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) design of distributed FADEC systems is therefore a vastly complex optimisation problem in which the output of nearly every decision is tightly coupled to another. At present, there is no framework for viewing distributed control systems from the range of perspectives required. Those within the industry tend to speak from either a technical or commercial perspective and fail to see the close coupling between the two. The author proposes a framework which will allow the commercial and technical viewpoints to be discussed together and for optimisation algorithms to efficiently tackle the design problem. Beyond the scope of this research, the models could include dynamic elements for simulation of control system performance and through life performance. 6 The Proposed Framework The framework consists of four views which each comprise of a model or series of models: a functional view an architectural view, a commercial viability view and a lifecycle view as shown in Figure 4. Each view aims to relate to one of the principle stakeholders identified in the earlier systems analysis: the functional view to the engine manufacturer, the architectural view to the system developer’s technical perspective, the commercial viability view to the control system supplier’s commercial perspective and the life-cycle view to the system’s maintainers. As representatives of the airlines and airframers, the interests of the engine manufacturer are likely to extend across all of the views.
hardware architecture of the individual nodes which form the functional architecture through the use of circuit blocks corresponding to specific functionality. The models within the view may include architectural layouts for the overall system and the constituent nodes. The architectural view will also comprise models of the underlying system showing temperatures (which greatly affects node location) and keep out zones where control system hardware cannot be located due to engine hardware or harness which cannot be re-routed. A wealth of performance data regarding system weight, harness length, power consumption and system reliability may be obtained from apriori knowledge of circuit block characteristics and interconnection reliabilities. Architectural
Business
DCS FRAMEWORK
Business Life‐cycle Architectural Functional
Functional
In the framework proposed, each view manifests itself as a model or set of models – this allows storage of the data in the models and, ultimately, optimisation of the design using the models. The four views are discussed in more detail presently.... Functional view Captures high-level functional requirements as tasks which the distributed FADEC must perform. The corresponding models are likely to include details of data flow between functions, an analysis of functional coupling and the communication needs between the functions and for a given number of distributed nodes, the allocation of functionality to each. The models within the functional view should permit system and software architects an abstract view of the FADEC system which is unhindered by the physical architecture. Models may include… • Behaviour Diagrams • Control Flow Diagrams • Data Flow diagrams • Data dictionaries Difficulties lie in deciding on the appropriate levels of abstraction for functional representation and understanding the links between allocation of a function to a node and the system’s physical architecture. Architectural view shows where nodes are physically located across the engine and the routing of harnesses between them. The architectural view will also capture the Loughborough University – 20th - 23rd April 2009
Life‐cycle Product Life‐cycle Service‐Cycles 1 to x Product leaves system developer
Deve lopm ent
Desig n
P Product h Development a s e I
Man ufact ure
P Product h Producti a on s e I I
Integ ratio n
In‐service cycles 1 to (y‐1) In‐ servi ce
Repa ir and Over haul
In‐service cycles (y+1) to (z‐1)
+ ... +
In‐ Prod servi uct ce Refre (y) sh Through‐life Support
In‐ servi ce (y+1)
Repa ir and Over haul
+ ... +
In‐ servi ce (z)
Retir eme nt
Servi ce P Life h Product a Life s e I I I
Figure 4 – The proposed framework consists of four views each hosting a set of models. Commercial viability view aims to represent how a distributed control system would influence the cost and viability of design processes to the system developer. The view will attempt to capture where non-recurring expenses (NRE) such as engineering development can be minimised and where reuse may contribute to savings in test and certification costs. Models may include activity based cost models and aim to show where certain activities in product development may be shortened, lengthened, brought forward, or deferred. Moreover, the models included will aim so show how re-use effects development cost and NRE. Lifecycle View aims to capture the costs and added value of the control system throughout its life-cycle based on reliability data and the number of serviceable components.
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) The life-cycle cost model may be amongst the hardest to construct as many of the life-cycle costs are obscured by commercial boundaries. Models will include analysis of spares holding, modifiability (which may also be a feature of the architectural view) and ease of obsolescence control. 7
Application of genetic algorithms to control system design and optimisation Having captured the essential features of the problem in the above framework, it should be possible to use computing power combined with engineering experience to optimise the design of a distributed EEC system from both technical and commercial perspectives by applying a systems science approach to a systems engineering problem. Whilst the decisions taken during design of a distributed control system are tightly coupled, the number of fundamental design decisions are quite small. They include • The number of nodes • The communication network architecture • The power supply topology • The allocation of functionality to a node • The location of each node The sensitivity of these design choices is highlighted by the possibility of constructing the models within the views proposed entirely from the output of these decisions and some a-priori data. For example, the functionality allocated to each node (the functional view) determines the hardware that is required at each node (architectural view), a-priori knowledge of the hardware reliability will contribute to developing the life-cycle view and the nature of the hardware, the commercial viability. The models may be used to evaluate the effectiveness of each design solution For example, the data network topology (from the architectural view) will impact the weight and cost of the system. This research aims to capture these relationships between the basic design decisions and the views and then use the derived models to ascertain the fitness of candidate architectures. Once the relationships are established, it is proposed to use a multi-objective genetic algorithm approach to generate and optimise candidate control system architectures. Genetic algorithms are a form of optimisation technique based on the ‘processes’ of evolutionary biology such as inheritance, mutation, selection and cross-fertilisation [17]. The algorithms generate solutions to a problem, evaluate them against a cost function and reject weaker solutions in favour of those with lower costs. The more favourable solutions may be randomly mutated or combined with other favourable solutions to generate a second set of solutions which are evaluated, cross-fertilised and mutated as before. Genetic Algorithms have previously been used to solve optimisation problems relating to distributed control systems. Dick and Jha (1998) [18] propose a hardwaresoftware co-synthesis for distributed embedded systems and works such as Kumar et al show application of genetic algorithms to distributed topology design [19]. Genetic algorithms have also been applied to task allocation in distributed systems [20]. This research differs because the
genetic algorithm is being used to optimise an architecture from a systems engineering perspective to satisfy both a technical and business case. In this application, a major advantage of genetic algorithms over other optimisation approaches is their ability to operate on non-linear problems – as such, fitness functions comprising of decisions, look-up tables, linear and nonlinear mathematical functions may be used to define the solution’s cost. For many of the design decisions there exist a discrete number of choices. The communication network topology may be a ring, star, bus, mesh – each has its own characteristics. Similar sets of possible implementations may be made for the power supply topology. The genetic algorithm is capable of generating solutions using such inputs. 7.1 Method The method proposed is to use the genetic algorithm to search for optimal solutions to the DCS design problem. The four views and their corresponding models will be constructed from the basic inputs given in section 7. Based on these models the system may be analysed. The results from this analysis will provide parameters for the ‘fitness functions’ used in the genetic algorithm. The costs functions will be finalised as the models are constructed, but it is likely that significant parameters will be cost, weight, reliability, development time and cost and the availability of reusable components. It is hoped that the genetic algorithm will permit many different solutions to be compared and an optimum solution found. 7.2 Assumptions In order to make the research feasible, a number of assumptions must be made. These assumptions will be subject to change as the research evolves. Some of the more fundamental are listed below… • The communications platform will be a time triggered TDMA network • All requirements are included as functionality or cost function parameters • All processing elements will reside away from the sensors – there will be no smart sensors • The network will have a single architecture, eg. Ring, bus, star etc. The possibility of combinational topologies, hubs and gateways will be ignored. All network elements will be assumed to be dual redundant. 8 Conclusion This paper has considered the problem of replacing current centralised electronic engine controllers on large civil aircraft engines with distributed controllers. A background has been given and it has been shown that considering the problem in the context of a “wicked-problem” is useful in understanding the complexities and issues surrounding the
Loughborough University – 20th - 23rd April 2009
7th Annual Conference on Systems Engineering Research 2009 (CSER 2009) uptake of DCS in this domain. To address this complexity, a framework has been presented based-on known systems approaches which allows a model-based approach to capturing and analysing the “fitness” of various aspects of the design. The paper proposes that having modelled the problem, optimisation will be possible using genetic algorithms. The current phase of work is focussed on populating this framework with appropriate models. Subsequently, GAs will be developed to produce distributed control system architectures which meet both technical and commercial criteria. 9 Acknowledgements This research has been undertaken as part of a Systems Engineering Doctorate project run jointly by Loughborough University and Aero Engine Controls, a joint venture company between Rolls Royce plc and Goodrich Corporation. The first author owes a debt to his colleagues at Aero Engine Controls who have helped him better understand the aerospace industry and the challenges associated with distributed control system development. The Engineering Doctorate (EngD) is jointly funded by Aero Engine Controls and the Engineering and Physical Science Research Council (EPSRC); their continued financial backing is greatly appreciated. 10 References [1] F.L. Lian, J. Moyne, and D. Tilbury. Network design consideration for distributed control systems. IEEE Transactions on Control Systems Technology, 10(2):297– 307, 2002. [2] AK Mok. Fundamental design problems of distributed systems for the hard-real-time environment. 1983. [3] H. Kopetz and W. Ochsenreiter. Clock synchronization in distributed real-time systems. IEEE Transactions on Computers, 36(8):933–940, 1987. [4] H. Kopetz. Real-Time Systems: Design Principles for Distributed Embedded Applications. Springer, 1997. [5] R.K. Yedavalli, R.K. Belapurkar, and A.R. Behbahani. Stability Analysis of Distributed Engine Control Systems Under Communication Packet Drop (Postprint). 2008. [6] H. Kopetz and G. Grunsteidl. Ttp - a timetriggered protocol for fault-tolerant real-time systems. Fault-Tolerant Computing, 1993. FTCS-23. Digest of Papers., The Twenty-Third International Symposium on, pages 524–533, 1993. [7] Mo-Yuen Chow and Yodyium Tipsuwan. Network-based control systems: a tutorial. Industrial Electronics Society, 2001. IECON '01. The 27th Annual Conference of the IEEE, 3:1593–1602 vol.3, 2001. [8] H. Chan and U. Ozguner. Closed-loop control of systems over a communications network with queues. International Journal of Control, 62(3):493–510, 1995. [9] Chun-Hsiung Chen, Chun-Liang Lin, and ThongShing Hwang. Stability of networked control systems with Loughborough University – 20th - 23rd April 2009
time-varying delays. Communications Letters, IEEE, 11(3):270–272, 2007. [10] M. Short and M. J. Pont. Fault-tolerant timetriggered communication using can. Industrial Informatics, IEEE Transactions on, 3(2):131–142, 2007. [11] T. Führer, B. Müller, W. Dieterle, F. Hartwich, R. Hugel, and M. Walther. Time Triggered Communication on CAN (Time Triggered CAN-TTCAN). Proceedings of International CAN Conference, Amsterdam, The Netherlands, 2000. [12] Dennis E. Culley, Randy Thomas, and Joseph Saus. Concepts for distributed engine control. NASA, 2007. [13] Dennis Culley and A. Behbahani. Communication needs assessment for distributed turbine engine control. 2008. [14] H.W.J. Rittel and M.M. Webber. Dilemmas in a general theory of planning. Policy Sciences, 4(2):155–169, 1973. [15] E. Jeffery Conklin and William Weil. Wicked problems: Naming the pain in organization. 3M Meeting Network, 1998. [16] S. Garg. Propulsion Controls and Health Management Research at NASA Glenn Research Center. 2002. [17] A. Konak, D.W. Coit, and A.E. Smith. Multiobjective optimization using genetic algorithms: A tutorial. Reliability Engineering and System Safety, 91(9):992–1007, 2006. [18] RP Dick and NK Jha. MOGAC: a multiobjective genetic algorithm for hardware-softwarecosynthesis of distributed embedded systems. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 17(10):920–935, 1998. [19] A. Kumar, R.M. Pathak, Y.P. Gupta, and H.R. Parsaei. A genetic algorithm for distributed system topology design. Computers & Industrial Engineering, 28(3):659–670, 1995. [20] P.Y.R. Ma, EYS Lee, and M. Tsuchiya. A Task Allocation Model for Distributed Computing Systems. Transactions on Computers, 100(31):41–47, 1982.
