Optimizing Life Cycle Cost of IT Systems in Process Industry Applications Using Genetic Algorithms Ralf Gitzel, ABB Corporate Research, Industrial Software Lab 1 Martin Herbort , RWTH Aachen Abstract: Process Automation equipment is an important market, providing the technological mechanisms to automatically produce, amongst other things, food, beverages and pharmaceutical products. Recently, a growing need to control the aftersales cost of the IT components within such systems has led to the approach of Life Cycle Cost calculation, which is similar to total cost of ownership concepts. In this paper we present a Genetic Algorithm-based optimization for Life Cycle Cost in the Process Industry. We identify key cost drivers, provide a generic cost model and test several Genetic Algorithm variants. The main contribution of this paper is that we show the feasibility of Life Cycle Cost optimization via Genetic Algorithms and provide an encoding suitable for the domain. Keywords: Industry Application, Process Industry, Investment Planning, Life Cycle Cost, Genetic Algorithms
1
[email protected], ABB AG – Corporate Research Center Germany, Wallstadter Str. 59, 68526 ladenburg
1.
Introduction
Automation of industrial manufacturing is an important market, with multinational companies such as ABB providing products from robots to process control systems. An important sub-market is Process Automation, which improves the efficiency of chemical, pharmaceutical and similar production processes. Recently, there is an increasing trend to try reducing the total cost over the life cycle. While one prominent approach is to increase the quality of the automation products, thus reducing maintenance cost, we try to look at the potential of optimizing life cycle planning. In this paper, we present a heuristics-based optimization of life cycle cost in the domain of Process Automation. The purpose of this paper is to show that Genetic Algorithms can be applied, reducing the cost over a life cycle. Also, we want to show the best encoding of life cycle information in a Genetic Algorithm and discuss the real-world applicability of the results. The discussion in the paper begins with a brief description of the problem domain Process Automation and the Life Cycle Cost concept. In section 3, we will show how to apply LCC calculation to Process Automation and which factors are of core relevance. As a result we get a mathematical optimization problem that is described in section 0. Section 4 shows some possible optimization approaches and briefly explains why we chose Genetic Algorithms for our paper. Different Genetic Algorithm variants are discussed in section 5 to identify the best encoding, mutation, and crossover selections. We present an example case in section 7 and evaluate our approach in section 8. The paper ends with a description of related work and our conclusions.
2.
Problem Fundamentals
In order to understand the factors that impact the cost optimization presented in this paper, the fundamental aspects of the problem are explained. First, we briefly introduce the domain of Process Automation and discuss its specific properties regarding investments. Second, we will explain the concept of Life Cycle Cost that can be used to better assess and compare investment strategies.
2.1.
The Domain of Distributed Control Systems
Before it is possible to devise an optimization algorithm, the peculiarities of the Process Automation domain have to be identified. In this paper, the systems to be optimized are Distributed Control Systems (DCS). A DCS is a network of human-machine interface “terminals” connected to real-time capable computers called controllers, which in turn connect to field devices. The field devices can be sensors and/or actuators controlling the chemical process. The control system is distributed, because it is not controlled by a central unit but rather by multiple controllers that communicate via a network. As DCSs tend to be very complex systems, they often require a set of expensive auxiliary services, e.g. maintenance or remote monitoring. Recently, the human-machine interface level’s technological base has shifted from proprietary technologies to commercial-of-the-shelf machines, in this case Intel/Windows-based PCs. As a result, the formerly relatively static world of Process Automation has been confronted with the short product life cycles of the IT world. As a
consequence, there is an increased need to control the now comparatively unpredictable cost through life cycle cost calculation. A further step not commonly considered today is to minimize life cycle cost through heuristics such as Genetic Algorithms. To briefly summarize, there is a real need for a cost optimization encompassing the whole life cycle in the domain. The reasons are exploding after-sales cost. Also systems in the domain differ from many other investments in that they consist of software, electronic hardware, mechanical hardware, and often incorporate service products.
2.2.
Life Cycle Cost
Due to the impact of after-sales cost, acquisition cost is a poor measurement for comparing different investment strategies. A better approach to compare DCS investments is to calculate the Life Cycle Cost (LCC) associated with the system. Life Cycle Cost Calculation (LCC), which actually does not regard costs but discounted cash flows, is a recent trend in manufacturing that is largely industry-driven (see for example [VD06] and [VD05], but also [FP95]). The cost elements included in the calculation vary widely from domain to domain. There exist examples for different markets ranging from carpeting [KR04] to industrial valves [DS06]. The LCC concept is closely related to Total Cost of Ownership [KI87]. While there have been attempts to differentiate the two terms (cf. [VD06]), we do not believe this delineation to be globally accepted. While some companies in the Process Automation environment already use LCC, their calculation models are neither globally accepted nor published in all details (also see section 9). For this reason we are going to identify the cost drivers for the domain of distributed control systems in the next section. The cost drivers will form the cornerstone of a cost model that can be used as a fitness function for our optimization heuristic.
3.
A Life Cycle Cost Model for Process Automation
In this section, we will present an LCC model that will describe the optimization problem of this paper. As a first step, we will identify the cost drivers. Based on these factors, we will create taxonomies of cost types for the model. Finally, a generic mathematical model will be presented.
3.1.
Cost Drivers in Process Automation
An important first step to measure cost effectively is the identification of cost drivers. We adopt the view of Hauff, who identifies a high level of obsolescence due to technological change, the downtime due to poor system availability, and the migration cost as core problems of Personal Computer based IT [HA06]. Expert interviews within ABB mostly agree with this view, having identified cost due to obsolescence, migration effort, and configuration of systems as major cost drivers. Obsolescence cost is strongly tied to the risk of breakdowns. When a component is obsolete and breaks, there is often no way to replace it, leading to delays and additional cost for necessary upgrades that cascade though the system. Therefore, the number and length of breakdowns is also a cost driver. Indeed, LCC standards consider financial effects due to corrective maintenance as part of the life cycle cost (e.g. [VD06], cost category IH3). It should be mentioned, however, that this view is not commonly shared. For instance, risk specialists in the financial area typically consider “business disruption
and system failures” as risk ([BC02], pg. 2) as opposed to cost. Since the distinction between risk and cost is beyond the scope of this paper, all relevant financial effects are treated as costs.
3.2.
Life Cycle Cost Model for Process Automation
In order to build an LCC model for process automation, the cost drivers have to be incorporated into a general schema of costs. The DIN standard on LCC [DI05] suggests adopting three dimensions for life cycle cost; the product causing the cost, the cost type, and the life cycle stage in which the cost occurs. The three-dimensional view allows avoiding omissions of critical aspects and to provide a more detailed view of a system’s cost elements. Figure 1 shows a taxonomy that classifies costs by product. The tree shows the incorporation of hardware, software and services that is typical for the process automation domain (see section 2.1).
Figure 1 - Products in a DCS
Figure 2 shows the second cost dimension. The cost drivers from section 3.1 are present in the cost tree. Obsolescence requires frequent changes. Migration effort and system configuration are represented in the change cost category. Downtime is an issue caused by various problems and is thus found in 3 out of 5 categories of cost.
Figure 2 - Cost Model
The third dimension suggested by the DIN standard is life cycle stage. In our approach, we aim for a fine-grained solution and regard individual years of the life cycle (see section 0) as the temporal dimension. The three dimensions form the basis of a mathematical optimization problem. A generic description of this model will be given next.
3.3.
Optimization Problem
Now that the relevant elements have been identified, it is possible to combine them in a comprehensive cost model. Since we want to describe a generic solution for LCC optimization (as opposed to calculation) we will not explain every detail of the model. Instead, we will focus on the cost drivers and the elements suggested by the LCC standards, which have in incorporated in the above taxonomies. In this paper, we model our life cycle cost based on dynamic investment calculation. Thus, a DCS is represented as a sequence of states, connected by change decisions. Figure 3 shows the general concept. Each odd column represents a state that is a combination of several products currently in use and that represents a single year in the life cycle. Each even column represents a change, with one decision applying to each element. The decisions are assumed to be made at the end of a year.
PC
Stay
PC
Stay
PC
Replace
PC
Stay
PC
OS
Stay
OS
Stay
OS
Stay
OS
Stay
OS
State Change Figure 3 - Internal Model of the Life Cycle
Figure 4 shows a year in detail. In addition to the elements of dynamic investment calculation (state and change decision) random events (i.e. malfunctions) can occur. Each of the three elements has associated costs which will be described below. Element with all associated regular costs
One decision at end of year: Stay or Replace
PC
Stay
Malfunction
OS
Stay Random events add cost
One year Figure 4 - Elements of a year
Since the problem contains stochastic elements, the objective function is the expected value of the total cost incurred by a specific scenario.
F x1 ,....x Objective function:
Fglobal
k 1
min , the average of
realizations of
the random variable f x1 ,..... x , which is the net present value of the cost of all periods. Objective function per scenario:
f x1 ,..... x
NPV f z k 1 , x k , where f is the cost of a period. k 1
The cost per period is in principle the sum of all costs identified in section 3.2. The cost values are influenced by the products currently installed and the change actions performed. Thus, the decision variables xk that are optimized represent the decisions made between the states z k 1 and z k . Since a single decision has to be made for each element of the system, the decision variable is a vector of all decisions for the system’s product instances:
xk
x k ,1 ... , z k x k ,n
k
t k z k 1 , xk
1,....,
xk ,1 ,..., xk ,n are the decision variables for the individual products. For each product instance in the system, the decision is either to keep the instance, to replace it with a model of the same type, or with a product that performs the same function (represented by t k , i ): x k ,i
X k ,i
stay
switch tk ,i
tk ,i
Replacement decisions typically have cost associated with them. Notable exceptions are changes regarding service products. Since the service product is a contract for services rendered over the year, there is no cost for installation etc. Several other constraints apply to the problem, which can only be touched on briefly. A very important constraint is that certain products require others to be present at the same time. For example, some software requires a specific version of the operating system to run. Modeling explicit dependencies between elements is quite complex. For the purposes of our prototype, we have exploited the fact that elements within a DCS have a welldefined role. For example, we require that the operating system used runs on all machines in the system. Another constraint is that products cannot be bought before their release date or after the final sales date. This product information is taken from a product data base. A further constraint is that the optimized life cycle must begin in a specific start configuration and to end in a specific end configuration. The reasoning behind the last requirement is that plant operators often have a roadmap for the systems they run (containing e.g. modernization goals and repair cost limits). Finally, products whose cost depends on configuration values, e.g. the number of concurrent users, must have the same values as their predecessor. Several factors influence the search for an optimal solution. On the one hand, there are the change decisions. On the other hand, there are costs for failures, which for mechanical components such as hard drives increase over time due to wear-out. Also, failure becomes more expensive for obsolete products as there are no more readily available spare parts. In essence, solving the problem means finding the balance between postponing change and suffering from expensive breakdowns. A second aspect is picking the right products from a list of alternatives which might vary in cost, reliability and the time period of availability on the market. For example, one product might be cheap and reliable but only available for the next 2 years. This product could be compared to an alternative that is more expensive but will be available for a longer time, avoiding configuration cost. With this admittedly brief description of our cost model we have established the basis for the main contribution of our paper, i.e. the description and analysis of an optimization algorithm for LCC.
4.
Possible Optimization Approaches
In section 3 a cost function for Life Cycle Cost was defined as a rough draft that includes the important cost drivers and the decisions that influence them. We refrain from elaborating the model further as the core question of this paper is how to optimize LCC using a genetic algorithm (GA). In this section, we will briefly look at alternative optimization solutions and discuss their suitability for solving an LCC optimization problem. While we do not rule out alternative algorithms, we use this section to explain why we think that GAs are a good choice for LCC optimization. The application of GAs to LCC will be presented in section 5.
4.1.
Brute Force Approaches
Given the typical complexity of a LCC problem, brute force approaches can be ruled out for most realistic problem instances. To give a general impression, consider a DCS consisting of n = 10 components which is supposed to run for T = 15 years and whose components can either be replaced or kept installed in each year (which means d=2 decision possibilities). The resulting search space has a size of (d T 1 ) n = (214 )10 1.39 *10 42 Even without the stochastic elements there are about 1.39 *1042 possible life cycles. Under the assumption that 100 life cycles could be evaluated per second, it would still need 4.4 *10 23 years to process the complete search space.
4.2.
Other Non-Heuristical Solutions
Based on our problem-definition above, non-heuristical solutions also run into computational problems rather quickly. While most of them typically perform a lot better than brute-force approaches, the complexity (in terms of search space size) is still too high. For example, dynamic programming can be applied to discrete stochastic problems such as ours. However, the number of possible states in each period grows rapidly. To illustrate our case, consider a small system with 10 components that can fail individually. Even without any decision branching, each state has 210 1024 exits. Early experiments we conducted in that direction where quickly dismissed. Generally speaking, the stochastic element adds a level of complexity that makes non-heuristics unappealing.
4.3.
Heuristical Solutions
Heuristics hold more appeal for LCC, because the complexity can be reduced at the expense of the solution quality. While a heuristic gives us a valid solution (if it exists), this solution is not necessarily optimal. However, given the goal of LCC optimization, i.e. saving money through improved replacement decisions, any solution that costs less than the original plan is acceptable. The number of heuristics that could be applied to LCC is huge and it was not within our scope to do a detailed survey. Instead, we picked GAs as one popular heuristic and tested its applicability to LCC.
4.4.
Genetic Algorithms
Genetic Algorithms (GAs) are heuristic algorithms that are particularly suitable for solving numeric and combinatorial problems with a large and complex search space. GAs
are a variant of Evolutionary Algorithms (EAs) that follow the Darwinian theory of evolution. For detailed information about GAs see [Ei03].
Figure 5: General scheme of an evolutionary algorithm (see [MH1])
EAs simulate an evolutionary process in the context of the optimization problem. For that purpose, a set of candidate solutions of the problem is generated which forms the initial population. Each candidate solution represents an individual of this population. Cyclically, a random selection procedure is applied to determine the individuals that will contribute to the succeeding population (the next generation). This selection procedure is fitness-based in that it takes the quality of the candidate solutions into account. The selected individuals are called parents. Therefore, this step is called parent selection. In the next step, the parent solutions are recombined and mutated in order to create new solutions (the offspring) that potentially share characteristics with their parents. In the last step, another random selection procedure (survivor selection) is applied to determine which of the parent and offspring individuals make it into the next generation population. The process cycle ends as soon as some given end criterion is fulfilled (e.g. when a given generation number has been reached, or when the quality of the best solution of the last k generations does not increase any longer). Figure 5 recapitulates the general scheme of an evolutionary algorithm. Figure 6 describes the basic evolutionary computing metaphor which connects components from the evolutionary theory with the corresponding components from the area of optimization problems.
Figure 6: The basic evolutionary computing metaphor (see [MH1])
As mentioned above, GAs are a variant of EAs. The special characteristics of GAs extend to the representation of solutions and to the recombination and mutation operators. Within GAs, solutions are called chromosomes (also genomes) and are represented using multiple genes. Each gene encodes a single element of a candidate solution. Genes typically have a domain of binary, integer or real numbers. As a consequence, solutions are represented using strings of binary, integer or real numbers, respectively. When new offspring solutions are to be generated, selected parent solutions are recombined as part of the crossover and mutated. The most basic crossover operator
(one-point-crossover) works by taking two genomes (representing two different candidate solutions), determining a cut-off position within the genomes and swapping the the parts behind the cut-off position. After recombination has taken place, mutation is applied to the offspring solutions. Again, many variants are possible for mutation. Typically, each gene of each genome is assigned a small probability to switch to a random value from the domain (i.e. binary, integer or real numbers). Genetic Algorithms’ chain-like encoding is quite suitable for representing a life cycle. As will be shown in the next section, the nature of LCC problems can be mapped to genomes in several ways.
5.
Genetic Algorithms for LCC Optimization
Our approach for life cycle cost optimization of control systems is to take the general problem description provided in 3 and apply the concepts of Genetic Algorithms. To run the optimization, the problem is first encoded in a form suitable for the genetic algorithm. The algorithm returns an optimized variant to the life cycle, which is reconverted into a human-readable form. The process is summarized in Figure 7.
Figure 7: Flow of model instances within GA-based LCC optimization
As a first step we will look at the encoding of life cycles as genomes. We discuss different possibilities and analyze their suitability. The encoding involves exactly the data relevant for determining the total life cycle cost. The DCS life cycle model is based on the dimensions of the search space (see section 2). It explicitly contains the following pieces of information: The installation and replacement years of a component. The type of the replacement component. Figure 8 shows a sample life cycle (as a screenshot from our prototype). Each box represents one or more identical components of the type given by the label. The installation and replacement dates for all components are indicated by the location and the width of the component boxes on the timeline. Each row in the picture represents a partial life cycle for one element of the system, i.e. a number of components that are installed consecutively as a replacement for each other. The screenshot could represent a customer’s initial plan for replacements and can be encoded in multiple ways.
Figure 8: Example of a Simple DCS Life Cycle
So far, constraint handling has not been discussed. Actually, it is not generally necessary to handle constraints explicitly in the model or in the encoding scheme of a GA. In fact, it can be delegated to the selection procedures of the actual GA. There are many constraint handling techniques for GAs, from which several have been used to find out which one is most suitable for LCC optimization. A common approach is imposing penalty values on the fitness values of chromosomes which represent invalid life cycles. The amount of penalty depends on the degree of invalidity. In the context of this paper, we have looked at several different GA variants to solve the optimization problem. The algorithms vary in the aspects shown in Table 1. The different options for each aspect are also shown. In the following subsections, we will describe each choice in more detail. Table 1: Encoding Variants
Property Encoding Length Encoding Data Type Crossover operator Mutation operator
5.1.
Variants Fixed Length, Variable Length Integer, Binary, Floating Point 1-point, 2-point, BLXstandard, non-uniform, special
Encoding Length
The encoding of the life cycle instances has to reflect the decision variables relevant for the problem. In this paper, we have looked at two different ways to encode life cycle instances. The first one results in fixed length chromosomes, the second one in a variable length. 5.1.1. Fixed Length Encoding Fixed length encoding is very close to the problem description given in section 3.2. For each year, a change decision is given for each component, which is either stay or a replacement. The encoding scheme has fixed length because it explicitly contains the replacement decision for each and every year of the life cycle planning horizon. A “0” in year i means that the component is not to be replaced for year i 1 . Any number greater 0 is the successor list index. The successor list is a mapping to only those product IDs that are legal replacements at that point of time.
To illustrate the concept reconsider the life cycle in Figure 8. There are three different server products available in the year 2012, i.e. the servers Beta, Gamma, and Delta (in that order). The successor list assigns them the numbers 1, 2, and 3 respectively. As can be seen in the partial chromosome representation below, the replacement of core 2 by beta is thus encoded as a 1. The successor list can be different for each year, depending on product obsolescence and other factors. Thus, in the example, the 2 in year 2019 means something else (Zeta) than it would in 2012 (Delta). 0 0 0 0 1 0 0 0 0 0 0 2 0 0 The total chromosome is a concatenation of all partial life cycle encodings. For example, a system with 5 different components and therefore 5 partial life cycles and a life cycle horizon of 15 will consist of 75 genes. 5.1.2. Variable Length Encoding Another encoding variant examined describes pairs of changes and the number of years before the next change. Using this encoding, the partial life cycle in line 1 of Figure 8 has the form: 1(4) 1(7) 2(3) The numbers without brackets denote the changes made. Our example server in Figure 8 goes through 2 changes. Change encoding again uses the concept of successor lists. The numbers in the brackets indicate the number of years between the changes. Given all periods of operation for all consecutively installed components and the starting year, one can easily determine the corresponding installation times. Note that “-1” is the successor list index of the very first component of a partial life cycle. This is because the start configuration is given and therefore does not allow modifications of the component type. For the same reason, the value for the period of operation of the first component is by one smaller than indicated by the width of the bar in the picture. As is the case with fixed length encodings, the total genomes is a concatenation of the partial life cycles. The number of genes per partial life cycles varies, however as the length of time is encoded implicitly there will always be an exact interpretation for each resulting chromosome.
5.2.
Encoding Data Type
GA chromosomes are essentially vectors filled with values like the ones in the previous section. On an algorithmic level there are several possibilities to represent the information contained in the chromosomes. The numbers used to encode the successor list indices and periods of operation can be integers (as in the example), binary, or floating point numbers. Binary encodings are a variant of the integer encoding. Instead of using one integer per gene, the binary represenation of the number instead forms several genes, e.g. 32 bits for a C# integer. A binary-encoded number will not change completely due to a mutation of a single gene. Floating point numbers are a less intuitive encoding for life cycles of the form described above. The floating point notation is achieved by mapping the integer values to discrete subintervalls of [0,1]. Thus, several numbers represent the same integer. The main effect of this notation is a different behaviour with regard to mutation.
The data type chosen will affect the changes wrought by the operators, as will be explained in the next section.
5.3.
Crossover Operators
There are several different techniques for cross-breeding solutions, i.e. to recombine the parts of two genomes into one. Each of these solutions is realized with a crossover operator. In the context of this work, we have looked at 1-point, 2-point, and BLXcrossover operators. 5.3.1. 1-Point Crossover Operators The 1-point crossover operator cuts the two parent chromosomes at a random point that is identical for both parents. The resulting cut-off “tails” are exchanged. The 1-point crossover was one of the first operators identified for GAs and is very closely related to the actual biological concept of inheritance. Since the incision point is random, it can lie within a single partial life cycle or sometimes exactly between two partial life cycles. In the latter case, the different partial life cycles are mixed. More commonly though a single partial life cycle is changed additionally to the recombination. A special variant of the 1-Point-Crossover Operator is required when using variable length encodings. Since the incision point is random, two problems occur. First, completely different partial life cycles would be mixed. Second, many freshly-combined variable length solutions would no longer match the required time horizon. To ensure that all solutions have the required number of years, a different incision point is used for each parent. First, a random incision is made in chromosome 1, making sure that no decisionyear pair is cut in half. Then, the corresponding partial life cycle in the second parent is identified and cut into half. Finally, the resulting children are repaired to cover the proper time period. 5.3.2. 2-Point Crossover Operators A 2-point crossover operator works the same way as the 1-point version, only that there are two incision points resulting in an exchange of non-consecutive parts of the chromosome. Not surprisingly, this variant introduces a higher level of change between the generations. 5.3.3. BLX- Operators A Blend Crossover (BLX- ) operator is a speical case that can only be used in conjunction with floating point gene values. Unlike the previous operators which generate two children, BLX- results in only one offspring. Each gene of the offspring is created as composite of the corresponding parental genes. Each new gene is a random number drawn from the intervall [lmin , l max + ], where lmin is the lower parental gene value and lmax the higher one. The parameter indicates how much the gene can vary from the interval defined by its parents. The BLX- crossover operator differs from the previous two operators due to its greater offspring deviation from its parents. It was included in our approach to identify whether bold steps in the solution space will lead to better results or not.
5.4.
Mutation Operators
Mutation operators introduce small changes to a single genome. We have examined three different types of mutation operators. 5.4.1. Standard Mutation Operators There are two standard mutations operators, one for integers and one for floating point values. The simple mutation operator applies to integer numbers (and thus also to their subset, the binary variables). A single, random gene is selected and is replaced by a random value from the interval [0, indexmax]. In the case of binary encoding the interval is [0,1]. The equivalent mutation for floating point numbers is uniform mutation. The new value between 0 and 1 is created using a uniformly distributed random variable. 5.4.2. Non-Uniform Mutation Operators Non-uniform operators can only be applied to floating point numbers. The new value of the gene is a random number between 0 and 1. However, the random variable does not use a uniform distribution. Instead, the new value depends on the number of iterations the GA has gone through. In the beginning, the allowed deviation from the previous value is high but is reduced with each generation. Since the details are relatively complicated and the algorithm does not play a major role in our findings, we refer you to [Mi96] for a detailed explanation. 5.4.3. Special Variable Length Mutation Operations Since the variable length encoding has two different types of genomes (i.e. the exchange policy and the number of years between changes), applying the regular mutation operators would result in many invalid solutions. Thus, we have defined special mutation operators that reduce the risk of ending up with a non-valid solution. They are typically applied together. The successor list index mutation changes only the product chosen when a change is performed. The new value is picked from the list of all valid choices based on the year and the previous product. The operation time mutation, on the other hand, only changes the time period that passes between two changes. As shown in Figure 9, one of the length genes is selected randomly. In the example, the white block represents the selected gene. The operation time mutation changes the time value to a random value between 1 and length of block 2 plus length of block three minus 1. Effectively, the replacement decision marked by the black arrow is shifted around while all other decisions stay the same way.
1
2
Length = 3
3
Length = 2
Length = 1
Length Adjustment to Stay Valid
Mutation of the Length of Block 2
Length = 3
Length = 3
4
Length = 4
Length = 1 Length = 1
Figure 9: Operation Time Mutation
Besides shifting the years when exchanges are performed, it is also required to introduce operators for adding or removing exchanges. Otherwise, large parts of the solution space are ignored. The insertion mutation operator adds an additional exchange somewhere in the genome, along with a time period. The removal mutation does exactly the opposite, removing a single exchange. After both of these operations the chromosome has to be repaired to still have the correct time horizon for all partial life cycles.
6.
Comparison of Different Approaches
The algorithm we have chosen for the optimization was carefully fine-tuned testing different combinations of the properties shown in Table 1. The different GA variants were applied to two different example systems. While system 1 was designed with a high optimization potential, system 2 was based on the IT level of a real-world water treatment plant. Table 2 shows the GA variants analyzed in this context. Table 2: Analyzed GA Variants
# 1 2 3 4 5 6 7 8 9
Genome Length Fixed Fixed Fixed Fixed Fixed Fixed Fixed Fixed Fixed
Data Type Integer Integer Binary Binary Floating Floating Floating Floating Floating
Crossover Operator 1-Point-Crossover 2-Point-Crossover 1-Point-Crossover 2-Point-Crossover 1-Point-Crossover 1-Point-Crossover 2-Point-Crossover 2-Point-Crossover BLX- Crossover
Mutation Operator Simple Simple Simple Simple Uniform Non-Uniform Uniform Non-Uniform Uniform
10 Fixed 11 Dynamic 12 Dynamic
Floating Integer Integer
BLX- Crossover Mod. 1-Point-Crossover Mod. 2-Point-Crossover
Non-Uniform Special Special
As a first step, we looked at all suggested configurations to figure out a general trend. The results are shown in Table 3. As can be seen, even for a simple system the dynamic length encodings are superior both in speed and quality of the results. Table 3: Results for System 1
Cost after # Optimization 1 57’202 2 94’916 3 126’807 4 134’937 5 56’455 6 No valid solution 7 60’925 8 60’293 9 70’073 10 148’711 11 54’170 12 54’170
Number of Generations Before Termination 196 174 200 77 195 157 53 46 176 74 25 14
The selected subset of the same GA variants was then applied to a more realistic example. The result in this case was less conclusive but still pointed to the variable length solutions (see Table 4). These experiments led us to use combination 12 for our optimization algorithm. Table 4: Results for System 2
Cost after # Optimization 1 2.33 Million 5 2.11 Million 7 2.26 Million 11 1.33 Million 12 1.46 Million
7.
Number of Generations Before Termination 134 199 121 190 54
Walk-Through Example
To give a better impression on how our optimization algorithm works, we will describe a single optimization example in more detail. The system under observation is part of a chemical plant’s DCS. It is based on an actual customer’s request but has been made anonymous. The initial life cycle is the customer’s desired evolution plan. The system is then optimized using version 12 (cf. Table 2) of our GA. Finally, the results are discussed.
Figure 10 shows an evolution plan for an existing IT-level of a DCS. It consists of several service products: remote service, preventive maintenance service, spare parts delivery and Automation Sentinel – a software subscription program. Several client PCs (presented as one line in the life cycle diagram) with their installed software and servers are also represented. Finally, network switches that connect the various machines are modeled.
Figure 10: Existing DCS Evolution Plan
Figure 11 shows the optimized evolution plan, where cost was reduced from 487,000 € to 424,000 €. When comparing the result with the original life cycle, several interesting effects can be seen.
Figure 11: Cost-Optimized Evolution Plan
There is no cost for changing from one service contract to another (or the same for that matter). Thus, solutions that show unnecessarily fragmented service lines are not inferior to those having a continuous contract. This optical nuisance does not affect the solution, however. In this example, we have assumed an infant mortality failure rate for the PCs. This means that, even though cost for replacement parts goes up astronomically in the end, it is cheaper to keep the old machine as it is becoming more reliable over time. On the other hand, since the first and the last product are fixed, the life cycle has to end with a client and server of type Epsilon. Since the project uses a negative interest rate (i.e. things become more expensive), the new machine is not bought at the last possible date. The operating system changes are linked to the changes made to the machines. Finally, the network switch replacement is removed. On the one hand, this reduces the replacement cost from 12,200 € to 3,400 €. On the other hand, the expected cost for failures of the switch also goes down moderately from 40,000 € to 38,500 €. Clearly, this is again caused by the decreasing failure rate.
8.
Evaluation
In sections 6 and 7 we have presented several of our experiments with Genetic Algorithms for LCC optimization. As a result, we have identified several properties that we are going to discuss. Due to the high complexity of the search space even for small examples, the application of GAs seems to be an appropriate method to tackle the life cycle optimization problem.
GAs as a solution approach to LCC optimization have proven to be able to solve realistic problem cases in acceptable time. The examples shown were optimized overnight on a standard office PC. An additional benefit is that GAs are easily parallelized. For example, the most expensive task of evaluating each genome of the population (which means calculating the total costs of a candidate life cycle here) could be divided up to multiple processors. Also, from a mathematical standpoint we are satified with the quality of the solutions. We were able to identify an GA encoding that significantly optimized a realistic example. In our example from section 7, a life cycle considered optimal by its human creators was improved by 13%. On the other hand, the results run counter to the effects described by our experts. The failure behavior has little impact – our example above produces the same optimized result for increasing, decreasing, and constant failure rates. As a result, extending the use of equipment to avoid upgrade cost is the preferred solution of the GA. The problem is that the extent of this solution (i.e. skipping a whole generation) runs counter to the “intuition” of our experts. Several explanations are possible for this: 1. The impact of obsolescence is overestimated. An argument in favor of this interpretation is that none of the IT components cause production downtime. 2. Cost estimates for obsolescence are wrong. It could be that the cost values given to us miss some essential point. In fact, the cost model does not include any quantification of delays and required ad-hoc updates due to unavailable parts. 3. The effects of obsolescence are not primarily cost related. Instead obsolete systems are relatively less effective than their modern counterparts. It is our assumption that the LCC models currently proposed inadequately handle obsolescence. While improvements to the existing cost models are not our primary concern, such an investigation would be interesting future work.
9.
Related Work
We divide our review of related work into two sections. First, we look at work that overlaps or enables our proposed optimization algorithm. In a second step we look at life cycle optimizations from other fields and explain, why they cannot be adapted to the domain of process automation. So far, there has been published little work on life cycle calculation in the context of Process Automation. To our knowledge, ours is the first attempt at optimizing Process Automation evolution plans. Kanawuchi and Rausand have published a white paper, looking at a specific application of Process Automation, i.e. oil and chemical industry. Their comprehensive cost model falls back on [DI05], which was also very important for our cost model. However, their model is more complex than ours; the requirements of our customers mandated an approach with limited input variables. Kanawuchi and Rausand briefly skirt optimization (even genetic algorithms) but do not provide or reference any optimization solution [KA99]. Also, Siemens has published a technical paper describing an LCC approach for process control. The solution is basically an expansion of dynamic investment calculation and fits well with various standards. However, they do not discuss any form of optimization [SI01].
Outside of the process industry domain a lot of material regarding Life Cycle Cost calculation can be found. Indeed LCC calculation for industrial production focuses mostly on discrete manufacturing and is largely industry driven [VD05, VD06, DI05]. In the defense industry, LCC calulcation is already an important issue and a calculation tool called EDCAS2 serves as the de-facto standard. However, there are also some university projects, for example the well-documented ViLMA. The ViLMA final report cites several industry examples for LCC, most notably Daimler’s approach to LCC controlling for their production machines [FL02]. While there are LCC optimization papers, these come from domains that cannot be easily translated to the cost drivers of process automation. A common field is construction, including steel structures [SA02], concrete structures [SA98] and highway bridges [FJ01]. The difference is that some of these have more easily assessable state information (e.g. corrosion) that the comparatively complex systems of a DCS. Also, obsolescence is no major issue in these cases. There are also papers addressing the optimization of product Life Cycle Cost. While they sound like related work from their titles, they address a different issue. Life Cycle Cost in the context of a product life cycle is actually the cost the producer has over the lifecycle of the product, e.g. cost for design changes and time to market. These approaches do not look at individual instances of the product but at the cost for manufacturing, marketing, shipping etc. [SK02]. This work is mostly unrelated and cannot be adapted for our purposes. Adeli and Sarma offer detailed optimization solutions for the life cycle cost of buildings including one based on Genetic Algorithms. However, as stated before, the domain covered is completely different from ours. For example, one of the main cost drivers to optimize is weight [Ho06]. Optimization also exists for some of the sub-aspects of LCC. Maintenance Optimization tries to find the balance between benefit and cost of maintenance activities. Our model is on a higher level of abstraction. Therefore, it does not distinguish between quality levels, the impact of which on MTBF would be future work. The main showstopper is the complexity and need for data (especially for outsourced service). Indeed many models of this kind are criticized for the fact that they focus more on mathematical details than on applicability ([De96], section 5.3). For an overview on the foundations of this field see [Mc65] and Chapter 3 of [De96]. Kleyner et al propose an optimization of the life cycle cost associated with mass market automotive electronics. Again, the cost drivers differ greatly from ours, with cost defined mostly by product validation and warranty cost [Kl04]. Sarangar and Kumar propose a GA-based optimization approach to the Level of Repair Analysis (LORA). LORA is about determining the optimal maintenance actions for structured complex systems and the optimal locations where to carry out that maintenance actions. For example, some specific module of an aircraft engine may be best replaced at the airport while the parts that the module consists of should be repaired at the manufacturer's site [Sa06]. From an algorithmic point of view, this approach is very similar to ours. There, the suitability of GAs for huge search spaces and the constraint handling capabilities are also identified as useful properties of GAs for life cycle cost optimization. The main difference is that there is no evolution of the system. That is, 2
http://www.tfdg.com/edcas.php
“replacement” always means “replace by a technically identical spare part”. However, for our problem, change is a major cost driver. Thus, we address a different problem and take into account different factors.
10.
Conclusion
In this paper, we have presented a GA-based optimization algorithm for the LCC of IT systems in Process Automation. We have identified the peculiarities of the problem domain and created a generic cost model. Different variants of Genetic Algorithms were tested with multiple examples and the best variant was showcased with a real-world example. As a result of our experiments, we were able to identify a core weakness of LCC calculations with regard to Process Automation. The approach of handling failures proposed in the standards is inadequate to handle the issue of obsolescence.. The optimization tool described in this paper is currently used in the context of several pilot projects within ABB. As future work, we plan to integrate risk aspects as a constraint into our optimization in order to avoid cost-optimal results that bear unacceptable risks. We will also further fine tune the input data for our system and look into controlling strategies for our optimized life cycle plans.
11.
Acknowledgements
The research work presented in this paper has been financed by the Industrial Software Lab at ABB. It is based on a master thesis at the chair of Prof. Lichter at the RWTH Aachen University.
References [AS98] Asiedu, Y., Gu, P.: Product life cycle cost analysis: state of the art review, International Journal of Production Research, Volume 36, Issue 4 April, 1998 , Taylor & Francis Group, pages 883 - 908 [BC02] Basel Committee on Banking Supervision (2002): Sound Practices for the Management and Supervision of Operational Risk. http://www.bis.org/publ/bcbs91.pdf, last visited 2007-12-1 [De96] Dekker, Rommert, Applications of maintenance optimization model: a review and analysis. [DI05] Deutsches Institut für Normung: DIN EN 60300-3-3 Dependability management – Part 3-3: Application Guide – Life Cycle Costing [DS06] Dervisopoulos, Marina; Schatka, Anne; Torney, Meike; Warwela, Marc: “Life Cycle Costing im Maschinen- und Anlagenbau”, in: Industrie Management 22, GITO Verlag, pp. 55-58, 2006 [Ei03] A. E. Eiben and J. E. Smith. Introduction to Evolutionary Computing. SpringerVerlag, 2003. [FJ01] Frangopol, Dan M., Kong, Jung S., Gharaibeh, Emhaidy S.: RELIABILITYBASED LIFE-CYCLE MANAGEMENT OF HIGHWAY BRIDGES, JOURNAL OF COMPUTING IN CIVIL ENGINEERING / JANUARY 2001 [FL07] Fleischer, Jürgen, Wawerla, Marc, Abschlussbericht ViLMA, Stiftung Industrieforschung, Forschungsvorhaben Nr. S 689
[FP95] Fuller, Sieglinde, K.; Petersen, Stephen R. (1995): Life-Cycle Costing Manual for the Federal Energy program. Technical Handbook 135, US Department of Commerce, Boulder, Colorado, USA [HA06] Hauff, Thomas (2006): Prozessleitsysteme: Lebenszyklus und Qualität. In: atp 2006 (48), pp. 43-42 [Ho06] Adeli, Hojjat; Sarma, Kamal. Cost Optimization of Structures: Fuzzy Logic, Genetic Algorithms, and Parallel Computing. Wiley, 2006 [KA99] Kawauchi, Yoshio, Rausand, Marvin, Life Cycle Cost (LCC) analysis in oil and chemical process industries, http://www.ntnu.no/ross/reports/lcc.pdf, last visited 2008-0627 [KI87] Kirvin, Bill: TCO – Applied Methodology Tools. http://amt.gartner.com/TCO/MoreAboutTCO.htm, 1987, last visited 2007-12-1 [Kl04] Kleyner, Andre; Sandborn, Peter; Boyle, Joseph. Minimization of life cycle costs through optimization of the validation program - a test sample size and warranty cost approach. Reliability and Maintainability, 2004 Annual Symposium – RAMS, pp. 553558 [KR04] Carpet and Rug Institute: “Understanding the Real Cost of Carpet”, http://www.facilitiesnet.com/bom/article.asp?id=2021, 2004, last visited 2008-2-28 [Mc65] McCall, John J., Maintenance policies for stochastically failing equipment: a survey. Management Sci., 11 (1965) 493-524. [Mi96] Michalewicz, Zbigniew. Genetic Algorithms + Data Structures = Evolution Programs. Springer-Verlag, 1996. [SA02] Sarma, Kamal C., Adeli Hojjat, Life-cycle cost optimization of steel structures, In: International Journal for Numerical Methods in Engineering, 2002, John Wiley & Sons, Ltd. [Sa06] Haritha Saranga and U. Dinesh Kumar. Optimization of aircraft maintenance/support infrastructure using genetic algorithms. Annals of Operations Research, Volume 143(1):91-106, 2006. [SA98] Sarma, Kamal C., Adeli Hojjat, Cost Optimization of Concrete Structures, J. Struct. Engrg., Volume 124, Issue 5, pp. 570-578 (May 1998) [SI01] Siemens, Life Cycle Cost Analysis of Process Automation Systems, Technical Paper, https://www.sea.siemens.com/process/docs/tp39-6_rev2.pdf, last visited 2008-0627 [SK02] Seo1, K.-K., Park1, J.-H., Jang D.-S., Wallace, D., Approximate Estimation of the Product Life Cycle Cost Using Artificial Neural Networks in Conceptual Design, The International Journal of Advanced Manufacturing Technology, Volume 19, Number 6 / April 2002, Springer, 2002 [VD05] Verein Deutscher Ingenieure: VDI 2884 – Purchase, operating, and maintenance of production equipment using Life Cycle Costing (LCC) [VD06] VDMA (2006): VDMA 34160:2006-06 Forecasting model for lifecycle costs of machines and plants. Technical Report, VDMA, Frankfurt
