COMPUTER INTEGRATED MANUFACTURING:CIM ARCHITECTURE AND ENTERPRISE MODELING

CIM ARCHITECTURE AND ENTERPRISE MODELING

An enterprise is a complicated social, economic, and physical system. The implementation of CIMS in an enterprise is an even more complicated feat of system engineering. To implement CIMS suc- cessfully, engineers with an excellent analytical and technological background and abundant expe- rience are needed, as well as the guidance of advanced CIM system architecture and implementation methodology and powerful support tools. CIM system architecture studies the components and their relationship to CIM to provide the basis and guidelines for the design and implementation of CIMS in a company. A good system architecture can not only act as a basis for describing the system components but also provide a good way to communicate among users, designers, and other parties. A number of CIM system architectures are available, such as the SME wheel structure (Figure 3), CIM open system architecture (CIMOSA), the Purdue enterprise reference architecture (PERA) (Wil- liams 1992), the architecture for information system (ARIS) (Scheer 1992), and GRAI (graphs with results and activities interrelated) integrated methodology (GIM) (Doumeingts et al. 1992).

With the development of CIM reference architecture, a number of enterprise modeling methods have been put forward to describe the enterprise. Because the enterprise is a very complex system, it is difficult to describe it using a simple and unified model. A typical method used by almost all enterprise modeling methods is to describe the enterprise using several view models. Each view defines one aspect from a specific point of view, and then the integration method between the different view models is defined. The general view models now used in describing enterprise are function view, information view, organization view, resource view, and process view. Other views are also presented by researchers are control view, defined in ARIS, decision view, defined in GRAI / GIM, and economic view, proposed by Chen et al. (1994).

Views of the Enterprise Model

As discussed above, the enterprise model consists of several interrelated view models. Each view describes a specific aspect of the enterprise and has its own modeling method. This section gives a brief description of the aims of each view and the method currently used in building the view model.

Process View

The process view model takes a major role in defining, establishing, analyzing, and extracting the business processes of a company. It fulfills the requirements of transforming the business process, the manufacturing process, and the product-development process into a process view model. The process model is the basis for business process simulation, optimization, and reengineering.

Modeling Method for Process View Process view modeling focuses mainly on how to organize internal activities into a proper business process according to the enterprise goals and system restrictions. Traditional function-decomposing-oriented modeling methods such as SADT and IDEF0, which set up the process based on activities (functions), can be used in business process modeling.

The business description languages WFMC (Workflow Management Coalition 1994), IDEF3, and CIMOSA are process-oriented modeling methods. Another modeling method uses object-oriented technology, in which a business process can be comprehended as a set of coordinated request / service operations between a group of objects. Jacobson (1995) presents a method for using object-oriented technology, the use case method, to reengineer the business process. Object-oriented methods offer intrinsic benefits: they can improve systemic extendibility and adaptability greatly, their services based on object-operated mode can assign systemic responsibility easily, existing business processes can be reused easily, and distribution and autonomy properties can be described easily.

The main objective of the process view modeling method is to provide a set of modeling languages that can depict the business process completely and effectively. To depict a business process, it should be able to depict the consequent structure of processes, such as sequence, embranchment, join, con- dition, and circle, to establish a formal description of the business process. Generally accepted mod- eling languages today are IDEF3, CIMOSA business process description language, and WFMC workflow description language.

Some business process description methods originating in the concepts and models of traditional project-management tools, such as the PERT chart and other kinds of network chart, are generally adopted in practical application systems because they can be easily extended from existing project management tool software. If the business process is relatively complex, such as existing concurrent or collision activities, some superformal descriptions, such as Petri net, should be used.

Figure 19 is a workflow model of a machine tool-handle manufacturing process. The process model is designed using the CIMFlow tool (Luo and Fan 1999). In Figure 19(a), the main sequential process is described and the icon stands for a subprocess activity. Figure 19(b) is the decom- position of the subprocess activity Rough Machining in Figure 19(a). After Turning activity is exe- cuted, two conditional arcs are defined that split the activity route into two branches. The activity Checking is a decision-making task that is in charge of the product quality or the progress of the whole process.

Function View

The function view is used to describe the functions and their relationships in a company. These functions fulfill the objectives of the company, such as sales, order planning, product design, part manufacturing, and human resource management. The efficient and effective operation of these func- tions contributes to the company’s success in competing in the market.

Modeling Method for Function View Function view modeling normally uses the top- down structural decomposition method. The function tree is the simplest modeling method, but it lacks the links between different functions, especially the data flow and control flow between different functions, so it is generally used to depict simple function relationships. In order to reflect data and control flow relationships between different functions, SADT and IDEF0 (Colquhoun and Baines 1991) methods are used to model function view. The IDEF0 formalism is based on SADT, developed by Ross (Ross 1985).

The IDEF0 model has two basic elements: activity and arrow. Figure 20 gives the basic graphic symbol used in the IDEF0 method. IDEF0 supports hierarchical modeling so that every activity can be further decomposed into a network of activities. In order to organize the whole model clearly, it is advised that the number of the child activities decomposed from the parent activity be less than 7 and greater than 2. Figure 21 gives a demonstration IDEF0 model (A0 model) of the control shop floor operation function.

In the CIMOSA model, the overall enterprise functions are represented as an event-driven network of domain processes (DPs). An individual domain process is represented as a network of activities. The domain process is composed of a set of business processes (BPs) and enterprise activities (EAs). The BP is composed of a set of EAs or other BPs. An EA is composed of a set of functional operations (FOs). The BP has a behavior property that defines the evolution of the enterprise states over time in reaction to enterprise event generation or conditions external or internal to the enterprise. It is defined by means of a set of rules called procedure rules. The structure property of BP describes the functional decomposition of the enterprise functions of enterprise. This can be achieved by means of a pair of pointers attached to each enterprise function. EA has an activity behavior that defines

the internal behavior (or flow of control) of enterprise activities. It specifies how to perform the functionality of an EA in terms of an algorithm making use of FO.

It can be seen that the process view and the function view are closely related to the CIMOSA modeling method. Hence, any tool that supports the CIMOSA modeling methodology should be process oriented and include function decomposition.

Information View

The information view organizes the information necessary to support the enterprise function and process using an information model. Data for a company are an important resource, so it is necessary to provide a method to describe or model the data, such as data structures, repository types, and locations, especially the relationships among different data. It is very important for the company to maintain the data resource consistently, eliminate possible data redundancy, and finally enable data integration.

The information view modeling method provides different models for different phases of a com- pany’s information system, from requirement analysis to design specification to implementation. The most commonly used model to express data today is the relational data model, which is the basis

for the relational database management system. The currently used IDEF1X method is an extension of the entity-relationship model proposed by Chen (1976). Three phases of the modeling process, a conceptual model, a logical model, and a physical model, are used in designing and implementing an information system. Vernadat (1996) gives a good introduction to information modeling in the context of enterprise modeling.

Organization View

The organization view is used to define and represent the organization model of a company. The defined model includes the organization tree, team, faculty, role, and authority. It also creates an organization matrix. In the organization view, the relationships between different organization entities are defined. It provides support for execution of the company’s functions and processes.

The hierarchical relationship between the organization units forms the organization tree, which describes the static organization structure. The team describes the dynamic structure of the company. It is formed according to the requirements of business processes. Personnel and organization units are the constituents of the team.

Figure 22 shows the organization view structure. The basic elements of the organization view are organization unit, team, and personnel.

The attributes of the organization unit include organization unit name, position, description, role list, leader, and the organization’s associated activities and resources. The leader and subordinate relationships between different units are also defined in the organization unit. In defining a team, the attributes needed are team name, description, project or process ID, associated personnel, and re- sources.

Resource View

The resource view is similar to the organization view. It describes resources used by the processes to fulfill the company’s business functions. Three main objects are defined in the resource view model: resource type object, resource pool object, and resource entity object. Resource type object describes the company’s resource according to the resource classification. The resource type object inherits the attributes from its parent object. A resource classification tree is created to describe the company’s resource. The resource pool object describes resources in a certain area. All the resources located at this area form a resource pool. Resource entity object defines the atomic resources. An atomic resource is some kind of resource that cannot be decomposed further—that is, the smallest resource entity.

Figure 23 gives the resource classification tree structure. In this tree, the parent node resource consists of all its child node resources. It depicts the static structure of the company’s resources.

The resource–activity matrix (Table 1) defines the relationships between resources and process activities. Every cross (X) means that the resource is used by this activity. The resource–activity matrix presents the dynamic structure of the resources.

Enterprise Modeling Methods

As pointed out in the previous section, there are many enterprise modeling methods. Here we only give a brief introduction to the CIMOSA, ARIS, and GIM methods.

CIMOSA

CIMOSA supports all phases of a CIM system life cycle, from requirements specification, through system design, implementation, operation and maintenance, even to a system migration towards a

CIMOSA solution. CIMOSA provides modeling, analysis, and design concepts in a set of languages and methodologies adapted to enterprise users at different levels and according to different users’ viewpoints.

The CIMOSA reference architecture, developed by the AMICE consortium within the European ESPRIT project, is a set of semiformal structures and semantics that is intended to be used as a modeling language environment for any business enterprise. The basic constructs and fundamental control structures of the architecture are collected in volumes called Formal Reference Base II (FRB) and Formal Reference Base III. FRB consists of two parts: the modeling framework and the inte- grating infrastructure (IIS).

The CIMOSA modeling framework, known as the CIMOSA cube, is shown in Figure 24. The modeling framework provides a reference architecture and a particular architecture. It contains three modeling levels (requirements definition, design specification, implementation description) and four views (function, information, resource, organization). The CIMOSA reference architecture (two left slices of the CIMOSA cube) provides a set of generic building blocks, partial models, and user guidelines for each of the three modeling levels. The particular architecture (right slice of the CI- MOSA cube) is the part of the framework that is provided for the modeling of a particular enterprise, that is, it exhibits a given CIM solution.

Generic building blocks or basic constructs are modeling elements with which the requirements and solutions for a particular enterprise can be described. Partial models, which are partially instan- tiated CIMOSA solutions applicable to one or more industrial sectors, are also provided in the reference architecture. The user can customize partial models to a part of the model of his or her particular enterprise. The CIMOSA modeling framework ensures that partial models from different sources can be used to build a model of one particular enterprise.

The CIMOSA integrating infrastructure (IIS) provides services to integrate all specific application processes of the enterprise into one cooperating system. IIS consists of the following services:

• Information services: administering all information required by the various application processes

• Business process services: scheduling the provision of resources and dispatching the execution of enterprise activities

• Presentation services: representing the various types of manufacturing resources to the business process services in a homogeneous fashion

• Communication service: being responsible for system-wide homogeneous and reliable data com- munication

CIMOSA model creation processes, namely instantiation, derivation and generation, define how generic building blocks and partial models are used to create particular enterprise models.

The instantiation process is a design principle that suggests: (1) going from a generic type to particular type (types are refined into subtypes down to particular instances); and (2) reusing previous solutions (i.e., using particular models or previously defined models) as much as possible. This process applies to all four views. It advocates going from left to right of the CIMOSA cube.

The derivation process is a design principle that forces analysis to adopt a structured approach to system design and implementation, from requirements specification through design specification and finally to full implementation description. This process also applies to all four views. It advocates going from the top to the bottom of the CIMOSA cube.

The generation process is a design principle that encourages users to think about the entire enterprise in terms of function, information, resource, and organization views, in that order. However, the complete definition of the four views at all modeling levels usually requires going back and forth on this axis of the CIMOSA cube.

ARIS

The ARIS (architecture of integrated information systems) approach, proposed by Scheer in 1990, describes an information system for supporting the business process. The ARIS architecture consists of the data view, function view, organization view, and control view. The data view, function view, and organization view are constructed by extracting the information from the process chain model in a relatively independent way. The relationships between the components are recorded in the control view, which is the essential and distinguishable component of ARIS. Information technology com- ponents such as computer and database are described in the resource view. But the life-cycle model replaces the resource view as the independent descriptive object. The life-cycle model of ARIS is divided into three levels. The requirement definition level describes the business application using the formalized language. The design specification level transfers the conceptual environment of re- quirement definition to the data process. Finally, the implement description level establishes the physical link to the information technology. The ARIS architecture is shown in Figure 25.

The ARIS approach is supported by a set of standard software, such as the application systems ARIS Easy Design, ARIS toolset, and ARIS for R / 3, which greatly help the implementation of ARIS.

GIM

GIM (GRAI integrated methodology) is rooted in the GRAI conceptual model shown in Figure 26. In this method, an enterprise is modeled by four systems: a physical system, an operating system, an information system, and a decision system.

The GRAI method makes use of two basic modeling tools: the GRAI grid and the GRAI net. The GRAI grid is used to perform a top-down analysis of the domain of the enterprise to be analyzed. It is made of a 2D matrix in which columns represent functions and lines represent decision levels. The decision level is defined by a horizon H and a period P. Long-term planning horizons are at the top and short-term levels are at the bottom of the grid. Each cell in the matrix defines a decision center. The grid is then used to analyze relationships among decision centers in terms of flows of information and flows of decisions.

GRAI nets are used to further analyze decision centers in terms of their activities, resources, and input–output objects. With this method, a bottom-up analysis of the manufacturing systems studied can be made to validate the top-down analysis. In practice, several paths in both ways are necessary to converge to a final model accepted by all concerned business.

GRAI and GIM are supported by a structured methodology. The goal is to provide specifications for building a new manufacturing system in terms of organization, information technology, and man- ufacturing technology viewpoints. The methodology includes four phases: initialization, analysis, design, and implementation.