enterprise', `network of enterprises', or `virtual corpora- ... as nodes in a network of suppliers, customers, engineers, and other specialized service functions.
Journal of Intelligent Manufacturing (1998) 9, 189±199
Towards an architecture for virtual enterprises L . M . C A M A R I N H A - M A T O S , 1 H . A F SA R M A N E SH , 2 C . G A R IT A 2 and C . L I MA 1 1
New University of Lisbon, Faculty of Sciences and Technology, Quinta da Torre, 2825 Monte Caparica, Portugal
2
University of Amsterdam, Kruislaan 403, 1098 SJ Amsterdam, The Netherlands
Received February and accepted October 1997
An approach to the design of an architecture for industrial virtual enterprises (VE), with special emphasis on the identi®cation of main functional requirements, is presented. First, a discussion of the various types of virtual enterprises is provided. Some classi®cation scenarios and discussions of the modelling and reengineering tools and methodologies are described. Due to the importance of the information ¯ows and management in the VE, one section is merely devoted to the analysis of the appropriateness of a federated information management approach. This work is based on and represents the ongoing activities in two European Union funded projects; the Esprit PRODNET II and the INCO-DC SCM+ projects. Ó 1998 Chapman & Hall Keywords: Virtual enterprise, supply chain management, information systems
1. Introduction 1.1. The concept of virtual enterprise The paradigm of virtual enterprise (VE) is a predominant area of research and technological development for today's progressive industries (Browne et al., 1994; Rabelo and Camarinha-Matos, 1996; Walton and Whicker, 1996). The research area is, however, a growing and multidisciplinary one that requires precise de®nition of the concepts and an agreement on the terminology used. So far, there is no uni®ed de®nition for this paradigm and a number of different terms are even competing in the literature that either refer to the same concept or to its dierent perspectives. Among others, the terms `extended enterprise', `supply chain management', `electronic commerce', `cross border enterprise', `network of enterprises', or `virtual corporation', are commonly used. These terms, although not necessarily synonymous, represent related concepts. A set of common characterizing elements can be found in various de®nitions. For instance, for the NIIIP project: `a Virtual Enterprise is a temporary consortium or alliance of companies formed to share costs and skills and exploit fast-changing market opportunities' (NIIIP, 1996). In Byrne, cited in Walton and Whicker (1996) a `Virtual Corporation is a temporary network of independent companies ± suppliers, customers, even rivals ± linked by information technology (IT) to share skills, costs and access 0956-5515
Ó 1998 Chapman & Hall
to one another's markets. It will have neither central oce nor organisation chart. It will have no hierarchy, no vertical integration'. To Walton and Whicker (1996), `the Virtual Enterprise consists of a series of co-operating ``nodes'' of core competence which form into a supply chain in order to address a speci®c opportunity in the market place'. Clearly, there is a tendency to describe a VE as a network of enterprises. The manufacturing process is no longer carried on by a single enterprise, rather every enterprise is just a node that adds some value (a step in the manufacturing chain). In VEs, manufacturers do not produce complete products in isolated facilities. They operate as nodes in a network of suppliers, customers, engineers, and other specialized service functions. VEs materialize by selecting skills and assets from dierent ®rms and synthesizing them into a single business entity. In fact, the establishment of cooperation agreements (links) between enterprises is not something new, but the use of IT to support the information networking is one of the characteristics of the VE concept. The concept of extended enterprise, the closest `rival' term, is better applied to an organization in which a dominant enterprise `extends' its boundaries to all or some of its suppliers, whilst the VE can be seen as a more general concept including other types of organizations, namely a more democratic structure in which the cooperation is peer to peer.
190 1.2. Classi®cation views There is clearly a need to classify dierent perspectives of the paradigm before it can be properly addressed and modelled. In a ®rst attempt in the direction of this classi®cation, a number of characteristics can be identi®ed, among which the duration, geometry, coordination, and purpose are described in this section. 1.2.1. Duration There are alliances made for a single business opportunity and which are dissolved at the end of such process, and long-term alliances that last for an inde®nite number of business processes or for a speci®ed time span. 1.2.2. Topology/geometry Another way of characterizing a VE, with major impact on requirements speci®cation for a supporting infrastructure, is to look for the `geometry' of the network. The most typical case is perhaps the one that shows a variable/ dynamic nature, in which enterprises (non-strategic partners) can dynamically join or leave the alliance according to the phases of the business process or other market factors. But in many sectors there are supply chains with an almost ®xed structure (little variation in terms of suppliers or clients). Another facet related to the `geometry' is the possibility of an enterprise participating simultaneously in various networks or being committed to a single alliance (exclusivity). It is also important to analyse whether the VE operates in a situation of monopoly or under open market conditions. 1.2.3. Coordination In terms of network coordination various models can be found. In some sectors, as typi®ed by the automobile industry, there is a dominant company `surrounded' by a relatively ®xed network of suppliers (star-like structure). The dominant company de®nes `the rules of the game' and imposes its own standards, namely in terms of information exchange. Similar examples can be found in the agribusiness sector. A dierent organization could be found in some supply chains without a dominant company (democratic alliance) in which all nodes cooperate on an equal basis, keeping their autonomy, but joining their core competencies. Once a successful alliance is formed, companies may realize the mutual bene®ts of having some common management of resources and skills and they may tend to create a kind of common coordination structure (federation). There are fewer real-life examples of federated structures (if we exclude the groups of enterprises owned by the same owners), but it will not be surprising if the market dynamics forces SMEs to embark on such deeper coordination alliances.
Camarinha-Matos et al. 1.2.4. Purpose Finally, it is important to understand the purpose or motivation for a company to join a network. Is it to extend its boundaries, keeping control over its vital suppliers (for instance, in terms of quality control) or is it to complement its core competencies in order to be able to share some market opportunities? Is it to be involved in a consistent supply chain, from the raw materials to the end customers, or just to bid for a single opportunity in the market? Is it to increase the geographical presence or to improve the quality and responsiveness to the market opportunities? In terms of linking channels and protocols it is important to notice that most enterprise networking experiences are based on the implantation of EDI (Electronic Data Interchange) for commercial data. Some enterprises are already insisting on the use of EDI as a prerequisite for conducting business with them. A smaller number of cases are motivated by the exchange of technical product data, namely resorting to the STEP standard. For other kinds of information most of the work is still to be done. Also an eort to integrate the various types of information is necessary. 1.3. Projects There are a considerable number of projects, worldwide, trying to de®ne infrastructures and supporting functionalities for VEs. Perhaps the most signi®cant one is the NIIIP (National Industrial Information Infrastructure Protocols) project (NIIIP, 1996) in the USA. This is a 60 million dollar project, involving 18 organizations (companies, research and governmental organizations) which aims to adopt and develop, demonstrate and disseminate the supporting technologies for the industrial virtual enterprise. A large number of results are already available and most of them disclosed for public viewing on the Internet (www.niiip.org). At the European level, after one initial phase characterized by a `fragmented' approach, covering only parts of the ®eld, and too much concentrated on object-oriented infrastructures, there are a number of recent projects addressing more global issues in the framework of the ESPRIT program of the European Union. Examples are the LogSME, the X-CITTIC (a planning and control system for semiconductor virtual enterprise), or the MARVEL OUS. The work described in this paper is partly done in the framework of another Esprit project ± Prodnet II: Production Planning and Management in an Extended Enterprise ± which aims the development of a reference architecture and supporting infrastructure for VEs particularly suited for small and medium-sized enterprises (SMEs) in the area of metalomechanics. The architecture will employ the new emerging standards and advanced technologies in communication, cooperative information management, and distributed decision making. This project
Towards an architecture for virtual enterprises
191
involves partners from Portugal (CSIN, Universidade Nova de Lisboa, ESTEC, Uninova), Netherlands (University of Amsterdam), France (Lichen Informatique), UK (CIMIO) and Brazil (Universidade Federal de Santa Catarina, Fred Jung), including software houses, end-users and research organizations from two continents. Another example of international cooperation, involving partners from the European Union and from Latin America, is the SCM+ (Beyond Supply Chain Management in Food Industry) project sponsored by the INCO Program of the European Union. Part of the activities being carried out in the SCM+ project also contributed to this paper.
2. Architectural aspects 2.1. General requirements As a general requirement for an infrastructure to support VEs, it can be pointed out that the companies must be able to inter-operate and exchange information in real time so that they can work as a single integrated unit, although keeping their independence/autonomy. It also has to be taken into account that legacy systems were not designed with the idea of directly connecting to corresponding systems in other enterprises. Sometimes these systems were developed for the particular needs of those enterprises. The situation is thus one of great heterogeneity and requires adaptation of existing production planning and control systems (PPC) to electronic linking. Typically, enterprises preexist before they decide to join in an information sharing and exchange network. Consequently, every enterprise is autonomous, developed independently of other enterprises and uses distinct information management and control strategies that serve its purposes best. However, for these enterprises to cooperate, on one hand they need to share and exchange a part of their information with the others, and on the other hand every company would like to preserve its local autonomy. Furthermore, distinct enterprises have distinct and often contradictory views and semantics associated with the information they store. To support this environment the PRODNET infrastructure will include two main modules (Fig. 1): (1) Internal module ± represents the autonomous unit of a particular company. It includes the complete structure of the company's information (databases, information systems, etc.) and all the internal decision making processes/ enterprise activities (internal PPC and engineering systems); (2) Cooperation module ± contains all the functionalities for the inter-connection between the company and the whole net. It represents the communication role and works as the interlocutor of the company within the net. As a ®rst
Fig. 1. First approach to the PRODNET infrastructure.
approach, this module functions as a buer of information input/output (represented by EDI, STEP, Public Information, etc. submodules) between the enterprise and the network. Our aim is that `nodes' exchange information, but at the same time, there is a guarantee that existing systems may run independent from the network. Namely, although there will be joint cooperative information exchange within the network, each node can keep its privacy and independence. Nodes in the network can play the role of supplier, producer or a ®nal consumer. Each SME is represented by a node in the network. Every node is extended with a cooperation module to support the information exchange among the nodes. In order to support the information sharing among the nodes, two interfaces must also be de®ned in the cooperation module, a `mapping interface' to connect the internal module to the cooperation module, and a `network infrastructure interface' to connect the cooperation modules of dierent SMEs to the network. Within all cooperation modules, the information will be modelled using a common information model and will be queried and updated using a common language. The main components of the cooperation module are: (1) EDI ± component responsible for the commercial information interchanges;
192 (2) STEP ± component involved with product models interchange, based on the STEP standard; (3) Quality information ± deals with those interactions related to quality issues according to the contractual agreements between the clients and the suppliers, like quality records, inspections, measurements and test plans; (4) Security information ± responsible for the security aspects, access rights, etc. Although a separation is made by `classes' of information for sake of clarity, an integrated approach is to be pursued. Therefore, Fig. 1 does not necessarily represent the ®nal implementation model. In fact, a proposal for a reference architecture to support SMEs-based virtual enterprises will be one of the deliverables of PRODNET-II. (5) Public information ± represents all the information that is important for supporting the cooperation of the enterprises in the network. The public information of the cooperation layer of an enterprise consists of the following three main categories: self-information (local enterprise information); acquaintance information (other enterprise information); joint information (joint workspace for interworking between this enterprise and other enterprises in the network); (6) Mapping interface ± supports the replication of the enterprise information in the cooperation layer and the transformation and translation of information into the common data model and/or standard STEP models in the cooperation layer; (7) Network infrastructure ± infrastructure supports the exchange of information among dierent enterprises, including the retrieval of acquaintance information from other companies. In the case of local modi®cation of joint information, it supports the update of joint information in other enterprises, and the broadcast of information that is of interest to all enterprises in the network, etc. Both Internet and `private' networks (VAN ± Value Added Networks) will be considered. Other functionalities have to be considered in this module, as will be discussed in sections 2.2 and 2.3. The internal module is the private Production Planning and Control (PPC) system together with the other application packages used at each enterprise. Building a system to integrate all manufacturing PPC and engineering support components has been the focus of attention of many research activities during the last years and is outside of the scope of PRODNET-II. Within PRODNET-II, the PPCs of dierent enterprises collaborate only through the node's cooperation modules, where the cooperation module only deals with a part of the PPC information. However, it is anticipated that the production scenario developed for PRODNET-II will have consequences in the internal design of the PPC systems. The `bricked area' inside the internal PPC system in Fig. 1 represents these impacts. For instance, management of incomplete and imprecise orders, a functionality that will be supported by
Camarinha-Matos et al. PRODNET-II, has obvious impacts on many aspects of the PPC systems. The proposed approach will exemplify and represent this situation; namely an existing PPC system (by CSIN) will be used as a testbed to investigate the changes (reengineering) needed to support a virtual enterprise concept. In particular, the impact of accepting incomplete orders will be thoroughly analysed. Anticipating a future evolution towards a `federated coordination architecture' some additional decision-making functionalities will be necessary. The structure shown in Fig. 1 includes only some of the basic functionalities, mainly those related to information exchange. As will be discussed in the following sections, other functionalities can, however, be identi®ed. From a life cycle perspective, two main phases have to be considered in a VE: (1) Creation ± for which some of the major required functionalities are: network de®nition/parametrization, negotiation, join/leave functionalities, de®nition of access rights, sharing level, etc.; (2) Operation ± which requires functionalities such as: basic information exchange and sharing, orders management, incomplete orders processing, distributed and dynamic planning and scheduling, distributed task management, high levels of coordination. 2.2. Basic functionality classes Let us now have a closer look on the basic functionalities required to support an industrial VE. 2.2.1. Information-related functionalities The following aspects have to be considered: (1) Information ¯ows and types ± frequency, amount, actors, who takes the initiative, classes (commercial, technical, quality-related, etc.), broadcast or point to point ¯ows, etc.; (2) Shared information ± catalogues, update and access rights, market information, etc. Interactive electronic catalogues and multimedia-based shopping vehicles are becoming more and more important and are likely to become a fundamental component of a VE infrastructure. As the number of end consumers with access to computer networks increases, besides the members of the network, the access to such catalogues will be granted to an undetermined number of `visitors'/clients (home-initiated electronic transactions), with dierent rights than the VE members. Another example of shared information can be market data. For instance, in the agribusiness sector it is important to have access to worldwide statistics and forecasts on crop production. (3) Electronic trading ± some experiments are already available in terms of using Internet-based `blackboards' for post-product oers/buyers notices. Links between the VE
Towards an architecture for virtual enterprises and such `virtual trading markets' will be necessary. On the other hand, the electronic links also create an opportunity for a much more responsive channel for end-user registration and feedback, service and post-sale support than the traditional mail and phone systems. Some software product vendors are already using these media and it is likely that the same approach will be followed by other (non-software) product vendors. (4) Security ± some of the most obvious problems requiring a solution are: access rights and ®rewalls, privacy and encryption, authentication, validation and auditability. (5) Other information-related services ± browsers, monitoring orders, etc. Fax or other non-electronic media lead to a non-eective monitoring of the orders' status. Delays in order processing, temporary incapacity of a supplier, changes in not-completed orders, the need to readjust delivery times, etc., are some factors that point to the need for a more ¯exible and reliable interchange of information. For instance, a client node might want to know the status of processing of its orders at the supplier's site in order to prevent any diculties for itself. The implementation of a truly just-in-time philosophy requires an infrastructure that supports stronger client±supplier interactions; (6) Formats and protocols ± the extensive use of EDI standards, instead of fax, is becoming a reality for the interchange of commercial documents, like orders. The adoption of STEP for the exchange of electronic product model data throughout the product life cycle is essential for ¯ow of technical data between nodes. For other types of information a standardization eort is necessary. Interoperability between the various standards employed is also a requirement; (7) Demonstration of operation results/network (BP) status. 2.2.2. Materials-related functionalities It is important not to confuse the ¯ow of information across the network with the ¯ow of products and services through the supply chain, although the two aspects might be inter-related. Some required functionalities include: (1) Materials ¯ow management ± identi®cation, representation and monitoring (according to orders ¯ow and status) of all materials ¯ows within the network; (2) Logistics ± transportation, inventory and warehousing planning. This includes route planning, vehicles/ crew assignment, distribution sequencing, etc., i.e. all activities which provoke materials ¯ow between a point of origin and a point of consumption (Pfohl, 1996), including the subsets supply logistics, production logistics, distribution logistics and waste logistics; (3) Forecasting ± the use of electronic links to transmit information from points of sale to production units and suppliers, combined with historic data, will allow the im-
193 plementation of forecasting functions. One early example of such a system can be found in the Toys `R' Us chain (Tapscot and Custon, 1993), which uses EDI to transmit sales information to a selected number of suppliers which might then determine the tendency of sales; (4) Speci®c information ¯ows related to product (bar coding, POS) ± in particular, it is important to understand and coordinate the interactions between materials ¯ows and information ¯ows; (5) Other related services. 2.2.3. Infrastructure-related aspects Although many recent developments on virtual enterprises are privileging Internet-based infrastructures, the architecture should be technology-neutral in order to accommodate other alternatives, like the various VAN options. One of the necessary components is a type of cooperation controller that coordinates the interactions with other nodes in the network. 2.3. Advanced functionalities and requirements Once an eective electronic interlinking infrastructure is established, it is natural to expect a growth in the number and level of associated services. As the process of alliance formation (federation?) is a very competition sensitive one, a step-by-step demonstration approach (and trust building) is the most adequate one. Building con®dence and reliability requires experience of cooperation and a clear demonstration of the existence of bene®ts for all parties. Some early experiments and recent proposals suggest a number of future functional improvements in the VE architectures. Let us consider some examples: (1) Coordination ± a joint coordination of activities and resources for a more global optimization may be an important step towards a federation-style of network coordination. This will include topics such as: work¯ow related services; distributed scheduling; de®nition of roles/assignment of responsibilities; and collaborative engineering (concurrent engineering over the network); (2) Creation/con®guration ± functions to help the formation of a VE, including partner search, decision support tools to help the negotiation process and all the dynamics associated with the joining/leaving of enterprises (de®nition of roles, duties, rights); (3) Characterization by `area' of the network (i.e. position in the value chain) ± the behavioural patterns of subnetworks may vary depending on their position along the value chain. There are `areas' that are relatively stable and share some crucial information (strategic partners in the network) and other `peripheral zones' that are much more volatile and involving lower levels of interaction.
194 (4) Reorganization and training ± tools to support the internal reorganization/business processes (BP), re-engineering and training of people; (5) Con®guration tools ± con®gurability is a must as we may face many dierent organizational structures and not a single VE pro®le. Also, as some levels of trust, based on personal relationships, may dynamically change (reputation), con®guration tools must support this dynamism. Another question is the visibility scope of each enterprise in the network. Should a node be `conscious' of the network or of just the immediate neighbours? Figure 2 tries to organize the identi®ed functionalities by levels. At the bottom level there are the most basic ones. 2.4. PRODNET functionalities Some of the advanced functionalities are strongly dependent on several non-technical factors. For instance, coordination functionalities depend on the level of cooperation and trust achieved or desired by the enterprises. For some other functionalities there are already some tools on the market or solutions are being developed in various projects. This is the case, for instance, for logistics planning, forecasting or collaborative engineering tools. Therefore, and taking into account the available resources, the PRODNET consortium is not addressing all these topics. Instead, a subset of functionalities is being developed. The basic platform includes: (1) Exchange of commercial data (EDIFACT); (2) Exchange of technical product data (STEP);
Camarinha-Matos et al. (3) Order status monitoring; (4) Quality-related information exchange; (5) Common (public) information system supporting, not only administrative information about the VE, but also all the information a node (enterprise) decides to make available to the network; (6) Coordination module that handles all cooperationrelated events (execution of a local work¯ow plan); (7) Con®gurator, allowing the de®nition and parametrization of the VE; (8) Extended PPC system, adapted to interact with a VE environment and including the management of incompletely and imprecisely speci®ed orders (along their life cycle). Additionally, some more experimental modules on advanced coordination functionalities are being developed: (1) DRP (Distributed Resources Planning); (2) Negotiation support system to facilitate partner search and the contractual processes during the formation of a VE; (3) Management of a contracts database; (4) Electronic catalogue and its supporting services.
3. Business process modelling and reengineering 3.1. Understand and evaluate current situation As mentioned before, the starting point for establishing a VE is a set of existing enterprises which might contribute
Fig. 2. Some of the basic and advanced VE supporting functionalities.
Towards an architecture for virtual enterprises with some of their functionalities (core competencies) to the formation of the virtual entity. Current BP structures in such companies were not, in principle, designed to a networked IT-based operation. But the basic business interactions between companies are already in place. Perhaps they are not optimized or adapted to an IT-based linking infrastructure and therefore a reengineering process is necessary, but the basic processes have to be understood and supported. An EDI link to the suppliers can reduce (or eliminate) the need for temporary warehouses/checking buers. Electronic checking procedures based on EDI information can replace the manual checking procedures. There is, therefore, a need to model current BPs (in terms of interactions between companies) and to assess them. Considering a step-by-step implantation approach, this assessment is a necessary phase in order to identify priorities. The establishment of an electronic link can be more easily justi®ed in those cases where highly frequent ¯ows of information can be found (namely to reduce overall delivery times). For instance, the creation of a BP model supported by a software simulation tool represents a practical approach to systems analysis and a very eective
Places p1: Initial conditions for the farmer p2: Production enabling p3: Tomatoes ready to be cropped p4: Total tomato volume to produce p5: Tomatoes cropped ready to be shipped p6: Oer from the farmer p7: Order for one 25-ton tomato trailer delivered to the farmer p8: A 25-ton tomato trailer is sent from the farmer to the factory p9: Tomato trailers in queue at the factory p10: Tomatoes in stock at the farmer's, ready for shipping to the factory p11: The factory produces 50 000 tons of tomatoes p12: Quantity of tomatoes to be processed p13: Farmer's oer is received at the factory p14: Monitoring of tomato orders Fig. 3. Petri net model of a BP.
195 medium for `convincing' the enterprise managers about the need to change some processes. Figure 3 illustrates a partial BP model in the agribusiness sector (tomato industry). The use of this model in combination with a simulation tool as presented in Camarinha-Matos et al. (1997) provides a way to assess system performance. 3.2. Reengineering towards a VE Although there is a lot of interest in VEs, there are no established methodologies and tools for their implementation. Similarly there is no common reference architecture that could lead the development (instantiation) process. Most of the worldwide eorts are still concentrating on the dicult task of producing a reference architecture for a single enterprise, as in the case of CIM-OSA and GERAM (Williams et al., 1994). Even in terms of case studies there are not enough examples in order to have general models. Various international running projects are applying and evaluating various tools and methodologies borrowed from other areas, namely from computer integrated manufacturing, BP reengineering, and software engineering.
Transitions t1: Enabling for start of production t2: The farmer produces 25 tons of tomatoes t3: 25 tons of tomatoes are cropped t4: A 25-ton tomato trailer is sent to the factory t5: The farmer tells the factory that he has available 25 tons of tomatoes t6: Trailer arrives at the factory t7: Trailer is unloaded in the factory's warehouse t8: 25 tons of tomato are processed t9: The factory approves and places an order for this oer of 25 tons of tomatoes PN initial marking K1: 100-trailer unit K2: 2000-trailer unit
196 Namely, in terms of process modelling, various approaches are being pursued. Some of them emphasize the structural aspects, like IDEF0 or CIM-OSA BP/EA. Others concentrate on the dynamics, such as the various Petri-net-based approaches or the rule-based systems, as in some work¯ow systems. For instance, in the SCM+ project an attempt to combine structural models with dynamic models is being explored. First experiments based on Petri nets have shown that this can be a convenient tool to describe the dynamics of a supply chain and to test changes in the processes (and evaluate their impact), either by simulation or by analytical methods. It is, however, necessary to follow a top-down modelling approach (supported by hierarchical representations) in order to use this tool as a means of communication between humans. Another diculty is that classical Petri nets (or even timed Petri nets) are not adequate to handle variable geometry networks. For instance, the subnet corresponding to the farmer in Fig. 3 could be repeated for representing all farmers that are suppliers of the factory. But the number of suppliers can change dynamically. This situation can be accepted when modelling the alliances between strategic partners (long-term alliances), but it is dicult to model the volatile nodes. One possibility to handle this situation is to employ coloured Petri nets. The farmer subnet in Fig. 3 could represent all farmers and the coloured tokens would represent the individual farmers. 4. Information management 4.1. Management of information in a VE From the information management point of view, the problem of designing the necessary architecture to allow the proper ¯ow of data and control information across the virtual enterprise network, is challenging. The information management system will have to provide a high degree of interaction between physically distributed nodes. Figure 4 describes the general structure of the enterprise network in terms of information management nodes. As a ®rst step towards the ®nal design, two kinds of nodes can be de®ned. 4.1.1. Network coordinator The network coordinator will be the regulatory component of the enterprise network. The coordinator is either one speci®c node in the network, or its role can be played by another existing node(s) in the network. Among other things, the network coordinator will be responsible for the following tasks: (1) Registering new enterprises in the network; (2) Giving assistance to the new enterprise to install the cooperation layer;
Camarinha-Matos et al.
Fig. 4. Network of enterprises (not all ¯ows are represented).
(3) Maintaining the network directory information; (4) Generating news about the network con®guration; (5) Possibly serving as a `witness' for those enterprises which want to have a third-partner support in a negotiation with other enterprises. This coordination role is meant from the point of view of the management of the informatics infrastructure. This does not necessarily coincide with a dominant node or a node that is `responsible' for the products/services for the customers. 4.1.2. Member enterprise Every enterprise in the network will have its corresponding member enterprise node which will store the information about the enterprise itself, and provide the external connectivity. Some of its functions are: (1) Managing the self, acquaintance, and joint information (2) Establishing contact and interaction with other nodes (3) Handling the ®rst contact made by a costumer (user) (4) Share and exchange the information required in the production scheduling for a particular order with other member nodes. As mentioned in section 1.2, there exist dierent ways in which the enterprises can interact between themselves. In the simplest case, the interaction is only one-to-one between two enterprises (client±supplier). But it is also possible to have a `star' relationship where one enterprise expects products from dierent enterprises to accomplish
Towards an architecture for virtual enterprises an order, or a `pipeline' where an enterprise generates a product which serves as input to another one, and so forth. Also, as mentioned in section 2.2, there are some security issues which must be addressed. For example, the local information about an enterprise must be private. But some information is needed to be shared with the entire network, such as the enterprise self-description, or it is needed to be sent to a speci®c group of enterprises, like a product request. To increase the level of security, every node will be augmented by a `security component' which will provide the necessary ®re-wall protection. Even more, the information about the schemas can be exchanged using a de facto standard data encryption facility. Here, the `public-key' encryption algorithms can be in particular an interesting option to consider. 4.2. Information modelling approach In order to support several important information management requirements of the VEs, we use as the base a federated architecture that provides both for the data exchange and for the cooperation on joint missions. These two requirements are already addressed in section 2.1, as operational functionalities in a VE's life cycle. Namely, for data exchange we use the importation/exportation of schemas (described below) and for cooperation on joint missions, e.g. a VE order ful®lment, we employ the self, acquaintance and joint workspace exchange of information, as described in section 2.1. As a consequence, the information management system must be able to allow a high level of interaction between nodes, where the information is constantly changing due to the dierent levels of dependencies among the production chains of the enterprises. To accomplish these tasks, a federated architecture can be de®ned along the network. This architecture supports the sharing and exchange of information among cooperating autonomous and heterogeneous nodes. An example of an object-oriented federated/distributed database system is the PEER system (Afsarmanesh et al., 1993; Tuijnman and Afsarmanesh, 1993; Wiedijk et al., 1996). PEER is a federated object-oriented information management system that primarily supports the sharing and exchange of information among cooperating autonomous and heterogeneous nodes. The PEER federated architecture consists of a network of tightly/loosely inter-related nodes. Both the information and the control are distributed within the network. The interdependencies between two nodes' information are established through the schemas de®ned on their information; thus there is no need to store the data redundantly in dierent nodes. Every node is represented by several schemas (see Fig. 5): a local schema, several import schemas, several
197
Fig. 5. PEER schemas representation.
export schemas and an integrated schema (Afsarmanesh et al., 1993). The local schema is the schema that models the data stored locally. The various import schemas model the information that is accessible from other databases. An export schema models some information that a database wishes to make accessible to other nodes (usually, a node de®nes several export schemas). The integrated schema presents a coherent view on all accessible local and remote information. The integrated schema can de®ne a particular classi®cation of objects which are classi®ed dierently by the schemas in other nodes. The local schema is the private schema de®ned on the physical data in a node. Derived from the local schema there are export schemas, each one de®ning a particular view on some local objects. Export schemas restructure and represent several related concepts in one schema. For every export schema, the exporter node manages the information on nodes who can access it, by keeping their node-id, their access rights on the exported information, and the agreed schema modi®cation conditions to notify the nodes who use this export schema of its changes. To obtain access to data in another node's export schema, a node has to input it as import schema. An import schema in one node is an export schema in another node. Originally, a node's integrated schema is derived from its local schema and various import schemas. In later stages of integration, instead of the local schema, the previous integrated schema will be used as a base. At the level of the integrated schema, the physical distribution of information becomes hidden, and the contributing nodes are no longer directly visible to the end user. Dierent nodes can establish dierent correspondences between their own schema and other nodes' schemas, and thus there is no single global schema for the network. The functionality of the PEER federated system is supported by the speci®c architecture of each PEER node and its PEER-kernel, and by the existence of the community dictionary in the network. The community dictionary is the
198 `source of information' within the network and can be consulted at any time by other nodes. Its function is to provide up-to-date information on all the nodes in the network. It contains the network addresses of the active nodes and their current state. For every node, it also stores its export schemas and the speci®c access rights and schema modi®cation rights that the node supports. The dictionary can also be used as the general store for other static information that concerns the entire community such as the objects' name-tables. Although, in the architectural design of PEER, the community dictionary is represented as a separate node to be accessed when needed, any other node in the community can keep local copies of all or parts of its information. To this federated architecture, some extensions can be added to support a real co-working environment where the remote object references are handled together with the local objects (Afsarmanesh et al., 1995; Wiedijk et al., 1996). To de®ne the interrelations among the local and remote objects, the local schema needs to be extended. An extended local schema extends the local schema by a speci®c type called extended local type. Extended local types are derived from a type de®ned in an import schema and support the interrelation of speci®c local objects through a remote reference to objects accessible from other nodes. The remote reference is a mapping (attribute) de®ned on a local type (as its domain) and an extended local type, corresponding to a remote type, as its range. Actually, instances of an extended local type are object-identi®ers of the remote objects that are stored locally at the node as references to the real remote objects. In general, the schemas for a node are de®ned using the PEER Schema De®nition and Derivation Language (SDDL) (Afsarmanesh et al., 1993). SDDL includes facilities for de®ning schemas, types, and maps, and for specifying the derivation among a derived schema and a number of base schemas using a set of type and map derivation primitives. An integrated type is constructed from other types de®ned in dierent nodes by the union, restrict, and subtract primitives. Map integration is accomplished by specifying a map as either a union of other maps, or as a threaded map, or some combination of these two primitives. 4.3. Supporting the VE requirements The described modelling approach provides the base for an eective information sharing and cooperation among different enterprises (nodes in the network), to support many features, of which the following can be emphasized: (1) objects stored by a node can be shared with other nodes; (2) it is possible to access the remote objects shared by other nodes; (3) objects stored locally can be related to the remote objects shared by other nodes; and (4) the physical and logical information distribution among the nodes is transparent.
Camarinha-Matos et al. This model can provide many of the required features to model the dynamic relationships between the members of a VE, including many of the points addressed in section 2.2.1 under the classi®cation of the shared information, and other information related services. In this way: (1) Through the network coordinator, an enterprise can read speci®c information (like the self-information and product requests) of other enterprises, and the information of general interest to all nodes, e.g. the market information; (2) Through its export schemas an enterprise can determine which other enterprises are allowed to access and/ or update a speci®c subset of its local information; (3) Through the remote referencing and extended local schemas, the local schedule of an enterprise can establish references to an oer submitted by one or more dierent enterprises, therefore representing the joint work; (4) Through the importation of export schemas, the joint and share information is read on-line and always re¯ects the current state; (5) No redundant information is needed to be maintained in the network; (6) Through the schema integration it is possible to de®ne a joint co-working space where the enterprises can negotiate the products and/or services contracts, monitor the progress of an order along the network, modify and readjust the incomplete order information (e.g. the delivery date), and coordinate tasks with other enterprises in a value-added chain. Furthermore, the mapping interfaces (described in section 2.1) are clearly supported by this modelling mechanism; (7) The dierent types of schemas are suitable to share and exchange the information maintaining the basic necessary level of security access. Thus, for every node in the domain of the enterprises network, the self-information would be stored in the export schema to allow the rest of the network to access it, the private information would be located in the local schema to guarantee its con®dentiality, the acquaintance information can be composed by a set of imported schemas, and the joint information might be modelled as an integrated schema. As mentioned before in section 4.1, the security can be enhanced with other mechanisms. It should be noted that we are discussing the cooperation layer and, therefore, these schemas have to be understood in this context. The private information of the companies remains in its internal PPC system; (8) Through the federated dictionary, the network coordinator collectively represents the self information and the current product/services request information, that will be accessed by other nodes and will be imported as their acquaintance and current request information. Clearly, the federated architecture is a strong base approach. However, in order to eectively support the cooperation of enterprises and the dynamic generation and cease of the VEs, it is necessary to further extend the fed-
Towards an architecture for virtual enterprises erated architecture with other features, such as an on-line message passing mechanism between the nodes, to facilitate the dynamic and non-synchronic interactions. For example, this is needed to support the dynamic importation/ integration of schemas with the updates and new information. In this direction, other state-of-the-art technologies will be considered and evaluated. Standards and architectures like OMG and CORBA, as tools to support the integration of information from dierent sources in distributed heterogeneous environments, are promising approaches. This mechanism has to integrate various standards (EDIFACT, STEP, etc.). Similarly, the need for data warehousing as a centralized integrated source of information for the VE must be investigated. One possible application requirement that can bene®t from data warehousing is the integrated catalogue for all the products/services that can be oered through the network.
5. Conclusions A preliminary framework/approach for the characterization of virtual enterprises was presented and an identi®cation of some required supporting functionalities was made. A platform supporting some of the identi®ed requirements is being developed in the framework of the Esprit PRODNET II project. This project focuses the speci®c needs of SMEs in the metalomechanics sector. Another project mentioned in this work is the INCO-DC SCM+, which addresses the supply chain management in the agribusiness/food industry sector. It is the authors' belief that an eort to synthesize the contributions from these and many other worldwide experiences being carried on is necessary in order to achieve a ¯exible architecture for VE. Although recent technological developments, specially in the area of computer networks, make us believe this area will have an explosive growth, there are still many open questions, some of them of a non-technological nature. For instance, the legal barriers and the need for reorganizational changes implying retraining of people and new role assignment (new power structures!) take time to implement and require a very careful approach. On the other hand, the development of advanced internetwork coordination mechanisms and safety procedures has to be accompanied by trust building actions, an area whose exact evolutionary shape is hard to anticipate at current stage. These uncertainty factors recommend a stepby-step approach instead of an ambitious general infrastructure development approach as followed by some projects. The adoption of standards (EDIFACT, STEP, etc.) is a mandatory process but an eort for achieving the interoperability between these standards is still necessary.
199 Acknowledgements The authors acknowledge partial funding from the European Commission (PRODNET II and SCM+ projects) as well as the contributions from all partners of the mentioned projects. Celson Lima also acknowledges the support from the Brazilian CNPq organization. References Afsarmanesh, H., Tuijnman, F., Wiedijk, M. and Hertzberger, L. O. (1993) Distributed schema management in a cooperation network of autonomous agents, in Proceedings of the 4th International Conference on Database and Expert Systems Applications (DEXA'93), Lecture Notes in Computer Science 720, Springer-Verlag, pp. 565±576. Afsarmanesh, H., Wiedijk, M., Hertzeberger, L. O., Negreiros Gomes, F., Provedel, A., Martins, R. C. and Salles, E. O. T. (1995) A federated cooperation architecture for expert systems involved in layout optimization, in Balanced Automation Systems, Camarinha-Matos, L. M. and Afsarmanesh, H. (eds), Chapman & Hall. Browne, J., Sackett, P. J. and Wortmann, J. C. (1994) The system of manufacturing: a prospective study, report to the DG XII of the CEC. Camarinha-Matos, L. M., Carelli, R., Pellicer, J. and Martin, M. (1997) Towards the virtual enterprise in the food industry. Submitted to ISIP'97 ± OE/IEEE/IFIP International Conference on Integrated and Sustainable Industrial Production, Lisboa, May. NIIIP (1996) The NIIIP Reference Architecture. www.niiip.org. Pfohl, H.-C. (1996) Logistics. State of the art, in Proceedings of the Esprit±Copernicus Symposium on Quality, Logistics and Technology Management, Budapest, Hungary, 9±10 September. Rabelo, R. and Camarinha-Matos, L. M. (1996) Towards agile scheduling in extended enterprise, in Balanced Automation Systems II, Camarinha-Matos, L. M. and Afsarmanesh, H. (eds), Chapman & Hall. Tapscot, D. and Custon, A. (1993) Paradigm Shift, McGraw-Hill. Tuijnman, F. and Afsarmanesh, H. (1993) Management of shared data in federated cooperative PEER environment. International Journal of Intelligent and Cooperative Information Systems, 2(4), 451±473. Walton, J. and Whicker, L. (1996) Virtual enterprise: myth and reality. Journal of Control, 22±25. Wiedijk, M., Afsarmanesh, H. and Hertzberger, L. O. (1996) Coworking and management of federated information-clusters, in Proceedings of the 7th International Conference on Database and Expert Systems (DEXA'96). Lecture Notes in Computer Science 1134, Springer-Verlag, pp. 446±455. Williams, T. J., Bernus, P., Brosvic, J., Chen, D., Doumeingts, G., Nemes, L., Nevins, J. L., Vallespir, B., Vlietstra, J., and Zoetekouw, D. (1994) Architectures for integrating manufacturing activities and enterprises. Computers in Industry, 24 (2±3), 11±139.
