THE PLATFORM FOR
PRODUCTION PLANNING AND MANAGEMENT IN VIRTUAL ENTERPRISES
L. M. Camarinha-Matos *; C. Lima *; A. L. Osório **
*
New University of Lisbon, Faculty of Sciences and Technology
Quinta da Torre, 2825 Monte Caparica, Portugal
**
ESTEC, Lda
Taguspark, Edifício de Tecnologias I, N. 16, 2780 Oeiras, Portugal
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 reengineering 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).
Research on virtual enterprises is a growing multidisciplinary area still lacking unified
definitions and terminology. It is usually accepted that a virtual enterprise is a
temporary alliance of enterprises that come together to share skills and resources in
order to attend a business opportunity and whose cooperation is supported by
computer networks and adequate IT tools and protocols. Companies operate as
nodes in a network of suppliers, customers, engineers and other specialized service
providers. Virtual enterprises materialize by selecting skills and assets from different
firms and synthesizing them into a (apparently) single business entity. However, a
number of “competing” terms, such as extended enterprise, supply chain
management, electronic commerce, etc., representing related concepts or partial
views, are sometimes mistakenly used as synonymous of virtual enterprise. In fact
different forms of virtual enterprises can be found nowadays. As a consequence
there is clearly a need to classify different perspectives of the VE paradigm before it
can be properly addressed and modeled. A first classification according to a number
of characteristics such as duration, topology, coordination, and visibility scope, has
been proposed in [Camarinha97a]:
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
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
In te r n a l
M o d u le
C oope ration
L ayer
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.
Figure 1 - PRODNET General Approach
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.
Some of the required functionalities are strongly dependent on several non-technical
factors. For instance, global VE 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. That is the case, for instance, of 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 are being developed. The basic platform includes:
• Exchange of commercial data (EDIFACT).
• Exchange of technical product data (STEP).
• Orders status monitoring.
• Quality related information exchange.
• Information management supporting administrative information about the VE,
and the information a node (enterprise) decides to make available to the
network.
• Coordination module that handles all cooperation related events (execution of a
local work flow).
• Configuration, allowing the definition and parametrization of the VE and the
behavior of each particular node.
• Extended PPC system, adapted to interact with a VE environment and including
the management of incompletely and imprecisely specified orders (along their life
cycle).
Additionally, the adequacy and implementation feasibility of some more experimental
modules on advanced coordination functionalities are being investigated:
• Tools to facilitate partners search selection.
• Management of a contracts data base.
• Distributed Resources Planning.
Considering the target scenario (SMEs) it shall be noticed that not all enterprises will
be interested in all proposed functionalities. Therefore, the various functionalities can
be enabled or disabled according to a set of configuration parameters.
Figure 2 shows the PRODNET general architecture for each node of the VE.
PCL
Advanced
Coordination
Functionalities
User Configur.
Interface Module
S TEP Mod ule
EDI Mo d u le
PPC
Production
Planning
and Control
PICP
DIMS
Federat ed
s ch ema man ag .
Federated
query proces.
E ngin eering &
other internal modules
LCM
Workflow
Engine
Protocol
Handler
Infor. handling & Coordinati on kernel
PCI
PECP
Safet y &
Authentication
C om m uni ca t .
M a n a ge r
Figure 2 - PRODNET General Architecture
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.
Orders management. Orders management is one of the most important
functionalities of the Virtual Enterprise. This component is mainly influenced by EDI
or WWW connections and the possibility of receiving direct inquiries about orders
status from other nodes (clients). An explicit state transition diagram has to be kept
for each order, however this information cannot be kept in the PCL Distributed
Information Management System (DIMS). Therefore, the PPC system must be
prepared to answer queries about the orders status coming from PCL. In same
cases, depending on contractual conditions, the company might be obliged to take
the initiative of notifying its client of each change in the order status. Additionally,
technical product specifications (BOM, geometric models, etc.) may be associated to
an order and received also electronically (for instance via a STEP representation).
On the other hand, it is PRODNET’s aim to handle orders that, at a given stage,
might be incompletely or imprecisely specified. All the dynamics associated to an
order, namely the process of receiving further information to complete it, needs to be
defined in a good interaction with the PCL.
Let us consider an example of an order for a car model X, where it is possible to
specify particular features (optional characteristics), like the type of engine, the color,
etc. An incomplete order is one which does not include all required product details.
An order could, for instance, simply specify a car model X. If an order like that is
received then it is possible to start immediately the production of the chassis, the
doors, etc., independently of the missing information about complementary
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 readjust 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).
Engineering and other legacy systems. Although several impacts of a VE
operation are expectable to the other legacy systems of a node enterprise, they are
out of the scope of PRODNET. However, PRODNET is proposing an “open” protocol
which allows communication and interoperation between other legacy systems and
PCL.
PRODNET COOPERATION LAYER
This module contains the functionalities and supporting information for the
interactions between a company and the VE(s) the company is participating in. The
components of PCL are:
DIMS - Distributed Information Management System. The Distributed Information
Management Subsystem in the PRODNET Cooperation Layer is responsible to
model and manage all cooperation support information [Afsarmanesh97].
LCM - Local Coordination Module. This component is the “executor”/controller of
the activity flow plan defined by the Configuration Component (a kind of workflow
engine). In other words, it is responsible for the behavior of the PCL and interacts
with all the other modules. It handles all Cooperation Events according to the
specified rules for the particular enterprise. These events have an asynchronous
nature and are provoked by other nodes of the VE, by the Internal Module of the
enterprise or by the Human Interface.
EDI Module. This module is responsible for receiving and formatting orders-related
messages in EDIFACT format. Among its functionalities, it will check / parse
EDIFACT syntax (for various versions of the standard), check for completeness of
messages contents, and generate appropriate formats for sending out EDI
messages. It will also detect and extract EDI messages embedding information
represented in other formats, such as a STEP specifications associated to an order.
STEP Module. The STEP module’s function is to handle the technical product data
used within PRODNET. Ideally all product data should be exchanged in STEP
format. The STEP services provided to PRODNET will allow for the transmission and
reception of STEP files that have been clear text encoded according to a defined
schema; as described in Part 21 of the STEP standard. It should also be possible to
query that STEP data held within PRODNET by the usage of the Standard Data
Access Interface, SDAI, defined as part 22 of ISO 10303.
PCI - PRODNET Communication Infrastructure. This module is responsible for
handling all communications with the other nodes in the network. It includes
functionalities such as: Selection of communications protocol and channels; Basic
communications management; Privacy mechanisms (cryptography); and Secure
message communication channels between nodes.
Configuration and User Interface. The PRODNET platform is intended to support a
large diversity of enterprises and interconnection modes. This means a large
heterogeneity in terms of available / installed services and desired management
procedures. Therefore it is necessary to specify the desired cooperation behavior in
an explicit plan (each enterprise has to define its particular activity flow plan) that will
be “executed”/controlled by the Local Coordination Module. Additionally, the
Configuration Component will allow a manual specification of the structure of the VE
and the access rights of all its members. The User Interface assures an interface
between the human operator (responsible for the interactions with the VE) and the
PCL. As mentioned before, the level of human intervention in this process will
depend on the policy of each company and will be specified at the configuration
phase (configuration and workflow plan).
PICP and PECP. PRODNET defines two different protocols to deal with
communications from both the company internal side and the outside world. The
protocols are the so-called PRODNET Internal Communication Protocol (PICP) and
PRODNET External Communication Protocol (PECP). PRODNET proposes the use
of PICP for dealing with all kinds of interactions with the company’s legacy systems.
All messages which come from the internal side of the company are sent to PCL
according to the PICP encapsulation format, regardless the origin of the message
(PPC system, STEP tool, EDI system, etc. ). PICP defines several classes of
messages and commands, which are used to allow the communication between any
company’s system and PCL.
Company
Internal
Side
O u ts id e
World
PCL
Domain
- In te r n a l
PPC
System
- Other
Legacy
Systems
Private
D om ain
Classes of
Messages
Prodnet
External
C o m m unic a ti o n
Protoco l
Prodnet
Internal
C o m m uni catio n
Protocol
PCL
PCL
(Limited to the available
Standards)
Human
Operator
Different
Coop.
Layers
Company
Private
Domain
Configuration
Management
Orders
Quality
EDI
STEP
DIMS
Unformatted
PICP
(or none)
Figure 3 - PRODNET Protocols
Figure 4 - PICP classes
From the outside world point of view, PCL can receive messages from two different
external sources: from another PCL or from a “foreign cooperation layer”. The
messages coming from a PCL partner are automatically recognized and treated,
without problems, because PECP encapsulates them in a particular format. On the
other hand it can be very difficult to deal with the messages coming from different
cooperation layers, mainly because there are hundreds of possible types of
messages arriving. Therefore, PCL will deal with a particular set of foreign
messages, namely the standard protocols EDIFACT and STEP.
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).
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 4
Workflow API and Interchange formats
Interface 5
Other Workflow
Enactment Service(s)
Workflow Enactment Service
Administration
& Monitoring
Tools
Workflow
Engine(s)
Workflow
Engine(s)
Interface 2
Interface 3
Workflow
Client
Applications
Invoked
Applications
Figure 5 - Reference Model of Workflow Management Systems WfMC94
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.
Definition Tool
Generates
May
reference
Process
Definition
Interpreted by
References
Organisation/
Role Model
Data
maintain
may
refer to
WFM
Engine(s)
Workflow
control
data
Invokes
Application(s)
use
Manipulate
Work
List
Interact via
Administration
& Control
Workflow
Relevant
Data
update
Workflow
Application
Data
Worklist
Handler
(Supervisor)
Invokes
Application(s)
User Interface
Figure 6 - Structure of a workflow system
The PCL’s components can be viewed as Workflow Client Applications.
The multi-VE environment can be configured in the company internal model, by
using one workflow model per VE, as shown in the Figure 7.
COMPANY INTERNAL MODEL
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
Figure 7 -Structure of a company’s internal model showing participation in multi-VE
The Local Configuration Module allows a particular configuration of PCL,
according to the particular needs of a company and the structure of the VEs in which
that company is involved.
Since the information exchange is a very sensitive aspect as it is related to the level
of autonomy and privacy that each company wants to keep, the LCF deals with three
different classes of information: the Company Profile, the Company Internal Model
and the VE Directory Information. The company profile is the information related to
the company itself (company’s legacy systems to be linked to the PCL, the PCL’s
users, etc.). As already mentioned, the company internal model defines the PCL’s
behavior - in other words, how a particular company intends to handle the
messages/events within the VE. For instance, some companies may want to use all
communication functionalities and standards, whilst others may be interested in
using mainly EDI. Some companies may want a strong human-based control of the
interactions process, whilst others may prefer a more direct channel to the PPC
system. The VE directory information is defined during the configuration phase of a
VE and it covers the need of information about the “external world”. Some examples
of each class are presented below.
Company profile
Internal system environment: information to enable / disable PCL services - for
instance, STEP or EDI components.
Internal system environment: the identification of the existing legacy systems to
be linked to PCL.
Specification of passwords for local users and working directories: to allow the
internal security/control related to PCL operation (privileges of access).
Company Internal Model: In the example of the Figure 8, PCL is handling two simple
messages: an EDI message and a STEP message.
EDI
Application
Process
EDI
Message
Human
Operator
DIMS
Application
T3
T4
Save
EDI
Info
Send
Message
to HI
PPC
T5
Send EDI
Information
T1
CAD TOOL
Process
Message
STEP
Application
T2
T6
Process
STEP
Message
Send
STEP info to
CadTool
DIMS
Application
T7
Save
STEP
info
Figure 8 - Graph example of a Company Internal Model
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.
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.
COMMUNICATION INFRASTRUCTURE AND SAFETY
A communication infrastructure to support the concept of virtual enterprise should
offer transparency regarding the panoply of communication protocols. Also, it must
be secure, which means the network connecting all enterprise nodes must have
safety characteristics. Here, safety means the transport of information through
reliable and secure communication channels. Concerning communication reliability,
the goal is to provide a flexible and efficient set of communication paths. Bandwidth
and latency are the key factors that can contribute to the “quality” of available
communication infrastructure. The growing needs on communication, mainly those
requested by the e-mail and the Web infrastructure with its multimedia requirements,
pushed new technologies and investments to spread new communication channels
at a lower price. Today the public communication infrastructure, with the participation
of multiple communication service providers, offers modular communication services
according to the user requirements.
Nevertheless, when technical and/or commercial information crosses the
communication channels in consequence of user driven activities or even automatic
planned ones, response times can be critical to run good businesses. The
transference of big amounts of data needs a communication infrastructure, hardware
and software, with bandwidth large enough to offer reasonable response times.
Latency times generated by protocol implementers, message routers, compressing
algorithms, or other message intervening, must be reduced to increase message
throughput. To cope with this bottleneck, PRODNET’s communication infrastructure
will provide an intelligent communications module to provide transparency of
communication services to the other modules of the PCL. The PRODNET Intelligent
Communication Module (PICM), being developed by ESTEC, will provide a message
delivery service considering the best unification between the communication
expectations of PCL and the real available communication resources.
Another crucial aspect, involving information transactions among enterprise nodes, is
the security of the exchanged information. Commercial and technical data are, in
most cases, considered strategic information and so, considered as reserved or even
secret. To clarify this aspect [Coulouris 94] proposed a classification for the most
common information threats:
leakage - access to information without authorization.
tampering - alteration of information without authorization. This includes the
changing of programs’ behavior (through virus, mobile agents, …).
resource stealing - unauthorized utilization of resources.
vandalism - information forge without any gain to the perpetrator.
PRODNET Cooperation Layer
(other functionalities)
PRODNET
Communication Infrastructure
PCI
PRODNET Intelligent
Message Class
Communication Manager Authentication
Identifier
PICM
Multi Protocol Access
Control (MPAC)
Encryption
Web Interface
Module
TCP/IP SMTP CGI
Figure 9 - Detailed view of the PRODNET Communication Infrastructure
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.
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
Symmetric Key
encripted by:
XXX…
encripted by:
Public Key of
the receiver
enterprise node
Communication Infrastructure
Figure 10 - Encryption technique used to guarantee privacy
Privacy is guaranteed by the utilization of both symmetric and asymmetric
cryptographic techniques (Figure 10). Nevertheless, with this technique it is not
possible to guarantee that the message was not changed during its transportation.
Another important aspect to be considered is the authentication of the sender and
the integrity of the sent message.
The PCL Authentication module will add a digital signature to a message to be sent.
With this digital signature, the receiver can always check if the message was
changed and besides that it can legally associate the message to the sender. The
digital signature is generated by encrypting with the sender’s private key the result of
the application of a digest function (a kind of hash function) to the message content.
The application of the hash function to the message contents generates a small
digest message that is encrypted with the private key of the sender. The receiver
node can verify the integrity of the message and the authenticity of the sender by
generating the digest message and comparing it with the received deciphered digest
message. If they are not the same, either the sender is not who it was expected to be
or the message has been tampered.
Digital Signature Generation Process
Original
Message
Digest
Function
signature
encripted by:
Private Key of
the sender node
Original signed
message to be sent
Figure 11 - Generation of the digital signature
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
is the auditability aspects that are considered in EDI systems and not yet in WWW
systems.
Figure 12 - PRODNET port to WWW
The approach followed in PRODNET is to include both approaches in its platform.
Figure 12 illustrates how a WWW-based form can be linked to PCL. Inside PCL
these interactions will follow the normal flow as messages arriving from other ports.
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
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
Management for Cooperative Virtual Organizations, Proc. DEXA’97, 8th 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 1013, 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.
[Camarinha97c] L.M. Camarinha-Matos - A platform to support production planning
and management in a virtual enterprise, Proceedings of CAPE’97, IFIP
International Conference on Computer Applications in Production and Engineering
(Chapman & Hall), Detroit, USA, Nov 97.
[Rabelo96] Ricardo Rabelo, L.M. Camarinha-Matos - Towards Agile Scheduling in
Extended Enterprise, Proceedings of BASYS'96: Balanced Automation Systems
II, L.M. Camarinha-Matos, H. Afsarmanesh (Eds.), Chapman & Hall, Jun 1996,
ISBN 0-412-78890-X, cap. 41, pp.413-422.
[Coulouris 94] Coulouris, G.; Dollimore, J.; Kindberg T. (1994) - Distributed Systems,
Concepts and Design, Addison-Wesley.
[Macgregor 96] Macgregor, R. S.; Aresi, A.; Siegert, A. (1996) - WWW.Security, How
to Build a Secure World Wide Web Connection, IBM, Prentice Hall PTR.
[SET Book 1 97] SET Book 1 (1997) - SET - Secure Electronic Transactions
Specification, Book 1: Business Description, Visa and MasterCard, May, 1997
WfMC94 Workflow Management Coalition (1994) - Workflow Management
Coalition, The Workflow Reference Model - Document Number TC00 - 1003,
Issue 1.1, Brussels Nov 29, 1994.
WfMC97 Workflow Management Coalition (1997) - Work Group 1 - Workflow
Management Coalition, Interface 1: Process Definition Interchange - Document
Number TC - 1016, Issued on April 18, 1997.