Professional Documents
Culture Documents
The PRODNET Platform For Production Planning and Management in Virtual Enterprises
The PRODNET Platform For Production Planning and Management in Virtual Enterprises
The PRODNET Platform For Production Planning and Management in Virtual Enterprises
net/publication/264346992
CITATIONS READS
28 125
3 authors, including:
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Luis Camarinha-Matos on 02 September 2014.
ABSTRACT
The concept of virtual enterprise, as a temporary alliance of enterprises that come
together to share skills and resources in order to better respond to business
opportunities and whose cooperation is supported by computer networks, challenges
the way industrial production systems are planned and managed. The
materialization of this paradigm, although enabled by recent developments in
communication technologies and computer networks, requires the definition of a
reference architecture and the design and development of a supporting platform and
appropriate protocols and mechanisms. This paper describes the current approach
being developed by the Esprit project PRODNET II, which aims to design and
develop an open platform to support industrial virtual enterprises with special focus
on the needs of small and medium enterprises (SMEs). One of the main components
of this platform is the Cooperation Layer that contains all functionalities and support
information for the interconnection between a company and its partners in the virtual
enterprise. A detailed description of this system is presented, including the
management of interactions based on standardized information (EDI, STEP),
workflow management, communications infrastructure and safety aspects. The re-
engineering needs for a PPC system to be integrated in this environment are also
discussed. Finally some advanced coordination functionalities are proposed.
INTRODUCTION
The materialization of the paradigm of virtual enterprise (VE), although enabled by
recent developments in communication technologies and computer networks,
requires the definition of a reference architecture and the design and development of
a supporting platform and appropriate protocols and mechanisms. This paper
describes the current approach being developed by the Esprit project PRODNET II1,
which aims to design and develop an open platform to support industrial virtual
enterprises with special focus on the needs of small and medium enterprises
(SMEs).
1
This research is partially supported by the ESPRIT project 22647, PRODNET II of the European Commission.
This project involves the following partners: CSIN (PT), New University of Lisbon (PT), University of
Amsterdam (NL), ESTEC (PT), Uninova (PT), Lichen Informatique (FR), CIMIO (UK), Federal University of
Santa Catarina (BR) and Fred Jung (BR).
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97
Duration. Some enterprise alliances are made for a single business opportunity and
are dissolved at the end of such process. This situation corresponds perhaps to the
most typical kind of virtual enterprise for which examples can be found in large scale
engineering systems, such as, for instance, consortia involved in building a bridge.
But there are also long term alliances that last for an indefinite number of business
processes or for a specified time span. In most cases of supply chains in food
industry or in the automotive industry it is more typical to find long term alliances.
Topology. According to the topology of the network, there are situations that show a
variable / dynamic nature, in which some 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 fixed 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).
Coordination. In terms of network coordination various models can be found. In
some sectors, as typified by the automobile industry, there is a dominant company
"surrounded" by a relatively fixed network of suppliers (star-like structure). The
dominant company defines "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. The concept of extended enterprise can be used to describe
this particular case. A different 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 benefits of having
some common management of resources and skills and they may tend to create a
kind of common coordination structure (federation). There are less real life
examples of federated structures, except in the cases of groups owned by the same
holding, but it will not be surprising if the market dynamics forces SMEs to embark in
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97
such deeper coordination alliances. Examples of this tendency can already be found
in the small retailers sector as a reaction to the large hypermarket chains.
Visibility scope. Both related to topology and coordination is the aspect of visibility
scope, i.e., “how far”, along the network, can one node “see”. In many cases a node
only sees its direct neighbors (suppliers, clients). That is the case of most supply
chains. In more advanced coordination situations, a node might have some visibility
over other (non direct) levels.
In order to design a supporting platform for VEs it is necessary to understand the
business processes involved, i.e., how enterprises interact nowadays, which are the
main information flows, time constraints and coordination actions. It is therefore
necessary to establish a kind of reference framework. As presented above, the forms
of organization and coordination of alliances of enterprises is quite diverse,
depending on the type of VE, and subject to a dynamic evolution, depending on the
market evolution and trust building processes. The PRODNET approach is to start
with a platform that supports the basic interaction requirements for networks of
SMEs in the metalomechanics sector and, at the same time, evaluate some more
advanced coordination policies.
GENERAL ARCHITECTURE
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. Typically, enterprises pre-exist 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 serves its purposes best. The
situation is thus one of great heterogeneity and requiring adaptation of existing
production planning and control systems (PPC) to electronic linking. It shall be
noted that a complete redesign of a PPC system would represent a tremendous
effort, not justifiable in market terms as companies wouldn’t easily replace their
running systems. Therefore, a better strategy is to try to separate the internal
functionalities from the network-related ones and develop the necessary mappings
to legacy systems.
Cooperation
Layer
Internal
Module
To support this environment the basic PRODNET infrastructure considers two main
modules: Internal Module and Cooperation Layer (figure 1). The Internal Module
represents the autonomous unit of a particular company. It includes the complete
structure of the company's information (data bases, information systems, etc.) and all
the internal decision making processes / enterprise activities (internal PPC and
engineering systems). The Cooperation Layer contains all the functionalities for the
inter-connection between the company and the whole net. It represents the
communication and coordination role and works as the interlocutor of the company
within the net.
Required functionalities
A number of functional requirements to support the creation and operation of a VE
have been identified in [Camarinha97a] and [Afsarmanesh97]. Examples of such
functionalities are:
• Basic information handling functionalities:
-Exchange of business related (e.g. orders) and technical information
(e.g. product models, quality reports).
-Sharing of information: catalogues, market information, company profiles,
etc.
-Broadcasting information: call for tenders, news, etc.
-Safety and authentication of exchanged information.
-Browsing (e.g. order status) and notification mechanisms.
-Handling of standards (EDIFACT, STEP).
• Materials related functionalities:
-Logistics.
-Materials flow management.
-Forecasting.
-Handling of information specific to materials flows (e.g. bar codes).
• Creation and configuration functionalities:
-Partners search and selection.
-Negotiation and contracts management.
-Roles and responsibilities assignment.
-Workflow definition.
• New emerging services:
-Support to Electronic Commerce: electronic catalogues, “active” marketing
tools,
secure payment mechanisms, etc.
-Directories of products / services suppliers.
-Specialized advice services.
• Coordination functionalities:
-Local coordination (workflow support at each node).
-Global VE coordination: distributed resources management, distributed
scheduling, etc.
-Collaborative Engineering.
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97
Advanced PCL
Coordination STEP Module
User Configur.
Functionalities Interface Module
EDI Module
PPC SYSTEM
From the internal module side of a VE node, the Production Planning and Control
System is the most important component regarding the interactions with the outside
world. As mentioned above, it is out of scope of PRODNET to design a completely
new PPC system particularly suited for operation under a VE environment. But it is
also foreseeable that legacy PPC systems need some adaptations in order to
properly interact with the PCL. The approach followed by PRODNET is, therefore, to
start with a legacy PPC system (by CSIN) and proceed to its reengineering towards
a smooth integration within the proposed architecture.
This PPC system was designed for the context of SMEs and includes the following
main functionalities: i) Industrial Logistics Management: Orders flow management,
Product data management, Sales Forecasts handling, Actual Requirements
Planning; ii) Master Production Scheduling; iii) Production Control; iv) Quality
Control / Tracking; v) Industrial Costing.
According to a preliminary analysis major re-engineering or adaptation is necessary
in the areas of orders management and quality information management. Other
changes will depend on the level of global (advanced) coordination achieved in the
VE.
attributes. New “orders” (or messages) are supposed to arrive in the future
complementing the missing attributes in the “original” order (these orders are not
really new orders but additions to the original one). Thus they should be associated
to the original one (logically merged). This process continues until all details about
the required product are specified. An imprecise order is an order in which the value
of some attribute is not missing but it is specified in a vague way. For instance, in the
car example, the attribute color, in the initial specification, could say “dark color” or
“one of blue, black, green”. Only later on this attribute would get a specific (precise)
value. Another example of vagueness could be on the quantity. An order could
specify a tentative amount of between 100 and 120 units (to be confirmed later).
A selection of a subset of EDIFACT messages and the identification of any eventual
need for their extension towards the handling of incomplete and imprecise orders is
being carried out by LICHEN Informatique.
Besides the exchange of the order itself, using an EDI standard, the order has to be
followed up in order to cope with, for example, delays in orders processing,
temporary incapacity of a supplier, changes in not completed orders, the need to re-
adjust delivery times, and so on. A client node might even want to know details about
the manufacturing state of the ordered products in order to prevent any difficulties for
itself. This requires an infrastructure that supports a stronger clients - suppliers
interaction. To support this, besides the identification of the adequate subset of
EDIFACT messages and their implementation in the EDI module, it is necessary to
adapt the PPC system to supply / consume all information handled by those
messages.
Quality information management. The extended PPC system will include
functionalities to manage the basic information needs for a standard (ISO 9000)
quality system (inside the company). At network level, the situation is more
ambiguous as there is no standard yet. Nevertheless, new legislation regarding
responsibilities for components included in a product will provoke an increasing
demand for such information to be exchanged at network level.
In the absence of standard definition of the contents and structure of quality related
information to be exchanged between nodes in the VE, the following principles are
proposed:
-The report will have a free format [to be agreed between interacting nodes].
-Two levels of reports are foreseen:
-One related to the value added by the particular enterprise
Examples of information: Who has supplied the raw materials / components;
Quality certification information; Identification of production batch, production
history; Rejected parts in this production batch; Other production statistics; etc..
-Another level with "tracing" information related to components used by the
enterprise but supplied by other nodes.
-The access to quality information will be on request only. It doesn't make sense to
have this information stored on DIMS: it might be a huge amount; it can even be
stored on historical backups (not on-line).
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97
LOCAL COORDINATION
Since the PCL is composed by several modules working as a single unit, there is a
need for a coordination function among these modules. Moreover, within a VE
environment, a company has to deal with several types of events / messages (client
orders, partners requests, unexpected events, etc.). It is also mandatory to preserve
the company’s privacy and autonomy within the VE, which means that each company
must be able to configure the PCL’s behavior according to its particular needs and
internal environment. The approach to handle all these topics involves two PCL’s
components engine, being developed by the New University of Lisbon: the Local
Configuration Module (LCF) and the Local Coordination Module (LCM).
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97
Since there is a good match between these coordination requirements and the
functionalities of a workflow system, the Prodnet approach to deal with the flow of
messages within the PCL is based on the workflow reference model from the
Workflow Management Coalition Group - WfMC [WfMC94]. Figure 5 shows the
WfMC reference model. From the WfMC workflow definition, “a workflow consists in
the automation of procedures where documents, information or tasks are passed
between participants based on a predefined set of rules to accomplish an objective”.
In the PCL case, the participants are the PCL’s components, the information/task is
each message/event to be treated by PCL and the predefined set of rules is defined
by each company according to its particularities.
Process
Definition Tools
Interface 1
Interface 2 Interface 3
Workflow
Invoked
Client
Applications
Applications
Prodnet can extract several benefits from the WfMC reference model, namely:
• The WfMC is a well-known reference model towards the standardization in the
workflow systems area;
• The WfMC includes a component to define properly a workflow model. Such
model can be used by PCL as the Company Internal Model, which is configurable
by each company according to its needs. PCL can provide, through the Local
Configuration Module, a user-friendly “process editor” to support the
creation/definition of that workflow model;
• There is a formal language already developed to support the workflow model
definition - the Workflow Process Definition Language (WPDL) [WfMC97]. PCL
can use it to represent the company’s internal model as well as to import any
workflow model written in WPDL;
• The Wokflow Engine is the executor of a workflow model. Thus, the coordination
role inside PCL can adopt some concepts from this component. In other words,
the Local Coordination Module can be viewed as a specialized workflow engine
executing the company internal model.
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97
Definition Tool
Generates
May Process
reference Definition
Interpreted by
References
Organisation/
Role Model
Data
maintain Workflow
WFM control
may data
refer to Engine(s) Invokes
Application(s)
use
Manipulate
Work Workflow
List Relevant update Workflow
Data
Interact via Application
Administration Data
& Control
Worklist
Handler
(Supervisor)
Invokes Application(s)
User Interface
WPDL-VERSION
VENDOR
CREATED
WORKFLOW ‘VE_XYZ’
NAME
DESCRIPTION
…
// PARTICIPANT LIST
// APPLICATION LIST
// PROCESS RELEVANT DATA LIST
// ACTIVITY LIST
// TRANSITION INFORMATION LIST
END_WORFLOW
WORKFLOW ‘VE_ABC’
NAME
DESCRIPTION
…
// PARTICIPANT LIST
...
END_WORKFLOW
T1
CAD TOOL
Process
Message
STEP
Application Send
T2 T6 STEP info to
CadTool DIMS
Process
STEP Application
Message T7
Save
STEP
info
VE directory information
a. Identification of VEs (participation in several VEs simultaneously);
b. Information about partners of each VE (directory of partners):
• Partners identification;
• Network address: to allow network communications with a partner (send
messages, validation of received messages, etc. );
• Partner’s environment (if a partner has PCL or not): to guide the correct
sending of messages to a partner;
• Access rights over the Public/shared Information: what information is
available to a known partner, what information is available even for
“unknown” partners (for example, catalogues of products).
c. Information to be shared (with or without restrictions).
d. If a company exchanges product data files using STEP protocol, the
“configuration” of the Application Protocol (AP) used.
e. If a company exchanges orders using EDI format, the particular EDI subset
used.
This information is stored and managed by DIMS.
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97
The Local Coordination Module (LCM) is a particular workflow engine, which has
to execute and monitor the flow of messages configured in the company’s internal
model. Just to reinforce the association between LCM and the workflow engine, the
later is responsible for [WfMC94]:
◊ interpretation of the workflow definition;
◊ control of process instances - creation, activation, suspension, termination, etc.;
◊ navigation between process activities, which may involve sequential or parallel operations,
deadline scheduling, interpretation of workflow relevant data, etc.;
◊ sign-on and sign-off of specific participants;
◊ identification of workitems for user attention and an interface to support user interactions,
◊ maintenance of workflow control data and workflow relevant data, passing workflow
relevant data to/from applications or users,
◊ an interface to invoke external applications and link any workflow relevant data,
◊ supervisory actions for control, administration and audit purposes.
It is very easy to identify among all these “functions/activities” a strong similarity with
the LCM functions/activities: it is necessary to execute a particular company internal
model; it is necessary to execute/handle each single message/event coming to PCL;
it is necessary to monitor the accomplishment of every message/event according its
predefined flow; it can be necessary to ask for a human decision made
(unknown/unexpected messages); it is necessary to invoke the components
responsible for the message/event handling; and finally, the LCM has to administrate
the PCL behavior.
The LCM receives all messages/events that comes to PCL, from the legacy systems
as well as from the external world. It centralizes and control the global operation of
the PCL.
PRODNET
Communication Infrastructure
PCI
PRODNET Intelligent
Message Class
Communication Manager Authentication
Identifier
PICM
Multi Protocol Access Encryption Web Interface
Control (MPAC) Module
TCP/IP SMTP CGI
To prevent any kind of these threats or even from any other origin, a set of security
objectives were proposed by [Macgregor 96]:
• Access Control - services locally or remotely accessed should be validated
against unauthorized users. This can include the validation of permission
to do a specific information access.
• Authentication - it is necessary to be sure that the interlocutor at the other
(human or computer process) side is what it claims to be.
• Integrity - it is necessary to believe that the received information is what
was sent.
• Accountability - it is necessary to guarantee that the sender and/or
receiver does not deny the transaction after it took place (non-
repudiation).
• Privacy - eavesdroppers should not have access to sensitive information.
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97
The two PRODNET’s Encryption and Authentication modules will provide a set of
services concerning privacy and authentication. There are two main techniques to
provide information privacy during its transportation through public communications
infrastructures: symmetric cryptography also known as secret-key cryptography and
asymmetric cryptography also known as public-key cryptography. The first method
involves one session key to hide information during its transportation. This method
as the advantage of being efficient, and through implemented algorithms like DES,
Triple-DES, RC2, RC4, IDEA, etc., it has proven to be secure. The main obstacle to
this cryptographic technique is the distribution of the keys. Each interlocutor needs
to know a priori the key to cipher and decipher the message, i.e., the cipher and the
decipher keys are the same.
The public key cryptography has the advantage of facilitating the key distribution.
The asymmetric or public-key cryptography algorithm is based on the generation of
two keys: one to be considered the private key (only known by the owner) and the
other the public key (“to be put on the company’s presentation card”). One message
ciphered by one key can only be deciphered by the other key. If a company wants to
receive private information from its partners, it should give to them a presentation
card with its public key. When sending a message to a partner, the company’s public
key must be used to cipher it. No one knowing the same public key and having
access to the ciphered message can decipher it. Only the owner of the public key
can decipher the message with its corresponding private key. This special feature of
this cipher technique, the interchange of the key pair to do the cipher and decipher
operations, can facilitate the distribution of session keys. The SET protocol [SET
Book 1, 97] proposes the utilisation of a technique like that to distribute session keys
by using asymmetric cryptography, to enable secure goods purchasing through the
Internet.
The PCL Security Module will provide optional message privacy during message
transportation, through the utilization of both cryptographic techniques. The public
key of the receiver enterprise node will be used to cipher a session key generated
randomly for each message to be delivered. The message content will be ciphered
by the session key. The receiver node starts to retrieve the session key from the
received message, using its private key to decipher it. With the session key, the
receiver node can obtain the original message content.
Original message
to be sent
5389…
Hiding Process
Locally
generated
encripted by:
Symmetric Key
Public Key of
XXX… encripted by: the receiver
enterprise node
Communication Infrastructure
Original Digest
Message Function
Private Key of
signature encripted by: the sender node
Original signed
message to be sent
The privacy of the original signed message to be sent can be guaranteed by the
same process presented in Figure 10.
With these services PCL will provide virtual enterprise nodes with a private
communication infrastructure enhanced with authentication facilities. Authentication
is crucial when the communications infrastructure supports exchange of commercial
information. No one can repudiate a message that was signed and sent by one
enterprise node. In the future, the PCL communication infrastructure must be trusted
against some communication authority in order to guarantee that some contest can
be tracked and valid to be present in a court.
Port to WWW
One important question when designing the PRODNET architecture is to know if EDI
will be replaced or not by WWW-based solutions, in the future. Although this is a
difficult question, it seems that EDI will keep its role when the need is for handling a
large number of orders, in many cases automatically generated by PPC systems.
WWW-based approaches, with the attractiveness of the multimedia aspects, are
more adequate for human-initiated transactions. Another aspect to take into account
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97
is the auditability aspects that are considered in EDI systems and not yet in WWW
systems.
ADVANCED COORDINATION
The platform described in the previous sections addresses basic interaction services
to allow a company to participate in a networked environment. The concept of VE
could, however, suggest a much stronger cooperation level between enterprises,
namely in terms of joint coordination of activities and resources management. Such
advanced coordination could lead to more efficient and flexible organizations. This
would, however, require that some decision making processes, nowadays located in
the internal PPC systems, would be delegated to a VE decision making level. There
is here a question trade off between the loss of autonomy and the potential global
optimization. And this is not only a matter of technological solutions, specially if we
consider the social and organizational context of SMEs. The future shape of the VE
organizations strongly depends on trust building processes and market pressure /
tendencies. It is, therefore, quite risky to anticipate which functionalities will be
required in future cooperative scenarios.
PRODNET, although taking a somehow conservative approach in the sense that
puts more emphasis on a basic interactions platform supported by standards, is also
addressing a few advanced coordination aspects: i) Partners search and selection;
ii) Distributed resources planning and contract management. The proposed
advanced coordination functionalities were selected based on the opinions of the
end-users and will be implemented on top of the basic platform. The expectation is
that the trust building process and the decision to move forward at the SME level can
be facilitated by demonstration of such functionalities and their potential benefits.
Partners search and selection functionality. The list of core suppliers of a
company is a major asset for many companies (in many cases a secret information).
The selection process is a complex decision making process based on many factors,
namely on historic information. But for new components / services, it is sometimes
difficult to find the adequate suppliers (new nodes of a VE). Resorting to Internet and
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97
specialized directory services that are emerging, it is possible to conceive tools that
help in this task:
-Characterization of the required supplier (profile);
-Search for potential suppliers based on the internal lists (kept in the PPC
system) and on Internet services;
-Decision support system to give advice on suppliers selection.
DRP and contract management. This task aims at providing the enterprise with
“real-time” information about its current suppliers. It includes a simple information
system to collect previously identified information from a supplier and a VE workload
functionality to manage the VE global planning, workload and unexpected events.
The derivation of configuration information (to be used by PCL) from contracts is
also a goal being evaluated.
CONCLUSIONS
This paper presented the architecture of a platform to support virtual enterprises,
being developed by the Esprit project PRODNET II, and which is particularly suited
to the needs of SMEs. The proposed platform is based on the most common
standards for information management and interchange, workflow management and
communications. Reengineering needs in legacy PPC systems in order to support
the VE environment were identified. Particular attention was devoted to the
coordination of interaction activities and to the safety and authentication aspects.
Major open questions, requiring further investigation, are related to the advanced
coordination functionalities which depend on the level of integration / federation the
companies participating in a virtual enterprise decide to achieve. On the other hand,
it is important to note that the concept of VE raises new requirements in terms of
methods and contents of work and the skills of the human resources involved.
Therefore, the social and re-organisational aspects have to be analysed together
with the technological developments.
Acknowledgments. This work was funded in part by the European Commission
(PRODNET project). The authors also thank the contributions of all partners of the
mentioned project.
REFERENCES
[Afsarmanesh97] H. Afsarmanesh, L.M. Camarinha-Matos - Federated Information
th
Management for Cooperative Virtual Organizations, Proc. DEXA’97, 8 Int. Conf.
on Databases and Expert Systems (Springer Verlag), Toulouse, France, Sept 97.
[Camarinha97a] L.M. Camarinha-Matos, H. Afsarmanesh, C. Garita, C. Lima -
Towards an Architecture for Virtual Enterprises, Proc. of the 2nd World Congress
on Intelligent Manufacturing Processes & Systems, Budapest, Hungary, June 10-
13, 1997.
[Camarinha97b] L.M. Camarinha-Matos, Ricardo Carelli, J. Pellicer, M. Martín -
Towards the virtual enterprise in food industry, Proceedings of the ISIP'97
OE/IFIP/IEEE Int. Conf. on Integrated and Sustainable Industrial Production,
Lisboa, Portugal, 14-16 May 1997, Chapman & Hall, ISBN 0 412 79950 2.
th
In Proceedings of ICE'97 - 4 Int Conf. Concurrent Enterprising, Nottingham, Oct 97