1. Proceedings of the 3rd Annual SuRP-A05.4
IEEE Conference on Automation Science and Engineering
Scottsdale, AZ, USA, Sept 22-25, 2007
A Software Framework for Process Control in the Agroindustrial Sector
Monica Reggiani, Massimo Zuppini, and Paolo Fiorini
Abstract— Recent manufacturing systems introduce an ever approaches to the distribution of data (ICEStorm) and to
increasing needs of flexibility and adaptability to cope with component management (ICEGrid) allow to cope with the
the changing requirements of the organization and of the requirements of timeliness and accuracy of information that
customers. The continuous process of expansion, modification,
revision, testing, and repairing is even exacerbated in small and has become a critical factor in the overall business process.
medium-size firms, such as those operating in the agroindustrial However, a middleware such as ICE is simply a tool for
sector in the Veneto region, where our center of research is connecting objects across heterogeneous processing nodes,
located. The limited number of resources, indeed, prevent the but does not implement an application by itself. Additional
possibility to use part of them for a research activity to setup a work is required to develop a software architecture sup-
more efficient software infrastructure. Approaches promoting
software reuse, such as developing a common framework and porting manufacturing, as it is not a standard client/server
exploiting components-off-the-shelf, could potentially drasti- application. The resulting architecture must be able to sup-
cally reduce the development time and cost. port systems that grow in complexity, size, and heterogeneity
The aim of this paper is to investigate how mainstream and and, therefore, it cannot be an accidental by-product of the
advanced features of Internet Communications Engine (ICE), software acquisition and integration process but must be
an object-oriented distributed middleware can be put at work
to meet the requirements of novel manufacturing applications. carefully crafted.
We show that ICE properties and services can be relied The purpose of this paper is to describe how main-
upon to meet performance and functional requirements of stream and advanced features of a modern object-oriented
agroindustrial manufacturing systems. The effectiveness and middleware can be exploited to meet the requirements of
suitability for agroindustrial applications are tested by means manufacturing applications in the agroindustrial sector. This
of a software framework exploiting ICE service. A prototype
application built based on the framework is described. sector has been chosen for its importance for the industrial
base of the Veneto region, where our center of research is
I. INTRODUCTION located. Most of the local industry is composed of small and
medium-sized firms, often born with characteristics of family
Manufacturing information systems possess a unique set management enterprise, that till now worked mostly at local
of requirements, which are continuously increasing in com- level but that are now experimenting new kinds of collabo-
plexity. While in the past, centralized ad-hoc system ar- rations beside national borders. This process exacerbates the
chitecture, often client/server based, were acceptable, the needs of flexible and adaptable solutions and asked for a
novel challenging business requirements of the modern change in the development process of their manufacturing
manufacturing organizations requires a different approach. solutions.
Component-based development and software reuse are re- The remaining of the paper is organized as follows.
quired to achieve the portability, flexibility, data abstraction, Section 2 describes the requirements of manufacturing ar-
and low development cost which are the goals of modern chitectures for new applications. Section 3 introduces a
manufacturing applications [1]. proposed general framework exploiting ICE specifications
Following a trend in modern distributed systems design to meet the requirement of manufacturing applications. The
these architectures can be built using standard middleware experience collected so far in implementing the framework
software for distributed object computing. Several mid- in a prototype of a real agroindustrial application is reported
dlewares are available, including JavaSoft’s Java Remote in Section 4. Finally, Section 5 concludes the paper.
Method Invocation (Java RMI) [2], Microsoft’s .NET Frame-
work [3], Object Management Group’s Common Object Re- II. REQUIREMENTS OF MANUFACTURING
quest Broker Architecture (CORBA) [4] and ZeroC’s Internet INFORMATION SYSTEMS
Communications Engine (ICE) [5]. We identify ICE as the Manufacturing information systems present special re-
middleware best suited for the development of complex quirements, which are becoming more and more complex
distributed manufacturing applications. It provides language, following the increase of complexity and dynamicity of new
vendor, and operating system independence able to deal with automation applications and the advance of technologies.
the high heterogeneity of hardware and software exhibited by An effectual strategy for the design of manufacturing
these applications, since they incorporate legacy or third-part system architectures defines two separated, yet extremely
components and specialized equipments. Moreover, modern linked, areas: the production control and the information
systems. The manufacturing production control system (PCS)
M. Reggiani, M. Zuppini, and P. Fiorini are with the Department of Com-
puter Science, University of Verona, I-37134 Verona, Italy {reggiani, controls the scheduling, material planning, and production
zuppini, fiorini}@metropolis.sci.univr.it activities. In the design of this software layer, developers
1-4244-1154-8/07/$25.00 ©2007 IEEE. 164

2. SuRP-A05.4
usually exploit dedicated low-level interfaces, such as the infrastructure, this missing vision of the whole can hamper
Profibus/DP network [6], and overestimate the required re- the development of new components by junior developers.
sources to guaranteed operation and preserve performance of These considerations motivate the adoption of
services even with variable system load. The manufacturing components-off-the-shelf (COTS) and component-based
information system (IS) manages information that forms design in developing new manufacturing applications.
the basis of the activities of the PCS. Its responsibilities Approaches promoting software reuse, such as developing
range from the configuration of the production process to the a common framework and exploiting COTS, have the
management of documentations. While extremely connected, potential of drastically reducing development time and cost
information and production control systems pursue different of new manufacturing systems. The successful deployment
objectives. The first one should be able to manage the large of a COTS based system still requires large efforts to
amount of data from the PCS and it should continuously acquire and integrate COTS applications in a meaningful
provide a high-level representation of the state of the man- architecture able to meet current domain and also to be the
ufacturing plan to the users. The second one, instead, must foundation of the future needs of the organization.
correctly interfaces with the low-level machinery to control Developing a suitable system architecture meeting all the
the production and satisfy the requests coming from the IS, previously described requirements remain a difficult and
while continuously producing new data to update the system time-consuming task. In many cases, the expensive devel-
state representation. Most approaches in the past elected to opment of a new application can be avoided relying on
keep these two systems separated but linked, adapting them previous experience or, even better, on a common frame-
to make intersystem communication transparent. However, work from which specific architectures are instantiated. The
this strategy fails to address the important problem of how following section describes the framework exploiting an
to restructure the manufacturing operations to meet the advanced object-oriented distributed middleware to meet the
demand of future operations. An alternative approach is to requirements of manufacturing companies, mainly working
integrate them as a federated heterogeneous system, where in the agroindustrial sector.
the IS system can directly access on the shop floor, while
in turn the PCS can then gain direct access to production III. FRAMEWORK
information [1]. Building a manufacturing architecture from scratch that
Providing appropriate and accurate information at the right meets all the requirements listed in Section II is not always
time has become a strong requirement for the modern man- feasible, due to economic and time constraints. Following
ufacturing systems. Solutions proposed in the past usually a trend in modern distributed system design, open, re-
trap critical data inside the applications. The result is the configurable, and scalable architectures can be built using
existence of islands of duplicate information, inconsistent commercial off the shelf (COTS) components. The object-
data, and difficulties in creating statistics reports. Moreover, oriented (OO) design methodology coming with these COTS
na¨ve solutions have also been proposed for the exchange
ı components provides fundamental concepts such as inheri-
of critical data between the process control and information tance, polymorphism, and hiding, useful in the development
systems. Often the communication between the two systems of complex systems [7]. In this area, several COTS software
is limited to sharing files encoding the exchanged data or to behaving as a middleware between low-level API and the
using a centralized database, a fairly more advanced solution. user requirements are available. The Internet Communication
Moreover, distribution of information should also provide a Engine (ICE) middleware [5], developed by ZeroC, has been
service to handle exceptions. Information about anomalies in recently adopted in an increasing number of projects, since
the manufacturing process should be immediately reported to it allows integraton of systems built using different software
the upper layer to be handle by the software or made visible technologies, programming languages, operating systems,
to the users. and hardware. In this section, after a brief introduction of
While in the past, centralized solutions were acceptable, this middleware, a detailed description of the framework
the ever increasing needs of flexibility and adaptability built on top of ICE for the purpose of process control in
require software applications able to adapt to the changing agroindustrial sector is proposed.
needs of the organization. The difficulty to predict cus-
tomer demand adds additional complexity to the problem A. Internet Communication Engine
of manufacturing. Manufacturing environments must not Internet Communication Engine (ICE) is an object ori-
only be reliable but they must exhibits a highly flexible, ented middleware platform that has been developed by the
adaptive architecture based on software components that can ZeroC group as an alternative to CORBA OMG standard.
be quickly modified and integrated as the production demand ZeroC project aims at providing an efficient object-oriented
changes. middleware platform suitable for heterogeneous environ-
The continuous process of expansion, modification, re- ments and with a full set of features to support the devel-
vision, testing, and repairing is even exacerbated in small opment of realistic distributed applications for a wide area
companies where documentation is often missing or outdated of domains. It also aims at avoiding unnecessary complexity,
and the knowledge about the overall architecture is retained for a platform easy to learn and use. Finally, built-in security
by the small group of early developers. In a rapidly changing solutions make ICE suitable for insecure public networks.
165

3. SuRP-A05.4
While most of ICE aims are shared with other distributed dedicated low-level interfaces, such as the Profibus/DP net-
middleware solutions, the attention to a code suitable for work. Each elements located at this layer is wrapped in an
not advanced users without sacrificing the completeness of ICE object, named elementary object, to allow the interaction
the middleware is something new and definitively not shared with the other ICE components of the system. Together with
with most of the previously proposed solutions. the elementary objects, the framework implementation of
Two services included in the ZeroC middleware are of the PCS layers includes also a more complex object, called
preeminent importance for the framework proposed in this ObjServer, taking care of the management of the overall
paper: ICEGrid, that implements grid computing service to automation process. This component has two fundamental re-
control remote objects, and ICEStorm, to efficiently distribute sponsibilities: to initialize the system at start-up and to create
data within the architecture. The goal of ICEGrid is to sim- all the elementary objects involved in the automated system.
plify the configuration of complex applications containing This is shown in the collaboration diagram of Figure 2 in the
several servers, and to provide a simple query service that phase 1: the ObjectServer calls the factoryObject that creates
allows clients to obtain proxies for remote objects they are all the ICE objects wrapping the control of the elements of
interested in. Its main functionality is to locate objects based the production activities. Once that the objects are created
on symbolic information and provide an indirect proxy to a based on a configuration file that will be described in the
protocol address pair for indirect binding. ICEGrid provides following, they subscribe to the ICEStorm service (phase
many other capabilities, such as replication, load balancing, 2.2). Finally, the IS area is connected to the PCS to allow
and the possibility to register servers for automatic startup, a direct communication among the objects belonging to the
i.e. the server is started on-demand, when the first request IS and PCS area.
for the server is received.
INFORMATION SYSTEM (IS) PROCESS CONTROL
The second ICE service which has been strongly exploited SYSTEM (PCS)
in the framework is ICEStorm, which adopts a Publisher/-
Subscriber communication model [8] to decouple client and
GUI Controller
servers. Whenever the Publisher (server) changes state, it USER
sends a notification to all its Subscribers. Subscribers in turn
retrieve the changed data at their discretion. The ICEStorm Profi-bus
implementation allows categorizing messages by topic, and
Subscribers can specify the topics they are interested in.
MES
We decided to choose ICE instead of CORBA for sev-
eral reasons. While ICE is largely inspired by the OMG’s ODBMS
CORBA standard, its architecture is clearer and it is simpler
to learn and use. Moreover it supports a large number of
languages and the Slice interface is smaller, cleaner, and Fig. 1. The new architecture design.
more powerful than CORBA IDL. An in-depth analysis of
the differences between Ice and CORBA and a comparison
of their performances can found at the web page http: The main assignment of the Information System area is
//www.zeroc.com/iceVsCorba.html. performed by the InterfaceController object. This object
constructs a batch process that will be executed by the PCS
B. Framework Architecture according either to a Management Execution System (MES)
production plan, received from the MES Application objects,
A middleware such as ICE is simply a tool for connecting or on a user request received directly from GUI objects.
objects across heterogeneous processing nodes, but does Once that the objects involved in the batch process are cre-
not implement an application by itself. Indeed, additional ated, ICE objects of both PCS and IS areas can communicate
work is required to develop a manufacturing application, directly as shown in phase 4 of the diagram in Figure 3. Data
which is not a standard client/server application. This section exchange among MES, GUI, controller, and the elementary
describes the proposed general framework for distributed objects in the PCS layer is based on the ICEStorm service,
control process in agroindustrial sectors. that allows distributing the data to the subset of objects which
Figure 1 shows an overview of the proposed framework. previously subscribed their interest.
The two main areas of PCS and IS, which are usually present ICEStorm is particularly valuable in the implementation
in manufacturing system architectures (Section II), are also of the distribution of critical data, i.e. information about
defined in the framework. The collaboration diagrams in anomalies in the manufacturing process that should be imme-
Figure 2 and 3 provide, respectively, a snapshot of the main diately reported the upper layer to be handle by the software
components and their interaction during the initialization and or made visible to the users. It is, indeed, possible to set
execution phases. up dedicated communication channels among the objects.
The Production Control System (PCS) controls the This allows the upper layer to be quickly informed from the
scheduling, material planning, and production activities. In elementary objects about anomalies and to clearly identify
the design of this software layer, developers usually exploit the source of the anomaly so to recover in a short time.
166

4. SuRP-A05.4
config.xml
elaborate 1.1 read()
5.1 < Activate GUI > data 1 < Activate ObjectServer > 1.2 createObject(i)
:MES Application anytime
:objectServer :factoryObject
1 initialize()
{location: Information System} {location: PCS} {location: PCS}
3 End initialization
5.2 Connect() 4.1 Connect 5.2 Connect()
to each 2 activate(obj)
other anytime:
exchange data
publish()
ODBMS i :instanceOfObject
ODBMS 6.3 connect
exchange :interfaceController
data {location: PCS} 2.1 connect
objects
{location: Information System}
5.3 Set(nome_GUI) logging or via profi-bus
update object
4 < Activate InterfaceController >
status 2.3 send(status)
a : Anomaly 6.2 Subscribe()
publisher : IceStorm
{location: PCS}
view01: GUI
2,2 subscribe(itself)
{location: Middleware ICE}
7 < Anomaly Server > 6.4 Ready
{location: Information System} to Use
6.1 < Activate GUI >
Fig. 2. Collaboration Diagram: System Inizialization.
The framework includes an AnomalyServer object able to duced in the framework. With reference to the collaboration
recognize the anomaly and to resume the system, ensuring diagram shown in Figure 2, in the initialization phase the
the maintenance of a safe-critical state during the batch required elementary objects for the control of the plan
process. are created according to the content of an inizialization
The proposed solution for the distribution of the informa- file (config.xml in Figure 2-phase 1). The syntax of the
tion within the application allows to avoid na¨ve solutions for
ı configuration file is available through an XML Schema [9]
the exchange of information between PCS and IS. Often the that defines a set of tags for the description of the list of
communication between such a different layers is still solved elementary objects, together with their main features.
through the exchange of files encoding the information or XML is also used to describe the interaction between mid-
using a centralized database, a fairly more advanced solution. dleware objects and ICE services. An example is represented
This result in bottleneck and the impossibility to establish by the objects that are required to be activated on-demand
priority channel of communication for the distribution of through the IceGrid service. Their inclusion in the registry of
anomalies. In the proposed framework the database is no the IceGrid service is, once again, simply a matter of writing
more a link between the various part of the system, assuming a configuration file (Listing 1).
the improper role of bridge of communication. Instead, it is Listing 1. Configuration of objects activated on-demand by the IceGrid
required only for logging data about material movement as service.
<i c e g r i d>
required by the laws in the agroindustrial sector. <a p p l i c a t i o n name= ” O b j c l a s s ”>
Another problem solved with the use of ICE is the <!− For every s e r v e r t o d e f i n e − >
− −
possibility to let the developers of the different parts of <node name= ” Node1 ”>
<s e r v e r i d = ” BinsServer0001 ”
the manufacturing system to choose the technology they exe= ” . / BinsSrv ” a c t i v a t i o n = ” on−demand ”>
prefer. Different requirements of PCS and IS call for different
<a d a p t e r name= ” BinsAdapter0001 ”
software technologies to optimize time of development while i d = ” BinsAdapter0001 ”
facing with performance issues. But the heterogeneity of the endpoints= ” tcp ”
r e g i s t e r −process= ” t r u e ”>
adopted solutions does not have any impact on the overall
framework as the use of ICE ensures wide possibility of <o b j e c t i d e n t i t y = ” BINS0001 ”
t y p e = ” : : O b j C l a s s : : B i n s C l a s s ” />
interaction, also with third part software. A large number of </ a d a p t e r>
languages, including C++, Java, C♯, Visual Basic, PHP, are
<p r o p e r t y name= ” I d e n t i t y ” v a l u e = ” BINS0001 ” />
supported by the mapping of ICE from Slice interfaces (the <p r o p e r t y name= ” i n d e x ” v a l u e = ” 0001 ” />
ICE Interface Description Language).
</ s e r v e r>
</ node>
C. Framework Configuration
<node name= ” . . . . . ”>
As previously described in Section II there is an increasing ......
</ node>
need of highly flexible, adaptive architecture that can be ....
quickly modified and integrated as the production demand </ a p p l i c a t i o n>
</ i c e g r i d>
changes. The proposed framework must, therefore, provide
efficient solutions for the configuration of new application. Moreover, the use of the property tag in the XML descrip-
Several different point of customization have been intro- tion of the components, allows the ICE platform to provide
167

5. SuRP-A05.4
Exchange Data
3: Elaborate Work to do
to Control
Anomaly Status
:ObjectServer i: instanceOfObject a: Anomaly
3.1 Extend All Comand to Object
3. AnyTime: {location: PCS}
{location: PCS} {location: PCS}
Control
Status
Connection
logging or
ODBMS update object 3.AnyTime:
anytime:
2.1 Extend All status Send or Recive
exchange data
Request
Data
4. publish(status,obj) machinery
:interfaceController 2: elaborate
Profi-bus
Request
3. Periodically:
{location: Information System}
1.4 Response send(status)
1.3 require to user request
something 1.1 bis:
publisher: IceStorm
to do user
4. publish(status,obj)
1.2 : elaborate request
If Anomaly
data change {location: Middleware ICE}
then publish()
3.1 Publish(status, Obj)
MES Application
query refresh data
data
view01: GUI
anytime
{location: Informatin System}
1bis: interact
{location: Information System}
query Actor
data 1.1 change
data
ODBMS
Fig. 3. Collaboration Diagram: System Execution.
information at run-time about the specified properties of the execution of a batch process exploiting the Handling Setup
remote objects without requiring a direct interaction. of static objects.
The setup of a new plan from a set of available elementary
objects does not require any additional implementation effort COMD0001 TRASP002
BINS0030
on the code but only the creation of a new configuration
file that describes the components and their interaction. COMD0020
DIST0003
COMD0001
Therefore, the process of expansion, modification, revision of
TRASP001
an application is not only largely simplified for the designer 0031 0032 0033 STAT0034
BINS0010 0031 0032 0033 BINS0034
of the application but can also be quickly learned by new
LEVEL_MAX
developers.
LEVEL_MAX LEVEL_MAX LEVEL_MAX
STAT0003
BINS0003
LEVEL_MED LEVEL_MED
IV. EXPERIMENTAL ASSESSMENT
LEVEL_MED LEVEL_MED
LEVEL_MAX
LEVEL_MIN LEVEL_MIN LEVEL_MIN LEVEL_MIN
The framework described in Section III has been used
LEVEL_MED
STOC0001
LEVEL_MIN
STOC0031 STOC0032 STOC0033 STOC0034
to build a prototype for a system proposed by a company BINS0001
GRUPPO 2
TRASP003
operating in the agroindustrial sector. The goal was to test the
BINS0002 BINS0020
suitability of the developed framework in real applications. BINS004
GRUPPO 1
DIST0002
The proposed agroindustrial scenario refers to the load- BINSCLASS: Object as filter, choclea,
switch,spirators,conpressor.
ing/unloading of raw material from sack to silo, as shown in 0021
0022
STAT0023
Figure 4. The developers proposed a three-level description STATCLASS: Object as state-controller
for filter.
0021 0022 BINS0023
of the automation process. The first level (red dashed line in STOCCLASS: Object to storage as silo,
LEVEL_MAX LEVEL_MAX LEVEL_MAX
tramoggia.
Fig. 4) defines the concept of the general Handling Setup. LEVEL_MED LEVEL_MED LEVEL_MED
Each handling setup is composed of a set of Transport, the DISTCLASS: Object for distribution that
deflect the material flow
among more destinations.
second level of their abstraction. The Transport (blue dashed LEVEL_MIN LEVEL_MIN LEVEL_MIN
line in Fig. 4) is an indivisible unit of a batch process; COMDCLASS: Object that needs a activation
command as ligths or hooter.
STOC0021 STOC0022 STOC0023
its execution allows to achieve a well defined sub-goal of
the production chain. Each Transport is then composed of Fig. 4. Synoptic for the loading/unloading of raw material from sacks to
silo.
a set of well-define objects, identifying subtasks of the
production chain, such as switches, filters, hoppers, ... A
set of classes is used to classify the objects: BinsClass, The agroindustrial scenario proposed in Figure 4 is com-
bistable objects, such as filters, aspirators, compressors; posed of three Transports: the acceptance of the raw material
StatClass, static objects; StocClass, storage objects, such as (TRASP001), its storage toward the silo group number 1
silos and hoppers, DistClass, distributed objects, distributing (TRASP002), and the storage toward the silo group number
the material from one source to multiple destination; and, 2 (TRASP003). As previously stated, a Transport is an
finally, ComdClass, objects that need an activation command, indivisible unit of a batch process. Each transport is then
such as lights or electric sirens. The final concept introduced composed by a set of objects belonging to the classes
by the developers is the term Mission, to identify the dynamic previously defined. As an example, Transport TRASP001
168

6. SuRP-A05.4
is composed of a hopper (StocClass), receiving the raw ICE GRID ICE STORM
material, an aspirator (BinsClass) located over the hopper and
MODEL.XML
connected to a filter (BinsClass) to remove the dust. Under
the hopper it is located an cochlea (BinsClass) moving the BINS0001
BINS0002
material from the hopper to a pipeline, where a compressor TRASP
BINS - - - -
001 P
(CmdClass) raises the pressure artificially. At the end of R
Movimentator O
TRASP001, a switch element (BinsClass) moves the material TRASP001.ini
TRASP001.automa
STAT0001
F
either toward TRASP002 or TRASP003. STAT0002
I
B
The framework described in the previous section supported Object STAT- - - -
U
S
Server TRASP
the implementation of the software prototype, controlling Mission
002
/
D
this scenario. Frameworks are defined as a form of design TRASP002.ini
COMD0001 P
COMD0002
reuse providing the skeleton of an application than can be TRASP002.automa
COMD - - - -
customized by application developers [10]. Our framework LEVEL 3 LEVEL 2
proposes then a library with immutable parts (frozen spots) LEVEL 1
and yet open to the users that can implement code tuned to
the application. This code must be inserted in a few parts Fig. 5. Objects in the production control system as instantiated by the
of the framework which are left intentionally incomplete by framework.
the framework designers (hot spots).
The frozen spots of our framework is the overall archi-
tecture presented in Section III-B. For example, the Object The ZeroC’s Internet Communications Engine middleware
Server, provided by the framework, is able to controls mis- has proven well suited for the needs of the manufacturing
sion loads, executing all the batch processes, and supervising, firms operating in the agroindustrial sector. In this paper we
without any change in the code or configuration files. The hot have summarized our experience resulting from development
spots of our framework are represented by the development of a software framework and its use on a real application.
of the classes of the three levels, which are often already The results obtained show that exploitation of ICE brings a
available from the development of other systems. number of remarkable advantages, enabling portable, highly
Designer efforts for the development of a new system are, reconfigurable applications. Furthermore, the use of ICE
then, usually limited to the conversion of the synoptic of standard services for data distribution and management of
the plant (Figure 4) in a set of configuration files. These components avoids the need of ad-hoc solutions, which are
files provide the list of objects to be instantiated and their often error-prone, require significant development effort, and
properties. They can also describe object behaviors through prevent portability.
finite state models that will then be executed by the frame-
work. This allows introducing dynamic components during VI. ACKNOWLEDGMENTS
the configuration of the system. We would like to thank Daniele Avesani and Fabio
The configuration phase for the presented testbed results in Beghelli of the Tecnica Electronica company for their kind
the scenario in Figure 5. Once that the factoryObject creates support and the many useful discussions.
the required ICE objects, the Production Control System can
R EFERENCES
directly communicate with the Information System parts and
its components, including MES applications and GUI. [1] G. B. Alleman, “Architecture-centered information systems in
the manufacturing domain,” Niwot Ridge Resources, Tech.
The proposed framework demonstrates its suitability, al- Rep., 2002. [Online]. Available: http://www.niwotridge.com/PDFs/
lowing a simple and fast development of the proposed ArchCenteredDesign.PDF
[2] JavaSoft, “Java Remote Method Invocation Home Page.”
scenario, able to cope with the technological and economical [Online]. Available: http://java.sun.com/javase/technologies/core/
requirements of a real application. basic/rmi/index.jsp
[3] Microsoft, “.NET framework Home Page.” [Online]. Available:
http://msdn.microsoft.com/netframework
V. CONCLUSIONS [4] OMG, “Common Object Request Broker Architecture Home Page.”
[Online]. Available: http://www.corba.org
Manufacturing information systems are becoming more [5] ZeroC, “Internet Communication Engine (ICE) Home Page.” [Online].
and more complex following the increase of complexity Available: http://www.zeroC.com/ice.html
and dynamic of the new automation applications and the [6] Profibus Nutzerorganization e.V. Std., Profibus DP Standard: Trans-
lation of the German National Standard DIN 19245 part 3, 1994.
advanced of technologies. The implementation of the control [7] B. P. Douglass, Doing Hard Time: Developing Real-Time Systems with
software for these systems poses demanding challenges, UML, Objects, Frameworks, and Patterns. Addison-Wesley, 1999.
as they should be dynamically reconfigurable and highly [8] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal,
Pattern-Oriented Software Architecture: A system of patterns. Chich-
scalable to deal with changing needs of the organization ester, England: .John Wiley and Sons, 1996.
and the customer demands. Moreover, providing appropriate [9] D. C. Fallside and P. Walmsley, “XML Schema: Primer,” W3C, Tech.
and accurate information at the right time while ensuring Rep., 2004. [Online]. Available: http://www.w3.org/TR/xmlschema-0/
[10] R. E. Johnson, “Frameworks = (components + patterns),” Communi-
guaranteed performance in the distribution of critical errors cations of the ACM, vol. 40, no. 10, pp. 39–42, 1997.
is also a critical requirement.
169