evaluation tools for s88 batch control systems...

Evaluation Tools for S88Batch Control Systems

Design

M.Sc. Thesis at the Technical University of Denmark in cooperationwith NNE A/S and Arla Foods amba

Kristjan Haukur Flosason, s040321

February 23rd 2006

SupervisorsJohannes Petersen and Morten Lind

Ørsted•DTU, Automation

Technical University of DenmarkDK-2800 Kongens Lyngby, Denmark

Abstract

Automation is not always feasible for a manual production facility. The costof automation can be hard to earn back. There are financial arguments ineach case and these can support automation or not. Upgrading an alreadyexisting automation system is often even harder to argue for in discretefinancial terms. However, many automation systems are becoming so main-tenance intensive with spare parts hardly acquired that a strategic decisionto upgrade may need to be taken on technical terms rather than financialones.

Standardization methods in automation design provide means to increasethe productivity of the design process itself, thus contributing to the feasi-bility of automation. The standardized methods can be improved with othertools to further augment this utility. The S88 system design standard hasin this thesis been supplemented with the Architecture Tradeoff AnalysisMethod to provide a decision framework accelerating the design process andensuring that conflicting factors are objectively taken into account.

Further formalizing the design process is possible and this thesis at-tempts to formalize the work procedures used in building the physical modelof an S88 compliant control system. The formalization is possible to someextent but the essence of human creativity is still seen to be best left tohuman hands.

iii

Resume

Automatisering er ikke altid rentabel for et manuelt produktionsanlæg idetudgifterne kan være svære at tjene hjem igen. Der findes i hver sag økonomiskeargumenter for eller imod automatisering. Endnu sværere kan det være atargumentere for opgradering af et eksisterende automationssystem. Mangeautomationssystemer kræver dog efterhanden sa meget vedligehold at det,sammen med store vanskeligheder ved at skaffe reservedele, giver anledningtil en strategisk beslutning om opgradering. Det kan med andre ord lige sagodt være pa et teknisk som et økonomisk grundlag.

Standardisering i automation giver mulighed for at øge produktiviteteni selve designprocessen og dermed at forbedre projektets rentabilitet. S-tandardiseringsmetoderne kan ogsa forbedres med forskellige værktøjer forat fremme denne sag videre. Dette eksamensprojekt har undersøgt sam-menkobling af S88 standarden og Architecture Tradeoff Analysis Metodenfor at give en designer et beslutningsværktøj som accelererer designprocessenog sikrer at alle modstridende faktorer er objektivt vurderet.

Videre formalisering af designprocessen er mulig og dette eksamenspro-jekt prøver at formalisere arbejdsgangen i udledning af det fysiske model iet S88 kontrolsystem. Formaliseringen er i nogen grad mulig men kernen imenneskelig kreativitet er fortsat bedst sikret i menneskelige hænder.

v

Evaluation Tools for S88 BatchControl Systems Design

February 23rd 2006

M.Sc. Thesis at the Technical University of Denmark in cooperationwith NNE A/S and Arla Foods amba

Preface

This report is about different methods to evaluate and designautomation systems for batch processing. The project was carried outat the institute for automation at the Technical University ofDenmark in collaboration with NNE A/S and Arla Foods amba.

A CD is attached at the back of this report, containing the reportitself, program code and other relevant data.

I would like to thank associate professor Johannes Petersen for hisgood support and motivation during the project and professor MortenLind for valuable insights. NNE engineers Ole Abildgaard and SørenTrostmann have put a most important mark on the project andBjarne Nielsen of Arla Foods has provided solid information andfeedback.

Last but not least I owe my deepest gratitude to my wife, Suzanne,for enduring with me through the last year of my studies.

Date Kristjan Haukur Flosason (s040321)

Project periodAugust 1st 2005 to February 23rd 2006

40 ECTS-point

Contents

Introduction 1

1 Value of technical solutions 51.1 Economics of Automation . . . . . . . . . . . . . . . . . . . . 51.2 Retrofit Feasibility . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2.1 Production model revisited . . . . . . . . . . . . . . . 131.3 Benefits of Standards . . . . . . . . . . . . . . . . . . . . . . . 14

1.3.1 What is a standard? . . . . . . . . . . . . . . . . . . . 141.3.2 The benefits . . . . . . . . . . . . . . . . . . . . . . . . 151.3.3 The costs . . . . . . . . . . . . . . . . . . . . . . . . . 151.3.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.4 Project Justification . . . . . . . . . . . . . . . . . . . . . . . 171.4.1 Justification methods . . . . . . . . . . . . . . . . . . 171.4.2 Intangible factors . . . . . . . . . . . . . . . . . . . . . 211.4.3 Extended production function . . . . . . . . . . . . . . 221.4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.5 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.5.1 Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.5.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 261.5.3 Qualitative factors . . . . . . . . . . . . . . . . . . . . 271.5.4 Non-negotiable factors . . . . . . . . . . . . . . . . . . 271.5.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2 Batch Control Systems Design 292.1 S88 Standard Compliance . . . . . . . . . . . . . . . . . . . . 29

2.1.1 Brief overview of S88 . . . . . . . . . . . . . . . . . . . 292.1.2 Why and how to comply? . . . . . . . . . . . . . . . . 312.1.3 Retrofitting with S88 . . . . . . . . . . . . . . . . . . . 342.1.4 Importance to food industry . . . . . . . . . . . . . . 34

ix

2.2 Systems Architecture and Tradeoffs . . . . . . . . . . . . . . . 352.2.1 Architecture Tradeoff Analysis Method . . . . . . . . 352.2.2 S88 Batch Control Systems Tradeoffs . . . . . . . . . . 372.2.3 Examples of tradeoffs and solution . . . . . . . . . . . 402.2.4 Batch Control Analysis . . . . . . . . . . . . . . . . . 43

2.3 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.3.1 The process . . . . . . . . . . . . . . . . . . . . . . . . 442.3.2 Identifying quality attributes . . . . . . . . . . . . . . 462.3.3 Identifying strategies . . . . . . . . . . . . . . . . . . . 472.3.4 Assessing and comparing quality attributes . . . . . . 49

3 Design Evaluation 533.1 Method definition . . . . . . . . . . . . . . . . . . . . . . . . . 533.2 Method formalizing and implementation . . . . . . . . . . . . 57

3.2.1 Formalizing the description . . . . . . . . . . . . . . . 573.2.2 ATAM scoring model . . . . . . . . . . . . . . . . . . 643.2.3 Object model . . . . . . . . . . . . . . . . . . . . . . . 69

3.3 Program validation . . . . . . . . . . . . . . . . . . . . . . . . 703.4 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4 Conclusion 774.1 Benefits of S88 . . . . . . . . . . . . . . . . . . . . . . . . . . 774.2 Efficient engineering . . . . . . . . . . . . . . . . . . . . . . . 774.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Bibliography 80

List of figures 82

List of tables 83

A Program code 85A.1 pmoInit.m - Model initialization . . . . . . . . . . . . . . . . 85A.2 PMO.m - Optimize physical model and quality grade . . . . . 87A.3 prufa.m - Result visualization . . . . . . . . . . . . . . . . . . 90

Introduction

Automation technologies provide increased productivity and designers ofautomation systems have adopted productivity enhancing methods in theirown work. More and more software tools have some sort of intelligence builtin and many mundane design tasks are left to computers. This report im-proves understanding of design methods in automation systems as well asfinancial argumentation for upgrading an automation system.

Groundbreaking work in automation is not only about seeking moreefficient or more accurate controllers but also about finding new domains forimplementing control and automation. This project attempts to do preciselythat — improving design productivity.

Problem formulation

Integrating standard S88 in an automation system is becoming the normin most larger batch manufacturing facilities. Using the standard demandscertain resources, it demands more manpower to design the system but therewards are expected to justify the extra resources. It is not quite clearhow much the standard provides in terms of quantitative advantages orhow much extra resources it claims. This project sheds a light on relevantquestions about the feasibility of the standard. A larger part of the projectis then about reviewing and developing design aids that can speed up thedesign process and result in a more optimal design.

Approach

The report progresses from literature review of economical theory, through acritical observation of the S88 standard to the development of design meth-ods. In order to give a practical perspective to the project, a case is studiedin relation to the work. The case studied is HOCO, a 50 year old nutritional

1

2

supplement factory currently owned by Danish dairy giant Arla Foods. Oneof the products of HOCO is casein and the control system needs upgrad-ing. The HOCO case gives opportunities to investigate the relevance of thepresented theory and methods.

Report contents

The first chapter of the report will cover the economical issues previouslydiscussed. The chapter will introduce basic economic principles regardingautomation and in particular retrofits of automation systems. Standards areconstantly becoming more and more important in automation systems so thebenefits of standards will be discussed. As technical managers often need toconvince financial managers about the importance of automation systemretrofits, the first chapter will briefly discuss project justification methods.The first chapter concludes with an analysis of the feasibility of upgradingthe automation system in HOCO.

The goal of the first chapter is — through well known and classicaltheory — to establish a foundation and gain understanding of the economicprinciples that govern industry and thereby clarify why it is we automateand upgrade our systems.

The second chapter discusses the essentials of the S88 standard anddescribes the design process and the different alternatives that need to beconsidered. During this process different tradeoffs have to be accepted somethods will be proposed to assess these tradeoffs and effectively arrive atan optimal solution. As in the first chapter, the HOCO case will be takenup again, this time from a more technical perspective, as an S88 model willbe built for the casein process and an optimum solution sought out throughsystematic evaluation of alternatives and tradeoffs.

The purpose of the second chapter is to give insight into S88 designmethods and different alternatives that need to be considered. With thatknowledge, one is better equipped to continue in the development of gener-alized design methods that eventually could be automated to some extent.In the second chapter, relatively recent standards and methodologies areused to solve a design task.

The third chapter is the most creative part of the report. It formalizesthe work habits of experienced engineers and creates an evaluation tool anddesign aid.

The backbone of this report is formalization of somewhat abstract termsdescribing economics as well as technology. This formalization effort should

3

give the reader better understanding of fundamental economic arguments inautomation as well as a more detailed view of batch processing design andthe S88 standard.

Chapter 1

Value of technical solutions

This chapter will provide a literature review of related economic theory andapplications. The basic economic theory is discussed and it should forma background understanding to economics related to automation. Lookingeven closer at different automation scenarios, the retrofit problem is ex-plored and a method introduced to objectively estimate the feasibility ofsuch a change. Since one of the main interests of the collaborating partner,Arla Foods, is to implement a new control system under the S88 standard,the economics of standards will be discussed so as to give a better ground-ing in deciding on standardization. There will be an introduction to differentproject justification methods, particularly aimed at investments in automa-tion systems. All of the above material will be used in a case study for ArlaFoods, where the costs and the benefits of migrating to a new control systemwill be evaluated.

1.1 Economics of Automation

The neoclassical production theory provides an intuitive explanation of theeconomics of automation [4]. The explanation applies to a firm about whicha few simplifying assumptions are made. Among these assumptions are

• the firm produces one homogeneous product

• demand and supply are in equilibrium in relevant markets

• the firm is owner-managed

• the firm maximizes profits

5

6 1. Value of technical solutions

The production is viewed as a combination of inputs or ’factors of pro-duction’, most importantly labor and capital. Automation systems are aconsiderable part of the capital in the equation but more generally, capitalincludes buildings and machines that are used in the production. The laborfactor is simply the workforce used in the production. In its analytical form,the production function is:

Q = f(K,L)

where Q is output, K is capital and L labor. The production function canbe represented by a series of isoquants1 along whom infinite different com-binations of the production factors produce the same amount (see figure1.1). The convex shape of the isoquants means that as one production fac-tor replaces the other, the process of substitution becomes gradually moredifficult.

Two different conventions can be used to describe the picture. The iso-quants can either represent a change in output (Q1 > Q2) or a change inefficiency in the production of constant output (Q1 = Q2). At any giventime, the company should be expected to produce the output with the com-bination of factors that minimizes the production costs. This combinationcan be shown to be represented by a tangent to the isoquant function, thetangent having a slope equal to the ratio between the production factors.All the points on Q2 represent maximum technical efficiency but only thetangent point corresponds to the maximum economic efficiency.

In the neoclassical production theory, a shift of the production functionrepresents technical change. In figure 1.2, Q2 is a more technically advancedproduction than Q1. The shift can actually take a number of paths as shownin the figure. Q2 uses proportionately the same input as Q1, Q3 uses pro-portionately more capital and Q4 uses proportionately more labor. These d-ifferent shifts represent different technical changes, where Q1 → Q2 is calleda neutral technical change, Q1 → Q3 is a labor saving technical change (e.g.machines, automation) and Q1 → Q4 is a capital saving technical change(e.g. outsourcing, cheaper workforce) . The changes that are not neutral arecalled biased.

If there is a change in the ratio of the factor prices, a rational firm wouldchoose the technique that minimizes the cost in the new situation (see figure1.3). Graphically, the slope of the tangent changes so a new tangent point isfound. The most effective technique was presented by C before the change

1Isoquants represent all combinations of two factor inputs which produce an identicallevel of output.

1.1. Economics of Automation 7

Figure 1.1: Production function represented by isoquants. Q1 can eitherrepresent greater output or higher efficiency.

but after the change, labor became proportionately more expensive thancapital so a new equilibrium is found in C ′.

As shown in section 1.4.2 and the following case study there are numerousother factors of production that affect a real world scenario. The theorypresented up until now is a simplified view of the production world made oftwo factors but at the same time it is justifiable and it gives a good overviewof the economic playground. An extended version of the two dimensionalproduction model consists of additional dimensions and constraints and willbe presented in section 1.2.1.

Historical evidence has shown that existing techniques are modified ornew techniques invented to use proportionally less of the most expensiveinput[4]. When the cost of one factor changes a new equilibrium can befound to produce the same amount with lower costs and a rational firm wouldrearrange the production to match the new equilibrium. (Irrational firms arealso found, e.g. in Copenhagen’s Christiania and in Amish communities).In many cases, new technologies or automation lower the relative cost of


Figure 1.2: Production function shifted by technical change. The shift di-rectly towards (0,0) is called neutral change, the others biased.

capital so that it becomes a more feasible input into the production thanlabor. This puts people out of work. This classical explanation is still validtoday and it is interesting to see the economic theory rationally explainingwhy assembly work is being sent to the Czech Republic or China in thebeginning of the 21st century. It is simply more preferable than to invest inexpensive automation systems. Another advantage of manual labor is thatit is more general and flexible than machines. A firm executive makes thisrational choice because he has no motivation other than to maximize theprofits.

Automation can be viewed as a consequence of a rising stock of capital[3] so automation is here acting as a means of adaptation. As capital in-creases, the wages increase and it thus becomes preferable to shift to capitalintensive techniques previously not economic. Automation methods or tech-niques are usually invented a long time before they become a feasible optionin production. An automation method sometimes called ”Detroit automa-

1.1. Economics of Automation 9

Figure 1.3: Factor price ratio changes lead to changes in the most effectivetechnique. C is the most effective technique when the factor price ratio is A-B. When the factor price ratio changes to A′-B′ the most effective techniquebecomes C ′.

tion”was developed in the UK car industry in the early 20th century forinterlocking work transfers between automatic workstations. The methodwas technically successful but it was not economically successful until a fewdecades later when the wage rates had doubled. In the same way, expectedlabor rates increase can support automation decisions.

As opposed to the adaptation role of automation, inventions can leadto quick automation. An imperative in the profit driven production worldis that a new invention that saves both capital and labor compared withexisting technologies will be applied.

Even though automation has been around for thousands of years, au-tomation in the early 21st century is primarily seen as digital technology(DCS, PLC, SCADA etc.). The more elementary form of automation is notso much viewed as an automation system in itself as the digital systems. It


makes sense to talk about automation in this way because the benefits of au-tomation are maximized through the information gathered from the systemsand the integration of the information. deSpautz [5] is a good source on thebenefits of automation and in particular the digital automation techniques.According to deSpautz, some of the tangible benefits of digital automationare found in:

• manufacturing resource planning

– reduced inventories

– real-time data

– improved scheduling

• plant floor execution

– less production delays

– shorter production cycles

– improved material tracking

• document management

– less time to create documents

– improved operator productivity

– reduced batch variance

• quality

– improved product quality

– improved yields

– reduced WIP 2

• maintenance

– reduced down time

– reduced parts inventory

– improved maintenance productivity

2WIP: Work In Progress.

1.2. Retrofit Feasibility 11

New challenges constantly arise in the production industries. Global-ization, regulatory pressures and price control are adding to the complexoperations of process plants. Greater returns in the form of increased effi-ciencies, manpower rationalization and productivity gains are being requiredto justify the expenses for new automation systems. Therefore it is impor-tant for the planning engineer to have some economic ground to stand onwhen projecting a new system. Further and more detailed work on financialjustification is found in chapter 1.4.

1.2 Retrofit Feasibility

”Retrofit is a term used to describe the replacement of one ormore components of a system with the intention of improvingthe system. The improvement objectives can include optimizingthe cost of operation, optimizing product quality, avoiding thecost of building a new system or increasing the capabilities ofexisting systems.”[7]

As discussed in section 1.1, a new invention that saves both capital andlabor compared to existing technologies will be applied. The firm clearlygains by lowering costs and new advanced automation systems often bringstrategic as well as financial benefits. One of the main obstacles to justifyinginvesting in more advanced automation systems is that the benefits arebecoming increasingly more of the strategic kind [16] and therefore needto be evaluated qualitatively. The traditional economic analysis methodsoften fail to justify investing in high tech equipment unless with unrealisticbenefit estimates. This makes managers somewhat reluctant to investing ina system upgrade.

The strategic benefits, although hard to financially quantify, are essentialto companies working in a strictly regulated environment and facing interna-tional competition. The evaluation of retrofit feasibility must include futureestimates of the customer base and that depends heavily on the operationsbeing flexible, responsive and of high quality. The retrofit feasibility is alsoheightened by looking at the authorities’ demands for complying with lawsand regulations. Documentation of production processes is becoming an im-portant part of all companies’ operations [7], both towards its customersas well as towards the authorities. Efficient documentation procedures cansave great resources and these efficient procedures are attainable throughthe advanced automation systems. The features added in each generation of


automation systems are usually not revolutionary but a system’s life timeshould be evaluated and the system replaced before it becomes obsolete,non-functional or too maintenance intensive. The replacement phase shouldbe used to estimate the future life span of the system and get as much aspossible from the retrofit.

As stated earlier, the retrofit should aim at improving a system. The im-provements should be obvious even though it is hard to put a price tag onthem. The strategic improvements are essential to a company willing to sur-vive in an international playground. The control engineer needs to establishthe retrofit goals in order to aim right in his work and avoid irrelevant work.These goals should be evaluated after the retrofit has been implemented tosee how the plan turned out and to see if future plans need to be revisedor postponed. These goals can be subjective as well as objective because anevaluation afterwards allows for a relatively good estimate of all the factors.

The benefits of digital automation have been shown to appear in manyparts of the operations: maintenance, quality, productivity etc. By goingfrom an old automation system to a new one these benefits are furtherenhanced and greater strategic benefits include:

• shorter lead time

• more consistent quality

• improved capability to react to changing demand

• more efficient documentation procedures

• regulation compliance

There are generally no technical drawbacks with a retrofit, i.e. migratingto a more advanced automation system. The investment still needs to bejustified with the benefits and a plan devised to counteract possible dangers.When retrofitting a control system in a running production plant, care needsto be taken to plan the transition so as not to stop the production for toolong and extensive tests have to be made to try to avoid errors in subsequentstages of implementation and operation. The retrofit project may providea tempting opportunity for the engineer to implement new features in anautomation system, features that are hardly relevant or beneficial to theprocess or the financial result of the firm. It is therefore quite importantfor the engineer to focus on the core improvements and stick to working onthose until they are accomplished.

1.2. Retrofit Feasibility 13

The costs of retrofits include programming, training and installation andthe benefits include productivity and quality increase and maintenance de-crease. Methods to justify automation and retrofit investments will be dis-cussed in detail in section 1.4. Some issues are specific to retrofits and needto be considered. These issues will be addressed in the case study in section1.5.

1.2.1 Production model revisited

The production function presented in section 1.1 is a simplified view but itgives a good overview. It should be possible to analyze production situationsby means of the production function if it wasn’t for the mere simplicity ofthe function and the assumptions that are made. In the late 20th century, asfinancial argumentation became harder with classical economic theories, theproduction model got added value by intuitive observations. These obser-vations have become known to explain the so-called ’putty-clay’ productiontechnology [1]. It claims that before production is started, a company hasmany alternatives and can choose from a wide variety of possible techniques.However, when the production is set in motion, machines are in place andcontracts are made, then the company has fewer possibilities of substitutionin the short run. Thus the ’putty-clay’ analogy: Putty can be molded inmany ways before baking but once baked it becomes hardened clay and itsshape cannot be changed. So, what seemed to be a flexible model in section1.1 is actually only flexible in the long run and not immediately applicableto all scenarios.

Plant life cycle

Different factors dominate in the economic feasibility depending on wherein the life cycle an automation system is. When changing from manual pro-duction to analog automation in the early 20th century, a purely financialargumentation may easily have been strong enough to support an executivedecision to automate a plant. 30 years later when the analog automationsystem was no longer providing the competitive advantage it did in its earlydays, the managers would take a DCS system into consideration. It mightclearly be a more accurate system and it could provide operators with a bet-ter working environment. The investment is however considerable and theargumentation is not as clear cut as it was in the first automation project.When the DCS system is running out of life time, the new automation ar-chitecture is presented but the economic argumentation is still weaker. The


performance of the plant will not be dramatically improved and the opera-tors’ workplace will not change much. The argumentation this time wouldbe that regulations and standards are demanding the retrofit even thoughthe investment is greater than the short term benefits.

This little anecdote explains what differences there are in justifying au-tomation projects depending on if it is initial automation project or if itis a retrofit. In first-time automation scenarios, the production model is animportant argument for the investment but the model gets weaker in itssupport as more qualitative and non-negotiable factors come into play. Thisis well supported with the ’putty-clay’ notion.

1.3 Benefits of Standards

1.3.1 What is a standard?

A standard is an agreed way of doing something. Standards can have differ-ent degrees of validity, ranging from a formally published standard to a com-pany’s unwritten procedure. Standards can apply to products, processes orservices. Some examples of standards are the ISO 9000 quality managementstandard, BS 5808 for carpet underlay, DIN 53923 about water-holding, S88for batch control systems and all the Internet standards with abbreviatednames e.g. FTP, HTTP, HTML and XML.

Standards can be private, public, national or international. Private s-tandards are used within an organization that developed them whereas apublic standard is usually developed in cooperation between several orga-nizations and shareholders. Public standards can be used by any relevantorganization. National standards are developed in collaboration with thegovernment, businesses and society and can be enforced by regulation or becomplied with voluntarily. International standards are developed by largerorganizations, such as the European Committee for Standardization (CEN)or the International Organization for Standardization (ISO) that have na-tional standards organizations participating.

The more formal standards - the national and international ones - do notalways require compliance. Sometimes they specify requirements for an en-tity or enforce compliance through legislature but other times the standardsare only a recommendation for best practices.

1.3. Benefits of Standards 15

1.3.2 The benefits

Although standards’ primary objective is to establish an agreed way of doingsomething, they reach much further than that and benefit businesses as wellas government and the general public.

Businesses benefit from standards partly because

• standards enable interoperability and thereby open up markets

• innovation is increased by the platform for knowledge sharing, reducingrisk and costs

• standards can act as a flexible alias to regulations, thus reducing reg-ulatory burden.

Government benefits from standards partly because

• emerging technologies may require frequent alterations in existing reg-ulations. The regulations can be complemented with standards and thestandards then updated through industry consensus instead of chang-ing the regulations all the time

• research and development is encouraged by standards that allow knowl-edge sharing and reduce risks and costs.

Society benefits from standards mainly in the way that products andservices improve.

Looking more into the detailed benefits of standards, they allow profes-sionals to be more productive working with standardized technologies acrossdifferent projects or companies. Outsourcing becomes a safer endeavor be-cause components and systems that are developed by an outsourcing partnercan be plugged into an existing system without any adaptation, given thatthe existing system conforms with the same standard. Developing an entityaccording to a standard ensures its future usability and easy migration intoa subsequent system.

1.3.3 The costs

Standards and their compliance come at a cost. Most standards requiresome training and even implementation of a new technical infrastructure.It has been estimated that control system retrofit with the S88 standardwill cost 30 to 100 percent of the installed cost of existing systems [15].This is still important because the legislative authorities are demanding


new features that are hard or impossible to achieve in older systems. Insome cases the decision to comply with a standard is optional but in othercases it is required by law and in yet other cases it is a bare necessity becausewithout the standard a system would not be functional. In the cases whereit is optional, a financial justification should be in place before implementingthe new standard.

1.3.4 Examples

Standards ideally work for the safety and convenience of all and they areunderlying in many events in daily life. Credit cards are the same size all overthe world and electric sockets are standardized to a few alternative solutionsin different countries. Labeling of consumer products is standardized andprovides consumers with safety and ease of use and virtually every part ofthe computer industry is standardized, creating enormous synergy betweendifferent hardware and software vendors. A few examples of standards givea good explanation of standards and their different nature.

The ISO standards ISO9000 and ISO14000 are some of the better knownstandards in the world. They relate to quality management and environmen-tal procedures. These standards are quite extensive so a company usuallyneeds extra resources to implement them. Among the rewards for doing soare credibility and prestige as well as an established source of known pro-cedures. In many cases the implementation of the standard enables fasteraccess to markets and quicker acceptance by authorities and consumers.

One of the better known de facto3 standards is the QWERTY keyboardlayout that western countries use today. In the early days of typewriters,with certain keyboard layouts, the typewriters would become jammed ifthe typist operated too quickly. The solution, developed in the 1870s, wasto separate frequently connected letters to slow the typist down and thusthe QWERTY layout came to exist. In 1911 the QWERTY typewriter wasthe first one to display letters immediately after they were typed and ittherefore came a preferred typewriter and won many trained typists over.Then it became the most widespread keyboard layout and even though thetypewriter jamming is no longer a problem, new and more efficient keyboardlayouts have not caught on. The vast majority of the worlds keyboards arecurrently QWERTY based and this is a typical de facto standard.

The Internet and its underlying techniques have been successfully stan-dardized with such an acceptance that the development of the Internet is

3de facto: Something that exists in fact but not legally as opposed to legal standardsor regulations

1.4. Project Justification 17

called a revolution, similar to the 200 years old industrial revolution. In the1970s a protocol called TCP was developed and in 1974 put in the publicdomain. This protocol allowed physically distinct networks to interconnectwith one another as ”peers”in order to exchange data. The protocol wasrapidly adopted because it was reliable, it was open and it became an in-tegral part of another standard, namely the de facto platform standard ofIBM or DEC hardware running the Unix software. Other proprietary net-work architectures and protocols were introduced at the same time as TCPbut the free, reliable and open standard of the TCP/IP was found to be theideal ’glue’ between networks built on a variety of different platforms andprotocols [19].

The S88 standard for batch control systems was developed to emphasizegood practices for the design and operation of batch manufacturing plantsand to improve control of bach manufacturing plants [18]. S88 provides stan-dard models and terminology for the design and operation of batch controlsystems. The standard separates products from the equipment that makesthem and this enables more productive system designs as well as more flex-ible manufacturing. The standard does not require strict compliance anddoes not suggest that there is only one way to implement batch control. TheS88 standard is a backbone of this project and is therefore further discussedin section 2.1.

1.4 Project Justification

In previous sections, it has clearly been established that automation, retrofittingand standardization can all provide economical advantage. However, this isnot always the case, so formal analysis is appropriate before investing in anew system.

1.4.1 Justification methods

Although economic analysis does not always justify a project by showing apositive result, the analysis is still an important part in successfully man-aging projects and keeping an overview of the operations. Many investmentjustification methods exist and each method is appropriate in certain cas-es. Parsaei and Mital [16] categorize justification methods into four classes.These are single-objective deterministic methods, multi-objective determin-istic methods, probabilistic methods and fuzzy set methods. Following is arelatively short description of the first three classes but for further explana-tion, refer to [16]. The fuzzy set methods are actually quite similar to the


scoring models and are not assumed to be important here.

Single-objective deterministic methods

In this class, a single economic objective is evaluated for the justification ofinvestment in an automation system. Among the methods in this class arethe Net Present Value (NPV) method, the Internal Rate of Return Method(IRR), the cost benefit analysis (CBA), payback period and the integerprogramming method.

The NPV is the the expected gain from an investment at a certain inter-est rate4. To calculate a project’s NPV one has to take the yearly expensesand the yearly revenues from a system, find the difference and discountthe value with an interest rate. This is done for each year throughout theproject’s lifetime. An investment is feasible for any non-negative NPV.

The IRR is the interest rate that makes the NPV of the cashflows fora given project zero. Any project with a higher IRR than a selected hurdlerate is acceptable.

The payback period is the minimum length of time required to recoverthe initial investment without considering the time value of money.

The integer programming method has the objective to maximize the N-PV value under given constraints of interdependence, mutual exclusiveness,multi-period budget, labor and material restrictions etc.

The cost benefit analysis method accumulates each factor and finds aproject acceptable if the benefits are more than the costs.

Multi-objective deterministic methods

In the second project justification methods class, methods are proposed toselect between multiple and conflicting objectives. Scoring model and goalprogramming are among the methods proposed.

The scoring model is good in that it accommodates the considerations ofintangible elements in an analytical fashion so it can incorporate strategicconsiderations in the analysis. The scoring model in [16] is carried out intwo phases, where the first phase considers the desirability of strategic (longterm) proposals available and the second phase evaluates each tactical (shortterm) alternative for implementing the most desirable option of phase one.In principle, the same method applies in both phases. A project’s sharehold-ers decide on certain attributes that are meaningful in evaluating a project.

4Interest rate is the ”rental”price of money. The borrower pays the lender for the useof the money. A higher risk project usually has to pay higher price for money


Some of those can be Flexibility, Cost reduction and Product quality im-provement. After having decided on these attributes and their weights, eachproposal is scored for each attribute and a linear additive model discoversthe most desirable proposal or alternative as in the following relationship:

MaxDj =∑

WiXij i = 1, 2, ..., m

where Dj is the score earned by the jth decision alternative, Wi is the weightassigned to the ith attribute and Xij is the expected performance of the jthdecision alternative with respect to the ith attribute.

Another method frequently used to evaluate multi-objective decision s-cenarios is goal programming. An analyst may be faced with numerous con-flicting goals such as low investment, short payback period, high flexibility,high quality etc. According to the goal programming method, ordinal pri-orities are developed for these goals and the most important goal pursuedfirst. After obtaining the first objective, the second goal is pursued etc. Inthis way, it is possible to attain an optimum solution.

Probabilistic methods

Economic assessments are often based on future expectations or estimates.These estimates can be uncertain to some degree, due to factors such astechnology changes, business risk, global economic health etc. Among thevarious methods developed to cope with this uncertainty is sensitivity anal-ysis.

The sensitivity analysis is a simple tool with which the decision maker isable to see which factors must be estimated with more care, which of themwill cause the most deviation in the actual result if estimated incorrectly.This analysis is carried out by varying all factors within a certain range andsee how that affects the result. An example of this is shown in section 1.4.4.

Since the cost benefit method will be applied in this project, a furtherintroduction is appropriate.

Cost-Benefit Analysis

One of the better known — and at the same time simplest — methodsto evaluate investment options is the cost-benefit analysis method (CBAM,CBA). The CBAM is relatively straightforward and its basic notion is verysimple. In it, the feasibility of a project or an investment is evaluated simply


by comparing the costs and the benefits involved. Putting it in the simplestform we have:

V = B − C

where V is the project’s value B are the benefits C the costs associated withthe project.

The above formula gains credibility by introducing into it the project’slifetime and calculating the projects net present value. Quoting [12] we have:

NPV =RFL∑

n=0

Bn − Cn

(1 + i)n

where NPV is the net present value of the project’s profit through its life-time, Bn is the total amount of benefits in year n, Cn is the total amountof costs in year n, i is the estimated interest rate and RFL is the remainingprofit generating life of the project.

The composition of the cost and the benefit factors depends on the typeof project being evaluated. Typical cost factors for a production site areproject commissioning and building, equipment, training, physical installa-tion, operation, service etc. Typical benefit factors are increase in outputquantity, workforce change, quality increase, safety improvement, mainte-nance cost decrease etc. Projects evaluated by CBA can be as different asa ship automation installation, building a power plant or investment in abusiness.

The interest rate is different between projects. The interest rates is therate that a firm would receive it it invested its money someplace else withsimilar risk. Common estimates are 10-20% and even higher for risky busi-nesses. The interest rate does therefore represent the estimated risk of aproject, the higher the risk, the higher the interest rate. Thus, the interestrate in a CBA for a startup company with a new technology would generallybe higher than in a CBA for a hydro power plant.

Figuring out a projects lifetime is different between fields whereas acomputer system has other factors affecting the lifetime than a building has.A computer system may be expected to have a lifetime of 10 years whenat the same time a radically new technology emerges every 18 months. Abuilding may be expected to have a lifetime of 80 years and during that timethe design becomes obsolete many times over.


Applications of CBAM

The CBAM tends to be further complicated by different users and differentscenarios with specific needs. There is actually no explicit rule that stateshow a CBA should be be carried out and this can clearly be seen in theevaluation of several projects [8, 20, 9, 6]. Going through this literaturegives a broader perspective to the world of CBAM and makes it quite clearthat the method is not strictly defined but needs to be adapted to eachindividual scenario. Each case also has to account for specifics of the caseand the CBAM approach.

Kaldellis et al. [8] evaluate small hydro power plants with a thoroughCBA and carry out an extensive sensitivity analysis to account for lack ofdata or very rough estimates.

Wang et al. [20] carry out a very theoretical CBA of series systems witha probabilistic approach as opposed to the more traditional deterministicapproach. The statistical methods allow one to make a more rational choicebetween different options where each one is dependent on probability distri-butions.

Direct benefits can be categorized differently form indirect benefits. Hinesand Davis [9] assess improvements in nuclear power plants’ monitoring andclassify reduction in manual labor as direct benefits whereas performanceenhancements are classified as indirect benefits. The line between these twoclasses is not always clear but it only affects the analysis, not the bottomline. Other things that might need to be taken into considerations are theindirect benefits a society gets from a project. A power plant outage may re-sult in considerable economic loss for the customers and this can be includedin the CBA model in a probabilistic way.

Ehlmann et al. [6] lobby for the project of sending humans to Marchby doing a feasibility study and a partly qualitative CBA. The costs arenot to hard to explore quantitatively but when it comes to the benefits theevaluation tends to become somewhat qualitative and as it turns out in [6]the CBA does not end with a conclusion. Instead a wide-reaching brainstormof possible benefits is discussed but it is hard to put a credible price tag onthings like international cooperation or learning about microgravity.

1.4.2 Intangible factors

Many of today’s automation projects are hard to justify by financial anal-ysis. Modernization is often a strategic decision and thus, traditional eco-nomic justification is not suitable. Many intangible benefit factors are hard


to quantify. International competition, regulatory pressure, time-to-marketand employee job satisfaction are all factors that are hard to put a pricetag on but may in many cases be non-negotiable if the company wants toprevent decline and loss of income. Such factors must be taken into accountin the final stage of the project justification because even though the cost-benefit analysis seems to be a strictly rational analysis, it often turns outto be quite irrational and out of touch with the real world if the externalfactors and constraints are not taken into account.

Many attempts have been made to quantify the factors that traditionallyare considered qualitative. So is the case of the ATOMOS project [12] wheresafety improvements are evaluated quantitatively. Rightfully, one can doubtthe correctness of such evaluations or the conclusions that are based onthem. Such factors should rather remain outside of the scope of the financialanalysis and only be taken into account when the executive decisions aboutthe project are being made.

Automation has recently more been seen as an ’enabler’ than merely ameans to save labor. A better automation system can enable managers tosee where waste and variances occur and so the system can be justified withquality issues, responsiveness and flexibility.

1.4.3 Extended production function

The production function discussed in sections 1.1 and 1.2 is naturally limitedand it needs several assumptions to make sense. Extending the function canhelp explain why choices are sometimes made according with the model andsometimes violating the model.

The simple production function has the form:

Q = f(K,L)

and in this abstract form it answers many of the questions raised in pro-duction planning. It is particularly helpful in explaining long term trends aspointed out in section 1.2 but the explanations may be more confusing thanexplaining when it comes to short term and executive decisions.

Extending the production function might raise the topic of adding di-mensions to this two dimensional model but most factors used in productioncan actually be incorporated into the two factors already present: capital (K)and labor (L). What is not presented or made clear in the production func-tion is that the factors themselves are subject to external constraints andthe output can be constrained as well. The one obvious constraint is that an


optimum solution is found where the ratio K/L is a certain number, depend-ing on factor prices. This is seen in figure 1.1 on page 7. Other constraintsare ideally compensated for in the model, whereas limitations in one factorlead to a higher price but the compensation is not always clearly visible.Some other relevant constraints in a non-ideal world are:

• regulations put a lower limit on capital usage

• regulations put a lower limit on labor usage

• competition puts a higher limit on capital usage

• available raw material is constrained

• available labor is constrained

• available technologies put a lower limit on capital usage

• substituting one factor for the other takes time and costs money

Some of these restrictions will become apparent in the following sectionswhere the production function is not actively used but rather maintained asbackground knowledge.

1.4.4 Example

The following simple example will clarify the use of some of the aforemen-tioned methods. In this case, cost benefit analysis is used together with netpresent value and sensitivity analysis. The costs and the benefits are esti-mated throughout the lifetime of a project and the NPV calculated. Sub-sequently, a sensitivity analysis is carried out to reveal the most sensitivefactors.

For the example, let us assume that the owners of a grinding mill arelooking into automating their plant further. An investigation of the case hasshown the following costs:

• Software, licences, programming, installing: 47

• Hardware, control room, plant, controllers: 137

• External costs, lost sales, disruption, failures: 40

• Periodic costs, training, service, upgrades: 125


The first three cost categories are initial costs Cinit that only occur inthe first year but the last category Cper will occur every year throughoutthe lifetime of the system. The system’s lifetime is estimated 15 years.

The following benefits Bann are expected to be derived annually fromusing the system:

• Staff decrease: 60

• Maintenance decrease: 80

• Energy reduction: 30

• Safety and environment: 10

Now the costs and the benefits have been estimated with the initialinvestment Cinit = 224, Cper = 125 and Bann = 180. For simplicity, salvagevalue of the system is estimated zero at the end of its lifetime. Assuminginterest rate for this project to be 10 percent, the net present value is 63.This is a positive sign and the investment should be made. Before makingthe final decision, sensitivity analysis helps clarify the risk of the decision.Some of the cost and benefit factors are well known and can be estimatedwith fairly high precision while four of the factors are less known and willonly be known after the implementation of the system. The four factorsare staff reduction, interest rate, safety savings and lost sales because ofdisruption. Each of these factors are varied within a 50% range. The resultsof the sensitivity analysis are shown in figure 1.4. It is clear from the figurethat the two factors the NPV is most sensitive to are interest rate and staffreduction. These factors might now be estimated again to make the analysismore robust but a decision might still need to be taken with some degree ofuncertainty.

1.5 Case Study

The case to be studied here is HOCO, a 50 year old nutritional supplementfactory currently owned by Danish dairy giant Arla. One of the products ofHOCO is casein and the current control system in the casein production isRS3 from Emerson. This system has been running successfully for 15 yearsbut since Emerson is stopping support for the RS3 system, a new systemneeds to be installed. Emerson is still a strong player in the field of automa-tion and some time ago, they launched their new generation of automationsystems. This is called DeltaV and it has already been successfully imple-mented in large sections of the HOCO plant and will therefore be used for

1.5. Case Study 25

Figure 1.4: A graphical summary of sensitivity analysis.

further retrofits. This section of the report will take into consideration im-portant factors in evaluating the project and try to shed an economic lighton the case.

As stated in section 1.2 the benefits of more advanced automation sys-tems are becoming more of the strategic kind so the traditional analysismethods are hard to apply. The case at HOCO may at first appear to beanalyzable with the cost-benefit analysis method, described in the last sec-tion. However, when the case is scrutinized further there appear to be noeasily quantifiable benefits in relation to the retrofit. There are other non-negotiable factors that make the retrofit a necessity and this strategic deci-sion needs to be supported by other arguments.

1.5.1 Costs

The analysis starts with establishing major cost categories and going furtherinto detail of each category. Expected major cost categories of cost are the


initial costs for software, hardware and external factors. The periodic costscould involve training, service, upgrade and maintenance.

The cost of the retrofit mainly involves hardware and software. Thatcost is estimated at around DKK 1,2 million and is equally divided betweenhardware and software (licences).

Programming work, installation and testing is mostly carried out by HO-CO staff members and is therefore not considered extra costs. Training costsare not relevant since no special training is undertaken when migrating toDeltaV. The operators simply move from one workstation to another andlearn how to use the new interface as they go. It is the control systemsengineer’s evaluation that special training period would be beneficial to op-erators before starting to use a new system but experience has shown that itis not critical and not profitable. The operators do however face a challengein that certain problems only arise every 3 years so there is not much train-ing in the reactions. Here, a simulator or training facilities could be usefulbut again, it has proven not to be detrimental.

The preparations for the switching could take up to three months, de-pending on how detailed the design and documentation will be. But physi-cally switching to another system for one process cell only takes one day ofchanging the controllers. This makes the disruption in production minimal.Actually, there are two casein lines at HOCO. Casein 1 outputs around 50t/h and casein 3 only 20 t/h and they are usually not run at maximumcapacities, so one lost day of production in casein 3 should hardly be men-tioned. If necessary, the lost production in casein 3 could be compensatedfor by running casein 1 closer to its maximum capacity.

It is estimated that the total investment in upgrading the control systemfor casein 3 is around DKK 1,2 million and that periodic costs do not occuroutside of what would have occurred with the old system.

1.5.2 Benefits

In the same way as for the costs, the most important potential benefits areestablished, where one might expect there to be a change in factors such asworkforce, maintenance, energy or safety. However it turns out that there isno considerable change in these factors. Upgrading to a new generation ofcontrol systems mainly changes things on the surface but the process stillneeds the same amount of human supervision and maintenance is largely thesame. A new control system changes nothing about the energy requirementsof the process. There is however a possibility that with a new system, moreaccurate or better performing regulators might be implemented, thus reduc-

1.5. Case Study 27

ing energy requirements to some extent. A more stable system also meansa more consistent quality. There are no changes in output with going fromRS3 to DeltaV. New ways to optimize the process might however show up,for example with a neural network add-in to DeltaV.

A quantitative estimate of the retrofit benefits has proven to be veryvague so a number will not be associated with the benefits.

1.5.3 Qualitative factors

The cost and benefit factors have shown to be either not present or hardto estimate. There are however factors that affect the situation and are on-ly estimated qualitatively. It is hard to put a price tag on better support,employee satisfaction and such. These factors do still count when making astrategic decision. Flexibility in production lines is at present not the pri-mary concern of HOCO but starting to work with methods such as S88 thatincrease flexibility will prove valuable in the long run because subsequentdesigns will have the flexibility built in, thus enabling easier and more effi-cient changes in products or production. Documentation is becoming moreand more important in the food industry. New regulations from the EU, aswell as from the American FDA, enforces tight control on documentationprocedures and traceability features in production. Designing S88 into a sys-tem makes the documentation up to par with the regulations and frees theoperators from much of the documentation work.

1.5.4 Non-negotiable factors

The RS3 control systems are being phased out by their supplier, EmersonSystems. Within 8 years there will no longer be any support to those systems.In the meantime, the systems are gradually less and less supported. Emersonhas issued dates for discontinuation of different products’ support but thereare no set dates for the discontinuation of DeltaV. In a few years, spare partsfor RS3 will no longer be sold and already today, the RS3 components aremany times more expensive than the DeltaV components. At HOCO thereis obviously a problem with components lacking for the RS3 system. If anextra keyboard is found, it is treasured like gold. The same goes for otherproprietary and legacy5 components for the RS3 system. This actually makesan economical argument for upgrading: An RS3 workstation (proprietary)costs hundreds of thousands of krona and the price is still rising fast whereas

5A legacy system is one with unreliable hardware, unavailable parts, costly upgrades,lack of support and service, limited proprietary technology


DeltaV runs on Windows (PC for DKK 6000) with a software licence (DKK30.000). This fact is hard to put into an economical model with the pricesof the RS3 components rising so fast.

1.5.5 Results

Calculating the difference in costs and benefits is a simple task and on-ly reveals that the initial investment is 1,2 million there are no periodiccosts and no quantifiable benefits. Looking at the case from a strictly fi-nancial perspective leads to the conclusion that the retrofit is not a feasibleproject. However, weighing in the qualitative factors and particularly thenon-negotiable factors leads to a totally different conclusion, i.e. the up-grade is considered a necessary action. It has to be completed within a fewyears or the plant will risk prolonged production stops and disturbances onlysolved with immense expenses. So after all, it may look like there is an eco-nomic support for the retrofit but in fact the expenses mentioned are of sucha degree that it is hardly even taken into consideration to pay those. Thedecision to upgrade is primarily a strategic one made on technical premises.

Of course it is rather disappointing not being able to set up a modelincluding all the theory that has been discussed in previous sections. Thatdiscussion has still provided important foundation to understanding the eco-nomical arguments and the importance of automation in a wider perspectivethan only the technical one. At the same time, the non-negotiable results ofthis analysis emphasize the fact that technical arguments can stand alonein supporting a strategic decision. One has to be aware of the multitude offactors affecting managerial decisions.

Chapter 2

Batch Control SystemsDesign

This chapter deals with the more technical aspect of the project. The S88standard in design is introduced and a method to analyze the design andthe different options and tradeoffs that arise. The HOCO case is used again,this time the control system design part of the case. Different alternativesand design tradeoffs are presented and systematically analyzed.

2.1 S88 Standard Compliance

The title of this section — although descriptive — is not fully justifiablebecause there is no such thing as a formal S88 compliance. S88 is a helpfuldesign guideline and engineers choose to use it because it increases pro-ductivity and quality of the design. Systems can be designed with differentdegrees of S88 compliance. A related standard, S95, actually describes dif-ferent implementations of S95 as conforming, compliant or complete so anabsolute completeness is in no way required.

2.1.1 Brief overview of S88

The S88 standard describes a physical model, a procedural control modeland several other models that can be used to define a producing facili-ty. S88 defines a hierarchical recipe management and process segmentationframeworks, which separate processes and equipment from the products theymake. S88 is primarily aimed at batch processing although it can success-fully be applied to other kinds of processes. A formal definition of batch

29

30 2. Batch Control Systems Design

Figure 2.1: S88 physical model and procedural model

process is given by S88 [2]:

A batch process is a process that leads to the production of finitequantities of material by subjecting quantities of input materialsto an ordered set of processing activities over a finite period oftime using one or more pieces of equipment.

The physical model is a hierarchy that describes a company, its process-ing facilities and goes further into details about the modules that produce aproduct. The higher levels of the physical model are rarely used but the low-er levels are directly used in control systems design. These are Area, ProcessCell, Unit, Equipment Module and Control Module.

The procedural control model hierarchically describes the proceduresthat are used to produce a product. The four levels of the model are proce-dure, unit procedure, operation and phase. Each is an ordered set of activitiesfrom the next level below. The physical and procedural control models aredescribed in figure 2.1.

2.1. S88 Standard Compliance 31

Figure 2.2: Mapping of procedural control model and physical model

Recipes link the process to equipment and define ingredients and quanti-ties. With this decoupling of equipment and process, the production becomesmore flexible and is thus better able to meet the ever changing demands ofmodern markets. Figure 2.2 describes the essence of the S88 framework.More literature on S88 is found in [2, 17, 18].

2.1.2 Why and how to comply?

There are several good reasons to work according to the S88 standard. Thebenefits are found in the design and implementation phase of a project aswell as in running the batch plant.

Isolating recipes from equipment is probably the most powerful fea-ture S88 enables because this makes recipe maintenance easier and processchanges more manageable. S88 also provides guidelines on how to recoverfrom abnormal events with a standard set of states.


Documentation and traceability are becoming increasingly more impor-tant in the food industry and collaboration between the food industry andthe pharmaceutical industry is growing where the latter can provide anabundance of experience and knowledge to the food industry. Products withundesired properties need to be called back from the market and a well struc-tured manufacturing execution system allows for efficient callback routinesto be implemented. One of the driving factors for NNE in implementing S88in their systems is the convergence between production and documentation.

By adhering to the S88 standard, communicating requirements betweenvendors and customers becomes more efficient and precise, as both partiesspeak the same language. Designers then create a system in a way that otherdesigners can understand and thus participate in the design or contributeessential improvements. This standard terminology can improve a compa-ny’s development process considerably and the design productivity. S88 hasproven to be a successful way of thinking.

In the same way that the engineers share information by talking thesame language, the systems themselves can be designed modularly, so thata design from one place is applicable in another place. This modularityis particularly important for companies that design many process plantswith similar modules or similar functions because the design can be reused,sometimes partly and sometimes totally, leading to improved productivityand efficiency.

When a company has more time to focus on the production itself insteadof focusing on maintaining the process equipment, the product quality in-creases and it’s consistency as well. This is appreciated by customers who— in return — keep loyal to the company, generating more revenue for thecompany.

This being said, and especially naming the more indirect benefit of cus-tomer loyalty it is appropriate to slow down in the praise. Much of theliterature on S88 claims benefits that have — at most — a vague logicalconnection to the utilization of the S88 standard. Parshall and Lamb [17]discuss the real benefits of S88 and then go off on a tangent about otherbenefits a batch manufacturing plant may derive from implementing S88.There are items like reduced batch cycle time and lower cost of capturingdata. These benefits have nothing to do with S88 but can be achieved withany well designed batch control system. This is an unnecessary oversell fortechnical people but it may be necessary to sell the idea to managers in high-er levels. However, there needs to be a logical reasoning behind the benefitsand that is not always the case. Companies often experience considerableimprovements in various production metrics after the implementation of S88

2.1. S88 Standard Compliance 33

[17] but the improvements can just as well be contributed by stricter workhabits and cleaning up the messy control room.

S88 compliance is not certified by an authority but instead it is up toeach engineer to create work habits that incorporate the S88 mindset. Thatmeans thinking modularly along the lines presented in the standard textand designing the control system accordingly. Most modern batch controlsystems offer features that either assist or force S88 into the design.

The first step in harvesting the benefits of S88 is to understand the s-tandard itself by reading it and other helpful material. A recommendablebook was written by Parshall and Lamb [17] and contains a practical per-spective to using the standard. When basic knowledge of the standard hasbeen attained, a system design can be undertaken with the S88 guidelines,on paper, or better yet, with a specialized assisting software, such as Con-trol Draw. The implementation can then be done in in any of the existingcommercial batch control systems, e.g. FlexBatch from GSE Systems, Open-Batch from PID Incorporate, VisualBatch from Intellution, FoxBatch fromFoxboro, InBatch from Wonderware, SattLine from ABB or DeltaV fromEmerson.

S88 can be implemented in a system to different degrees. Some controlplatforms that support S88 design allow the designer to choose whether tostrictly follow the standard, only follow it to some extent or not follow it atall. So there are certainly many ways the standard can be followed. In casesof smaller companies or projects it can be more of a personal preferenceof the engineer but in cases of a large scale design or a company specializ-ing in batch designs, the S88 guidelines provide a framework for increasedproductivity and quality and their use should be encouraged. Since S88 isnot a compliance document, a wide variety of implementations exist in theindustry. Designers can therefore balance the concepts of S88 against whatis economically feasible and practical for the operations.

Organizing the specifications

There are two extremes in how to handle the functional specification. Oneis to create a large functional-specification document for the entire facilityand another is to create smaller documents for each module. The benefitsof the large document is that it provides a ”big picture”of how that thefacility works but at the same time the document is harder to manage.The smaller documents are more manageable. These trade-offs have to beevaluated in each case but generally it can be said that for larger projects,smaller module documents are more feasible whereas for a smaller project,


one holistic document can efficiently keep all the design information.

2.1.3 Retrofitting with S88

When retrofitting S88 into an existing system, the physical design may beunchangeable and that poses a special challenge, whereas in a new system,the procedure can be designed and the equipment accordingly, laying it outto conveniently fit with the S88 view. No known method exists to map anexisting system into the S88 domain but in section 3.1 an attempt to createa design evaluation tool will be presented.

Before a retrofit, subjective and objective metrics should be developedto compare the process, before and after the retrofit. In the case of an S88retrofit, the metrics are more relating to the big picture, being more ofthe subjective nature. This has been shown in section 1.5 where there areapparently few objective benefits derived from the retrofit.

It is certainly a valid question whether or not to implement S88 at all. Inany case, S88 provides a structure that should be able to prevent extensiveredesign when a new system platform is presented. Many control systemsthat are now being retrofitted need to be designed again in great detail. Thiscan be attributed to the fact that no standard method was used in the highlevel design ten or twenty years ago. Another ten or twenty years from now,engineers can hope that S88 will still — independent of the platform chosen— provide the strong design foundation it seems to do today.

2.1.4 Importance to food industry

The S88 standard is important to the food industry because it providesguidelines on how to meet the requirements of different government regula-tions. Notably, the European regulation EU 178 states that companies haveto keep a full audit trail of the production and meeting theses requirementsis supported by using S88. Regulations from other bodies such as FDA1 andGMP2 also apply to companies working in the food sector and using S88prevents conflicts with the regulations. In S88 part 4, an object model forproduction record contents is described so setting up an S88 structure inphysical and procedural design will make compliance with the fourth partmuch easier. Adhering to the norms of S88 leads to a higher degree of trace-ability.

1FDA: US Food and Drug Administration2GMP: Good Manufacturing Practice, a set of standards

2.2. Systems Architecture and Tradeoffs 35

Traceability is an essential function of a quality management system.The high degree of traceability and the quality of documentation enablesquick callback procedures for sold products with undesired properties andat the same time, the source of the problem can be isolated and furtherproduct faults prevented. This is important for the company and consumersbecause both parties benefit from safe products. Furthermore, the informa-tion flowing in the food manufacturing chain has the potential to providean advantage since it can be sold along with the product [13].

2.2 Systems Architecture and Tradeoffs

When dealing with larger software systems, the quality of systems depend onthe high-level design decisions rather than how a certain solution is imple-mented or a programming detail is solved [11]. The high level decisions areoften called architectural decisions and those precede the implementation bydesigning the abstract framework for a system. One of the greater concernsof designers of S88 control systems is that with one architectural decisionsome quality attributes may be compromised as the different solutions aremutually exclusive. The different quality attributes (e.g. performance, se-curity, reliability) interact and more often than not, negatively affect eachother. Increasing performance is often at the cost of reliability and vice ver-sa. In designing a control system under the guidelines of S88 it has beenseen that certain quality attributes are compromised by one architecturaldecision and therefore a system needs to be iteratively designed, consumingvaluable time and resources. Often there is not one obvious ”right”solutionfor a particular scenario but instead a solution that best satisfies conflictingrequirements is selected. In traditional software engineering, several wayshave been proposed to analyze the different tradeoffs that occur with archi-tectural decisions. Two of those methods are Software Architecture AnalysisMethod and Architecture Tradeoff Analysis Method [10]. Such methods canform a basis for a modified method for S88 design and the latter will bedescribed in the following section.

2.2.1 Architecture Tradeoff Analysis Method

In a similar way to the economic analysis discussed in section 1.4, softwaredesign analysis can be carried out by means of a scoring model and a cost-benefit analysis called Architecture Tradeoff Analysis Method (ATAM) [10].This method focuses on quantifying quality attributes (QA) in differentarchitectural strategies (AS) and measuring the importance of each QA and


by comparing to the cost of each AS, a desirability metric is created. Thismetric enables the designer to make an objective choice between differentASs. Since this approach can be adapted to the S88 design tradeoff analysisa further explanation of this method is given.

The first step in the ATAM is choosing the different architectural s-trategies for comparison. The next step is for the project’s stakeholders toevaluate the contribution of each quality attribute to the overall qualityof the system and add up the scores to a certain total (such as 100). Forexample:

• Performance: 20

• Reliability: 30

• Interoperability: 5

• Security: 10

• Availability: 35

When the quality attribute importance has been assessed, the benefits ofthe architectural strategies need to be quantified. This quantification is doneby the stakeholders in a crude manner, for example by assigning numericalvalues from −1 to +1 to each quality attribute of each architectural strategy.A +1 means a substantial positive effect on the quality attribute and a −1means a substantial negative effect. Now the ”benefit”can be calculated foreach architectural strategy with the following formula:

Benefit(ASi) =∑

j

(Contij ∗QAscorej)

where Benefit(ASi) is the estimated benefit of architectural strategy i,contij is the effect of architectural strategy i on quality attribute j andQAscorej is the weight of quality attribute j. An example of this is shownin table 2.1.

The costs of each architectural strategy are now assessed, at this stagevery roughly (Low, Medium, High) or on a 1-100 scale. The costs shouldnot necessarily be seen in monetary terms although part of the cost can beestimated monetarily. The cost also consists of work effort needed, disad-vantages of strategy and side effects. After the costs have been assessed thedesirability metric can be calculated as follows:

Desirability(ASi) =Benefit(ASi)

Cost(ASi)


Architectural strategiesQuality attributes [weight] AS1 AS2Performance [20] +1, 0 −0, 4Security [10] −0, 5 +0, 2Availability [35] −0, 6 +1, 0Interoperability [5] −0, 4 0Reliability [30] 0 +0, 4Benefit −8 41

Table 2.1: Example of ATAM application

The architectural strategies can now be plotted for clarity as is seen infigure 2.3. In the figure, each architectural strategy has certain benefits andcosts estimated and the dotted ellipse around each indicates the uncertaintyin each estimate (average of shareholder’s estimates). It should be noted thatthis method coincides nicely with one implementation of the cost benefitmodel where an investment is found to be feasible if the benefit to cost ratiois greater than one. In figure 2.3, the solid curve circles those strategiesthat are considered optimal and the double dotted ellipse represents a non-negotiable strategy that must be implemented.

Some of the strategies are non-negotiable because they are needed tocomply with a standard, meet government regulations, keeping up with acompetitor etc. The other strategies need further scrutinizing to select theoptimal ones. Sometimes the AS with the highest desirability score can bechosen but there are often constraints (time to market, available technology)on which ASs can be chosen.

The ATAM process leads to a good conclusion but not necessarily theoptimal one. This is because it is hard to ensure a complete analysis of thesolution space. In order to achieve better results, more stakeholders need tobe involved and regular scrutinizing efforts carried out.

2.2.2 S88 Batch Control Systems Tradeoffs

Similar principles dictate batch control design as conventional software de-sign. Quality attributes are somewhat similar (performance, availability) butthere are also QAs that are more dominating the batch control domain (com-munication, modularity). Due to the complexity of a system it is often veryhard to keep an overview of the tradeoffs between QAs. Therefore, a wayto apply ATAM to batch control design is proposed here. Architecture doesactually not suffice as one term to describe the strategic design decisions


Figure 2.3: Architectural strategies plotted by costs and benefits. The solidcurve circles the optimal strategies and the double dotted ellipse representsa non-negotiable strategy that must be implemented.

for a batch control system because that system is defined on many differentlevels. There is physical architecture in the system and a functional architec-ture, the latter relating more to the architecture referred to in ATAM. Thephysical architecture will be the focus of chapter 3. However, as seen in thefollowing description, different architectural levels can be combined in onemethod that still gives a good indication of an implementation’s qualities.

ATAM does not have to be adapted much and the following steps canbe used in the case of batch control design:

1. Identify architectural strategies

2. Identify quality attributes and grade them for contribution

3. Evaluate all attributes to zero for the first AS

4. Evaluate each attribute of the subsequent ASs relative to the first one


5. Sum up the benefits for each AS. The highest scoring AS is supposedlythe most attractive one

The order of the process is not detrimental but a relative assessment isrecommended. The reason for adapting ATAM in this way — assessing oneAS and relatively assess the subsequent ones is that the estimates are some-what subjective. So, instead of assigning scores to each quality attributefor each architectural strategy independently, it is assumed to be a bettermethod to assign relative scores with a reference to one design. The qualityattributes can be evaluated with more certainty by direct comparison thanwith individual scoring. This also makes it easier to focus on the tradeoffsthat occur. This might actually be a more appropriate way in convention-al software design ATAM since the QA-score estimates are in many casesvery imprecise and not logically correlated with QA-score estimates for al-ternative designs. In this adapted version of ATAM, estimating cost andcalculating desirability is omitted because cost components are included inthe assessment (see table 2.2).

Identifying the architectural strategies available requires considerable ex-perience of the designer, or else the designer risks wasting time on a methodhe has no prerequisites to use and thus the effort can lead to confusing orinsubstantial conclusions. This initial identifying phase does not need to bedetailed, but rather a description of the intention in different domains ofthe project. Considerations like whether to use equipment module centric orunit centric designs; how much of the design to incorporate into classes andhow much to program individually; how to implement traceability etc. Thisstage of the design does not dictate how the S88 physical model is built up.It is more about how the functions of the system are implemented.

Among important quality attributes in batch control design are imple-mentation effort, modularity, flexibility, recipe management, traceability,performance and features, robustness, cleaning flexibility, and operator ap-preciation. Each of these attributes are described in table 2.2. The attributesshould be easy to evaluate for each design alternative. There are more at-tributes that only present themselves at later stages. They would require somuch work to evaluate beforehand that the tradeoff analysis method wouldbecome highly time and energy demanding instead of saving it, thus break-ing the purpose of the method.

In comparing the different quality attributes, some cases might seemlike comparing apples with oranges. This is the case for implementation andcleaning flexibility, where the attributes affect different budgets from thecompany’s viewpoint. Implementation is investment, cleaning flexibility is


operations and operator appreciation is an abstract term. However, takingall these different factors into a universal scoring method is justified withthe possibility to adjust weights in each case.

Batch control systems design has become more structured since the in-troduction of standard S88 a decade ago. In particular, the decoupling of thephysical and the procedural model of a system has provided great progressin design efficiency. These two major parts, the physical and the procedu-ral models do have their own tradeoffs. System architecture is therefore notthe most appropriate notion. A more appropriate notion could be to talkabout a physical architecture versus a functional architecture. The qualityattributes described in section 2.2 are mostly of the functional kind whereaschapter 3 will focus more on optimizing the physical architecture.

The performance and features attribute is a wide reaching attribute andit could be claimed that it should be divided into more of its components.That could well be done but at the same time it would increase the workneeded to make the ATAM evaluation. Therefore it is kept in one bundle ofsub-attributes and then evaluated in a subjective manner.

The decisions made in batch control design are only seen to a small extentin the running system but they affect the design work itself more. Often thechoice between two methods can be hard because the consequences can befurther away than just one-step reasoning. But because the architecturalstrategies mainly affect the engineer and his work, the stakeholders canbe the engineers themselves or their colleagues. The architectural decisionsdon’t have such a wide-spread consequence that a large group of stakeholdersneeds to assess the system as in the case of the ATAM previously described.The tradeoffs are usually evaluated continually by the designing engineerand the difference in solutions is rather dependent on the engineers field ofview.

2.2.3 Examples of tradeoffs and solution

To name only two different approaches in batch control design, there isunit centric design versus equipment module centric design. With the unitcentric design, the engineer achieves process functionality by running phaseson the unit. In this case the phases theoretically affect the whole unit. Thisis good for time critical applications because there is direct communicationbetween control modules (intra-unit vs. inter-unit3). At the same time this is

3Communication between units is usually more time consuming and it is harder toimplement than communication within a unit and therefore not suitable for time criticalapplications


Quality attribute DescriptionImplementation effort Includes design work, validation, implementation and

other engineering costs.Modularity A measure of how easily equipment phases can be

reused, how classes are used in the design or if eachequipment module has to be programmed as a sepa-rate instance.

Flexibility How much does S88 cover? If S88 extends into everypart of the system, it might be more complicated tochange the system. Typically trades off with modu-larity.

Recipe management Describes how new recipes are added or existing onesmodified, how well equipment has been isolated fromrecipes and if a large number of recipes is manageable.

Traceability Should be built into every new installation in batchmanufacturing and this attribute measures how wellhistorical data is tracked and if data logging and eventtracking are directly associated with a batch.

Performance and fea-tures

A very important factor in most automation systemsand it includes execution speed, communication, se-curity, possibility for manual operations, exceptionshandling and coordination control.

Robustness Describes a system’s capability to isolate problems, sothat problems in specific equipment have a minimaleffect on the rest of the process. Robustness is alsoabout how well deadlocks are prevented.

Cleaning flexibility Cleaning should be as flexible and equipment inde-pendent as possible so that the process equipmentis available for operation as quickly as possible aftercleaning.

Operator appreciation How well operators intuitively understand the S88design.

Table 2.2: Quality attributes for S88 design tradeoff analysis

a less modular design because there are less possibilities to reuse equipmentmodules. With the unit centric approach there are extensive possibilities forcoordination control between equipment modules and control modules buton the other hand this approach makes allocation and control of equipment


modules less visible to production staff.Regarding the equipment module (EM) centric design, process function-

ality is achieved at the equipment module level. This is a more modularsolution and gives the ability to call EM functions without needing to pro-gram each possible instance and combination. The EM centric system hasa longer execution time because equipment modules communicate throughthe unit and this is therefore not feasible for time critical applications suchas dosing in high precision applications. The design process is made easierbecause there is a simpler description of the EM states. On the other hand,coordination control between equipment modules and control modules isharder to implement.

Many other architectural strategies are conceivable but these two ap-proaches are radically different and most other approaches are only minorchanges on a larger scale design. One alternative design is splitting a unitinto more units where the process allows or demands it. Having a whole pro-cess in one unit requires a total stop of production while cleaning becausetwo batches may never exist in the same unit at the same time and a CIP4 isconsidered a batch. A way to make that process more efficient is to split theprocess into more units, thereby enabling CIP to start while still producingon subsequent units, and also starting production immediately after CIP isfinished on the first unit. CIP has to be possible independent from otherparts of a process cell.

Another approach could be to define the equipment modules to that eachphase in the process only relates to one equipment module. This enables thedesigner to only work with one equipment module in each phase but on theother hand, phase to phase communication is harder to achieve and thatmakes coordination control hard.

Different architectural strategies can be combined in one system to achievethe optimal solution but if a design for a process cell is being made by a com-mon approach, any deviation from that will cause confusion and inefficiencyin the design process.

Now, let us assume a system that is being developed for the pharmaceu-tical industry. For this project, the ATAM method was used to decide on anarchitectural strategy. The system has to be very accurate in dosing and thetraceability features are detrimental. Since the system is expected to controlthe production of a uniform product, it’s abilities for recipe management arenot that important. It is always appreciated that the implementation runssmoothly and that the design can be reused. The weight and evaluation of

4CIP: Clean In Place


Architectural strategiesQuality attributes [weight] AS1 AS2 AS3Performance [30] 0 +0,8 -0,2Traceability [40] 0 -0,5 -0,5Recipe management [5] 0 +0,3 -0,3Implementation [15] 0 -0,6 +1,0Modularity [10] 0 +1,0 -0,5Weighted score 0 +6,5 -17,5

Table 2.3: Architectural strategies evaluated relative to AS1

each of those factors are seen in table 2.3.From the table it can be seen that some improvement could be achieved

by following AS2 instead of AS1 but on the other hand, AS3 would leadto considerable decrease in quality. At the same time it is possible thatyet other factors influence the choice of architectural strategy that make itimperative to choose a less than optimal strategy.

In chapter 3, an attempt will be made to connect the implications of thetradeoff analysis of the quality attributes to a formalized method to createan S88 physical model.

2.2.4 Batch Control Analysis

With the introduction of standard S88 a more systematic approach to thedesign process is made possible. Engineers still make the remark that S88does not discuss design strategies and how to connect the procedural modelwith the physical model to achieve process functionality. This lack of guide-lines in the standard itself has at the same time lead to many approachesdeveloped and described, one of those described by Molnar et al. [14]. Inthe cited paper, a method called Batch Control Analysis is presented. Thismethod is comprised of five steps:

Process analysis — a simplified description of the process for controlpurposes Structuring — definition of hierarchy levels to be followed in thesystem (process and physical models) Decomposition of tasks — choice ofcontrol structure and design of procedural control elements List of instru-ments and manipulated elements Definition of operator requirements

This systematic design method has resulted in up to 50% shorter pro-grams and proportionately the same reduction in software errors. Accordingto [14], the systems also tend to be simpler to start up and be more reliable.

Reading through the method clearly indicates that it is fit to increase


engineering efficiency and yet, it can be further improved. The above elab-orated method of tradeoff analysis could improve the choices made in thestructuring and decomposition steps of the Batch Control Analysis and thenext chapter will introduce a method that aids in defining the S88 physicalmodel.

2.3 Case Study

2.3.1 The process

The process that will be focused on in this project is the production of casein.This process is described in detail in figure 2.5 where the extraction of caseinand drying and packaging of the product is shown. Milk is the input into theprocess and the output of the process is casein powder. Input to the processis 19-22% solids and the output is 84% solids. The production is a little lessthan three tons per hour. 250 tons of milk are fed to the system before theproduct starts emerging at the spray dryer at the end of the process so thereis obviously a large delay from input to output.

The milk is sent from storage tanks and initially pasteurized to destroypotentially harmful microorganisms. This is done by raising the temperaturefor a certain amount of time. After pasteurizing, the protein-richest part ofthe milk is extracted and hardened by raising the temperature and addingacid. The protein-rich part is then separated with a centrifuge so that onlythe casein continues in the process. This substance is now hardened evenmore at the same time as lactose and minerals are washed out. The hardmaterial is cut into smaller fragments to make is easier to dissolve. After thecasein has been dissolved it goes to a mixer tank where it is kept under opti-mal conditions before going on to further extraction. There are a few buffertanks in the process to prevent equipment to run dry or to lose pressure.This would cause damage or lead to frequent maintenance.

At this time in the process, the casein has been extracted from the milkand all by-products routed to appropriate holding tanks. The following partof the process is only for drying and packaging and many other processescan use that equipment. The casein is pasteurized and stored in a buffertank, from where it is injected into a spray drying tower. The substance issprayed into the top of a tower that contains warm air. The solid substancesfall to the bottom and most of the water evaporates. To eliminate as muchof the water as possible, the solids are dried more on a conveyor belt afterthe tower. The last stage of the process before bagging is sieving in orderto only bag fine grained material. This later part of the process that can be

2.3. Case Study 45

Figure 2.4: The casein process

shared with other products will for the sake of simplicity not be included inthis case study. So it only goes from where the milk is input into the systemto where the casein is cut up before emulsification.

An essential part in processing food is cleaning the equipment used inorder to prevent contamination or spreading of the same. In a normal house-hold the analogy is washing the dishes after a meal but in an automatedprocessing plant this procedure is known as CIP (Clean In Place) and ishighly integrated into the process. The CIP is commonly done automatical-ly when equipment is free but in many cases the CIP is controlled by anoperator that makes sure that the equipment being cleaned is not neededduring the time of cleaning. CIP also plays a crucial role in separating twobatches as is shown later. The casein line of HOCO is totally CIP cleanedevery 42nd to 120th hour and there are also regularly carried out smallerCIP cycles on parts of the line at a time. There is a buildup of bacteriaand microorganisms before and in the pasteurizing line where fresh milk isbeing handled. For that reason the pasteurizing line is caustic cleaned and


boiled out every 6 hours. The casein line is separated into three CIP sectionsbut since there is only one way through the process, the process is stoppedwhile the equipment is being cleaned. Immediately after the pasteurizing,the microorganisms are largely eliminated.

One difficult aspect of defining an S88 scheme for the casein process atHOCO is that it is barely a batch process. It rather resembles a continuousprocess whereas the process is started and then it runs continuously formany hours at a time. Procedural control is considered characteristic forbatch processes. There is only sequence control in few places in the system.There is a simple sequence for startup, the decanters have water injectionand the CIP has simple sequences. All of those sequences are time-controlled.Other control is a simple state control.

[PI diagrams and IO lists are available for the casein system but dueto the commercial value of these information they are not included in thisreport. Their value to the report is limited anyway. Instead we will use amuch simplified diagram to present the system. See figure 2.5]

Now that the process has been described, the method from section 2.2.2will be deployed to evaluate and compare different architectural strategies.

2.3.2 Identifying quality attributes

The casein system is not very time critical in the sense that no criticaldosing takes place and there are no operations that require fast processing.Therefore the performance and features attribute will have a 5% weight inthe evaluation between alternatives.

There are two casein systems running at HOCO and for the time beingno more of those are planned. It can never be totally excluded but the mod-ularity of the system is not considered a high priority and it will thereforealso have a 5% weight.

Recipe maintenance is usually important in batch systems but the caseinsystem is only producing one product and the changes to the receipt areminimal. However, recipes need to be maintained with accuracy to supportthe traceability so recipe maintenance will have a 10% weight.

The system has to be reliable and run as much as possible. Therefore,robustness (10%) must be ensured as well as cleaning flexibility (20%). Par-ticularly the later factor needs to be attended to because even though thesystem is not run at a maximum output, the efficiency of the system in-creases by shorter CIP stops.

Operator appreciation is not considered detrimental in the current sys-tem because the operators are expected to adapt to the system that is pre-

2.3. Case Study 47

sented. It can still not be any other system but needs attention in designing.Operator appreciation will have a 10% weight in the evaluation betweenalternatives.

Traceability is one of the main issues that is being improved by retrofittingthe control system. A good S88 design will aid traceability and this willtherefore have a 20% weight.

Implementation is always a big issue for designers and a smooth imple-mentation is their goal. So a 20% weight will be put on implementation sideof things.

2.3.3 Identifying strategies

First alternative (AS1)

The casein process cell has already been divided into S88 modules with sup-port from Emerson. State matrices are largely ready. The entire process isseen as one unit containing 12 equipment modules. An equipment moduletypically contains between 2 and 13 components. This approach is equip-ment module centric because functionality is implemented at the equipmentmodule level to achieve the process functionality. The process cell of thiscase has only one possible flow way and the equipment is therefore all ded-icated to the process. It is based on this fact that the whole casein processcell is made one unit. Dividing it into more units would require unneededoverhead to run it, such as allocating a unit and releasing it. This is notnecessary when equipment modules only need to communicate within thesame unit.

This alternative corresponds with the presentation in figure 2.5 wherethere are three equipment modules. The first equipment module is the supplyof raw material into the process, the second equipment module is the mainprocessing of the unit and the last equipment module is the final processingstages and packaging. The second step actually consists of many smallerprocesses, some of which are repeated. This is symbolically presented in thefigure.

The implementation is partly simplified because this approach leads toa simpler description of states. On the other hand, coordination controlbetween equipment modules and control modules is harder to implement sothis again negatively affects the engineering work.

An equipment module centric design is usually a more modular approachso a later reuse of equipment modules is possible, increasing design produc-tivity. There also comes up the ability to call functions in the equipment


module without having to program each possible instance.The selection of design approach, be it equipment module centric ap-

proach or any other, does not affect the traceability to a large extent. Trace-ability of the process is rather achieved by efficient documentation routinescoded into the system and in many cases the documentation system is al-ready built into batch control platforms.

The current approach could extend execution times but that is not rel-evant here because the casein process does not have any really time criticaldosing or other time critical operations.

Putting everything into the same unit has the disadvantage that onlyone batch can be present in a unit at one time and since the CIP is seen asa batch, considerable delays are necessary in the production while the CIPis taking place. This has been discussed in section 2.2.3.

Dividing the process up by the natural sequence of operations will pos-itively contribute to operator appreciation, not only because it gives anintuitive overview of the system but also because it is in accordance withhow the current RS3 system is designed.

Second alternative (AS2)

The second S88 design alternative is a unit centric design where processfunctionality is achieved by running phases on the unit. The physical modeldoes not need to change for that to happen, but instead of communicatingby means of the unit as in the first alternative, the equipment modulescommunicate directly with each other. This improves communication andcoordination control and the implementation becomes easier as well. Theapproach is less modular because the functions are not implemented onthe equipment modules. If interlocks are needed they will be executed withmaximum efficiency. The cleaning flexibility is not expected to change toany considerable extent.

Third alternative (AS3)

For the third alternative, the whole casein process cell is split into threeunits instead of having it one unit as in the first alternative. Furthermore,the design will be equipment module centric and so including all the benefitsattributed to this as seen in the first approach. The system is more modularbut communication and coordination control gets harder due to more inter-unit communication. The implementation will require more work because— as explained in the first alternative — a higher number of units requires

2.3. Case Study 49

more overhead allocating and releasing units. Cleaning flexibility increasesgreatly and shorter production stops are required to clean the process cell.

Reuse of designs is enabled by this approach (classes created for equip-ment modules) and validation becomes simpler through the same means.Upgrading one of the classes will affect all other instances of the class sothis makes the system a little more rigid so that upgrading one equipmentmodule will affect all equipment modules of the same class. This can be adisadvantage is the equipment modules are being changed independently.

Fourth alternative (AS4)

The fourth alternative can be considered a minor change to any of the above.It involves moving control modules around. But for this instance, it will bebuilt on the third alternative. So, an equipment module centric design inthree units. Regarding moving things around, several valves are moved intoown their own equipment module instead of having them on two separateones. By doing this the system is even more modular but implementationmight in return become harder and the flexibility might be compromised.

Another change for this fourth alternative is moving boundaries betweenequipment modules in order to make the system more logical, thus contribut-ing to operator appreciation. Two motors and several valves are moved be-tween equipment modules.

2.3.4 Assessing and comparing quality attributes

Now that all the design alternatives have been presented and their qualitiesdiscussed, the individual quality attributes of each have to be quantified.This is seen in table 2.4 where the first strategy is scored zero for all at-tributes. This is done to create a reference point for comparison with theother strategies. Each quality attribute for each of the other alternatives canbe evaluated with a score ranging from −1 to +1. Then the benefit formu-la on page 36 is deployed to calculate a total score for each architecturalstrategy, so the scores can range from −1 to +1.

From table 2.4 is can be seen that architectural strategy AS2 is the mostfeasible one according to this numerical method. The two factors contribut-ing most to this result are the increased ease of implementation and anincreased robustness and the lower modularity does not weigh particularlymuch. AS3 is also better than the baseline AS1 but the implementation getsconsiderably harder with modularity and cleaning flexibility being gainedinstead. With the different weights that were put on the quality attributes,


Architectural strategiesAS1 AS2 AS3 AS4

One unit One unit 3 units 3 unitsEM centric Unit centric EM centric EM centric

Quality attributes [weight] Move bordersPerformance [5] 0 +0,3 -0,4 0Traceability [20] 0 0 0 0Flexibility [5] 0 0,3 -0,2 -0,5Recipe management [10] 0 0 0 0Implementation [20] 0 +0,5 -0,7 -0,7Modularity [5] 0 -0,7 +0,5 +1Robustness [10] 0 +0,8 0 0Cleaning flexibility [20] 0 0 +1 +1Operator appreciation [5] 0 0 0 +0,3Weighted score 0 +0,175 +0,055 +0,100

Table 2.4: Architectural strategies evaluated relative to AS1

there is still not enough positive aspects for this approach to be consideredthe best one. AS4 is also a feasible solution, not far behind AS1 even thoughit has different qualities. Through harder implementation, increased mod-ularity and cleaning flexibility is achieved and the operator appreciation isalso higher. In table 2.4 it is obvious that traceability and recipe manage-ment are two factors that don’t seem to be affected much by the differentstrategies. This is however not a sign that these factors don’t belong in theanalysis because they could be affected by another strategy proposed. So itis for the safety that they are kept in here.

Of course, designing the quality attributes in first and fitting the systemdesign to those has been tried in S88 batch control design but the tradeoffsthat are inherent in the system platforms or mechanically in the processcell limit the designers possibilities. Going ’backwards’ through the designa designer can from table 2.4 see that traceability, implementation effortand cleaning flexibility are the highest priorities. Immediately there is anobstacle because increasing cleaning flexibility costs more implementationeffort so a compromise has to be found between these two attributes. Atthe same time, traceability will not be affected so much in this stage ofthe design. Robustness and operator appreciation can also be somewhatmutually exclusive. This shows that this ’backwards’ design approach is notsuitable and instead possible designs should be drafted and compared as

2.3. Case Study 51

suggested in this chapter.


Figure 2.5: An example PI diagram. This diagram is a very simplified versionof the casein process and explains some of the features described in the case.The topmost group supplies raw material to the process, the middle group ismain processing and the last group is final processing and packaging. Eachactive component in the diagram is a control module and can be combinedwith others to form equipment modules and units.

Chapter 3

Design Evaluation

Engineering is often seen as something inherently efficient. However, as am-bitious individuals all strive for more productivity, engineers always see anoption to solve their tasks in a more efficient way by automating and sys-tematizing parts of their work. The current status of the S88 standard andimplementation guidelines provides plenty of opportunities to increase de-sign efficiency and productivity.

In batch systems — the topic of this project — engineers tend to solveproblems based on their prior knowledge. The last chapter provided and dis-cussed some systematic approaches in S88 design that have a potential to im-prove the design process. Empirical evidence suggests that up to 50 percentdecrease in software size and errors can occur with systematic approaches[14]. This chapter proposes yet another method for efficient engineering. Themethod’s development and its validity will be described.

Design aids can increase quality and productivity in the design process.This chapter focuses on creating a design aid for design of batch control sys-tems under the S88 method. The design aid will include the scoring modelfrom the last chapter and thereby allow grading of different design alterna-tives suggested by an algorithm developed. This design aid primarily helpswith the definition of the physical model but at the same time it helps withthe subsequent design considerations.

3.1 Method definition

Many work procedures seem at first glance to be hard to formalize, thushard to automate. It is generally considered hard to automate creative workbecause there is a lot of intuition and dynamic intelligence that goes into

53

54 3. Design Evaluation

the work. Typical tasks that require creativity and intuition are painting,fiction writing, pioneering scientific research and - many types of engineering.Although it can be hard to see structure in creative work there are certainactions that are repeated or done systematically. If these actions can bedescribed, they may perhaps be formalized. In the following, the descriptionis in place so a cocky attempt to formalize it is only appropriate in thiscontext. This is primarily an evaluation tool but it also has the potential tobe actively used to do part of the design process itself.

Documenting of work procedures as shown in this section is importantfor any company working in the field of structured creativity such as engi-neering, design and programming. One of the reasons is that one generationof staff has often only a vague idea of the work procedures of the previousgeneration. As a consequence thereof, knowledge is lost and productivitydiminishes. Another reason for the importance of documented work proce-dures is that knowledge acquired and maintained in one link of the designchain is lost in subsequent links. An example of this could be a pharma-ceutical plant being designed by different classes of engineers. The processspecialists start the design by dictating what needs to be done. They knowwhy it needs to be done in such a way but it rarely goes further in the designchain. The next link in the design chain could be that structural specialiststake the specifications from the process specialists and design the structuresnecessary to produce a product. In the end, the control specialists enter thepicture and implement a control system for the plant. They may only havea faint idea of why a certain part of the plant is built in a certain way butas they gain experience their insight and intuition increases and they geta good overview over the process as a whole. There is usually a need forsomeone to lead projects through the design stage and the control engineerscould be a feasible choice for such a leadership because they have a goodoverview.

The work procedures of S88 design often seem to be highly individual, soone engineer might not find another engineer’s design methods particularlyeffective. After several meetings and talks, NNE control engineers came upwith a written and structured description of their methods to define thephysical model of S88. The description follows:

Unit definitionMake units as large as possible. Large units mean fewer unit interfaces todefine and manage. Size of unit is limited formally by:

• A unit can only contain one batch at the time. Analyze the productionsequence requirements to find out where contiguous batches are sepa-

3.1. Method definition 55

rated on the equipment at any time. Unit boundaries must be definedwithin these separations.

• Cleaning of equipment in the time between contiguous product batchesinfluences the localization of the unit boundaries. Cleaning as separate”batches”should be possible and therefore a product batch shall not bein a unit at the time where a cleaning is done on (parts of) the sameunit. If dispensation from this is required, the applicable part of theunit shall be defined as a common resource (and hence, eventually itmay be defined as a separate unit).

Size of unit is limited informally by:

• A unit should be of a size and have boundaries that match something anoperator would be able to comprehend as a separate processing entity.

• A unit should be of a size so that foreseeable modifications in batchscheduling practices would not lead to re-definition of unit boundaries.

• A unit should not contain so many control modules and equipmentmodules that possible ”unit states”are impractical to define and de-scribe.

Equipment module definitionEquipment modules do not have to execute equipment phases. Simple statematrices defining equipment module states (each state represents a specificcombination of control module states) may be categorized as equipment mod-ules, even though they according to the S88 standard can be categorized ascontrol modules containing other control modules. Equipment modules canbe formally defined through the following process:

1. List all the control module state combinations that are used during pro-cessing activities and during inactivity of the unit. Each combinationidentifies a unit state.

2. Group the control modules to form equipment modules.

• For each equipment module, define the states that match the con-trol module state combinations found in the unit states for thegroup of control modules at hand.

• Count the total number of identified equipment module/state com-binations


3. Perform step 2 until the minimum number of identified equipmentmodule/state combinations is found. The corresponding groups of con-trol modules define the optimum set of equipment modules for the unit.

Informal boundary conditions to the formal process should be:

• Control modules shall only belong to the same equipment module, ifthere is a describable functional relation between the control modules.

• Resulting equipment module states must be possible to name and de-scribe in a way that will make sense to an operator.

• Equipment modules that contain a group of control modules that wouldtypically be found in multiple units (e.g. jacket heater, agitation con-trol, tank pressure control) should be limited to contain only these con-trol modules, for the purpose of re-usability of equipment module defi-nitions across multiple units.

Common resource definition

• Common resources can be defined as control modules, equipment mod-ules or a unit.

This description has been supplemented with meetings and discussionswith the writers and further explanation will be found in the following sec-tions.

The reason for looking for the lowest number of equipment module /state combinations is not an absolute demand, it is simply one way to quan-tify the problem and to have a number to optimize. There is actually animplicit argument in that a system with fewer states allows for a simplerconfiguration and the least possible coordination.

The informal boundaries present more variables that need to be opti-mized so while looking for the lowest number of states the system still needsto be kept as modular as possible. In many cases, it is actually considered ahigher priority to have a modular system than a low number of states.

This description of the engineers’ work procedures is relatively accurateand highly informative. It will be used as the point of perspective in creatinga design aid and therefore referenced like a holy scripture. As with other holyscriptures however, there are some implicit conflicts. In this case, there areconflicts with what has been discussed earlier in this report. One of them isthe first paragraph about making units as large as possible. There is goodargumentation for it but on the other hand there is also an advantage to

3.2. Method formalizing and implementation 57

making units as small as possible. The main advantage of smaller units isthat the cleaning flexibility of the facility increases.

This method is no absolute design method but rather a description of howsome engineers choose to implement their interpretation of S88. It is actuallyhard to confirm that the design method works. It is still up to the designerto interpret the instructions and go into the details of implementation andas will be shown in the following section, the details are often the hardestpart to figure out because new challenges constantly arise when interpretingsemantic statements into discrete terms suitable for computing. The methodworks for the engineer that described it because to him there is no between-the-lines ambiguity.

3.2 Method formalizing and implementation

For this project, the focus is mainly on the equipment module definition partof the description. The unit definition is undertaken at a higher level wheredesigners decide on where the boundary of the unit should be. This is usuallynot a very delicate matter or hard to see intuitively because the boundariesof a unit are usually clear and easy to mark. The detailed physical modelingof each unit poses more challenges because the same unit can be divided indifferent ways that result in much more complex implementation that theoptimum does.

Now, a design method has been described in a formal manner so it islikely that it can be further formalized and partly automated. The formaldescription still contains vague and unclear terms such as ”functional rela-tion”and ”make sense”. How can ”make sense”be translated into an algo-rithm with a strict execution and still give a meaningful result? This is thetopic of the chapter.

3.2.1 Formalizing the description

Formalization of semantic statements and quantification of vague terms isan interesting task ind highly relevant today, as related projects are aimed atimproving internet technologies. In order for a computer to work, everythingneeds to be formalized and quantified. The equipment module definitionmethod, as described in section 3.1, will be scrutinized in this section andan attempt made to formalize it. The definition method is segmented intoactions and constraints, each of whom is then formalized.


Unit statesControl modules 1 2 3 ... m

1 1 0 1 ... 12 1 1 1 ... 03 0 1 0 ... 0... ... ... ... ... ...n 0 0 1 ... 1

Table 3.1: Unit state matrix describes which state each control module is infor each state of the unit

Action: List state combinations

List all the control module state combinations that are used dur-ing processing activities and during inactivity of the unit. Eachcombination identifies a unit state

This action is rather simple and needs only little further explanation.This can be seen as creating a table with unit states represented in columnsand control modules represented in lines. The entire unit can have manydifferent states depending on which part of production is being worked on.In each unit state, each control module has its own state so the matrix shownin table 3.1 will be known as the Unit State Matrix.

Action: Group control modules

Group the control modules to form equipment modules

The second step in the equipment module specification seems simpleenough, grouping control modules to form equipment modules. By comingup with all possible combinations, an exhaustive search could be made inthe solution space, thus finding the optimal solution. This is theoreticallyimportant for the method to be complete but practically it is not the mostrelevant objective at the current stage of development.

The grouping can be done in many ways as shown in figure 3.1 on page73. The number of possible partitions in the figure is three:

• one partition with one item in each slot

• another partition with two slots containing one and two items respec-tively


• the last partition with all three items in the same slot

The number of possible combinations is five for this extremely simplesystem of three control modules. Actually, the number of different combina-tions quickly explodes and there is apparently no algorithm that effectivelyhandles that task of finding all combinations. For twenty control modulesthe number of possible combinations is around 1014. For fifty control mod-ules the number is 1040! A common size of a unit is 30 to 50 and it isthus clear that this task is hard to formulate so that an exhaustive solu-tion space emerges. These astronomical numbers are in reality limited bythe informal constraints placed later and there might furthermore be trivialconstraints that exclude a vast majority of the solution space. Since thereis no known algorithm to find all possible combinations, let alone find thevalid combinations under the constraints, solving the problem completelywith a computer is a major project on its own. The expert system CLIPSwas utilized to try to solve the task of finding all combinations but it hadonly started crunching on the tip of the iceberg when the problem grew outof proportions. Therefore, finding all different combinations is omitted butinstead, a collection of random combinations is generated to validate theprogram.

Action: Match and count equipment module/state combinations

For each equipment module, define the states that match the con-trol module state combinations found in the unit states for thegroup of control modules at hand. Count the total number of i-dentified equipment module/state combinations

This action involves taking each combination, comparing it with the unitstate matrix and find how many unique states are present in each equipmentmodule of the combination. The total number of states in all equipmentmodules of a combination is the goal number.

Table 3.2 shows an example where there are three control modules in asystem and three unit states. There are two combinations being evaluated,one has control modules 1 and 2 in one equipment module and controlmodule 3 in another. The other combination has control module 1 in itsown equipment module and control modules 2 and 3 in another. The statesfor the equipment modules are simply defined by concatenating the statesymbol for the respective control modules.

In the first combination four different states are found and in the secondone five different states are found:


Unit states1 2 3

1 1 1 0Control modules 2 0 0 1

3 0 1 1 Number of statesCombination 1 1+2 10 10 0 4

3 0 1 1Combination 2 1 1 1 0 5

2+3 00 01 11

Table 3.2: Matching and counting equipment module/state combinations

Action: Minimize number of combinations

Perform [last step] until the minimum number of identified e-quipment module/state combinations is found. The correspond-ing groups of control modules define the optimum set of equip-ment modules for the unit

This action is an iteration of the last step where each combination getstested and the states counted. The lowest number of states found corre-sponds to the optimum combination.

It is clear that an exhaustive search through all possible combinations isnot a feasible task for a computer due to the size of the solution space butas suggested earlier, a constrained solution space is generated and searchedthrough.

The above explained actions are subject to several constraints. The mostimportant of those are demand for functional relation, operator appreciationand multiple units reusability. In the following section, further expansion oneach of these constraints will be presented.

For this end — to minimize number of state combinations — the sim-plest way would of course be to put all control modules into one equipmentmodule. In that case is is safe that the number of state combinations willbe the same as number of unit states. This is however not sensible for manyreasons: the advantages of S88 such as flexibility and modularity are lost,operator appreciation compromised and implementation effort increases forlarger systems.


1 2 3 ... n1 1 1 0 ... 02 1 1 1 ... 13 0 1 1 ... 1... ... ... ... ... ...n 0 1 1 ... 1

Table 3.3: Functional relation matrix describes which control modules canbe in the same equipment module

Informal constraint: Functional Relation

Control modules shall only belong to the same equipment moduleif there is a describable functional relation between the controlmodules.

The functional relation is not a special engineering term but it ratherrefers to what an operator comprehends as a relation or which componentscan with common sense be placed in the same equipment module. In order toformalize this constraint a matrix is manually created to describe functionalrelation between control modules. Table 3.3 is the functional relation matrix(FRij) where all control modules are matched with themselves.

Control modules are matched in columns and lines and a matrix valueof 1 indicates a functional relation and a value of 0 indicates no relation.

Two conditions always apply to the functional relation matrix:

FRij = 1 for i = j(a control module is seen to have a functional relation to itself)

FRij = FRji

(a functional relation is always mutual)

The constraint states that a functional relation has to be available be-tween two control modules residing in the same equipment module. Formallystated:

(FRij 6= 1) → ({CMi, CMj} /∈ EMA) for i = 1, 2, 3, ... and j = 1, 2, 3, ...

where CMi and CMj are two control modules and EMA is any one e-quipment module. It should be stressed that if (FRij = 1) is true then({CMi, CMj} ∈ EMA) is not necessarily true.

The functional relation along with the combinations problem can begenerally stated:


1 2 3 ... n1 1 0 0 ... 02 1 1 1 ... 03 0 1 1 ... 0... ... ... ... ... ...n 0 0 0 ... 1

Table 3.4: Forced relation matrix describes which control modules must bein the same equipment module

Given are n objects x1...xn and binary relational matrix FRij .The objects are to be assigned to slots where each slot can con-tain one or more objects. Two objects xi and xj can only exist inthe same slot if their relation is given with FRij = 1. FRij = 1does not force the objects into the same slot. How many alter-native assignments are possible?

Apparently there is no known algorithm to efficiently solve the problem.The problem is clear but the solution is not. The actual question is: Whichalgorithm can be used to efficiently find all the alternative assignments underthe presented constraints? This problem has been addressed with the actionof grouping components but without the constraints. As the problem is hugewithout the constraints it is trivial that it only becomes harder to solvewhen the constraints have been introduced. Therefore, no further trials willbe made in developing an complete code for this means.

Informal constraint: Operator comprehension

Resulting equipment module states must be possible to name anddescribe in a way that will make sense to an operator.

A computer interface has a large influence on an operator’s appreciationof a control system. The constraint is partly been formalized through thefunctional relation matrix because through this matrix, some relations havebeen ruled out, thus preventing unrelated objects from showing up on thesame display. To further improve operator appreciation, certain relations canbe forced by another matrix: the forced relation matrix (see table 3.4). Bysetting an item of this matrix to 1, it is thereby dictated that the respectivecontrol modules must be placed in the same equipment module.

The same two conditions always apply to the forced relation matrix asthe functional relation matrix: relation to itself and mutual relation.


In this case — opposite to the functional relation matrix — if (FdRij =1) is true then ({CMi, CMj} ∈ EMA) is always true for i = 1, 2, 3, ... andj = 1, 2, 3, .... Insert conditions

These two constraining matrices are only partly supporting operatorappreciation and many other factors affect it. Many of these factors cannot be affected by the control systems design. Examples of such factors arecontrol room design, choice of display units etc.

In plants designed by NNE, the operator interfaces generally correspondto the equipment modules even though that is not necessary. The interfacethen simply reflects how the engineers divided a plant into equipment mod-ules and units. This is one big reason for having the equipment modulescomprehensible but there are other reasons as well. An equipment modulethat is randomly put together of control modules that are far apart is hardto describe and most operators would have a hard time understanding theinterface. On the other hand, operators often ask for remote components tobe visible in a certain interface and if there is an fixed relation between thephysical model and the operator interface, then this poses a big challenge inthe design phase.

Informal constraint: Multiple units reusability

Equipment modules that contain a group of control modules thatwould typically be found in multiple units (e.g. jacket heater, agi-tation control, tank pressure control) should be limited to containonly these control modules, for the purpose of re-useability of e-quipment modules across multiple units.

This is not really a constraint whereas it does not limit the solutionspace. In practice, a designer works under this constraint during the entiredesign phase and aims at coming up with a valid and intuitive combinationthat also satisfies this reusability constraint. In the formalized method, thisconstraint will therefore be used when evaluating different combinationsafter they have been created. Further discussion about this part is in thefollowing section about the scoring model.

When all the above actions have been performed under the said con-straints, the result is a certain configuration of the physical model thatgives the lowest number of states. Since the ATAM model has previouslybeen mentioned as a very helpful tool in evaluation, it will also be built inhere, in an attempt to automatically score each of the solutions and thusfind out how the optimal tradeoff between quality attributes is achieved.


The ATAM model from section 2.2 — although numerical — is a ratherrough estimate of certain quality attributes but in the following section, anattempt will be made to automatically estimate each attribute by lookingat some relevant variables. Another difference between the previous ATAMcase and the current one is that with the rough estimates, it is possible toconsider a broader perspective of a system but in the following model, onlythe physical model itself can be evaluated.

3.2.2 ATAM scoring model

Some of the ATAM quality factors can be used quantitatively with the pro-posed work method and others can not. Implementation effort can be easyto score but traceability is harder to score. In this section, different qualityattributes will be explored and a scoring model created that is then used tograde all combinations and find the best quality, expressed by a weightedscore.

ATAM factor: Implementation effort

Definition: An indicator of how much work is required to get fromthe early design stages to a working system.

The degree of implementation effort is implicit in the results of the designmethod described earlier. It is there by means of the number of equipmentmodules. The fewer the equipment modules the less the coordination re-quired between equipment modules and the less communication to program.The implementation quality can be formulated in the following way:

QAimplement =nCM − nEM

nCM

where nCM is the number of control modules in the whole system and nEMis the number of equipment modules. The highest conceivable number ofequipment modules is nCM (one control module per equipment module)This score thus gives a proportional description of the quality, approaching1 for the highest quality and 0 is an awful quality.

ATAM factor: Modularity

Definition: An indicator of how reusable equipment modules in asystem are, even outside of that system.


Control module index 1 2 3 4 5 ... nModular value 0 1 1 0 0 ... 0

Table 3.5: Multiple units reusability vector describes which control modulesshould ideally be in the same equipment module

Modularity indicates whether one equipment module could be used inanother unit because of the likeness of the operations carried out and thecomponents included in it. This factor will be dictated by a vector specificallycreated for this purpose. The potentially modular groups are defined in amultiple units reusability (MUR) vector. This vector contains items thatdescribe which control modules in a system can be considered a group asthey might be used elsewhere in the system or other systems designed bythe same developer.

An example of the MUR vector is shown in table 3.5. The top row is thenames of the control modules and the bottom row contains the reusabilityindex. In the example, control modules 2 and 3 are of types that are oftenused together in similar systems and therefore they get index 1. Other controlmodules that are commonly found in other systems could be given the index2 and so forth.

In this method, modularity is an integer variable that starts at 0 for eachcombination evaluated and it increases for every instance of a modular groupthat is found in the corresponding combination. With the MUR matrix, eachcombination is now evaluated for modularity by comparing the MUR vectorwith equipment module assignments.

ATAM factor: Operator appreciation

Definition: An indicator of the extent to which an operator ac-cepts and appreciates a system, in particular the interface.

The operator appreciation is achieved partly through the functional re-lation matrix and partly through the forced relation matrix. These two canmake sure that certain objects stay together in one display or that certainobjects stay distributed over more displays. The relation matrices are nota means to quantify the problem but only to make sure that inadequatecombinations are not made. This means that invalid combinations are noteven in the solution space.

There are ways to quantify operator appreciation. The number of statesin a system and the number of control modules in each equipment module


affect the operator directly. All other things equal, the lower the numberof states, the easier it is for an operator to understand the operation thesystem. Part of the score therefore depends on the number of states:

QAopapp1 = 1− nStates

nCM ∗ nUnitStates

where nStates is the total number of states found in the corresponding com-bination, nCM the number of control modules and nUnitStates the numberof unit states in the whole system. nCM ∗nUnitStates is the absolute max-imum for states in a system and this grade therefore is in the range of 0 to1.

The other part of this score depends on the number of control modulesin each equipment module. There must not be too many components in adisplay because that confuses the operator and compromises the overview(although experience has shown that very complex displays can be learned).There must not be too few components in a display either because thatmakes the work very inefficient as the operator constantly has to switchbetween displays to view the whole system. Since equipment modules fre-quently correspond with displays, it will be assumed that those are the same.The number of control modules in an equipment module is nCE so an e-quipment module with fewer than x or more than y control modules willcontribute negatively to the total score. The size of the negative contribu-tion is up for discussion as this is not an absolute measure. This can beformulated thus, assuming a negative contribution of 1:

QAopapp2 =

{−1 if nCE < x or nCE > y0 else

The total score for the operator appreciation is the sum of QAopapp1 andQAopapp2.

ATAM factor: Design flexibility

Definition: An indicator of how hard it is to change the designof a system.

It is assumed that many of the changes that are done in a system, involvecreating new logical connections between components. The more equipmentmodules there are, the more likely it is that control modules need to bemoved between equipment modules when a change is done or that new


connections have to be made between equipment modules. This requires aconsiderable amount of work in redefining coordination control and com-munication. The same risk is at hand when adding new components to asystem. The less equipment modules there are, the more design flexibilitycan be considered to exist. The score for design flexibility is formulated withalready defined variables:

QAdesflex =nCM − nEM

nCM

This is the same grade that is being used for implementation effort.This can however be argued for because the different factors will later allbe weighted and combined in one quality grade. The applied weights willreflect each factor’s importance and then it is quite possible that the twofactors will not be making the same contribution.

This perspective actually describes a weak link in the ATAM methodbecause the factors are not graded in any scientific manner but more ar-bitrarily whereas it is not clear what the meaning of each number is. Thissituation can be improved with extensive case studies that shed a light onthe meaning of each number.

ATAM factor: Robustness

Definition: An indicator of how well system problems are isolatedand their impact minimized. Also indicates how well deadlocksare prevented.

Isolation of problems can partly be achieved by increasing the number ofequipment modules. Thereby, fewer control modules are contained in eachequipment module and a fault will not as easily propagate to a large numberof other control modules and interrupting the system.

QArobust = nEM − nCM

An alternative solution could be to put components that are known tobe sensitive into their own equipment module or grouping components ina certain way. The former suggestion would need some means to indicatesensitive components (a new matrix) but the latter suggestion is achievablethrough the forced relation matrix.


ATAM factor: Cleaning flexibility

Definition: An indicator of production downtime while cleaningis performed.

The cleaning flexibility is an important factor in physical model designbut its application lies on the unit design level. The higher the number ofunits, the higher the cleaning flexibility. Therefore, cleaning flexibility is notincluded in the final ATAM score for the physical model on the equipmentmodule level.

ATAM factors: Recipe management and Traceability and Perfor-mance

These three factors are important in S88 design but they are largely inde-pendent of the physical and procedural model. They depend more on theimplementation and the platform used. These factors have been approxi-mately defined and are found in the more subjective evaluation of chapter2.2 but for this discrete evaluation it has proven difficult to find relevantquantities from the design process that can be translated to a meaningfulgrade for one of these factors.

Quality factor

It is now possible to derive a quality factor from the above ATAM factorcontributions. As in the ATAM model described in chapter 2.2, each factorgets assigned a weight for its importance. The factors are now combined ina weighted multiple:

Q =∑

i

Wi ∗QAi

The three ATAM factors mentioned above that seem hard to quantifyare easily kept outside of this equation and just as easily included if relevantvariables are found to express these qualities. Future work with this methodmight tackle the questions on how to quantify recipe management and inparticular traceability. Since the demands for traceability are ever increasing,a quick way to evaluate traceability would be a very helpful tool.

Figure 3.2 on page 74 summarizes the design aid proposed in this chapter.Initially there is a collection of control modules and under constraints fromtwo relation matrices a collection of valid partitions is created. Each of thesepartitions are researched with the use of the unit state matrix for the system.


With this research, the number of different states for each combination isshown. The combination with the lowest number of states is consideredthe best solution according to the design procedure described in section3.1. Since there are more factors that affect the overall quality of a systemdesign, and in particular many delicate tradeoffs that are found, the ATAMis deployed to evaluate each combination and thus find the optimum qualitysolution.

One has to be careful interpreting the results of the ATAM algorithm aspresented here because the factors are not all clearly linear and the measuredquality attributes are not scientific units. The results only support relativeevaluation of a number of designs. Evaluating only one design does not makesense because there is nothing to measure against and the quality grade doesnot have a known unit so in that sense it is not a strictly objective method.A relative quality grade in the range of 0 to 1 is a good indicator and canbe argued for as a design tool for engineers that are used to working withabstract measurements.

It is important to realize that this implementation of the ATAM systemhas circular references in that by creating all the different matrices andspecial evaluations, the systems are already partly evaluated beforehand. Soa system’s quality is already defined by all those prerequisites. Still, these arejust a general evaluation that applies equally to all the solutions. There aretwo ways in designing a system when all the prerequisites for an optimumsystem already exist. One way is the proposed way of finding all applicablesolutions and searching those for the optimal one. Another way is to tailor asystem precisely to the prerequisites. The end solution is the same but thereare differences in the implementation of the methods.

Finding the optimal system by the number of states is a valuable result.This is the proposed result in the work description in section 3.1. Thatsuffices as a result, even without the ATAM addition. However, the ATAMprovides another perspective and emphasizes more aspects of the designer’spreference.

3.2.3 Object model

In order to be able to exchange data about a system and its configuration,an object model is needed. The object model contains the data structure,stored data and an interface description. The object model is not necessaryin achieving the functionality. It can be introduced whenever connectionwith other software becomes important.

XML has become increasingly more popular in recent years and is widely


used in internet technologies as well as in the industry. XML was designedto carry data but it does not have any active function like manipulation ofdata. There is an XML scheme defined for the batch environment, calledBatchML and there is an object model defined in the fourth part of S88.It may be beneficial to include it in further development of the design aidbecause it can therefore exchange data with other applications. That couldenable integration of this tool with existing design tools (e.g. ControlDraw)and the resulting physical model could with ease be transferred to anotherplatform.

An important issue is designing a useful object model is that it mustfit well with an input procedure and - better yet - software that is alreadyknown, such as ControlDraw. The input work must not be too extensive orit will steal all the time that the method is supposed to save.

3.3 Program validation

The details formalized in the last section have been programmed using Mat-lab. The source code can be found in appendix A. Validation of the code isdone by randomly creating a unit state matrix with 40 control modules and15 unit states. This corresponds with the first action of listing state combi-nations. The next action of grouping control modules is very hard to solveperfectly with a computer as discussed earlier so instead, 400 combinationsare arbitrarily created. It is assumed that each combination is created inaccordance with the constraints described.

For each combination unique states are counted and then it is easy to findthe optimum solution. Now there are two variables available from the systemand they are used to calculate quality grades for each of the five qualityattributes that are quantified and used to calculate a quality grade. Figure3.3 on page 75 shows the two variables nEM , the number of equipmentmodules and nStates, the number of states. It also shows the five partialgrades along with each of their weights and the weighted quality grade forthe physical model. The figures seem very organized but the reason for thatis that the randomly generated combinations have a predefined number ofequipment modules and there are also four combinations that are manuallyforced to contain a reusable equipment module.

From figure 3.3 it is clear that there is a larger variance in the number ofstates the more equipment modules there are. In fact, in one of the systemtest runs, the collection of combinations with 4 equipment modules had theaverage number of states is 56,0 and the variance is 9,7. In the same test

3.4. Perspective 71

run, the collection with 12 equipment modules had average number of states89,9 and variance 29,3. This greater variance then clearly shows up in thequality grade.

The quality grade is composed by weighing together the five partialgrades. It is clear from the last figure that the quality grade is largely dic-tated by the modularity of the combinations and the number of equipmentmodules is another influential factor. The influence of these factors can beaffected by altering the weights.

A drawback of the numerical ATAM computation is that a lack of vari-ables limits the impact of the results. With only two variables available, thefive supposedly different grades take on somewhat similar characteristics.But the validity of the computation can still be argued for with reference tothe weights that can be used to emphasize certain qualities while ignoringothers.

It hardly makes any sense trying this system on the Arla case fromsection 2.3 because that case had four alternative designs, only one of whichhad a real difference on the equipment module level of the physical model.With the current method it is not possible to quantify differences in a unitcentric and an equipment module centric design and neither difference in thenumber of units. This further confirms that the ATAM method is somewhata subjective evaluation and as such it can be efficient.

The proposed design aid has many of the prerequisites for an optimalsystem defined in various matrices and vectors. A negative aspect of this isthat the system might be excessively constrained in the first stages of systemdefinition. On the other hand, it is beneficial to realize how the details of asystem influence the quality of the solution. By scrutinizing these differentfactors, this awareness improves. And the extra work consumed by using theevaluation tools is not extensive so it can pay off for complex systems.

3.4 Perspective

The design aid proposed has the potential to support design decisions andthus enable a more nearly optimal solution. The design aid is fed with quiteraw information about a system and this is a drawback because a consid-erable time might need to be invested in feeding the information into anindependent design tool. However, an object model coupled with some ofthe design tools available could accelerate the definition process and subse-quent system implementation.

The current system optimizes a physical model in regard to the most im-


portant quality attributes identified. In the cases of small systems or systemswith casual quality demands the improvements are not too important butas the systems grow and the quality requirements increase, this design aid ispotentially of much value. Defining the physical model is an important partof the design under S88. The physical model requires structured creativityand the following programming and implementation is to a large extent dic-tated by the frame of the physical model. So a well defined physical modelmakes the programming and implementation easier.

Introduced here is primarily an evaluation method used to score differentalternatives. The same method could possibly be developed for some sortof automatic design, thus partly freeing the engineer from performing tasksthat in essence are repetitive labor.

The numerical ATAM method presented in chapter 2.2 as well as inthis chapter is hard to implement on such discrete terms as is tried here.This trial has shown that there are too few variables available to create ameaningful result from a computer model. Nevertheless, the ATAM can serveas a powerful method even if it is used only manually for rough estimationof the quality of a few alternative solutions and tradeoffs between them.

Methods such as the one that was discussed here are often not as validas the bricks used to create them ore the partial arguments behind them.The bricks and arguments are a result in themselves and as such, they havea considerable value in shedding a light on details that are usually hiddenor implicit in design choices.

3.4. Perspective 73

Figure 3.1: Different ways of combining control modules in equipment mod-ules


Figure 3.2: A method to optimize the physical model design

3.4. Perspective 75

100 200 300 400

nEM

0 100 200 300 40040

60

80

100nStates

100 200 300 4000.65

0.7

0.75

0.8

0.85

0.9

implementw = 0.20

100 200 300 400

operatorw = 0.20

100 200 300 4000

0.1

0.2

0.3

0.4

0.5

modularw = 0.20

100 200 300 4000.65

0.7

0.75

0.8

0.85

0.9

designflexw = 0.20

100 200 300 400

robustw = 0.20

100 200 300 4000.45

0.5

0.55

0.6

0.65

0.7Quality

Figure 3.3: Variables and resulting attributes contributing to the qualityfactor for each of the 400 different combinations that are being evaluated.The last figure is the quality factor.

Chapter 4

Conclusion

4.1 Benefits of S88

Open standards are catching on as the norm in electrical engineering and theS88 standard describes a powerful and proven design philosophy that aids indesign communication and increases design and implementation productiv-ity. Still, the standard’s supporters sometimes tend to oversell it, claimingbenefits to be due to the standard, when in reality any well designed au-tomation system could provide the same benefits.

The benefits of using the S88 standard in batch automation systems de-sign are very clear in the design and implementation process and — to someextent — in the production itself. Utilizing the standard is often a technicalpreference rather than a financial one, as the technical arguments can bequite as strong as the financial ones. It is therefore not always possible topresent economical feasibility directly related to the use of S88. In particularit is worth pointing out that modernization is a strategic decision with manyintangible benefits that are hard to quantify. Traditional economic analysisis therefore not suitable.

4.2 Efficient engineering

Although the S88 standard provides a framework for design, it lacks in designguidelines or practices. This has drawbacks but it is also good for the wideacceptance of the standard among designers, that there are many alternativeways in utilizing the standard and arriving at a functional, good or optimalsolution.

Two design aids have been presented in this report. One is a simple

77

78 4. Conclusion

scoring model that evaluates several alternative functional architectures ofa control system and systematically find the most appropriate solution. Theother design aid was developed by formalizing documented work habits ofexperienced engineers. This formalization has resulted in an algorithm thatcan be used to find the most optimal physical model for a system, givencertain constraints and conditions.

4.3 Future work

Future work in the field of S88 will among other things focus on designguidelines and tools to accelerate the design process. Other issues involvethe expansion of the standard, object models and the limitations of thestandard. The standard — like others of its kind — provide an undisputedadvantage for the time being but there is always a danger that a standardgrows out of dimension and starts counteracting its own benefits. Standardsshould be an uplifting utility but not a depressing burden.

Bibliography

[1] Technology and substitution. www resourcehttp://cepa.newschool.edu/het/essays/product/technol.htm, acquiredNovember 10th 2005.

[2] Ansi/isa-88.01-1995. batch control part 1: Models and terminology,1995. Standard issued by ISA.

[3] Yale Brozen. The economics of automation. Papers and proceedings ofthe sixty-eighth annual meeting of the american economic association,47:339–350, 1957.

[4] Rod Coombs, Paolo Saviotti, and Vivien Walsh. Economics and tech-nological change. MacMillan Education, London, 1987.

[5] Joe deSpautz. Quantifying the benefits of automation. ISA Transac-tions, 33:297–306, 1994.

[6] Bethany L. Ehlmann, Jeeshan Chowdhury, Timothy C. Marzullo, R. Er-ic Collins, Julie Litzenberger, Stuart Ibsen, Wndy R. Krauser, Bran-don DeKock, Michael Hannon, Jessica Kinnevan, Rebekah Shepard,and F. Douglas Grant. Humans to mars: A feasibility and cost-benefitanalysis. Acta Astronautica, 56:851–858, 2005.

[7] Kristjan H. Flosason. S88 compatible retrofit control system, 2005. Re-port from a special course at Technical University of Denmark, OrstedAutomation.

[8] J.K.Kaldellis, D.S.Vlachou, and G.Korbakis. Techno-economic ecalua-tion of small hydro power plants in greece: a complete sensitivity anal-ysis. Energy Policy, 33:1969–1985, 2005.

[9] J.W.Hines and E.Davis. Lessons learned from the u.s. nuclear powerplant on-line monitoring program. Nuclear Energy, 46:176–189, 2005.

79

80 BIBLIOGRAPHY

[10] Rick Kazman, Jai Asundi, and Mark Klein. Quantifying the costs andbenefits of architectural decisions. IEEE publication 0-7695-1050-7/01,pages 297–306, 2001.

[11] Rick Kazman, Mark Klein, Mario Barbacci, Tom Longstaff, HowardLipson, and Jeromy Carriere. Iceccs ’98 proceedings. fourth ieee inter-national conference on engineering of complex computer systems. pages68–78, 1998.

[12] D.V. Lyridis. Cost-benefit analysis for ship automation retrofit. Marinetechnology and sname news, 42:113–124, 2005.

[13] T. Moe. Perspectives on traceability in food manufacture. Trends inFood Science and Technology, 9:211–214, 1998.

[14] Ferenc Molnar, Tibor Chovan, and Tibor Nagy. Batch control analysis.Proceedings from the WBF European Conference, Mechelen, Belgium,Oct 2002.

[15] Rick Mullin. Fda batch rule: the next y2k? Chemical Week, 164(18).

[16] Hamid R. Parsei and Amil Mital. Economics of advanced manufacturingsystems. Chapmann and Hall, London, 1992.

[17] Jim Parshall and Larry Lamb. Applying S88 - Batch control from auser’s perspective. Instrument Society of America, ISA, North Carolina,USA, 2000.

[18] Bianca Scholten. S88 for engineers, 2004. Whitepaper from the WorldBatch Forum, www.wbf.org.

[19] Benn Steil, David G. Victor, and Richard R. Nelson. TechnologicalInnovation and Economic Performance. Princeton University Press,Princeton, New Jersey, 2002.

[20] Kuo-Hsiung Wang, Yi-Chun Liu, and Wen Lea Pearn. Cost benefitanalysis of series systems with warm standby components and generalrepair time. Mathematical methods of operations research, (61).

Figures

1.1 Production function represented by isoquants. Q1 can eitherrepresent greater output or higher efficiency. . . . . . . . . . . 7

1.2 Production function shifted by technical change. The shiftdirectly towards (0,0) is called neutral change, the others biased. 8

1.3 Factor price ratio changes lead to changes in the most effectivetechnique. C is the most effective technique when the factorprice ratio is A-B. When the factor price ratio changes toA′-B′ the most effective technique becomes C ′. . . . . . . . . 9

1.4 A graphical summary of sensitivity analysis. . . . . . . . . . . 25

2.1 S88 physical model and procedural model . . . . . . . . . . . 302.2 Mapping of procedural control model and physical model . . 312.3 Architectural strategies plotted by costs and benefits. The

solid curve circles the optimal strategies and the double dot-ted ellipse represents a non-negotiable strategy that must beimplemented. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.4 The casein process . . . . . . . . . . . . . . . . . . . . . . . . 452.5 An example PI diagram. This diagram is a very simplified

version of the casein process and explains some of the fea-tures described in the case. The topmost group supplies rawmaterial to the process, the middle group is main processingand the last group is final processing and packaging. Eachactive component in the diagram is a control module and canbe combined with others to form equipment modules and units. 52

3.1 Different ways of combining control modules in equipmentmodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.2 A method to optimize the physical model design . . . . . . . 74

81

82 FIGURES

3.3 Variables and resulting attributes contributing to the qualityfactor for each of the 400 different combinations that are beingevaluated. The last figure is the quality factor. . . . . . . . . 75

Tables

2.1 Example of ATAM application . . . . . . . . . . . . . . . . . 372.2 Quality attributes for S88 design tradeoff analysis . . . . . . . 412.3 Architectural strategies evaluated relative to AS1 . . . . . . . 432.4 Architectural strategies evaluated relative to AS1 . . . . . . . 50

3.1 Unit state matrix describes which state each control moduleis in for each state of the unit . . . . . . . . . . . . . . . . . . 58

3.2 Matching and counting equipment module/state combinations 603.3 Functional relation matrix describes which control modules

can be in the same equipment module . . . . . . . . . . . . . 613.4 Forced relation matrix describes which control modules must

be in the same equipment module . . . . . . . . . . . . . . . . 623.5 Multiple units reusability vector describes which control mod-

ules should ideally be in the same equipment module . . . . . 65

83

84 TABLES

Appendix A

Program code

A.1 pmoInit.m - Model initialization

%S88 Physical Model Optimizer, Initializing Routines%Kristjan Haukur Flosason, 2005-2006%Ørsted-DTU, Automation

nUnitStates = 15; nCM = 40; nPartitions = 400;

%Initialize structure for scoringfor i = 1:nPartitions

part.nEM(i) = 0;part.nStates(i) = 0;part.implement(i) = 0;part.modular(i) = 0;part.operator(i) = 0;part.designflex(i) = 0;part.robust(i) = 0;part.quality(i) = 0;

end

%Initialize structure for weighingweight.implement = 0.2; weight.modular = 0.2; weight.operator = 0.2;weight.designflex = 0.2; weight.robust = 0.2;

%Define experimental random control module/state matrixUnitStateMatrix = round(rand(nUnitStates,nCM));

85

86 A. Program code

%Define experimental multiple units reusability matrixMURmatrix = [0 0 1 0 0 0 1 1 0 0 ...

0 0 0 0 0 0 1 0 0 0 ...1 0 0 0 0 0 0 0 0 0 ...0 0 0 0 0 0 0 1 0 0];

%Create alternative partitions of control modules, 100 of each%Randomly generated experimental partitions%Functional relations not considered

Partitions = zeros(nPartitions,nCM);

%4 EMfor i = 1:100,

for j = 1:nCM,Partitions(i,j) = round(3*rand) + 1;

endend

%6 EMfor i = 101:200,


endend

%12 EMfor i = 201:300,


endend

%8 EMfor i = 301:400,


endend

A.2. PMO.m - Optimize physical model and quality grade 87

%make four modular combinationspartTemp1 = MURmatrix * 4; partTemp2 = (1 -MURmatrix).*(round(2*rand(1,40)) + 1); Partitions(50,:) = partTemp1+ partTemp2;

partTemp1 = MURmatrix * 6; partTemp2 = (1 -MURmatrix).*(round(4*rand(1,40)) + 1); Partitions(150,:) = partTemp1+ partTemp2;

partTemp1 = MURmatrix * 12; partTemp2 = (1 -MURmatrix).*(round(10*rand(1,40)) + 1); Partitions(250,:) =partTemp1 + partTemp2;

partTemp1 = MURmatrix * 8; partTemp2 = (1 -MURmatrix).*(round(6*rand(1,40)) + 1); Partitions(350,:) = partTemp1+ partTemp2;

A.2 PMO.m - Optimize physical model and qual-ity grade

%S88 Physical Model Optimizer, Main Program%Kristjan Haukur Flosason, 2005-2006%Ørsted-DTU, Automationhome; count = 0; minStates = 1000; minPartition = 0; maxQuality = [10]; str1 = sprintf(’S88 Physical Model Optimizer’); str2 =sprintf(’Finding the optimal unit partition, working with’);str3 = sprintf(’%d control modules and %d unit states.’,...

nCM,nUnitStates);disp([str1]) disp([str2]) disp([str3])

tic; for k = 1:nPartitions,CMgroup = Partitions(k,:);

%Count number of equipment modules in partitiontemp = zeros(1,8);nEM = 0;for i=1:nCM

if not(ismember(CMgroup(i),temp))

88 A. Program code

nEM = nEM + 1;temp(nEM) = CMgroup(i);

endendpart.nEM(k) = nEM;

%For each EM, define states that match the CM state combinations found in%unit states for the CM at handEMStates = zeros(nUnitStates,nCM,nEM);

for i = 1:nCM,for j = 1:nUnitStates,

EMStates(j,i,CMgroup(i)) = UnitStateMatrix(j,i);end

end

%Count total number of EM state combinationsnStates = 0;for i = 1:nEM,

nStates = nStates + 1; %first state is always uniquefor j = 2:nUnitStates,

B = ismember(EMStates(j,:,i),EMStates(1:j-1,:,i),’rows’);if B == 0 %if state has not been seen then count state

nStates = nStates + 1;end

endend

part.nStates(k) = nStates;

%Quantify implementation effortpart.implement(k) = (nCM - nEM) / nCM;

%Quantify operator appreciationQAopapp1 = 1 - nStates / (nCM * nUnitStates);

%check all equipment modules and count CMs in themQAopapp2 = 0;for i=1:nEM,

CM_in_EM = 0;

A.2. PMO.m - Optimize physical model and quality grade 89

for j = 1:nCM,if CMgroup(j) == i,

CM_in_EM = CM_in_EM + 1;end

endif or(CM_in_EM < 2,CM_in_EM > 10),

QAopapp2 = QAopapp2 - 0.03;end

endpart.operator(k) = QAopapp1 + QAopapp2;%Quantify design flexibilitypart.designflex(k) = (nCM - nEM) / nCM;%Quantify robustnesspart.robust(k) = nEM / nCM;

%Quantify modularitypart.modular(k) = 0;temp = MURmatrix .* CMgroup;biggest = max(temp);smallest = max(temp);for i=1:nCM,

if and(temp(i)~=0,temp(i)~=max(temp))smallest = temp(i);

endend

if and(biggest==smallest,...not(ismember(biggest,CMgroup-temp)))

part.modular(k) = 0.5;end

%Create quality factor for the corresponding alternativepart.quality(k) = weight.implement * part.implement(k)...

+ weight.modular * part.modular(k)...+ weight.designflex * part.designflex(k)...+ weight.operator * part.operator(k)...+ weight.robust * part.robust(k);

if part.quality(k) > maxQuality(2)maxQuality(1) = k;

90 A. Program code

maxQuality(2) = part.quality(k);end

if nStates < minStatesminStates = nStates;minPartition = k;ResultnEM = nEM;

endend %for k in Partitions

%Report the resultst = toc;str1 = sprintf(’\n%d alternatives evaluated in %1.1f seconds’,...

size(Partitions,1),t);str2 = sprintf(’Best alternative: alt %d: %d states, Q = %0.3f’,...

minPartition,minStates,part.quality(minPartition));disp([str1]) disp([str2])

plot(1:nPartitions,part.quality)

A.3 prufa.m - Result visualization

subplot(3,3,1) plot(1:400,part.nEM) title(’nEM’) axis([1,400,3,13])

subplot(3,3,2) plot(1:400,part.nStates) title(’nStates’)

subplot(3,3,3) plot(1:400,part.implement)str = sprintf(’implement\nw = %0.2f’,weight.implement);title(str) axis([1,400,0.65,0.95])

subplot(3,3,4) plot(1:400,part.operator)str = sprintf(’operator\nw = %0.2f’,weight.operator);title(str) axis([1,400,0.7,0.9])

subplot(3,3,5) plot(1:400,part.modular)str = sprintf(’modular\nw = %0.2f’,weight.modular);title(str) axis([1,400,0,0.55])

A.3. prufa.m - Result visualization 91

subplot(3,3,6) plot(1:400,part.designflex)str = sprintf(’designflex\nw = %0.2f’,weight.designflex);title(str) axis([1,400,0.65,0.95])

subplot(3,3,7) plot(1:400,part.robust)str = sprintf(’robust\nw = %0.2f’,weight.robust);title(str) axis([1,400,0.05,0.35])

subplot(3,3,8) plot(1:400,part.quality) title(’Quality’)axis([1,400,0.45,0.7])

%Histogram for partitions% for i=1:9% subplot(3,3,i)% hist(Partitions(315+i,:),1:8)% title(315+i)% end

evaluation tools for s88 batch control systems...

Documents