evolution of integrated automation approach of integrated automation approach edgar chacon...

Evolution of Integrated Automation Approach

Edgar CHACONUniversidad de Los Andes, Fac.Ingenierıa

Dpto.de Computacion, EISULA,Av. Alberto Carnevalli, Edf B La Hechicera

[email protected]

Juan CARDILLOUniversidad de Los Andes, Fac.Ingenierıa

Dpto. Sistemas de Control, EISULA,Av. Alberto Carnevalli, Edf B La Hechicera

Merida- [email protected]

Abstract: In the industrial automation have been taken as references various approaches and architectures in thesearch for integration into the production process. From 5-level pyramid model associated with the hierarchicalstructure of decision-making processes to holonic approaches, they have pursued the ideal of integrating data,aplication In this paper we show the evolution, contributions and weaknesses of the most outstanding approachesto integration in industrial processes from the pyramid approach to the holonic approach.

Key–Words: Integration in production processes, Holonic Approach

1. Introduction

The need for integration of decision-making pro-cesses, information, control mechanisms and ulti-mately the production process of a company is wide-ly discussed in the literature of the area. Existing ef-forts to achieve this integration are part of the areaknown as “ Modelling and Integration of the Enter-prise”. Modeling and Integration of the Enterprise isa very recent body of knowledge that includes con-cepts, models, methods and techniques for the identi-fication, analysis, redesign and business process inte-gration with the process data and knowledge, softwareapplications and systems information within a compa-ny, with the aim of improving the overall performanceof the organization.

One of the most important results of the Mod-eling and Integration of the Enterprise are the refer-ence architectures, which describe, in a generic wayas to achieve integration of the processes and ele-ments mentioned above. An architecture is a modelor pattern that provides the most important aspects tobe considered during the modeling process and inte-gration of the enterprise. Three architectures widelyknown are the open systems architecture CIMOSA,the reference model GRAI-GIM and the Purdue enter-prise reference architecture PERA [3]. Although thesearchitectures and their corresponding methodologiesclaim to be generic - applicable to any type of busi-ness, in the practice your orientation and applicabilityhas been demonstrated in manufacturing companies.

Continuous process industries such as refineriesand oil companies and gas production, have their owncharacteristics which are not considered in the above

architectures. Viewed as systems, these companiesare composed of a set of production units or semi-autonomous subsystems that transform inputs into in-termediate or final products through a continuous pro-cess. These subsystems must work in a coordinatedmanner to ensure optimal production under variousconditions, including changes in production require-ments (eg, volume and quality), equipment failures,plant shutdowns, changes in the market, etc.

In this article we intend to show the different in-tegration approach used in production processes. Westart with an introduction to the approach to decision-making pyramid. In Section 1 CIM-CIMOSA model.In section 2, a reference model for computer integrat-ed manufacturing (MRAI). In Section 3, a methodolo-gy for development of integrated systems,METAS. Insection 4 the model of Purdue University, PERA. Insection 4 the scope of a standard of integration such asISA95. Section 6 of paradigm change hierarchical de-cisions and describe the appointment process holonicproduction through PABADIS and finally give conclu-sions

The complete pyramid model consists of six lev-els of decision-making and three special interface.These interface have very clear concepts and definedelements and devices that generate and allow the flowof information, integrating the automation systems infloor plant with the computer systems the other lev-els. Show figure 1. This model and its variations withlower levels are well described in literature [referen-cias cim]

The select which applications and networks areneeded at each level leads to the proposal from thewheel-CIM and its variations. this is show in section

Advances in Computational Intelligence, Man-Machine Systems and Cybernetics

ISBN: 978-960-474-257-8 274

Figura 1: Pyramid Hierarchical Model

2

2. CIM-CIMOSABetween decades 70 and 80, Joseph Harrington

created the model CIM (Computer Integrated Man-ufacturing). This is how the manufacturing CIM isdefined as the use of technology through computersto integrate the activities of the company. Accordingto this, computer technology is technology that inte-grates all other CIM technologies. Computer technol-ogy includes the full range of hardware and softwareemployed in the CIM environment, including the needfor telecommunications.

CIM is a concept fthat complete the optimizationand the integration of the company, there are no pre-determined patterns to bring the integration of people,functions, information and business needs in specific.The management needs a shared vision for your com-pany that shows all the value added, interrelationshipsand interdependencies. Usually the problem is not theavailability of technology, but to implement the ap-propriate technology, know its advantages, know thepower of this technology inside the company, becausepeople generally resist change.

So, arises the wheel-CIM for the total integration.This makes emphasis on two aspects:

1. An architecture to support integration.

2. A strategy that links the organization and compa-ny information management and data.

The CIM model presents a substantial improve-ment and renaming with the name wheel-CIM by theSociety of Manufacturing Engineers (SME) in 1985,as shown in Figure 2 and his philosophy is based onthe Architecture of Integrated Systems. In 1993 thereis a new philosophy as it is the client and the CIMmodel changed again by the wheel-enterprise also ofSME, see figure 3.

CIMOSA represents the Open Systems Archi-tecture for Computer Integrated Manufacturing, is a

Figura 2: Wheel-CIMmodel

Figura 3: Wheel-CIMmodel 1993

working reference framework for modeling enterprisewhich aims to support integration of the enterprise,the computers and personnel. The frame of referencework is based on the concept of system life cycle andprovides a modeling language, methodology and tech-nological support to meet production targets. It wasdeveloped in the 90’s by the AMICE Consortium for aproject. The principle CIMOSA Association is a non-profit association established to create specificationsof CIMOSA, promote and support its evolution withthe possibility of doing a standard.

The original goal of CIMOSA (1992) has beendeveloping an open system architecture for CIM anddefine a set of concepts and rules to facilitate thebuilding of future CIM systems. One of the main ideaof CIMOSA is the categorization of manufacturingoperations, this is

The generic functions: The generic parts of aenterprise or business areas, this is to identifythe independent companies of its organizationalstructure.

Specification (partial and particular) of the func-tions: specific fopr each companies individualy.

Two important results in the development andevolution of CIMOSA are::

Modeling framework: This framework supports allphases of the life cicle CIM system, this is, fromthe requirements definition to the design specifi-cations, the descriptions of implementation andthe execution of daily operations in the company

Integrated Infrastructure: This infrastructure pro-vides specific services for information technol-ogy for the implementation of Particular Imple-mentation Model, which is conceived as an inde-pendent supplier.


ISBN: 978-960-474-257-8 275

Figura 4: Cube-CIMOSA

This modeling framework also provides eventmanagement, a modeling approach based on process-es with the goal of covering essential aspects of thecompany in an integrated model. The main aspects arethe functional, behavioral, resources, information andhuman aspects . Thus, the basic reference architectureincluding CIMOSA life cycle shown in Figure 4.

CIMOSA can be applied in the simulation andanalysis of the process. The models of CIMOSA-standardized can also be used in the manufacturingenterprise to establish calendars (agendas),dispatch ,monitoring and to provide information of the process.One of the standards based on CIMOSA is GERAM,this is Methodology and Architecture of ReferenceGenerals for enterprise, [12], [13], [14], [15], [16],[17], [18], [19], [20].

2.1. CAD-CAM consequences of CIMOSA

One of the direct consequences of these approach-es to integration was the different ways to gener-ate models of assembly in these systems, which in-clude: models in models,components o figures andintelligent assembled. Everything depends on whichsoftware and hardware available, giving rise to theComputer Aided Design then be reproduced on theComputer Aided Manufacturing. The basis of anyCAD/CAM system is the software platform used togenerate and document the model of a part (the doc-ument) and is called the heart of the system. Whatwould become the soul of the system are the applica-tions that can be added. It is by mean of the applicationcan be a real efficiencies of the CAD/CAM in termsof savings in production and cost related to the pro-cess. Environmental applications CAD / CAM can beseparated into three types: functions, disciplines andindustrial applications, namely:

Functions . They are usually those operations, toolsand actions supported by the software platform,such as wireframe geometry or surface modeling.

Disciplines . They are created with the addition ofspecialized application software, libraries, userinterfaces and tools on the basic functions to cre-ate applications schematics d iagram of wire-frames ap´plications or surface modeling soft-ware applications.

Industrial applications . They are created with spe-cific software for disciplines or industry, and theaddition of libraries and special tools for eachparticular process.

The creation and basic documentation of the mod-el CAD/CAM is part of the software platform, whilethe applications are the tools used to automate com-pletely the design process. The use of CAD/CAMmakes that the engineering analysis can be divided inseveral areas, however, one clasification more generalis:

Solve closed: Made with particular equations forthat type of problems.

Logical analysis and of simulation: Computa-tional analysis to check adjustment in the formand in the function.

Finite elements and analysis of finite differences:Computational analysis for particular systems:Structural analysis, mechanic and thermal.

The cinematic analysis. Virtually one can ob-serve the operation of one component.

The above-mentioned makes the concept Com-puter Aided Engineering.

Most of carried out development based so muchon the pyramidal approach as the architectures associ-ated to this approach was carried out on manufactur-ing processes. An effort to extend these prerogativesand to capture it in a reference model for systems ofcontinuous production is the denominated Model ofReference of Integral Automation (MRAI for its ini-tials in Spanish). MRAI was developed in the Uni-versity of the Andes through the project called CEN-TAUR. MRAI provides a reference mark to achievethe integration of data, information, control and tak-ing of decisions in industries of continuous processes.

3. Model of Reference of IntegralAutomation: MRAI

This model represents a reference architectureoriented toward the systems of continuous production,


ISBN: 978-960-474-257-8 276

Figura 5: MRAI Model

Figura 6: MRAI model with levels

which provides a reference mark to achieve the inte-gration of data, information, control and taking of de-cisions in industries of continuous processes. The fig-ure 5 illustrate the architecture MRAI which is basedon the automation pyramid show previously.

MRAI considers five faces also denominated ar-chitectures, which represent the structures that shouldhave the elements of data, information, control and de-cision of a enterprise with the purpose of reaching ahigh grade of integral automation. These five architec-tures are projected on the productive process or phys-ical process. Their pyramidal character associates tothe hierarchical structure of the processes of taking ofdecisions, which divides these processes in three ar-eas: 1) strategic management, located in the top of thepyramid; 2) tactical management or managerial con-trol, located in the means of the pyramid; and 3) op-erational management or production control, locateddirectly on the physical process. Just as it shows it thefigure 6.

The physical process represented in the base ofthe pyramid, this constitute basic processes of trans-formation or continuous production of products, fromrow material or products semi-elaborated in semi-final

or final products.The processes of taking of decisions of the com-

pany, required for management the business at differ-ent hierarchical levels, they are modeled in the archi-tecture of processes of decision.

The technologies that are used to transform mat-ter in products are represented in the architecture ofproduction technologies. This architecture is closelybound to the physical process, because the activitiesor functions of the physical process are carried outwith the aid of these technologies. The separation be-tween the physical process and its technologies allowsto reach a bigger grade of independence technology -process, which is fundamental in changing companiesor in evolution.

The elements of data, information and control, al-ready used by the three architectures mentioned, theyare modeled through the architecture of objects, ofapplications and of technologies of information andcommunications. The architecture of objects repre-sents the types of entities of the business that par-ticipate in its different processes in an or anotherway. The materials, the products, the suppliers, theclients, the employees, the teams represent, amongother, types of entities that commonly form part of abusiness of continuous production. This architecturedefines the databases and it dates warehouses requiredby the enterprise to support its different software ap-plications.

The architecture of applications describes all andeach one of the software applications that integrate thebusiness and that they are vital to support the so muchexecution of the physical process, as of the processesof decisions.

The information required to carry out these pro-cesses executes it the components of this architec-ture, which is structured in several levels of complex-ity. The highest level in the architecture contemplateseach one the systems of information that it possess-es the business and the relationships that exist amongthem. At an intermediate level the tools of planning ofresources are identified, such as ERP (Enterprise Re-source Planning) and MRP (Manufacturing ResourcePlanning). In the lowest level they are defined thepackages of applications of specific purpose, employ-ees to satisfy very particular necessities or you sumup of the business, so much of the physical process(for example, controllers, analyzers and virtual tools)as of the processes of taking of decisions (for exam-ple, word processors, graphic packages and calcula-tion leaves). The integration among these applicationsthat are usually heterogeneous, is also a very impor-tant aspect that this architecture takes in considera-tion.

Finally, the pyramid MRAI includes, under the


ISBN: 978-960-474-257-8 277

architecture form, all the technologies of informationand communication on which the architectures of ap-plications and objects are implemented. The nets ofcomputers, the computers and the software of oper-ation and development are the fundamental compo-nents of this last architecture. The base and the fivefaces of the automation pyramid that we have de-scribed in this section, are the conceptual base onwhich was designed METAS [9].

So, the integration in a enterprise can see as theintegration:

Between processes It contemplates basically twotypes of integration : (a) the integration betweeenprocesses of decision located in different levelsof the pyramid and (b) the integration betweenproductive processes. In both cases, the basicmechanisms of integration are the informationprovided by the systems of information and theautomated flows of works (workflow).

Of applications It consists on integrating the differ-ent components of the architecture of applica-tions. The technology web, the technology ofagents and the bases of meta-data are two pos-sible mechanisms that can be applied to solvethis problem. An schema of integration of appli-cations based on intelligent agentsis presented in[5]. The integration of applications by means ofinterfaces web is broadly discussed in [8].

Of data , The databases defined in the architecture ofapplications require to be integrated to be ableto be used by the systems of information. Twoimportant mechanisms of integration of data arethe bases of meta-data and them date warehous-es. These mechanisms you discusses in [8].

4. A Method for Integrated Automa-tion Systems: METAS

An essential resource in the automation of a con-tinuous production process is the strategic plan for au-tomation. This plan describes the activities the enter-prise must make to achieve a high level of automa-tion and integration in their process. To develop a planof this nature requires a methodology that takes inconsiderations the fundamentals elements of automa-tion and integration, as defined MRAI (by its span-ish acronym). METAS is a method for the automationof continuous production companies based in MRAImodel described in the previous section. The main re-sult to applied METAS is a strategic plan for integralautomation by one continuous production process.

4.1. METAS objetives

The main objective of this method is to guide thedevelopment process of integration of strategic plansor master plans of Automation (PMA) by the specifi-cation or design of each of the faces or architecturescontemplated in the model MRAI. This is

Decision-making process architecture

Production technology architecture

Data objects architecture

Application architecture and integration mecha-nisms

Technology architecture I&C: Hard-ware/Software/Nets

The strategic plan developed through METAS de-scribes the company must do to implement these ar-chitectures, as well as the time it should be used andthe human , economic, technological and material re-sources for its implementation.

Preliminary activities of the previous method tothe application of the METAS requires to carry outpreliminary activities to ensure the effective applica-tion of the method and give start to the study of au-tomation. These activities are described below:

1. Determining the objectives and reach of thestudy. Before starting the implementation of themethod is necessary to clearly establish the ob-jectives of the study of integrated automation andits reach within the enterprise. The objectives ofthe study are obviously related to the problemsthe company due to the absence of integrationbetween processes and applications. The analy-sis of these issues is needed to determine the ex-tent of automation. In this method, we use theterm .enterprise systemrefer to the reahc of thestudy, this ,is, all business areas in which to beheld on process automation and enterprise inte-gration. The study can be conducted in one ofthree different levels, namely:

Enterprise level: Covers the entire produc-tion organization.

Plant level: It covers a specific plant that thecompany has.

Production unit level: Covers a particularproduction unit.

The enterprise system consists of two closely re-lated sub-systems:


ISBN: 978-960-474-257-8 278

Business System: Frame all managementprocesses, business objects and items re-lated to organizational asociate to decisionmaking enterprise system. The businesssystem covers the three hierarchy levels ofthe automation pyramid and is responsiblefor conducting the planning, scheduling,organization, resource management, busi-ness management and management controlof the production process.Productive process: its refers to the prop-erly this processes of continuous produc-tion, that is, those activities that is supportof the technologies of transforming matteror intermediate products in final products.This process is commonly referred as phys-ical process and it is planned, programmed,directed and controlled by the System ofBusiness.

2. Organization of the work group. The applicationof the method requires the previous conformationof a group of multi-disciplinary work in charge ofcarrying out the different activities that she de-scribes. This group to which we will refer as theautomation group, should be integrated by engi-neers or specialists in systems and calculation,control engineers and key users of the compa-ny, such as plant managers, production managersand supervisors who will know the problem suf-ficiently well, as well as the managerial systemand their two components: system of businessand productive process.

3. Elaboration of the work plan. This plan deter-mines the specific activities that the automationgroup should carry out to leave the study of in-tegral automation. These activities are based onthose established by the METAS method. Theplan includes, also, an estimate of the cost ofthe study and the human resources, materials andcomputacional required to realize.

4. Approval of work plan. Once developed the planof work, this is presented for management to ob-tain approval and resources needed to start thestudy according to the activities set out in thenext section.

5. Description of the activities of METAS. METAShas a hierarchical working structure composed ofthree types of activity: phases, steps and tasks.This structure is inspired by the method of strate-gic planning of information systems Steven Spe-wak EAP [6]. In the first level of our work struc-ture are the following phases:

a) Preliminary modeling business

b) Modelling the production process

c) Definition of information requirements, au-tomation and enterprise integration

d) Architectural Design Management Process

e) Architecture Design Data Objects

f ) Design Application Architecture

g) Definition and specification of Systems In-tegration

h) Architectural Design Information Technol-ogy and Communications

i) Automation Development Plan

Cada una de estas fases se divide en pasos y estos,a su vez, en tareas, ver como se presenta en las sub-secciones siguientes.

4.2. Phase 1: Preliminary Modeling SystemBusiness

This first phase is intended to help the automationgroup to obtain a global understanding of the businessunder consideration. This phase involves identifyingand documenting business system objectives, func-tions, business objectives and organizational structure.The steps required in this activity are:

1. Definition of the objectives of the business sys-tem and business system,

2. Definition of the value chain of the enterprise

3. Preliminary description of business functions

4. Identification of the organizational structureframed in enterprise system

5. Identification of principal business objects

6. Documentation and validation of preliminarybusiness model

The aims of the enterprise are established first time.These purposes are classified based on their reach,in four groups: mission, values, objectives and goals.The value chain represents the logical sequence lead-ing production processes and their decision-makingor management support, seen from a very general orglobal. Figure 7 illustrates the structure of this type ofmodel.

Based on the value chain is building a businessmodel more detailed processes, which represents sev-eral levels of abstraction, the different managementprocesses in the value chain and their relationships,


ISBN: 978-960-474-257-8 279

Figura 7: Value chain of production process

inputs, outputs and information flows . Activity dia-grams of UML [1] are an excellent tool to carry outthis modeling activity.

The different organizational units involved in thebusiness system are identified from the charts of thecompany. These units bring together the actors of thesystem, this is, people that participate in the businesssystem executing their decisions.

The business objects are all those entities in-volved in the business system and whose data areneeded to produce the information required by thebusiness system. Customers, products, raw materials,equipment, employees are, among others, some of thebusiness objects most representative of a business sys-tem of continuous production. These objects and theirrelationships can be modeled using UML class di-agrams. The set of diagrams obtained in this phaserelate to and assembled to produce the preliminarybusiness model, a document that describes the currentstate of the business and in particular its business sys-tem. A meta-business model can form the basis forbuilding the business model is introduced in [7]. Thedetails of how to develop a business model for contin-uous production companies is presented in [8].

4.3. Phase 2: Modeling of Continuous Man-ufacturing Process

The purpose of this phase is to obtain an overviewof all plants, that is, a comprehensive knowledge ofthe production process itself, its technologies and pro-duction methods. By this stage the planning groupidentifies the following aspects of the production pro-cess:

1. structure, topology, relationships, performancemodel, autonomy and physical distribution of theproduction process;

2. control methods, evaluation of performance,measuring the state of the process and depen-dence of assets, and

3. the hierarchical control architecture and commu-nication that requires the production process, in-cluding production plannig, assigning tasks by

units of production and supervision of the directcontrol.

The steps referred to in this phase are:

1. Collecting information about the production pro-cess

2. Functional and structural description (s) ofplant(s)

3. Identification of monitoring and evaluationmethods

4. Identification of hierarchical control architecture

5. Establishing relationships between businessmodel and the model of the production process

6. Documentation and validation of the model ofthe production process

4.4. Phase 3: Definition of information re-quirements, automation and enterpriseintegration

The objective of this phase is to establish the re-quirements that the business system stakeholders ex-pect the comprehensive automation process meets.These requirements are divided into three types:

Information requirements. Describes the infor-mation needs of decision-making processes ofthe business model. That is, the information re-quired to perform each of the business processesof the enterprise system.

Automation requirements. They relate to au-tomation and control of production processes.Among these requirements are the mechanismsof control of production processes and informa-tion requirements for these mechanisms to oper-ate.

Integration requirements. This type refers to therelationships of information, control and deci-sion between the business system and the pro-duction process. The flow of information thatmust exist between the business system and theproduction process is one of these requirements.Similarly, the integration between applicationsthat support automation is another of these typesof requirements.

The steps in this phase are the following:

Definition of information requirements for thebusiness system.


ISBN: 978-960-474-257-8 280

Defining automation requirements of the produc-tion process.

Requirements definition system integration busi-ness.

Validation of requirements with the main actorsin the enterprise system.

4.5. Phase 4: Designing the Architecture ofDecision Processes

The models produced in Phases 1 and 2 describethe business system that currently has the company.All process of integral automation require and neces-sarily involves changes in this system. These changesare aimed at solving the problems of the system inte-gration business has until now.

The decision process architecture, as other archi-tectures, a new business model that solves the prob-lems that led to the comprehensive automation effortthat meets the requirements established in Phase 3.This phase is as objectives: modeling, relate and doc-ument the decision processes that drive the productionprocess of the new system. The result of this phase isthe Architectural Decision Processes of new systembusiness, as defined in the Reference Model for Inte-grated Automation (MRAI) described in Section 2.

The architecture of decisionincludes, at least, fourhierarchical levels of decision from the level of direct(regulatory) control at the base of the pyramid, up thelevels of coordination and optimization to the level ofplanning at the top of the pyramid. The developmentphase is done by executing the following steps:

1. Scheduling interviews and meetings with keypersonnel

2. Description of the level of control (regulatory)

3. Description of the level of coordination (controlcenters)

4. Description of optimization level

5. Planning level description

6. Description of the processes of support adminis-trative

7. Modeling decision-process

8. Documentation and validation of the Architec-ture Management Process.

These steps are carried out by applying processreengineering and functional modeling. The inter-views and meetings with key personnel are the funda-mental mechanism to achieve an architecture of deci-sion processes that actually meets the requirements ofstakeholders in the enterprise system. When the reachof automation is at a business level, steps 2 to 4 areperformed in each of the production plants involvedin the process automation

4.6. Step 5: Designing Object Architecture

By this stage the automation group must identi-fy, classify, relate and document the types of businessobjects that constitute or are related to the enterprisesystem. The result of this phase is the architecture ofdata objects must have the new business system, asdescribed in the Reference Model for Integrated Au-tomation (MRAI).

For the development of this phase the groupshould follow the following steps:

1. Identification of classes for each business processof the preliminary model.

2. Definition of the structure, behavior and relation-ships of generalization, association and aggrega-tion for the classes identified.

3. Development of class diagrams of business ob-jects.

4. Integration of class diagrams and define the basesof objects or databases required by the enterprisesystem.

5. Identification of the relationship between archi-tecture and process objects.

6. Documentation and validation of the architectureof Business Objects.

4.7. Phase 6: Design of Application Architec-ture

This phase determines the set of software appli-cations that will be used to support decision-makingprocess architecture and the production process itself.The term .applicationıncludes three types of softwaresystems:

1. The information systems,

2. The application development tools including, in-ter alia, the ERP tools (Enterprise Resource Plan-ning), MRP (Manufacturing Resource Planning),DBMS (Data Base Management Systems) andCASE (Computer Aided Software Engineering);


ISBN: 978-960-474-257-8 281

3. Productivity tools such as systems, spreadsheets,word processing, charting systems, virtual instru-mentation systems, etc.

Information systems are the main components of thearchitecture of applications since they provide the in-formation that the enterprise system requires to per-form its decision process and production. The applica-tion development tools and productivity tools are thetechnological support or software on which to developand / or base business information systems. The stepsfollowed in this phase are listed below:

1. Identification and definition of information sys-tems required by the enterprise system.

2. Identification of development and productivitytools.

3. Selection of providers of development and pro-ductivity tools.

4. Preliminary specification of information systemsand their interrelationships (network application)

5. Establishing relationships between the architec-ture of applications and processes and objects.

6. Documentation and validation of the ApplicationArchitecture.

4.8. Step 7: Defining and Specifying SystemsIntegration

This phase aims at identifying, selecting, definingand specifying the mechanisms or systems that inte-grate enterprise system architectures. Integration intothe model MRAI can be done in three ways:

Integration processes involves two types of integra-tion:

1. The integration of decision processes locat-ed at different levels of the pyramid, and

2. The integration of decision procees andproduction processes. In both cases, the ba-sic mechanisms of information integrationare provided by information systems andautomated work flows (workflow).

Integracion de aplicaciones Consist in integrate thevarious components of application architecture.Web technology, agent technology and meta-databases are two possible mechanisms that can beapplied to solve this problem. An application in-tegration system based on intelligent agents isproposed in [5]. Application integration throughweb interfaces is widely discussed in [8].

Data Integration Databases defined in the applica-tion architecture need to be integrated in orderto be effectively used by information systems.Two important mechanisms for data integrationare the basis of meta-data and data warehouses.These mechanisms are discussed in [8].

The steps below:

1. Identification of alternative integration.

2. Selection of process integration systems, appli-cations and data.

3. Definition of each system integration.

4. Draft specification for each system integration.

5. Validation of systems integration.

4.9. Phase 8: Define the Architecture of In-formation and Communications Tech-nologies

Having defined the object architectures and appli-cations, automation group must now determine how,where and with what technologies these architectureswill be implemented. This phase consist to identi-fy the information and communications technologiesthat will support these two architectures. Specifical-ly, it is necessary to define the hardware, software andnetwork support and data communications that imple-ment the solution specified in the other architectures.At this stage the group should perform the followingsteps:

1. Identify different strategies and information andcommunication platforms

2. Select the platforms I&C for direct control, su-pervisory, management and integration

3. Relate the architecture of I&C with the process,objects and applications

4. Document and validate the architecture of Infor-mation and Communications Technologies

4.10. Phase 9: Development of IntegratedAutomation Plan

The final step of the proposed method is the devel-opment of integrated automation strategic plan, whichdetermines the activities required to implement thedifferent architectures and components of the new en-terprise system and the financial, human and techno-logical required for the implementation process plan.The phase followed to develop the strategic plan are:


ISBN: 978-960-474-257-8 282

1. Establish the overall activities required to imple-ment each architecture.

2. Defined development projects or implementationof new enterprise system architectures.

3. Sequencing the development and deployment ar-chitectures (schedule of activities).

4. Estimate the costs, time and resources needed toimplement and deploy architectures.

5. Define critical success factors for implementa-tion.

6. Identify strategies for implementation and op-eration of new business systems (including theredesign of organizational structure, staff train-ing, conversion strategies from the current sys-tem again, etc.).

7. Document and validate the strategic plan for fullautomation

The integral automation plan is the main prod-uct of METAS. Like any strategic plan, its purposeis to define long and medium term the way forwardto achieve more comprehensive automated businesssystem. This plan identifies a set of projects that de-scribe the implementation of the components of thearchitecture designed. The level of specification anddesign of the architecture, which is achieved throughthe implementation of METAS, is quite general, it isassumed that the details of specification and designof each component of these architectures are executedduring implementation and are defined in their respec-tive tactical plans.

5. PERA:Purdue Enterprise Refer-ence Architecture

The following integrated vision of the problem isrelated to the functional decomposition of the deci-sion tree. The functions are divided into control func-tions, programming and planning by different authors.In [10], an analysis of their integration needs and dif-ficulties of implementation. In this case, managementdecisions is fully hierarchical structure. Another hier-archical scheme of separation of business functions,is given by the structure of corporate assets, whichare grouped according to CIM: Company, Plant, UnitCell, Computer.

In the case of continuous production processes,the model is given by the Automation Pyramid di-rect control functions (regulatory, sequential), super-vision (involving the handling of the parameters of

the drivers) and coordination (between processes inensure consistency in operations). The next level isassociated with the optimization of operations withina plant, and to select the best alternatives for a pro-duction process under given conditions. In this case,system dynamics is expressed in terms of a discretesystem, which allows to evaluate alternatives. This or-ganization with a vertical decomposition of the func-tions of management in the enterprise can be summa-rized in the proposal known as Purdue University Pur-due Enterprise Reference Architecture (PERA) andsupports the development of an integration scheme ofSP-95 ISA. currently ISA 95. At the time the solutionof the problems at each level of the pyramid in theindustry have been using techniques that range fromstationary models based algorithms to select optimalprocess operation, such as HYSYS (Aspentech,), theuse of heuristics as those used by GENSIM in G2 andNeuron-Line. (GENSIM, a and b). Different compa-nies are beginning to use object orientation to describethe functional units found in different plants. (GEN-SIM, c) and the Working Group proposal - WorldBatch Forum for describing business objects via XML(WBF).

PERA indicates that the most basic way to struc-ture the business model is ”phases.as indicated by thediagram. During each phase of the company differentdiagrams are used to reflect the detail of the devel-opment of how the company evolves from the initialdefinition phase operation until the dissolution. Thepurpose of PERA is to make the process of imple-menting enterprise systems a little more understand-able and predictable. This can be achieved by apply-ing some basic principles that relate to any business.Reference Architecture for Enterprise at the Univer-sity of Purdue or PERA model consists of a genericmodel which takes as its enterprise integration princi-ples for the company three basic components.

1. Production facilities or physical plant.

2. People / Organization.

3. Control and Information Systems.

PERA offers a life cycle model, which clearly de-fines the roles and relationships between the physicalplant, people and information systems.

These are described as three ”pillars”that beginwith the definition of business and end with the disso-lution of companies, as shown in figure 9.

Each company can be divided into ”phases”, asshown in Figure 10, this corresponds to a matrixwhere the rows are given by Production and Equip-ment, Human Roles, Control and Information Sys-tems and columns: Disposition of Assets, Operation


ISBN: 978-960-474-257-8 283

Figura 8: Purdue Reference Model,part A

Figura 9: Purdue Reference Model,part B

and Maintenance, Detail Engineering, EngineeringConcept and definition of the enterprise, linking eachof them as: policies, requirements, functions, flowcharts. Overall, defines the complete business modelAlthough formats for documenting each of the threemodel components (Services, People and InformationSystems) vary, the intent is the same: to provide a co-herent and coordinated the company during this phase.It is also true for the three components of the mod-el, this additional detail is added in each successivephase based on the information defined in the previ-ous phase.

The diagram 11 shows a typical form of ”sup-plies”, or, the documents produced at each stage of theCompany. These documents define the architecture ofeach component of the company during this stage, thisis, component manufacturing facilities, human and or-ganizational components and control components andsystems of information.

Since PERA represent the full life cycle of theCompany, all existing company documents and toolscan be tailored to its structure. As the company grew,and increasing levels of detail are defined, you can seehow each of the groups and their ”findingsrelate toothers.

PERA offers a formal methodology of the Mas-ter Planning of the Company, however, the method-ologies for use in later stages are not defined PERA,but complements existing methodologies for the engi-neering design, construction, operations, etc.

With the generic model provided by PERA arebeginning to see what should be the roles and func-

Figura 10: PERA Methodology

Figura 11: Application example


ISBN: 978-960-474-257-8 284

Figura 12: ISA 95 model

tions that are performed in a production process andthat due to the natural evolution of companies everyday are, or more specialized or more products man-ufactured, this leads to the dilemma of having to bemore flexible in settings (configurations) of the pro-duction process based on the compressed productionon open architectures of production units in Red Anattempt to define clearly which is an integrated en-terprise under the previous approach proposed by theISA in the ISA 95 standard.

6. ISA 95

The integration scheme is supported by ISA 95communicate efficiently control systems with enter-prise systems. The model is based on a hierarchicalmodel or sample levels that the activities involved ina manufacturing company. This includes a hierarchi-cal model of equipment and systems, which conceivesa general model of the functions in a enterprise. Aregiven in greater detail the functions of control, thatis, the management decision-making, coordination /monitoring and control loop process, and in less de-tail of business functions in order to establish a com-mon terminology for the functions involved in the ex-change of information. This will define the interfacesthat connect the exchange of information between en-terprise systems with control systems at levels 3 and4, see Figure 12.

As we see there is a stratification of three stagesthat correspond to the 3 stages of planning a distribut-ed enterprise. Each stage is comprised of levels. Thusthe plant floor activities between levels 0, 1, 2, 3 forStage 1, Level 4 Phase 2 and level 5, 6 for Stage 3 as

Figura 13: Functional relationship between controlsystems and enterprise systems according to ISA 95

Figura 14: Areas of Exchange of Information accord-ing to ISA 95

shown in the hierarchical functional figure 14.The most significant developments in the ISA 95

model set up between the levels of tactical planningand operations defined in levels 0, 1, 2, 3 and 4 respec-tively. This displays the functional relationships be-tween enterprise systems belonging to the tactical lev-el such as business planning and logistics and controlsystems belonging to the operational level, as shownin Figure 12.

Thus, integration is given through areas of ex-change of information between control systems ofmanufacturing and business systems as shown in Fig-ure 14

One of the most significant is the establishmentof the functions, see figure 15, among which we high-light

1. Order Processing

2. Production Scheduling

3. Production control


ISBN: 978-960-474-257-8 285

a) Process Engineering Support

b) Operations Control

c) Operations planning

4. Energy and Material Control

5. Procuradurıa

6. Ensuring Quality

7. Product inventory control

8. Production Cost Accounting

9. Shipping Management Products

10. Maintenance Management

11. Research, Development and Engineering

12. Marketing and Sales

And the information flows between functions areshown below

1. Programming

2. Production Plan

3. Production capacity

4. Orders energy and material requirements

5. Confirmation of the order of entry

6. Long-term requirement of energy and material

7. Short-term requirement of energy and material

8. Energy and material inventory

9. Costs of Production Objectives

10. Performance and Production Costs

11. Receiving incoming material and energy

12. Ensure quality results

13. Customer requirements and standards

14. Requerimientos del proceso y de productos

15. Finished goods waiver

16. In-process waiver request

17. Finished goods inventory

18. Data Processing

19. Pack out schedule

Figura 15: Data flow model between functions

20. Knowledge of processes and products

21. Maintenance requirements

22. Maintenance responses

23. Maintenance methods and standards

24. Maintenance techniques feedback

25. Feedback techniques of processes and products

26. Purchase order requirements for maintenance

27. Production orders

28. Viability

That establishing the basis of object model.ISA 95, makes a clear description of the func-

tions, features and exchange of information betweencontrol systems and enterprise systems and integra-tion scheme does not solve the problems of flexibil-ity and reconfiguration which has led to pass a newparadigm in the structure of decision making, rang-ing from model-based hierarchical heteraquico as pro-posed by PABADIS.

7. PABADIS: Plant AutomationBased on Distributed Systems

PABADIS systems based on product-orientedmanufacturing companies reconfigurable. One of theconcerns of manufacturing companies is that high


ISBN: 978-960-474-257-8 286

flexibility/adaptability and speed with respect to or-ganisation of production and supply-chain manage-ment and require an increasing amount of servicesand inter-company collaboration. These future re-quirements especially concern control and network-ing of embedded control systems of manufacturingenterprises at ERP (office), MES (factory control)and production level. PABADIS, extends the ideaof distributed control to an innovative architecturewhich incorporates both resource and product. Withthe projects new paradigm The Order is the Appli-cation which stipulates a correspondingly innovativecontrol and networking architecture across all threelevels, PABADIS combine European and internationalforces to provide this architecture allowing Europeancompanies to cope with the mentioned future needs[13].

As designated outcome the PABADIS develop anew control architecture based on distributed intelli-gence, a new manufacturing ontology, a first embed-ded Real-Time agent platform for control, a new gen-eration of RFIDs, a new generation of field controldevices, and building blocks for a new generation ofEnterprise Resource Planning systems. At ERP lev-el new functions together with new interfaces will bedeveloped, enabling direct access from ERP level tothe field control system following the new PABADIS-PROMISE ontology, which provides a framework forproduct and production process description and com-parison.

Both Manufacturing Execution System (MES)level and Field Control level will be completely de-centralised. Innovative to current practice and re-search, the MES level will be decentralised into Mo-bile Software Agents which are located (stored) insmart Tags which are attached directly to the prod-uct (Agent on RFID). Once the product arrives at aprocessing station, the Agent is read out of the RFIDTag and invoked to ensure product processing, furtherplanning based on the ontology based descriptions,and further necessary transport steps. For this, a firstEmbedded Real-Time Agent Platform will be devel-oped.

To be flexible with regard to the logical usage ofthe plants machinery, the product dependent controlpart (for which a new manufacturing ontology will bedeveloped) has to be provided individually for eachproduct in the moment of production and is also locat-ed within the Mobile Software Agent, respectively inthe RFID Tag. The Field Control level, corresponding-ly, is reduced to Residential Software Agents, whichrepresent the physically possible production process.Only these fine grained control building blocks arepermanently located on the resource control devices.They will behave as drivers for the physics of the re-

sources similar to drivers for PC periphery systemslike printers and modems.

PABADIS provide basic architectures, method-ologies and technologies for the long term innova-tion of manufacturing systems. By providing a newmanufacturing control paradigm - and proofing it by ademonstrator the project will have an economical im-pact both on Europes manufacturing industry by pro-viding it with better means for production but also forEuropes control equipment industry by providing newproducts and services. The main impact is expectedfor single piece production as given in automotive in-dustry, aircraft industry, machining tool industry, elec-tronics industry, and furniture industry.

By these means it will be possible to reach thefollowing benefits:

Dynamic reconfiguration of assembly, produc-tion, and transport systems (integrate new ma-chines, replace machines, or extract old ma-chines) in a plug-and-participate way,

Dynamic design of control applications on de-mand related to the intended products,

High degree of control code flexibility which en-ables an all-round plant, only limited by its phys-ical parameters,

Integration of customer demands until their ulti-mate point of no return by physical/machine rea-sons, and

Cross company wide co-operation over thewhole supply chain.

So we can say that this paradigm, particularly forEuropean companies, is based on automation usingdistributed systems to reduce the hierarchy to two lay-ers, the dissolves the supervision nayers and splits hisfunction in a part that can be centrally located insidethe planning system and other part that can be decen-tralized implemented by mobile agents as shown inFigure 16.

8. ConclusionIn this work, we present different visions of how

to deal with the problem of integration in produc-tion processes. The evolution presented ranging fromthe use of computers as an element of integrationthrough information (CIM, CIMOSA), happening bythe definition of function and functionalities requiredin all production process including their interactionsen ISA95 , as well as eliminating the gap betweenthe plant floor systems with enterprise systems by


ISBN: 978-960-474-257-8 287

Figura 16: PABADIS

the incorporation of systems which provide synergy(ISA95), up to define intelligent production units thatinteract through negotiation (PABADIS).

References:

[1] G. Booch, I. Jacobson, and J. Rumbaugh.The Unified Modeling Language User Guide.Addison- Wesley. 1998.

[2] S.H. Lim, N. Juster, and A. Pennington. Enter-prise modelling and integration: a taxonomy ofseven key aspects, Computers in Industry, 34(1997). 339-359.

[3] P. Bernus, L. Nemes, and T.J. Williams. Ar-quitectures for Enterprise Integration. London:Chapman & Hall, 1996.

[4] E. Chacon, F. Szigeti, and O. Camacho. IntegralAutomation of Industrial Complexes Based onHybrid System. ISA Transactions. Vol. 35. 1996,427-445.

[5] E. Chacon, A.I. Molina, and J. Montilva.Object-Oriented Modeling to Build Integrated Au-tomation for Continuous Production Systems.Proc. Of the 5th. International Conference onInformation Systems, Analysis and Synthesis(SCI/ISAS´99). Orlando, Fl., USA. Vol. 2,pp.296-301.

[6] S. H. Spewak. Enterprise Architecture Planning,Developing a Blueprint for Data, Applications,and Technology. John Wiley & Sons. 1993.

[7] J. Montilva. An Object-Oriented Approach toBusiness Modeling in Information Systems De-velopment. Proc. Of the 5th. International Con-ference on Information Systems, Analysis andSynthesis (SCI/ISAS´99). Orlando, Fl., USA.Vol. 2, pp.358-364.

[8] F. A. Chacon.Integracion de Software Het-erogeneo a traves de Sistemas de Informa-cion Web: Arquitectura y Metodologıa. Tesis deMaestrıa. Universidad de Los Andes. Facultadde Ingenierıa.

[9] J.A. MONTILVA, E.A. CHACON y E. COL-INA, Un Metodo de Automatizacion Integralpara Sistemas de Produccion Continua, Uni-versidad de Los Andes, Facultad de Inge-nierıa, Escuela de Ingenierıa de Sistemas, Av.Tulio Febres Cordero, 5101 Merida-Venezuela,IV Jornadas Panamericanas de Automatizacion.Caracas, Venezuela, Mayo, 2000.

[10] Donald E. Shobrys, Douglas C. White, Plan-ning, scheduling and control systems: why can-not they work together, Original Research Ar-ticle Computers & Chemical Engineering, Vol-ume 26, Issue 2, 15 February 2002, Pages 149-160.

[11] Kuhnle, Hermann (Ed.), PABADIS based Prod-uct Oriented Manufacturing Systems for Re-Configurable Enterprises, Results are publishedin Distributed Manufacturing - Paradigm, Con-cepts, Solutions and Examples,2010, XXII, 191p. 52 illus., Hardcover ISBN: 978-1-84882-706-6, Springer

[12] Nanua Singh, Systems approach To ComputerIntegrated Design And Manufacturing, John Wi-ley And Sons Inc, New York, 1996

[13] K. Kosanke, CIMOSA Overview and Status”,Computers in Industry, Volume 27 (2), pages101-109, 1995.

[14] K. Kosanke, F. Vernadat, M. Zelm, CIMOSA:Enterprise Engineering and Integration, Com-puters in Industry, Volume 40 (2, 3), pages 83-97, 1999.

[15] G. Berio, F. Vernadat,New Developments in En-terprise Modeling Using CIMOSA, Computersin Industry, Volume 40 (2, 3), pages 99-114,1999.

[16] M. Zelm, F. Vernadat, K. Kosanke, The CIMOSABusiness Modeling Process, Computers in In-dustry, Volume 27 (2), pages 123-142, 1995.

[17] T.J. Williams, P. Bernus, J. Brosvic, D. Chen, L.Nemes, Architectures for Integrating Manufac-turing Activities and Enterprises, Computers inIndustry, Volume 24 (2, 3), pages 111-139, 1994.

[18] Introduction To CIMOSA,www.rgcp.com/cimosa.htm, 11-11-99.

[19] Enterprise Modelling,www.rgcp.com/modelling.htm, 11-11-99.

[20] CIMOSA: A Primer Of key con-cepts, purpose and business value,http://cimosa.cnt.pl/Docs/Primer/primer93.html,11-11-99.


ISBN: 978-960-474-257-8 288

evolution of integrated automation approach of integrated automation approach edgar chacon...

Documents