Una plataforma de software para control de procesos en el sector agroindustrial


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Una plataforma de software para control de procesos en el sector agroindustrial

  1. 1. Proceedings of the 3rd Annual SuRP-A05.4IEEE Conference on Automation Science and EngineeringScottsdale, AZ, USA, Sept 22-25, 2007A 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 toincreasing needs of flexibility and adaptability to cope with component management (ICEGrid) allow to cope with thethe changing requirements of the organization and of the requirements of timeliness and accuracy of information thatcustomers. 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 forsector 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. Additionalpossibility 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 promotingsoftware reuse, such as developing a common framework and porting manufacturing, as it is not a standard client/serverexploiting 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 heterogeneityThe aim of this paper is to investigate how mainstream and and, therefore, it cannot be an accidental by-product of theadvanced features of Internet Communications Engine (ICE), software acquisition and integration process but must bean object-oriented distributed middleware can be put at workto 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-orientedagroindustrial manufacturing systems. The effectiveness and middleware can be exploited to meet the requirements ofsuitability for agroindustrial applications are tested by means manufacturing applications in the agroindustrial sector. Thisof a software framework exploiting ICE service. A prototypeapplication 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 localof 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 thechitecture, often client/server based, were acceptable, the needs of flexible and adaptable solutions and asked for anovel challenging business requirements of the modern change in the development process of their manufacturingmanufacturing 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 amanufacturing applications [1]. proposed general framework exploiting ICE specifications Following a trend in modern distributed systems design to meet the requirement of manufacturing applications. Thethese architectures can be built using standard middleware experience collected so far in implementing the frameworksoftware for distributed object computing. Several mid- in a prototype of a real agroindustrial application is reporteddlewares 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 MANUFACTURINGquest Broker Architecture (CORBA) [4] and ZeroC’s Internet INFORMATION SYSTEMSCommunications 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 complexdistributed manufacturing applications. It provides language, following the increase of complexity and dynamicity of newvendor, 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 manufacturingthese applications, since they incorporate legacy or third-part system architectures defines two separated, yet extremelycomponents 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 productionzuppini, fiorini}@metropolis.sci.univr.it activities. In the design of this software layer, developers1-4244-1154-8/07/$25.00 ©2007 IEEE. 164
  2. 2. SuRP-A05.4usually exploit dedicated low-level interfaces, such as the infrastructure, this missing vision of the whole can hamperProfibus/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 ofservices even with variable system load. The manufacturing components-off-the-shelf (COTS) and component-basedinformation 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 developingrange from the configuration of the production process to the a common framework and exploiting COTS, have themanagement of documentations. While extremely connected, potential of drastically reducing development time and costinformation and production control systems pursue different of new manufacturing systems. The successful deploymentobjectives. The first one should be able to manage the large of a COTS based system still requires large efforts toamount of data from the PCS and it should continuously acquire and integrate COTS applications in a meaningfulprovide a high-level representation of the state of the man- architecture able to meet current domain and also to be theufacturing 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 thethe production and satisfy the requests coming from the IS, previously described requirements remain a difficult andwhile 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 onkeep 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. Thethis strategy fails to address the important problem of how following section describes the framework exploiting anto restructure the manufacturing operations to meet the advanced object-oriented distributed middleware to meet thedemand of future operations. An alternative approach is to requirements of manufacturing companies, mainly workingintegrate them as a federated heterogeneous system, where in the agroindustrial sector.the IS system can directly access on the shop floor, whilein turn the PCS can then gain direct access to production III. FRAMEWORKinformation [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 alwaystime has become a strong requirement for the modern man- feasible, due to economic and time constraints. Followingufacturing 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 usingexistence 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 COTSna¨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 developmentsystems. Often the communication between the two systems of complex systems [7]. In this area, several COTS softwareis limited to sharing files encoding the exchanged data or to behaving as a middleware between low-level API and theusing a centralized database, a fairly more advanced solution. user requirements are available. The Internet CommunicationMoreover, distribution of information should also provide a Engine (ICE) middleware [5], developed by ZeroC, has beenservice to handle exceptions. Information about anomalies in recently adopted in an increasing number of projects, sincethe manufacturing process should be immediately reported to it allows integraton of systems built using different softwarethe 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 frameworkthe ever increasing needs of flexibility and adaptability built on top of ICE for the purpose of process control inrequire 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 Engineof 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 theadaptive 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-orientedchanges. 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 areacompanies 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 securityby the small group of early developers. In a rapidly changing solutions make ICE suitable for insecure public networks. 165
  3. 3. SuRP-A05.4While 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 annot advanced users without sacrificing the completeness of ICE object, named elementary object, to allow the interactionthe middleware is something new and definitively not shared with the other ICE components of the system. Together withwith 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, calledpreeminent importance for the framework proposed in this ObjServer, taking care of the management of the overallpaper: 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 createdata 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 theseveral servers, and to provide a simple query service that phase 1: the ObjectServer calls the factoryObject that createsallows clients to obtain proxies for remote objects they are all the ICE objects wrapping the control of the elements ofinterested in. Its main functionality is to locate objects based the production activities. Once that the objects are createdon symbolic information and provide an indirect proxy to a based on a configuration file that will be described in theprotocol address pair for indirect binding. ICEGrid provides following, they subscribe to the ICEStorm service (phasemany other capabilities, such as replication, load balancing, 2.2). Finally, the IS area is connected to the PCS to allowand the possibility to register servers for automatic startup, a direct communication among the objects belonging to thei.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 Controllerservers. Whenever the Publisher (server) changes state, it USERsends a notification to all its Subscribers. Subscribers in turnretrieve the changed data at their discretion. The ICEStorm Profi-busimplementation allows categorizing messages by topic, andSubscribers 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 ODBMSCORBA standard, its architecture is clearer and it is simplerto learn and use. Moreover it supports a large number oflanguages and the Slice interface is smaller, cleaner, and Fig. 1. The new architecture design.more powerful than CORBA IDL. An in-depth analysis ofthe differences between Ice and CORBA and a comparisonof 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 PCSB. 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 communicatework is required to develop a manufacturing application, directly as shown in phase 4 of the diagram in Figure 3. Datawhich is not a standard client/server application. This section exchange among MES, GUI, controller, and the elementarydescribes 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 implementationin manufacturing system architectures (Section II), are also of the distribution of critical data, i.e. information aboutdefined 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 softwarecomponents and their interaction during the initialization and or made visible to the users. It is, indeed, possible to setexecution 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 thescheduling, material planning, and production activities. In elementary objects about anomalies and to clearly identifythe design of this software layer, developers usually exploit the source of the anomaly so to recover in a short time. 166
  4. 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 collaborationrecognize the anomaly and to resume the system, ensuring diagram shown in Figure 2, in the initialization phase thethe maintenance of a safe-critical state during the batch required elementary objects for the control of the planprocess. 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 thetion 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 ofcommunication 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 representedThis result in bottleneck and the impossibility to establish by the objects that are required to be activated on-demandpriority channel of communication for the distribution of through the IceGrid service. Their inclusion in the registry ofanomalies. In the proposed framework the database is no the IceGrid service is, once again, simply a matter of writingmore 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 IceGridrequired 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 overallframework 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, provideefficient 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. 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 Setupremote objects without requiring a direct interaction. of static objects. The setup of a new plan from a set of available elementaryobjects does not require any additional implementation effort COMD0001 TRASP002 BINS0030on the code but only the creation of a new configurationfile that describes the components and their interaction. COMD0020 DIST0003 COMD0001Therefore, the process of expansion, modification, revision of TRASP001an application is not only largely simplified for the designer 0031 0032 0033 STAT0034 BINS0010 0031 0032 0033 BINS0034of the application but can also be quickly learned by new LEVEL_MAXdevelopers. 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 STOC0034to build a prototype for a system proposed by a company BINS0001 GRUPPO 2 TRASP003operating in the agroindustrial sector. The goal was to test the BINS0002 BINS0020suitability 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 STAT0023Figure 4. The developers proposed a three-level description STATCLASS: Object as state-controller for filter. 0021 0022 BINS0023of 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_MEDEach 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_MINline in Fig. 4) is an indivisible unit of a batch process; COMDCLASS: Object that needs a activation command as ligths or hooter. STOC0021 STOC0022 STOC0023its execution allows to achieve a well defined sub-goal ofthe 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 theproduction chain, such as switches, filters, hoppers, ... Aset 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 materialStatClass, static objects; StocClass, storage objects, such as (TRASP001), its storage toward the silo group number 1silos and hoppers, DistClass, distributed objects, distributing (TRASP002), and the storage toward the silo group numberthe material from one source to multiple destination; and, 2 (TRASP003). As previously stated, a Transport is anfinally, ComdClass, objects that need an activation command, indivisible unit of a batch process. Each transport is thensuch as lights or electric sirens. The final concept introduced composed by a set of objects belonging to the classesby the developers is the term Mission, to identify the dynamic previously defined. As an example, Transport TRASP001 168
  6. 6. SuRP-A05.4is composed of a hopper (StocClass), receiving the raw ICE GRID ICE STORMmaterial, an aspirator (BinsClass) located over the hopper and MODEL.XMLconnected to a filter (BinsClass) to remove the dust. Underthe hopper it is located an cochlea (BinsClass) moving the BINS0001 BINS0002material from the hopper to a pipeline, where a compressor TRASP BINS - - - - 001 P(CmdClass) raises the pressure artificially. At the end of R Movimentator OTRASP001, a switch element (BinsClass) moves the material TRASP001.ini TRASP001.automa STAT0001 Feither toward TRASP002 or TRASP003. STAT0002 I B The framework described in the previous section supported Object STAT- - - - U S Server TRASPthe implementation of the software prototype, controlling Mission 002 / Dthis scenario. Frameworks are defined as a form of design TRASP002.ini COMD0001 P COMD0002reuse providing the skeleton of an application than can be TRASP002.automa COMD - - - -customized by application developers [10]. Our framework LEVEL 3 LEVEL 2proposes then a library with immutable parts (frozen spots) LEVEL 1and yet open to the users that can implement code tuned tothe application. This code must be inserted in a few parts Fig. 5. Objects in the production control system as instantiated by theof 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 middlewareServer, provided by the framework, is able to controls mis- has proven well suited for the needs of the manufacturingsion loads, executing all the batch processes, and supervising, firms operating in the agroindustrial sector. In this paper wewithout any change in the code or configuration files. The hot have summarized our experience resulting from developmentspots 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 aavailable 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 ICEthen, usually limited to the conversion of the synoptic of standard services for data distribution and management ofthe plant (Figure 4) in a set of configuration files. These components avoids the need of ad-hoc solutions, which arefiles provide the list of objects to be instantiated and their often error-prone, require significant development effort, andproperties. 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. ACKNOWLEDGMENTSthe 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 kindthe 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 EFERENCESdirectly communicate with the Information System parts andits 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.htmland 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 withsoftware 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