Application of Reference Architectures For Enterprise Integration

7
Application of Reference
Architectures for
Enterprise Integration
7.1 Introduction
7.2 Enterprise Reference Architectures
7.3 CIMOSA
Introduction • CIMOSA Approach • CIMOSA Modeling
Framework • CIMOSA Integrating Infrastructure
7.4 Application of CIMOSA at Traub
Introduction • Reorganization Objective • Requirements
Definition • Architectural Design • Detailed
Design • Implementation • The Role of CIMOSA in Traub’s
Reorganization Process
7.5 The Practical Value of CIMOSA
Arian Zwegers
7.6 Two Other Enterprise Reference Architectures
Baan Development
GRAI/GIM • PERA
Henk Jan Pels 7.7 Baan’s Enterprise Modeler
Eindhoven University of Technology 7.8 Summary
7.1 Introduction
Enterprises face integration problems due to necessary internal adaptations to cope with severe competition
in the global marketplace. To survive at the global market, efficient operation and innovative management
of change are essential. Enterprises need to evolve and be reactive, so that change and adaptation should
be a natural dynamic state rather than something occasionally forced onto the enterprise. Enterprise
engineering is the discipline that identifies the need for change in enterprises and carries out that change
expediently and professionally. Enterprise engineering intends to cater for continuous evolution and to
achieve a certain level of enterprise integration. Enterprise integration propagates the integration of all
enterprise resources to optimize business operations. That is, enterprise integration involves the collec-
tion, reduction, storage, and use of information, the coordination of product flows, the organization of
machines, the integration of human actions, etc.
Recently, some reference architectures have been defined that aim to provide the necessary frameworks
for enterprise integration. They are based on the idea that large parts of enterprise integration projects
are similar in every type of enterprise. These parts could be standardized and supported by methodologies,
tools, and other products that facilitate integration projects (Bernus et al., 1996).
The objective of this chapter is to investigate the practical value of enterprise reference architectures
concerning the integration of production systems. For this, three enterprise reference architectures have
© 2001 by CRC Press LLC

been studied: namely CIMOSA, GRAI/GIM, and PERA. In addition, the CIMOSA reference architecture
has been applied during an industrial reorganization project.
The outline of this chapter is as follows. Section 7.2 outlines the objectives and ideas behind reference
architectures for enterprise integration. An essential point is that enterprise reference architectures aim
to support the whole life cycle of an enterprise integration project rather than just the (architectural)
design activities.
CIMOSA is the best-known and most studied of the three enterprise reference architectures. In
addition, it is also the one with the most impact at the standardization committees. CIMOSA is examined
more closely in order to obtain a good understanding of the concepts of reference architectures for
enterprise integration. Section 7.3 gives an explanation of CIMOSA’s view on enterprise integration and
how to accomplish it. Furthermore, CIMOSA’s two most important elements, the modeling framework
and the integrating infrastructure, are shortly discussed.
Section 7.4 presents an application of CIMOSA during a reorganization project at a machine tool
manufacturer. The role of the CIMOSA modeling framework in the design of a functional control
architecture is illustrated. Due to immature specifications, the assistance of the CIMOSA integrating
infrastructure was rather limited.
Subsequently, the practical value of CIMOSA is discussed. Although the discussion focuses on
CIMOSA, most statements apply to most enterprise reference architectures. Section 7.5 shows that the
realization of CIMOSA’s true objective, namely a dynamic, flexible, adaptive enterprise by execution of
models, is far away.
The two other major reference architectures for enterprise integration, GRAI/GIM and PERA, are
presented in Section 7.6. Whereas CIMOSA lacks a true engineering methodology, these two reference
architectures are accompanied by well-defined methodologies.
Finally, Section 7.7 shows an alternative approach in the field of enterprise resource planning (ERP)
that does realize some of the targets of enterprise integration thinking. The Dynamic Enterprise Modeler
of Baan Company allows users to make changes in models that are directly reflected in changes in the
underlying Baan ERP applications.
7.2 Enterprise Reference Architectures

Several problems occur during the (re-)design of an integrated manufacturing system. Because such a
system cannot be bought off-the-shelf, each company has to develop its own. Williams et al. (1994a)
notice that designing an integrated manufacturing system meets with a number of difficulties. Several
viewpoints must be taken into account; not only the technical point, but also the economic, social, and
human points of view have to be considered. By definition, CIM systems are very complex, and the
development of such systems is often quite expensive and risky. Most systems are not designed from
scratch; the existing systems have to be considered in the development process, so that newly developed
systems are integrated with the old ones. In addition, Aguiar and Weston (1995) claim that the activities
performed during each phase of the life cycle are essentially derived from ad hoc procedures, so that the
quality of the resultant system will depend considerably on the experience of the persons involved. The
problem is accentuated due to poor formalism with which those activities are usually carried out. This
often leads to solutions that do not adequately address business requirements, experience low repeatability
of successful results, and reveal a lack of traceability of design decisions, etc.
The objective of enterprise reference architectures is to offer the framework that solves the problems
mentioned above, and with which an enterprise might develop its integrated manufacturing system. The
idea behind enterprise reference architectures is that a large part of integration projects is in fact similar
and common in every type of enterprise (Williams et al., 1994a). This part could be standardized and
utilized instead of re-developing it from scratch. Once standardized, generally accepted reference archi-
tectures can be supported by tools, methodologies, and a range of compatible products, thus making the
entire integration project more time- and cost-efficient.

FIGURE 7.1 Components of the GERAM framework.
Wyns et al. (1996) state that the benefits of reference architectures lie, among others, in unified and
unambiguous terminology, in envisaged simplicity of designing specific systems, and in high quality by
relying on proven concepts. In addition, a reference architecture models the whole life history of an
enterprise integration project. It indicates and justifies how and at what stage in the development process
external constraints and engineering design decisions are introduced, thereby providing traceability
between solution-independent requirements and final realizations. It provides the framework in which
enterprise integration methodologies work.
The IFAC/IFIP Task Force on Architectures for Enterprise Integration has developed an overall frame
work to organize existing enterprise integration knowledge. The proposed framework was entitled
GERAM—Generalized (or Generic) Enterprise Reference Architecture and Methodology. GERAM is
about those methods, models, and tools that are needed to build and maintain the integrated enterprise.
GERAM defines a toolkit of concepts for designing and maintaining enterprises for their entire life cycle.
The scope of GERAM encompasses all the knowledge needed for enterprise engineering. Thus, GERAM
provides a generalized framework for describing the components needed in all types of enterprise
engineering processes. GERAM provides a description of all elements recommended in enterprise
engineering and integration (IFAC/IFIP, 1997).
Fig. 7.1 shows the components of the GERAM framework. The most important component is the
Enterprise Reference Architecture, which defines enterprise-related concepts recommended for use
in enterprise engineering projects. The reference architecture should point toward purposeful organization
of enterprise concepts (Nell, 1996); it should identify and structure concepts for enterprise integration,
most notably life-cycle activities and architectural concepts such as abstraction, hierarchy, and views.
GERAM distinguishes between the methodologies for enterprise engineering and the modeling languages
that are used by the methodologies to describe and specify the structure, content, and behavior of the
enterprise. These languages will enable the modeling of the human part in the enterprise operation as
well as the part of business processes and supporting technologies. The modeling process is supported
by guidelines, and the results of the process are enterprise models that represent all or part of the enterprise
operations, including its manufacturing or service tasks, its organization and management, and its control
and information systems. These models should be used to improve the ability of the enterprise to evaluate
operational or organizational alternatives (e.g., by simulation), and thereby improve its current and future
performance.
The methodologies and the languages used for enterprise modeling are supported by enterprise
modeling tools. The modeling process is enhanced by using reference models that provide reusable models
of human roles, processes, and technologies. The operational use of enterprise models is supported by
specific modules that provide prefabricated products such as human skill profiles for specific professions,
common business procedures (e.g., banking and tax rules), or IT infrastructure services.

By means of the GERAM framework, the overlaps and differences of enterprise reference architectures
can be identified. After all, the ways in which enterprise reference architectures try to achieve their
objectives differ from one reference architecture to the other. The following components are the minimal
set of elements a reference architecture should include:
1. Enterprise engineering methodologies, which can be thought of as roadmaps and instructions of
how to go about an enterprise integration project or program
2. Modeling languages, which are needed to support enterprise integration, and should be placed in
relation to each other by means of the reference architecture
3. A modeling methodology, which comprises a set of guidelines that define the steps to be followed
during a modeling activity
In addition, the following components are elements that should preferably accompany an enterprise
reference architecture:
4. Modeling tools, which are computer programs that help the construction, analysis, and, if applicable,
the execution of enterprise models as expressed in enterprise modeling languages
5. Reference models, which contain a formal description of a type (or part of an) enterprise
6. Generic enterprise modules, which are products that implement (parts of) a reference model; for
example, an integrating infrastructure, or components thereof
7.3 CIMOSA
Introduction
The goal of the ESPRIT project AMICE (reverse acronym of European Computer Integrated Manufacturing
Architecture) was to develop an Open System Architecture for CIM (CIMOSA). The project started in
the mid-1980s and finished after some extensions in the mid-1990s. CIMOSA should facilitate continuous
enterprise evolution and make necessary operational improvements manageable. At the same time,
CIMOSA should provide a strategy to deal with legacy systems to protect current and planned investment
in an enterprise’s production process. CIMOSA aims to offer support for enterprise integration, more
precisely for “business integration” and “application integration” (AMICE, 1993a).
Business integration is concerned with the coordination of operational and control processes to satisfy
business objectives. In every enterprise, processes are present that provide supervisory control of the
operational processes and coordinate the every-day execution of activities. CIMOSA aims to integrate these
processes by process-oriented modeling of enterprises. Modeling these processes and their interrelations
can be used in decisions regarding the requested level of business integration.
Application integration, which affects the control of applications, is concerned with the usage of
information technology to provide interoperation between manufacturing resources. Cooperation
between humans, machines, and software programs must be established by the supply of information
through inter- and intra-system communication. CIMOSA tries to support integration at this level by
defining a sufficient infrastructure to permit system-wide access to all relevant information regardless
of where the data reside.
In addition to business and application integration, a third level of integration is discerned by the
AMICE project, namely physical system integration. This level is concerned with the interconnection of
physical systems and has led to a number of standards, such as OSI and MAP. CIMOSA supports this
type of integration by adherence to the standards.
CIMOSA Approach
CIMOSA provides a framework that guides designers in the design and implementation of CIM systems.
In addition, it aims to guide vendors in the development of CIM system components, so that these

FIGURE 7.2 Overview of the CIMOSA concepts (AMICE, 1993a.)
components can be added and removed at will. It does not provide a standard architecture to be used
by the entire manufacturing industry, but rather a reference architecture from which a particular
enterprise can derive particular architectures that fulfill its needs. As such, CIMOSA adheres to a
descriptive, rather than a prescriptive methodology (AMICE, 1993a). Fig. 7.2 gives an overview of the
CIMOSA concepts.
The CIMOSA modeling framework enables one to describe a particular enterprise. Accompanying
methods, called “model creation processes,” guide engineers in the creation and maintenance process to
obtain and maintain a consistent system description. CIMOSA supports the explicit description of
enterprise processes at different levels of abstraction for strategic, tactical, and operational decision-
making. Simulation of alternatives and evaluation of design decisions enhances the decision support.
CIMOSA supports incremental modeling of the enterprise rather than following an overall top-down
approach. In short, CIMOSA allows the end user to define, prototype, design, implement, and execute
its business processes according to his/her needs.
CIMOSA facilitates a system life cycle that guides the user through model engineering and model
execution. The life cycle starts with the collection of business requirements in a requirements definition
model, and goes, through the translation of the requirements into a system design model, to the
description of the implemented system. These phases are followed by a model release for operation and
model execution for operational control and monitoring. However, various methodologies consisting
of various system life-cycle phases are possible to instantiate particular models from the reference
architecture. These methodologies are supported by tool sets, which are defined by enterprise engineering
implementation models.
Model engineering and model execution are supported by the CIMOSA integrating infrastructure.
This infrastructure provides a set of generic services that process the released implementation model,
provide access to information, and connect to resources. In addition, the integrating infrastructure hides
the heterogeneity of the underlying manufacturing and information technology.
In the next two subsections, the two most important parts of CIMOSA—namely, the CIMOSA
modeling framework and the CIMOSA integrating infrastructure—are explained in more detail.

Generation
Instantiation
Requirements
Definition
Derivation
Design
Specification
Implementation Organization View

Description Resource View
Information View
Function View
Generic Partial Particular
Building Models Model
Blocks
FIGURE 7.3 CIMOSA modeling framework.
CIMOSA Modeling Framework

In Fig. 7.3, the modeling framework is represented by the CIMOSA cube. The cube offers the ability to
model different aspects and views of an enterprise (AMICE, 1993a,b). This three-dimensional framework
has a dimension of genericity, a dimension of enterprise models, and a dimension of views:
• The dimension of genericity (and stepwise instantiation) is concerned with the degree of particu-
larization. It goes from generic building blocks to their aggregation into a model of a specific
enterprise domain.
• The dimension of modeling (and stepwise derivation) provides the modeling support for the system
life cycle, starting from statements of requirements to a description of the system implementation.
• The dimension of views (and stepwise generation) offers the possibility to work with sub-models
representing different aspects of the enterprise.
CIMOSA Integrating Infrastructure

The CIMOSA integrating infrastructure enables CIMOSA models to be executed, and it allows the control
and monitoring of enterprise operations as described in the models. Furthermore, it provides a unifying
software platform to achieve integration of heterogeneous hardware and software components of the
CIM system. Applications use the generic services of the integrating infrastructure, so that they need no
longer contain the specifics of the data-processing environment. This provides increased portability and
flexibility of the applications and reduces the maintenance tasks considerably.
The integrating infrastructure consists of a
number of system-wide, generic services. The
Business
business services control the enterprise operations Services
according to the model. The information services
provide for data access, data integration, and data
manipulation. The presentation services act as a
Information Presentation
standardized interface to humans, machines, and Services Services
applications. A product that is connected to the
presentation services can be attached and removed
without changing any other part of the informa-
tion technology environment. Figure 7.4 displays
Humans Machines Applications
the integrating infrastructure and the above-
mentioned services. Other services are the common
services and the system management services that FIGURE 7.4 CIMOSA integrating infrastructure.

provide for system-wide data communication and facilities to set up, maintain, and monitor the
components of the integrating infrastructure.
7.4 Application of CIMOSA at Traub
Introduction
The ESPRIT project VOICE (Validating OSA in Industrial CIM Environments) validated the CIMOSA
results by the development of manufacturing control and monitoring solutions according to the CIMOSA
concepts in three types of industries. The VOICE project consisted of vendors, system integrators, research
institutes, and industrial partners. In each of the three industrial pilots, a different aspect of the manu-
facturing process was addressed. This section focuses on one of these pilots, namely the Traub pilot.
Traub’s motivation regarding the validation of CIMOSA was to examine whether CIMOSA is a useful
tool to support the restructuring process of the existing manufacturing organization and to support the
new organization with implemented information technology (Gransier and Schönewolf, 1995). Besides
some mentioned references, the main sources of this section are VOICE meetings and reports.
Traub AG is a German manufacturer of machine tools. The products cover conventional machines as
well as NC machines for turning and milling. The economic downturn in the market and the world-wide
recession have forced all machine tool manufacturers to improve their cost situation and shorten the
terms of delivery. Customer demands are characterized by an increased diversification of products,
resulting in decreasing numbers of series production. Enormous sales efforts and the introduction of
new products are not the only guarantee for survival. Enhanced demands to become more flexible and
efficient forced Traub to reorganize its production department (Schlotz and Röck, 1995).
Figure 7.5 shows Traub’s production control system before the reorganization. At that time, it consisted
of a mainframe with the Production Planning System, an IBM RS/6000 for area control functionalities,
and several cell controllers. Traub undertook global production planning for a year and a half in advance.
In this planning, machine types, options, and number of products were incorporated. Every 10 days, a
partial planning was made, which consisted of timed orders for design, purchase, and production control.
It was possible to control the order flow from the area controller by releasing orders, standing in a “10 days
order pool.” Dedicated applications established the transmission of NC-programs between the area
controller and the cell controllers. The worker at the NC-machine obtained a list of order data, and could
transfer and edit NC-programs from and to the machines, and transmit the optimized programs to the
area controller. Order progress and other monitoring data could be automatically sent from the machines
to the area controller or by entering a message on a terminal. Monitoring information was sent to the
mainframe at the production planning level from terminals on the shop floor located at several places
near the machines.
One of the problems associated with the old situation at Traub was its flexibility to respond to changes
in customer needs. Shorter delivery times with simultaneous reduction of stocks were already forcing
Traub to shorten machining times and to link all processes in design, planning, and shop floor more
closely. Even more, it frequently became necessary to rearrange plans at short notice because of changes
in demand, machine downtimes, missing production facilities, urgent contracts with large customers,
absence of staff, or rejects. Rescheduling of manufacturing jobs became difficult due to the limited
feedback from the shop floor, and expenditures for short-notice re-work and machine modifications
increased sharply.
In particular, the preparatory sectors were the areas where increased deadline pressure and the tendency
toward smaller and smaller batch sizes added to planning complexity and expenditure. Most notably, tool
management became problematic because the lack of up-to-date information concerning the availability
of machine tools and their components also reduced the production capacity while operators waited for
resources. Furthermore, production management had to cope with a growing amount of specialized tools
necessary to produce individually designed machine parts. There were nine machine centers, that each

IBM host
Other applications:
- CAD
- Purchase NC Programming
Token Ring
IBM RS6000
Ethernet
Cell controller Cell controller
Terminal
Transport Transport
NC-machine NC-machine
TND 30 /42 TND 30 /42
Terminal NC-machine Terminal NC-machine
FIGURE 7.5 Traub’s production control system before the reorganization.
having a stock of approximately 120 tools. Each tool consists of eight to ten components. At that time,
there was no registration of which tool or component was in which machine (Schönewolf et al., 1992).
Reorganization Objective
The most important target of the reorganization was to optimize the order throughput time. To achieve
this, a number of changes had to be implemented related to the cooperation on optimized order scheduling
between the area controller and the cell controllers. Other changes concern tool management, monitoring
data acquisition, etc. In this sub-section, only a few major changes are discussed.
The old, process-oriented manufacturing departments such as turning, milling, and grinding were
changed for a more flexible organization. The new organization is based on the principles of cellular
manufacturing, which involves the creation of clusters of machines that are designed and arranged to
produce a specific group of component parts (Black, 1983). In particular, Traub expected the cellular
manufacturing principles to result in a decrease in setup times.
An area control system was required that had to perform the fine planning of manufacturing device
utilization under rescheduling conditions with the help of a production scheduling simulation tool. This
area control system had to be linked enterprisewide with existing production planning, CAD, and CAM
applications. It had to control not only the manufacturing processes, but also the delivery of material,
tools, and equipment. Furthermore, it had to take into account the actual status of each NC-machine.
This information had to be transferred online—without any influence of the working people—directly
from the machine controller to the planning application of the area controller.
Fine-planning had to be supported by efficient tool management to get a tool-optimized order sequence
to decrease the setup time for each machine. This system would provide information on the location

and states of tools by means of a tool identification system and a central database with tool information.
It was necessary to integrate the tool logistics application with the entire existing infrastructure (Schlotz
and Röck, 1995).
Requirements Definition
Traub defined requirements in a functional sense for the application to be developed, and in a technological/
physical sense for the application’s underlying infrastructure. In other words, requirements were defined
for both the functional and technology aspects of the various components in the manufacturing system.
In addition, requirements were imposed on the reengineering process, influenced by financial and time
aspects.
Traub described its requirements from a functional point of view in terms of a scenario. In this scenario,
the needed functions and information flows, and their places in the total manufacturing system, were
outlined. For example, part of the scenario for the fine-planning activity (precision planning) was
described as follows.
“The work sequences released are assigned to the individual machines during the automatic precision
planning. During a planning sequence, only the machine capacity is taken into account. Starting from the
terminating time given by the order pool system, timing is done backwards. If the calculated starting time
lies in the past, the timing is done forwards while considering the transition time. If the given terminating
time is not observed during this forward scheduling, this is explicitly displayed in the system. No alternative
machine groups are considered in the automatic precision planning” (Schönewolf et al., 1992).
Requirements for the technology to be used were given as well. Besides Traub’s current needs, requirements
took into consideration the existing manufacturing system, strategic aspects such as standards, the factory
environment, and production process constraints. Traub mainly defined its requirements of the infra-
structure in terms of the CIMOSA integrating infrastructure; for example:
• “Multiple machines must be connected to a homogeneous system (presentation services).
• Connectivity to multiple databases on heterogeneous networks must be achieved from different
kinds of computer systems (information services).
• The network must be transparent (common services)” (Schönewolf et al., 1992).
Architectural Design
After requirements were defined, the design of the CIM system commenced. The design activities of
Traub’s reorganization project could be distributed over two phases: architectural design and detailed
design. In the architectural design phase, the system’s functional and technology architectures were
defined, supported by the CIMOSA framework. In the detailed design phase, the system was worked out
in more detail, based on the defined architectures.
Area control was positioned between the production planning level (not in the scope of the reorganization
project) and the shop floor. As an autonomous decision center in a distributed order planning structure,
it processes the order pool coming from the production planning system, and performs scheduling and
management tasks for machine-level planning. The incoming orders are scheduled for a 10-day period
on the various machine groups. For each machine group, the area controller performs a daily planning
to achieve an optimized order schedule with time slices of 2 days. The new order sequence on a machine
is calculated on the basis of the available tools and the list of needed tools, which is extracted from the
NC programs for the new orders. Tools available at NC machines or in the tool store can be requested.
Tool handling is supported by the tool management process.
Being intermediate between production planning and shop floor, area control not only has to provide
the shop floor with orders, but also allows feedback of information from the shop floor to the production
planning system. Then, this system can use data that reflects the actual situation in the shop floor to
optimize the planning process. Based on online messages from the cell control level, the area controller
also supports processing and visualization of data such as the actual status of orders.

The scheduled orders in the time frame of 2 days are sent to the cell controller for execution. Tool
management has allocated the tools required for the orders, and the NC programs are downloaded
from the NC program server. Subsequently, the cell controller acts as an autonomous decision center,
responsible for the execution of the orders, the collection of machine and operational data, and monitoring
the shop-floor processes.
Traub defined its production control and tool management system by means of modeling this system
and its environment with the CIMOSA requirements level. First, Traub built a user model with the
Systems Analysis and Design Technique, because a tool and knowledge covering this modeling method
was available. Later, Traub converted the user model to a CIMOSA model at the requirements definition
level. For modeling at the requirements level, Traub used the modeling tool “GtVOICE,” which is
described by Didic et al. (1995). Traub specified the functions and their interrelations for both the tool
logistic system and its direct neighbors. By modeling, Traub structured its system component functions,
defined the components’ allowed inputs and outputs, and specified the relations between these compo-
nents. That is, by modeling at requirements definition level, a functional architecture was designed.
Figure 7.6 shows a CIMOSA model that presents a global view of Traub’s production control functions.
The principal control functions are captured in CIMOSA domains, the constructs that embrace the main
enterprise processes. Figure 7.6 gives the identified domains and their relations in the form of domain
relationships. Non-CIMOSA domains are parts of the enterprise that have not been considered for the
moment and that could be detailed in the future, such as “Purchase” and “DNC-Node,” or that are closed
applications that cannot be described, such as the “Area Control” application. Usually, these applications
are legacy systems.
Traub also made some models that showed more details than Fig. 7.6. Figure 7.7 is a partial refinement
of the previous figure, showing domains and domain processes. CIMOSA represents main enterprise
functionalities as domain processes. CIMOSA offers a modular modeling approach; the system can be
extended with new domain processes, and system modifications can be limited to few domain processes.
Enterprise operation is structured into a set of interoperating domain processes exchanging results and
requests. They encapsulate a well-defined set of enterprise functionality and behavior to realize certain
business objectives under given constraints. In the Traub case, examples of concurrent processes are the
Area
Purchase DNC-Node
Control
New Consign NC-Program

Tool Data
Orders Messages Version
Cell Tool NC-Program

Control Management Administration
Manufacturing Tool CIMOSA

NC-Program Exception
Messages Movement Domain
Non-CIMOSA
Domain
NC-Machine Exception
Handling Handling Domain
Relationship
FIGURE 7.6 Overview of Traub’s production control functions. (Reprinted from Zwegers et al., Evaluation of
Architecture Design with CIMOSA, Figure 2, Elsevier Science, 1997. With permission.)

NON-CIMOSA
Domain
Area Control
rder
Pr
Tool
ep
ew O
tus
ar
s Co
r Sta
e
Ne
ess N
w
nsig
Orde
Or
de
Proc
ned
r
CIMOSA CIMOSA
DOMAIN Process Order Tool Data Prepare DOMAIN
Cell Monitoring Monitoring Processing Processing Tools Tool
Control Data Management
Start Man
ls
oo
ols
M
lT
ac
To
hi
tal
ufac
ne
t
Ins
tpu
Da
turing
Ou
t
a
CIMOSA
Manu- Set Up DOMAIN
= Domain Process
facturing NC-Machine NC-Machine
Handling
FIGURE 7.7 Partial refinement of Traub’s domains. (Source: From Zwegers et al., Evaluation of Architecture Design
with CIMOSA, Figure 3, Elsevier Science, 1997. With permission.)
processing of tool data and the preparation of tools. These processes are represented in domain “Tool
Management” by two independent domain processes, namely “Tool Data Processing” and “Prepare Tools.”
Note that the domain processes in Fig. 7.7 influence each other’s behavior.
Domain processes are the root of the decomposition tree. They employ business processes that are
in the middle of the tree. The leaves are called enterprise activities and are employed by business
processes or, if there are no business processes, by domain processes. The behavior of a certain business or
domain process is defined by rules, according to which enterprise activities belonging to this process
are carried out. Enterprise activities represent the enterprise functionality as elementary tasks, and
they are defined by their inputs, outputs, function, and required capabilities. Fig. 7.8 presents a
part of the behavior of domain process “Order Processing.” For clarity, some relationships have been
deleted. Events, which are either received from or sent to other domain processes, are represented by
a Z-shape; enterprise activities are shown as boxes labeled “EA.” Note that there are no business
processes specified for this domain process. The large triangles indicate behavioral rules according
to which enterprise activities or business processes are carried out. Fig. 7.8 was constructed using the
GtVOICE tool.
Note that the requirements definition level of the CIMOSA modeling framework is used at architectural
design activities and not during the requirements definition process. The reason is that CIMOSA does
not support a “true” definition of requirements in the sense as described in the previous subsection.
Instead, the CIMOSA requirements definition level offers support in structuring a manufacturing system,
that is, in defining a functional architecture.
Along with defining a functional architecture, Traub also outlined a technology architecture that
was influenced by the existing infrastructure. When defining functional components, one immediately

FIGURE 7.8 Process behavior of domain process “Order Processing” (partly). (Source: From Zwegers et al., Eval-
uation of Architecture Design with CIMOSA, Figure 4, Elsevier Science, 1997. With permission.)
maps these components on technological ones; the functional architecture is depicted on the technology
architecture. For example, when a designer defines a control function, he/she decides to execute this
function by a certain type of software module. In addition, the designer determines the interaction of
this component with other technology modules.
Together with its partner, FhG-IPK (Fraunhofer-Institut für Produktionsanlagen und Konstruktion-
stechnik) in Berlin, Traub built a testbed for demonstrating the viability of the new production concepts.
Traub initially defined three production management domains that it considered in its manufacturing
system (or rather in its testbed), namely tool management, order planning (“cell control” in Fig. 7.6),
and machine handling. Subsequently, Traub distributed these three functions over an area controller, a
cell controller, and attached machines.
The technology architecture of the testbed is shown in Fig. 7.9. The area control level comprised
a DecStation 5100 for long-term order planning and tool management. The area controller’s user
interface was implemented via the X.11 protocol on a terminal that was connected to the area
controller via TCP/IP on Ethernet. Communication with the cell controller was established via MMS.
The cell controller was a 486 PC running OS/2, enabling cell controller applications to run in a
multi-tasking environment. A MAP network connected the cell controller with shop-floor devices.
The cell controller received orders from the area controller, after which it processed the orders,
controlling the shop-floor devices via MMS. These devices consisted of a robot controller connected
to an industrial robot, a Traub NC-machine, and a PLC that controlled a conveyor and a round-
table. Whereas the PLC had a MAP interface and connected directly to the MAP network, the NC-
machine and the robot controller communicated with the network via a “protocol converter.” The
converter presented functionalities of both the NC-machine and the robot controller as MMS virtual
machine devices to the MAP network. The machine and the robot controller connected to the
protocol converter via V.24/LSV2.

Area Controller X-Terminal
MMS X.11
Ethernet MMS
Cell Controller
MMS MAP
MMS
Protocol Converter
PLC
V24/LSV2
Drilling Unit
Round Table
Robot Controller
NC-Machine Robot
FIGURE 7.9 Technology architecture of Traub’s testbed.
Detailed Design
In the second design phase, Traub specified its production control system in more detail, elaborating on
the architectures that were defined in the architectural design phase. Both architecture definitions were
further decomposed and worked out into detailed system specifications.
By means of the CIMOSA design specification level, a designer is able to detail a manufacturing system’s
functionality, taking the model at requirements level as the starting point. The requirements definition
modeling level supports a user in the definition of his/her system’s functional architecture, whereas the
role of the design level is to restructure, detail, and optimize the required functionality in a consistent
model. System optimization can be supported by simulation, taking all business and technical constraints
into account. By specifying a model at the design level, a designer describes the full functionality of a
CIM system, while staying within the definition of the functional architecture. If the model at the design
specification level reveals inconsistencies, or the model lacks optimization, it might be necessary to adjust
the model at the requirements definition level.
In addition to detailing the functionality of the system, the designer specifies the technology to be
employed to achieve the required system functionality. Simply stated, CIMOSA prescribes that for each
of the most detailed specified functions, called functional operations, a specified resource is assigned that
provides the required capabilities. The prime task of the design specification modeling level is to establish
a set of (logical) resources that together provide the total set of required capabilities. Some of these
required capabilities are offered by the generic services of the integrating infrastructure.
For example, Traub made a model at the design specification level, elaborating on the previously made
model at the requirements definition level. Traub specified the required information structure, it defined its
most elementary functions, and it assigned resources to these functions. During the creation of the models, the
function and information views were used extensively, whereas the resource and organization views

order (n,m) Distribution (1,n) controlled (1,n)
Order sequence Data by
(1,n)
(0,1) (1,n) Shop Floor (0,n) (1,n)

Customer Order generates triggers
Order
(1,1)
assigned to
(1,n)
(1,1) described (1,n)
Material Workpiece Work Schedule
by
(1,n)
contains
Entity
(0,n)
Relation
(1,n) set into (1,n)
Program
Subset Relation operation
FIGURE 7.10 Model at particular design specification level, information view (partial). (Source: From Zwegers
et al., Evaluation of Architecture Design with CIMOSA, Figure 5, Elsevier Science, 1997. With Permission.)
were barely addressed. It was not sensible to consider other factors such as responsibility (specified
by constructs of the organization view) before Traub was satisfied with the new control structure
regarding functionality and information flow. Part of the specified information structure is depicted
in Fig. 7.10.
A refinement of specified functions is accompanied by a refinement of the technology that provides the
desired functions. An enterprise looks for adequate products, either commercial ones or user developed.
The technology components, which are defined in the architectural design phase, are specified completely.
The definitions of the CIMOSA integrating infrastructure support this specification. Then, the products that
fulfill the design specifications are selected, considering enterprise policies and constraints. CIMOSA
states that the final build/buy decisions should result in a model that describes the implemented system.
Appropriately, CIMOSA calls this model the implementation description model. However, because the
AMICE consortium defined this part of the modeling framework after Traub reorganized its production
department, Traub does not have any experience with it.
To implement a prototype, Traub identified candidates that might help to implement software modules
or that might be used as complete software modules within the testbed. From the system specification
and the analysis of possible candidates, Traub defined products, toolkits, and tools to implement the
functionalities of the area controller and the cell controller. Furthermore, network interfaces were adopted
and products fulfilling integrating infrastructure services were chosen. For example, Oracle 6 was selected
as the product that had to provide the information services. It was connected by an SQL gateway to
EasyMAP, which was used to provide the testbed’s communication services. The communication services
are part of the common services. In a later stage, FhG-IPK’s communication platform was chosen in
order to offer the desired communication services to the operational system.
Implementation
The final phase contains the implementation and release for operation of the specified CIM system.
Implementation is based on the results and decisions of the previous phases.
Implementation activities comprise those tasks needed to bring the system into operation. During the
implementation phase, Traub procured and built the necessary new physical components. Note that the
word “physical” should not be taken too literally; in software engineering, for example, there are no such
things as “physical components.” The components were tested on the testbed and the correctness of the
underlying logical model was verified. Traub decided to implement its physical system in an evolutionary

Host Area Controller NC Program Server Consign Tools Tool Preparation
Token Ring Serial
Ethernet
Cell Controller 1 Cell Controller 2 Cell Controller 3 Cell Controller 4 Cell Controller 5
Machine Group Machine Group Machine Group Machine Group Machine Group
Scharmann Scharmann 2 Heller Heller 2 Bˆ hringer
TND 30 /42 TND 30 /42 TND 30 /42 TND 30 /42 TND 30 /42
FIGURE 7.11 Technology architecture of Traub’s implemented production control system. (Source: From
Schlotz, C., and Röck, M., Reorganization of a Production Department According to the CIMOSA Concepts, Figure 7,
Elsevier Science, 1995. With permission.)
way, with stable intermediate forms. In this way, Traub hoped to achieve a stable implementation of all
products and their interactions. When the system passed the tests with satisfactory results, the system
was prepared for transfer to production.
Traub felt that user acceptance was a major concern. It realized that the complex changes of the
manufacturing system had to be put carefully to the operators in the production environment. Therefore,
after testing single components as prototypes in the test environment, training sessions for the users of
the area controller and the cell controller were held. To make the workers familiar with the new system,
parts were transferred to the production without being integrated in the existing system. In addition,
the graphical user interface was adapted according to users’ needs, which was done to get a greater
acceptance. When Traub believed that the operators were ready to use the new technologies, the new
components were integrated in the existing system and released for operation.
Finally, the accepted production control system was released for operation. Figure 7.11 shows the
technology architecture of Traub’s production control system as implemented during the reorganization
project.
The Role of CIMOSA in Traub’s Reorganization Process

During the reorganization of Traub’s production department, the role of CIMOSA was twofold: the CIMOSA
modeling framework assisted the definition of a functional architecture, whereas the CIMOSA integrating
infrastructure supported the design of the technology architecture of the control system’s infrastructure.
The CIMOSA models allowed Traub to analyze and redesign its functional control architecture. During
architectural design, Traub was able to acquire knowledge of its current manufacturing control system
by means of modeling at the requirements definition level. This knowledge was needed to analyze the
existing system. Then, the model was changed to take required modifications into account. By means of
the specification of operational and control functions, their inputs and outputs, and interfaces between
functions, a functional architecture was defined.

The definition of a sound functional architecture, upon which the further design of the system is based,
is one of the keys to business integration. CIMOSA takes a modular approach to integration; that is, enterprise
operation is modeled as a set of cooperating processes that exchange results and requests. Only this
exchanged data needs to have a representation that is common between the cooperating processes. By
employing models for identification, analysis, and coordination of existing and new functions, required
functional architectures can be designed that define modular components and their interfaces. When the
detailed design and implementation of the CIM system follow the architectural specifications, the requested
integration of business processes will be obtained. This way, the required level of business integration is
achieved, which is reflected by the coordination of operational and control processes.
CIMOSA aims to support application integration by its integrating infrastructure. Cooperation between
humans, software programs, and machines must be established. Whereas business integration can be
regarded as the integration of functional components, application integration affects the integration of
technology components. The integrating infrastructure aims to provide services that integrate the
enterprise’s heterogeneous manufacturing and information systems to satisfy the business needs as
identified with the help of the modeling framework. The CIMOSA specification of the integrating
infrastructure can be seen as a reference model. Components designed and implemented according to
this reference model should provide desired features such as interoperability, portability, connectivity,
and transparency.
Due to the immature specification of most integrating infrastructure services, Traub only considered
the communication services. An example of an implementation that fulfills the CIMOSA specifications
is the communication platform developed by the FhG-IPK. This platform has been developed according
to the needs of Traub and the other two industrial VOICE partners, and was based on the communication
services of the CIMOSA integrating infrastructure. Lapalus et al. (1995) provide additional information
about the communication platform and application integration.
7.5 The Practical Value of CIMOSA

In this section, the practical value of CIMOSA is central. Its theoretic value is undoubtedly large, because
many ideas, developments, and products are inspired by it. In fact, many contemporary products seem
to be largely influenced by the CIMOSA concepts. Its value for industry is evaluated by means of the sets
of essential and desirable elements that reference architectures should be accompanied by. Section 7.2 states
that a reference architecture should be accompanied by modeling languages, a modeling methodology,
and enterprise engineering methodologies. Furthermore, it is desirable that a reference architecture be
supported by reference models, modeling tools, and generic enterprise modules. A special feature of
CIMOSA, as compared to other enterprise reference architectures, is that it aims to execute models; that
is, to control and monitor enterprise operations as described in the models.
On the Eligibility of the Reference Architecture
Architectural concepts such as hierarchy, views, and abstraction are represented in CIMOSA’s modeling
framework. The functional specifications are hierarchically decomposed by means of the domain process,
business process, and enterprise activity constructs. The modeling framework provides an open set of
(at the moment) four views to focus on different enterprise aspects. As for abstraction, going from the
requirements definition level, via the design specification level, to the implementation description level,
can be considered as moving from a focus on the functional, via the technology, to the physical domain.
However, the level of detail increases as well. That is, CIMOSA relates a low level in the design process
to implementation details. It does not support the specification of a true technology architecture, but
only the detailed specification of technology modules.
The CIMOSA modeling framework supports designers during the specification and analysis of functional
architectures of production control systems. A reference architecture should allow the specification of
functional control architectures, either by refinement of reference models or by design from scratch.
Reference models were not used during the Traub reorganization project; instead, models were made

from scratch. These models proved their usefulness by revealing some bottlenecks and inconsistencies in
the organization (Schlotz and Röck, 1995).
Zwegers et al. (1997) show that most characteristics of functional control architectures can be specified
by means of the CIMOSA modeling framework. Domain processes, events, and object views are adequate
constructs to specify concurrent processes and the exchange of information and products between these
processes. By defining domain processes and establishing relations between them, any type of control
architecture can be modeled. In addition, the modular nature of domain processes makes CIMOSA
models extensible and modifiable.
On the Complexity of the Modeling Framework

Industry—almost unanimously—regards the modeling framework as too complex. In Traub’s view, the
high complexity of the CIMOSA modeling framework requires well-trained engineers (Schlotz and Röck,
1995). Traub practically used only the framework’s function and information view; the resource view
was barely addressed and the organization view was not used at all. The organization view, for example,
was seen as a view to manage systems, not to design them. In addition, the great number of constructs
and their sometimes-ambiguous definitions hamper a practical application. A tool was needed to
unambiguously define the meaning of constructs.
On the Novelty of the Model Creation Processes

A modeling framework should be accompanied by guidelines, called “model creation processes” by
CIMOSA. A designer must be guided to navigate through the modeling framework in a consistent and
optimized path, to ensure complete, consistent, and optimal models. During the modeling process for
the Traub application, no such modeling guidelines were available. Recently, some guidelines have been
defined, but their practical value for industry has not yet been established.
At the moment, CIMOSA provides a methodology to guide users in the application of its modeling
framework. Zelm et al. (1995) describe this so-called CIMOSA Business Modeling Process. As for mod-
eling at the requirements definition level, for example, the top-down modeling process begins with the
identification of domains, the definition of domain objectives and constraints, and the identification of
relationships between the domains. Afterward, the domains are decomposed into domain processes,
which are further decomposed in business processes and enterprise activities. The modeling process at
the requirements definition level ends with some analyses and consistency checking.
More recently, new methodologies have been proposed that aim to be improvements or alternatives to
the CIMOSA Business Modeling Process. For example Reithofer (1996) proposes a bottom-up modeling
methodology for the design of CIMOSA models. He claims that the CIMOSA Business Modeling Process
can hardly be focused on processes and activities that are relevant to solve a concrete problem. His bottom-
up modeling approach should not have this disadvantage. In addition, Janusz (1996) asserts that existing
CIMOSA models of particular enterprises are not complete, not consistent, and not optimal. Also, these
models often describe only functions or sub-processes limited by department borders of an enterprise.
Therefore, Janusz developed an algorithm that filters out process chains of an existing CIMOSA model.
Using the algorithm, the completeness and the consistency of the considered process chains can be checked.
On the Inadequacy of the Enterprise Engineering Methodology

CIMOSA lacks a “true” engineering methodology, which provides instructions of how to go about an
enterprise integration project or program. Williams et al. (1994a) notice that CIMOSA does have a “life
history” for CIM systems (namely, the CIMOSA system life cycle) but that this description has not been
extended into a “true” methodology. Zwegers and Gransier (1995) give a description of the engineering
approaches adopted by the three industrial partners of the VOICE project, which used CIMOSA during
their reengineering trajectories. However, these engineering approaches have not been extended into a
methodology either. Possible users are not supported by knowledge on how to apply CIMOSA to carry
out integration projects. This point cannot be over emphasized; an enterprise reference architecture
without matching methodology defeats its own purpose.

On the Availability of the Modeling Tools
A modeling language should be supported by a software tool. During the creation of models, problems
might occur regarding the size and complexity of the architectural models. Models become too big to
be overlooked by the user—and they become inconsistent. Furthermore, the modeling process without
tool support is tardy, and maintainability and extendibility of the models are jeopardized.
Some tools have been developed for modeling with CIMOSA, such as GtVOICE (Didic et al., 1995)
and SEW-OSA (Aguiar et al., 1994). GtVOICE was developed by the VOICE project. This tool ensures
model consistency and reduces modeling time by easy model modification and extension. In addition,
it provides non-ambiguous interpretation of CIMOSA constructs and a uniform way to present models
among CIMOSA users. Finally, GtVOICE makes communication with other tools feasible, such as an
SQL data server and a rapid prototyping toolkit.
SEW-OSA (System Engineering Workbench for CIMOSA) was developed at the Loughborough
University of Technology in England. It combines the CIMOSA concepts with Petri net theories, object-
oriented design, and the services of an infrastructure called CIM-BIOSYS (Aguiar et al., 1994). Both
SEW-OSA and GtVOICE support the design of CIMOSA models according to the CIMOSA Business
Modeling Process as described by Zelm et al. (1995).
On the Absence of Reference Models
Perhaps most important for industry are guidelines that support designers to make the right architectural
choices; that is, choices that result in flexible, effective systems. Industry needs guidelines for the archi-
tectural design of systems, to discard inadequate options early in the design process and to enable the
selection of the best options. Clearly, such guidelines are not present at present. However, it is not an
objective of CIMOSA to provide such a prescriptive methodology. The CIMOSA modeling framework
aims to support system designers with descriptive modeling of enterprise operation; it is a descriptive
rather than prescriptive framework.
Nevertheless, the CIMOSA modeling framework offers the ability to develop reference models with
its partial modeling level. Best-practice reference models are the encapsulations of the prescriptive
guidelines mentioned above. As such, they are recognized as major tools to support CIM system development
projects (Faure et al., 1995). They should be based on architectural principles, such as modularity, structural
stability, and layers. Aguiar and Weston (1995) signal the need to populate workbenches with a library of
reference models. However, virtually no CIMOSA-compliant reference models are currently available.
CIMOSA lacks the guidelines and reference models needed to make a transition from requirements
to specification. After all, it prescribes how to make a specification of a system, but is does not prescribe
how to design the system. It offers the architecting concepts, but not the architecting principles nor the
business knowledge. It gives the ruler and compass to draw a house, but it does not give the construction
theory.
On the Promises of the Integrating Infrastructure
The promises of the CIMOSA integrating infrastructure appear too good to be true. Integration of
hardware and software components, model execution, vendor independence, reduced maintenance, and
increased application portability and flexibility appeal to companies facing a heterogeneous world.
However, the CIMOSA specifications of the services as used by Traub (AMICE, 1993b) reveal many gaps.
In addition, no commercial products supporting the CIMOSA specifications are currently available.
Nevertheless, enterprises appear to be more attracted by application integration promised by the integrating
infrastructure than by business integration as actually supported by the modeling framework.
On the Illusion of Model Execution
After time, models produced during an enterprise integration project are almost certain to lose their validity.
Enterprise integration is an ongoing process rather than a one-off effort. However, there is little chance for
an enterprise to maintain an up-to-date picture of itself as time goes by. Much of the effort initially invested
in modeling an enterprise’s processes is lost as reality diverges from those models (Bernus et al., 1996).

Traub, for example, foresees a considerable effort in keeping its models consistent with the implementation,
also due to the complexity of the CIMOSA modeling framework (Schlotz and Röck, 1995). Note that
the consistency aspect is not a CIMOSA-related issue, but rather a common problem for all enterprise
reference architectures.
To remedy this obstacle, enterprise models must actually be used to drive operation control and
monitoring rather than being kept on the shelf. The transition from specification to an operational system
requires an infrastructure that supports “model execution” and therefore must consist of what CIMOSA
calls “business services.” The realization of the aims behind the business services as originally conceived
might just as well prove to be an illusion for a long time. Bernus et al. (1996), for example, regard the
achievement of business services as a goal for the future.
CIMOSA fails to fulfill the objectives of model execution. The result of the specification phase (i.e.,
documentation in the form of models) is useful for (one-time) business integration. Without a real
integrating infrastructure with services such as the business services, however, it is not sufficient to fulfill the
objectives of the enterprise integration philosophy. Applying CIMOSA does not result in operational
systems, let alone in flexible, adaptive, efficient systems; the translation from the models into a real system
must be made. Given the fact that it does not offer guidelines and reference models that support designers
in the transition from requirements to specification, CIMOSA should merely be seen as a framework for
the generation of documentation.
7.6 Two Other Enterprise Reference Architectures

Williams et al. (1994b) claimed that there were only three major enterprise reference architectures known
at that time. This section discusses the other two enterprise reference architectures—in addition to
CIMOSA—that Williams et al. referred to: namely, the GRAI Integrated Methodology and the Purdue
Enterprise Reference Architecture.
GRAI/GIM
The GRAI laboratory of the University of Bordeaux, France, has been rather active in the field of enterprise
reference architectures. Along with developing its own ideas, the GRAI laboratory has contributed to the
ESPRIT projects IMPACS and AMICE. Here, the main elements of what has become known as the GRAI
Integrated Methodology (GIM) are described: namely, a “global model,” a modeling framework, and a
structured approach to guide the application of the methodology.
The global model describes the invariant parts of a CIM system: the subsystems, their relationships,
and their behavior. The global model (sometimes called the “macro reference model” or “reference
model”) is based on the concepts of three activity types and their corresponding executional subsystems.
These three subsystems are:
1. Physical subsystem, which performs the activities of product transformation using human and
technical resources
2. Decisional subsystem, which guides production toward its goals
3. Informational subsystem, which feeds the other subsystems with information
Sometimes, a fourth subsystem is distinguished, namely the functional subsystem (Doumeingts et al.,
1987; 1992).
The modeling framework uses IDEF0 formalisms to model the physical and functional subsystems,
GRAI formalisms for the decisional subsystem, and MERISE formalisms for the informational subsystem.
The GRAI formalisms are described below; for the other formalisms, the reader is referred to (Doumeingts
et al., 1995). The GRAI formalisms consist of the GRAI grid and the GRAI nets. The GRAI grid allows
one to model a decision system. It is displayed as a table-like frame, and it uses a functional criterion to
identify production management functions and a decision-cycle criterion to identify decisional levels.

Each function is decomposed into several levels according to the decision horizon H and revision period
P. A decision period is a time interval through which decisions are valid; a revision period is a time
interval at the end of which decisions are revised. The building block of a grid is a decision center that
is the intersection of a production management function and a decisional level. Decision centers are
mutually connected by decision links and information links. The GRAI nets allow one to model the
various activities of each decision center identified in the GRAI grid. The results of one discrete activity
can be connected with the support of another discrete activity. Because this is done for each decision
center, the links between decision centers are shown (Chen et al., 1990).
GIM’s structured approach aims to cover the entire life cycle of the manufacturing system. Figure 7.12
shows that the approach consists of four phases: initialization, analysis, design, and implementation.
Existing User
System Requirements
Initialization
Definition of the domain of the study

(First levels of the functional model)
Physical Functional Decisional Informational

View View View View
Analysis Analysis Analysis Analysis
Detection of
Analysis
inconsistencies
Phase
Consolidated user
requirements
Physical Functional Decisional Informational

View View View View
Design Design Design Design
User-oriented
User-oriented
specifications
design
Manufacturing Organization Information

Design Design Design
Technical-oriented
Technical-oriented
specifications
design
Implementation
New
System
FIGURE 7.12 GIM structured approach. (Source: From Doumeingts et al., Methodologies for Designing CIM Systems:
A Survey, Figure 20, Elsevier Science, 1995. With permission.)

Initialization consists of defining company objectives, the domain of the study, the personnel involved,
etc. The analysis phase results in the definition of the characteristics of the existing system in terms
of four user-oriented views. The design phase is performed in two stages: user-oriented design and
technical-oriented design. User-oriented design employs the results of the analysis phase to establish
requirements for the new system, again in terms of the four user-oriented views. Technical-oriented design
consists of transforming the user-oriented models of the new system design to technical-oriented models.
These models express the system requirements in terms of the required organization, information technology,
and manufacturing technology. Finally, the new system is implemented (Doumeingts et al., 1995).
GRAI/GIM covers the whole life cycle of a manufacturing system, except the operation and decommission
phases. Its four views differ from CIMOSA’s; it introduces a decisional and physical view. However, the
models of the physical view do not describe physical attributes; they describe functional attributes of
physical elements. The four model content views used during the analysis and user-oriented design phases
are translated to three implementation views during the technical-oriented design phase. Concerning
modeling languages, GRAI/GIM is less formal than CIMOSA. After all, CIMOSA aims to achieve model
execution, and that requires formal modeling languages. GRAI/GIM uses several known modeling tech-
niques such as IDEF0 and MERISE, and it developed the GRAI grids and nets. Although the GRAI
laboratory has completed many projects with its modeling framework, there is no modeling methodology
described in the literature. Obviously, this does not imply that there is no such methodology. GIM’s
structured approach offers an enterprise engineering methodology. However, this structured approach
is focused on the initial phases of a system life cycle; GRAI/GIM mainly supports designers during the
analysis and design phases.
As for modeling tools, there is no tool known in the literature that supports modeling with the
GRAI/GIM modeling framework. The same applies to reference models. GRAI/GIM is based on a “global
model,” a kind of generic model of an enterprise. However, no reference models that encapsulate industry-
type or area-specific knowledge are known. GRAI/GIM does not aim to provide generic enterprise modules
such as parts of an integrating infrastructure.
PERA
The Purdue Enterprise Reference Architecture (PERA) and its accompanying Purdue Methodology were
developed at Purdue University, (Nest Lafayette, IN). This university has also taken a leading role in the
definition of reference models for computer integrated manufacturing.
The Purdue Methodology is based on an extensive Instructional Manual that guides the preparation
of Master Plans. According to the methodology, an overall Master Plan is necessary before attempting to
implement any CIM program. A Master Plan includes a CIM Program Proposal (i.e., a set of integrated
projects whose completion will ensure the success of the desired integration of the enterprise). The Purdue
Enterprise Reference Architecture provides the framework for the development and use of the Instructional
Manual, the resulting Master Plan, and the ultimately implemented CIM Program Proposal. PERA is the
glue that holds together all aspects of the CIM program (Williams, 1994).
Figure 7.13 shows that the Purdue Enterprise Reference Architecture is characterized by the layered
structure of its life-cycle diagram. Starting with the Enterprise Business Entity, it leads to a description
of management’s mission, vision, and values for the entity under consideration. From these, the opera-
tional policies are derived for all elements of concern. Two—and only two—kinds of requirements are
derived from the policies, namely, those defining information-type tasks and physical manufacturing
tasks. Tasks become collected into modules or functions, which at their turn are connected into networks
of information or of material and energy flow. Then, technology choices are made; the role of the human
in the information architecture and in the manufacturing architecture is defined. The result of the technology
choices are three implementation architectures: namely, the information systems architecture, the human
and organizational architecture, and the manufacturing equipment architecture. After functional and
detailed design, the life cycle goes through the construction and operation phases, after which it is
disposed of (Williams, 1994).

FIGURE 7.13 Phases and layers of the Purdue Enterprise Reference Architecture. (Source: From Williams, T., The
Purdue Enterprise Reference Architecture, Figure 1, Elsevier Science, 1994. With permission.)
A specific feature of PERA is the emphasis it puts on the role of humans. By defining the functions that
will be performed by humans, the information and manufacturing architectures are converted into the
information systems architecture, the human and organizational architecture, and the manufacturing
equipment architecture. Figure 7.14 illustrates that this definition involves three “lines.” The automatability
line shows the absolute extent of pure technological capability to automate tasks and functions, and is
limited by the fact that many tasks and functions require human innovation and cannot be automated with
presently available technology. The humanizability line shows the maximum extent to which humans can
be used to implement tasks and functions, and is limited by human abilities in speed of response, physical
strength, etc. The extent of automation line shows the actual degree of automation carried out or planned
in the system. This third line defines the boundary between the human and organizational architecture and
the information systems architecture on the one hand, and the boundary between the human and organi-
zational architecture and the manufacturing equipment architecture on the other side. Its location is
influenced by economic, political, social, and technological factors (Rathwell and Williams, 1996).
PERA explicitly takes into account the role of the human in a manufacturing system. In addition, it
does not distinguish between model content views such as function, information, and resource, but rather
between purpose views (information and manufacturing architecture) and implementation views
(human and organizational architecture, information systems architecture, and manufacturing equipment
architecture). The Purdue Methodology offers an enterprise engineering methodology that covers all
phases of a system life cycle. Of the three enterprise reference architectures described in this chapter,
PERA is clearly accompanied by the most extensive methodology. As for modeling languages, PERA offers
only the task module construct. Information system tasks, manufacturing tasks, and human-based tasks

Information Manufacturing
functional functional
network network
Information architecture Manufacturing architecture
Information Human and organizational Manufacturing

systems architecture equipment
architecture architecture
Extent of automation
Extent of automation
of the manufacturing
Human component
Human component
of the information
Humanizability
Humanizability
Automatability
Automatability
architecture
architecture
FIGURE 7.14 Humanizability, automatability, and extent of automation to define the three implementation architectures.
(Source: From Rathwell, G.A. and Williams, T.J., Use of the Purdue Enterprise reference architecture and methodology
in industry (the Fluor Daniel example), in: Proceedings of the IFIP TC5 Working Conference on Models and Method-
ologies for Enterprise Integration, Bernus, P. and Nemes, L., Eds., pp. 12–44, 1996. With permission from Kluwer
Academic/Plenum Publishers.)
are modeled by means of this construct. By combining the various task modules into networks, a type
of data-flow or material and energy flow diagram results. There are no modeling methodologies known.
In addition, no modeling tool is known in literature. Although the only construct is quite simple,
models might become large and, without a tool, their accuracy over time is jeopardized. Earlier, the
developers of PERA had defined a reference model for computer-integrated manufacturing (Williams,
1989). This reference model is restricted to the automatable functions of an enterprise, and all functions that
might require human innovation are considered as external entities. PERA does not provide components of
an integrating infrastructure or any other generic enterprise modules.
GRAI/GIM and PERA provide some solutions to some of CIMOSA’s shortcomings. In particular, they
provide well-defined engineering methodologies: GRAI/GIM offers its structured approach, and PERA is
accompanied by the Purdue Methodology. For enterprise integration, however, it is necessary to keep an
up-to-date picture of an enterprise as time goes by. None of the three reference architectures can guarantee that.
7.7 Baan’s Enterprise Modeler

Recently, some of the concepts of enterprise integration have been implemented in tools for the configuration
and implementation of enterprise resource planning (ERP) solutions. For example, the market leader in
ERP applications, the German company SAP AG, has developed a tool called “Business Engineer.” This
configuration and implementation tool is based on the R/3 reference model. The R/3 reference model
describes business processes that are most commonly needed in practice and that can actually be
implemented with SAP’s R/3 system (Keller and Detering, 1996). Business Engineer aims to streamline
implementation of R/3, and to adapt an existing configuration to new needs or changed circumstances.
It allows users to configure their own enterprise model, and to automatically tie the functionality of R/3
into the enterprise model (SAP, 1997).
In this section, the Enterprise Modeler, which is part of Baan Company’s OrgwareTM tool set, is
described in detail. Baan Company is currently one of the world’s largest suppliers of ERP solutions.
It recognized that enterprises attempting to implement ERP systems went through a serial process
of first modeling the enterprise’s processes and organization, then implementation, and finally manual
configuration of the actual system. The usual result of this static process is that customer investment in

modeling activities has not returned the expected value in the actually implemented system. This is
because the statically defined system is no longer in line with the new needs of the business. Therefore, Baan
Company developed Orgware, a set of tools and concepts that allows an enterprise to adapt its Baan ERP
application real-time to changing market needs. Even more, it supports a fast implementation and
optimization of a system (Huizinga, 1995).
Dynamic Enterprise Modeling (DEM) concepts comprise the foundation of Orgware. Basically, DEM
comes down to developing a model of an enterprise and using this model to adapt the enterprise’s
processes. As such, it does not differ from the objectives of enterprise reference architectures. However,
because Orgware is integrated with Baan’s ERP product, there is a direct link between the models and
their realization in the Baan software.
The Enterprise Modeler is one of Orgware’s main components. Examples of other components are
implementation methods and assisting IT services. A user makes four types of models with the Enterprise
Modeler; namely, business control models, business function models, business process models, and
organization models. In a business function model, a functional decomposition of business functions is
presented. It is the starting point for process selection and configuration. A business process model
describes formal processes and procedures, and is the basis for configuration of Baan software. An
organization model is a description of the organizational structure of an enterprise. The business control
model links the other three models, and it provides modeling teams as a starting point for modeling at
a high level (Boudens, 1997). Figure 7.15 presents an overview of Dynamic Enterprise Modeling with
the Enterprise Modeler.
A central feature of the Enterprise Modeler is its use of reference models. In a repository, functions,
procedures, rules, and roles are defined. The rules connect functions and procedures to each other. From
the components in the repository, reference models are assembled that are specifically designed by
industry consultants for a particular industry sector. For example, in the reference organization model
for engineer-to-order enterprises, an organizational structure is outlined that is based on the best practices
of that type of industry. In the reference business function and process models, optimization relationships
and roles are added respectively (Huizinga, 1995).
Models for a specific enterprise called “project models” can be instantiated from the reference models.
Phases are added to the project function model that provide for a phased implementation of the Baan
system; some functions are, for example, only wanted after optimization of the procedures. Employees
Repository Reference Models Project Model
Rules
................. Baan System
Configuration
.................
.................
Engineer-to-Order
Food Company X
Automotive
FIGURE 7.15 Dynamic Enterprise Modeling with the Enterprise Modeler.

are added in the project organization model. Subsequently, employees are linked to roles, thereby providing
the connection between the process and organization models. Finally, a configurator generates user-
specific menus and authorizations from the project models, and automatically configures the Baan system
by setting parameters.
A clear advantage of Baan’s Orgware product compared to enterprise reference architectures is its
linkage with the underlying Baan ERP applications. Models made by the Enterprise Modeler mirror the
implementation and configuration of the Baan system. Moreover, changes in the models are directly
reflected in changes in the Baan system. Enterprise reference architectures, on the other hand, lack an
integrating infrastructure with business services. Models made by these reference architectures might
reflect the enterprise’s current systems and processes, but changes in these models must be “manually
translated” to changes of the modeled processes and applications.
Orgware’s advantage of being linked with the underlying Baan ERP applications is also its disadvantage:
it covers only Baan products. The Enterprise Modeler allows one to model manual procedures and
applications by vendors other than Baan sessions. Clearly, it cannot automatically configure these other
applications. Although ERP products tend to cover more and more, they do not comprehend the processes
of an entire enterprise. Shop-floor control processes, for example, are not covered. In addition, the
Enterprise Modeler does not model a company’s IT infrastructure. For example, it cannot support distrib-
uted Baan applications. A product such as Orgware is a major improvement in the implementation of
ERP applications and, as such, it provides a contribution to the realization of the enterprise integration
philosophy. For the objectives of enterprise integration to become true, however, more is needed than
that: model execution by an infrastructure with real business and presentation services.
7.8 Summary
Reference architectures for enterprise integration aim to provide the necessary frameworks with which
companies might adapt their operation due to changing internal and external conditions. This chapter has
investigate the practical value of these enterprise reference architectures for the integration of production
systems. Three reference architectures have been studied; namely, CIMOSA, GRAI/GIM, and PERA. Their
overlaps and differences can be identified by means of the GERAM framework. Reference architectures should
at least be accompanied by engineering methodologies, modeling languages, and modeling methodologies. In
addition, modeling tools, reference models, and some generic enterprise modules are desirable components.
CIMOSA strives for the facilitation of continuous enterprise evolution. It intends to offer support for
business integration by means of its modeling framework, and for application integration by means of
its integrating infrastructure. Starting with the reference architecture and possible reference models, a
designer can make a CIMOSA model of its enterprise operations. The CIMOSA integrating infrastructure
processes the released model, so that operations are executed according to the model.
CIMOSA was applied during a reorganization project at Traub AG, a German tool manufacturer. The
modeling framework assisted Traub in the definition of a functional control architecture. Due to immature
specification of the integrating infrastructure, only the specification of the communication services was
helpful to Traub.
The CIMOSA reference architecture does not cover a full life cycle and lacks an accompanying engineering
methodology. However, CIMOSA does provide an eligible, although quite complex, framework for the
specification and analysis of functional architectures for production control systems. It prescribes how
to make a specification of the system, but it does not prescribe how to design the system. In addition, a
designer must personally make the translation from models to a real system. Therefore, CIMOSA should
be merely seen as a framework for the generation of documentation.
GRAI/GIM and PERA provide some solutions to some of CIMOSA’s shortcomings. In particular, they
provide well-defined engineering methodologies. For enterprise integration, however, it is necessary to
keep an up-to-date picture of an enterprise as time goes by, which is something the three reference
architectures cannot guarantee.

A product that ensures up-to-date models of an enterprise is Baan Company’s Enterprise Modeler. Based
on repository and reference models, a designer makes models of its enterprise. Because the Enterprise
Modeler is integrated with the Baan applications, it automatically configures these applications based on the
models. Changes in the models are immediately reflected by changes in the configuration of the applications.
References
Aguiar, Marcos Wilson C., Ian Coutts, and Richard H. Weston. (1994). Model enactment as a basis for
rapid prototyping of manufacturing systems. In Proceedings of the European Workshop on Integrated
Manufacturing Systems Engineering (IMSE ’94), Grenoble, Dec. 1994, 86–96.
Aguiar, Marcos Wilson C., and Richard H. Weston. (1995). A model-driven approach to enterprise
integration. International Journal of Computer Integrated Manufacturing, Vol. 8, No. 3, pp. 210–224.
AMICE Consortium. (1993a). CIMOSA: Open System Architecture for CIM. Springer, Berlin.
AMICE Consortium. (1993b). CIMOSA: Open System Architecture for CIM—Technical Base Line, Version 2.0.
Bernus, Peter, Laszlo Nemes, and Theodore J. Williams. (1996). Architectures for Enterprise Integration.
Chapman & Hall, London.
Black, J.T. (1983). Cellular manufacturing systems reduce setup time, make small lot production economical.
Industrial Engineering, 15(11), 36–48.
Boudens, Gijs. (1997). Eenduidig opstellen van het business control model in de dynamic enterprise modeler.
M.Sc. thesis, Eindhoven University of Technology, Eindhoven (in Dutch).
Chen, D.G. Doumeingts, and L. Pun. (1990). An integrated inventory model based upon GRAI tools.
Engineering Costs and Production Economics, 19, 313–318.
Didic, M.M., F. Couffin, E. Holler, S. Lampérière, F. Neuscheler, J. Rogier, and M. de Vries. (1995). Open
engineering and operational environment for CIMOSA. Computers in Industry; Special Issue on
Validation of CIMOSA, 27(2), 167–178.
Doumeingts, Guy, Bruno Vallespir, Didier Darricau, and Michel Roboam. (1987). Design methodology
for advanced manufacturing systems. Computers in Industry, 9(4), 271–296.
Doumeingts, Guy, David Chen, and François Marcotte. (1992). Concepts, models and methods for the
design of production management systems. Computers in Industry, 19(1), 89–111.
Doumeingts, G., B. Vallespir, and D. Chen. (1995). Methodologies for designing CIM systems: a survey.
Computers in Industry; Special Issue on CIM in the Extended Enterprise, 25, 263–280.
Faure, J.M., A. Bassand, F. Couffin, and S. Lampérière. (1995). Business process engineering with partial
models. Computers in Industry; Special Issue on Validation of CIMOSA, 27(2), 111–122.
Gransier, Theo, and Werner Schönewolf. (1995). Editorial: Validation of CIMOSA. Computers in Industry;
Special Issue on Validation of CIMOSA, 27(2), 95–100.
Huizinga, Jan. (1995). Een gereedschapkist vol software-en businesskennis. Software Magazine, 12(10),
68–71 (in Dutch).
IFAC/IFIP Task Force on Architectures for Enterprise Integration. (1997). GERAM: Generalised Enterprise
Reference Architecture and Methodology. Available to download from http://www.cit.gu.edu.au/
~bernus/taskforce/geram/V1_2.html.
Janusz, Barbara. (1996). Modeling and reorganizing of process chains using CIMOSA. In Proceedings of
the IFIP TC5/WG5.3/WG5.7 International Conference on the Design of Information Infrastructure
Systems for Manufacturing (DIISM ’96), Jan Goossenaerts, Fumihiko Kimura, and Hans Wortmann,
Eds., Chapman & Hall, London, 140–151.
Keller, Gerhard, and Sören Detering. (1996). Process-oriented modeling and analysis of business processes
using the R/3 Reference Model. In Proceedings of the IFIP TC5 Working Conference on Models and
Methodologies for Enterprise Integration, Peter Bernus and Laszlo Nemes, Eds., Chapman & Hall,
London, 69–87.
Lapalus, Etienne, Shu Guei Fang, Christian Rang, and Ronald J. van Gerwen. (1995). Manufacturing
integration. Computers in Industry; Special Issue on Validation of CIMOSA, 27(2), 155–165.

Nell, J.G. (1996). Enterprise representation: an analysis of standards issues. In Proceedings of the IFIP TC5
Working Conference on Models and Methodologies for Enterprise Integration, Peter Bernus and Laszlo
Nemes, Eds., Chapman & Hall, London, 56–68.
Rathwell, Gary A., and Theodore J. Williams. (1996). Use of the Purdue Enterprise Reference Architecture
and Methodology in industry (the Fluor Daniel example). In Proceedings of the IFIP TC5 Working
Conference on Models and Methodologies for Enterprise Integration, Peter Bernus and Laszlo Nemes,
Eds., Chapman & Hall, London, 12–44.
Reithofer, W. (1996). Bottom-up modelling with CIMOSA. In Proceedings of the IFIP TC5/WG5.3/WG5.7
International Conference on the Design of Information Infrastructure Systems for Manufacturing
(DIISM ’96), Jan Goossenaerts, Fumihiko Kimura, and Hans Wortmann, Eds., Chapman & Hall,
London, 128–139.
SAP AG. (1997). R/3 Business Engineer: Knowledge-based, Interactive R/3 Configuration and Continuous
Change Management. Available to download from http://www.sap.com/products/imple/media/pdf/
50014850.pdf.
Schlotz, Claus, and Marcus Röck. (1995). Reorganization of a production department according to the
CIMOSA concepts. Computers in Industry; Special Issue on Validation of CIMOSA, 27(2), 179–189.
Schönewolf, W., C. Rang, W. Schebesta, and M. Röck. (1992). TRAUB/IPK Pilot/Testbed Volume—
Specification Phase. VOICE Report R92073.
Williams, T.J. (on behalf of the CIM Reference Model Committee, Purdue University). (1989). A reference
model for computer integrated manufacturing from the viewpoint of industrial automation. Inter-
national Journal of Computer Integrated Manufacturing; special issue on CIM Architecture, 2(2),
114–127.
Williams, Theodore J. (1994). The Purdue Enterprise Reference Architecture. Computers in Industry;
Special Issue on CIM Architectures, 24(2–3), 141–158.
Williams, T.J., P. Bernus, J. Brosvic, D. Chen, G. Doumeingts, L. Nemes, J.L. Nevins, B. Vallespir, J.
Vlietstra, and D. Zoetekouw. (1994a). Architectures for integrating manufacturing activities and
enterprises. Computers in Industry; Special Issue on CIM Architectures, 24(2–3), 111–139.
Williams, Theodore J., John P. Shewchuk, and Colin L. Moodie. (1994b). The role of CIM architectures
in flexible manufacturing systems. In Computer Control of Flexible Manufacturing Systems, Sanjay
B. Joshi and Jeffrey S. Smith, Eds., Chapman & Hall, London, 1–30.
Wyns, Jo, Hendrik van Brussel, Paul Valckenaers, and Luc Bongaerts. (1996). Workstation architecture
in holonic manufacturing systems. In Proceedings of the 28th CIRP International Seminar on
Manufacturing Systems, Johannesburg, South Africa.
Zelm, Martin, François B. Vernadat, and Kurt Kosanke. (1995). The CIMOSA business modelling process.
Computers in Industry; Special Issue on Validation of CIMOSA, 27(2), 123–142.
Zwegers, A.J.R., S.G. Fang, and H.J. Pels. (1997). Evaluation of Architecture Design with CIMOSA.
Computers in Industry, (to be published).
Zwegers, A.J.R., and T.A.G. Gransier. (1995). Managing re-engineering with the CIMOSA architectural
framework. Computers in Industry, 27(2), 143–153.

Application of Reference Architectures For Enterprise Integration

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application of Reference Architectures For Enterprise Integration

Uploaded by

Copyright:

Available Formats

7

© 2001 by CRC Press LLC

7.2 Enterprise Reference Architectures

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

Implementation Organization View

FIGURE 7.3 CIMOSA modeling framework.

CIMOSA Modeling Framework

CIMOSA Integrating Infrastructure

© 2001 by CRC Press LLC

7.4 Application of CIMOSA at Traub

© 2001 by CRC Press LLC

Cell controller Cell controller

TND 30 /42 TND 30 /42

Terminal NC-machine Terminal NC-machine

FIGURE 7.5 Traub’s production control system before the reorganization.

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

New Consign NC-Program

Cell Tool NC-Program

Manufacturing Tool CIMOSA

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

FIGURE 7.9 Technology architecture of Traub’s testbed.

© 2001 by CRC Press LLC

(0,1) (1,n) Shop Floor (0,n) (1,n)

© 2001 by CRC Press LLC

Token Ring Serial

The Role of CIMOSA in Traub’s Reorganization Process

© 2001 by CRC Press LLC

7.5 The Practical Value of CIMOSA

© 2001 by CRC Press LLC

On the Complexity of the Modeling Framework

On the Novelty of the Model Creation Processes

On the Inadequacy of the Enterprise Engineering Methodology

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

7.6 Two Other Enterprise Reference Architectures

© 2001 by CRC Press LLC

Definition of the domain of the study

Physical Functional Decisional Informational

Physical Functional Decisional Informational

Manufacturing Organization Information

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

Information architecture Manufacturing architecture

Information Human and organizational Manufacturing

7.7 Baan’s Enterprise Modeler

© 2001 by CRC Press LLC

Repository Reference Models Project Model

FIGURE 7.15 Dynamic Enterprise Modeling with the Enterprise Modeler.

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

© 2001 by CRC Press LLC

You might also like