# Service Entities in Manufacturing Networks

Rubén Darío Franco, Rosa Navarro Varela, Angel Ortiz Bas, Pedro
Gomez-Gasquet

► To cite this version:

Rubén Darío Franco, Rosa Navarro Varela, Angel Ortiz Bas, Pedro Gomez-Gasquet. Service Entities in Manufacturing Networks. 9th IFIP WG 5.5 International Conference on Balanced Automation Systems for Future Manufacturing Networks (BASYS), Jul 2010, Valencia, Spain. pp.92-99, 10.1007/978-3-642-14341-0_11. hal-01060708

HAL Id: hal-01060708

https://inria.hal.science/hal-01060708

Submitted on 16 Nov 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Service Entities in Manufacturing Networks

Rubén Dario FRANCO, Rosa NAVARRO VARELA, Angel ORTIZ BAS and Pedro GOMEZ-GASQUET

Research Centre on Production Management and Engineering
Universidad Politécnica de Valencia
{dfranco | ronava | aortiz | pgomez @cigip.upv.es}

**Abstract:** Service Entities have been proposed as a relevant approach that may help to support structural and functional Collaborative Networks modeling and deployment, especially when they are engineered inside Virtual Breeding Environments. This work is intended to explore the suitability of such approach to next-generation manufacturing networks. By means of a supporting case, the paper identifies main service entities of the problem domain, exemplifies how service interfaces can be defined and how can they be used to compose abstract collaborative processes definitions.

**Keywords:** Service Entities, Collaborative Manufacturing Networks

## 1 Introduction

Virtual Breeding Environments enhance the effectiveness and rapidness of Virtual Organizations creation and operation [4]. In achieving such goals, it is necessary to design and implement a new kind of systems which can be able of managing both VBE and VO Life Cycles in a consistent and integrated way. The so-called **VBE Management Systems** are expected to fully support the creation, operation and dissolution of Virtual Organizations, by defining a set of reference models (at structural, functional or behavioral level, to name few of them) that must be adopted by VBE/VO participants when they are willing to be involved in emerging collaboration opportunities [9].

Manufacturing networks are clear manifestations of those VBEs where spot collaboration opportunities may usually appear. But, in order to fully take advantage of them, next-generation management systems need to be designed and implemented, by combining relevant previous developments [5] with most recent technological developments.

This work represents the first step in building that kind of systems since the approach here introduced is intended to combine architectural principles of Enterprise Integration [6] with fundamental principles of Service Oriented Architectures.

The work has been structured as follows. In Section 2, a short introduction to basic concepts is given; Services Entities concepts and their life cycle are also briefly described. In Section 3, supported by a running case, suitability of Service Entities
approach for manufacturing networks is analysed. Finally, in Section 4, main conclusions and further research needs are envisioned.

# 2 Main Concepts and Motivation

## 2.1 Virtual Breeding Environments and Virtual Organizations

Collaboration between partners is a preferred way to ensure optimal resource balance and to get perdurable benefits [1]. Time of preparation and difficulty of launching a Virtual Organization will increase in the same proportion as the number of potential partners and complexity of collaborative processes to be carried out.

Virtual Breeding Environments [2] are intended to harmonize the preparedness level of involved organizations while, at the same time, a collaborative infrastructure is deployed in order to deal with interoperability problems at different levels: communications, data, services, processes or business [3].

In VBEs, the main idea is to restrict the number of potential participants by drawing a border to the open universe and allowing some partners to come inside. Those partners have to agree on common operating principles: business semantics, strategies or goals, distributed business processes management practices or even common ICT tools. Being inside the border reduces uncertainty between partners, basic to share information and to reach their common objectives. Rapidness and flexibility in VO preparation and launching are requirements that any VBE management system must accomplish.

## 2.2 Service Entities

Service Entities (SE) have been defined as the result of logically grouping a finite series of web-oriented business services interfaces which, given its functionality and performance, enable interaction (making requests) with a specific conceptual entity (e.g., bank, supplier, factory, etc.) from an interorganizational network or a working team [7].

SEs have been proposed as basic modelling constructs for Collaborative Networked Organizations [8], for both the Structural and Functional dimensions. As they have been defined, a single Service Entity is the result of logically tying together:

- A finite set of business services interfaces which jointly defines the expected behaviour of those conceptual entities involved into the domain being modelled and,

- A finite set of attributes which will allow characterize and distinguish between them.

## 2.3 Abstract Service Entities (ASEs)

Abstract Service Entities are generic constructive blocks used to model different 'types' of entities that are present in the problem domain under study. For example, in manufacturing networks context, the ASE concept may be used to define and
represent the generic characteristics and services of: factories, suppliers, plants, warehouses, subcontractors, transport companies, lines, sections, or, in general, the different types of resources that will be part of the final model.

ASEs are not associated with any specific instance of the entity defining it. They not only represent the abstract definition of the series of attributes which may characterize the Entity, but also the specifications of the electronic services interfaces which are defined by each Entity.

If Transport entities, like trucks, are identified within the problem domain to be modeled, they could be defined as an Abstract Services Entity named as Truck which contemplates the attributes and services required to identify them and to discover their electronic behavior.

## 2.4 Concrete Service Entities (CSE)

ASEs may be used in the Design Specification phase to model the problem, but without referring any specific resource to be used. However, as for wishing to support the execution, it is necessary to consider that the activities involved in the processes are carried out by specific requests from the various entities that have been modeled.

These requests are provided by Concrete Service Entities (CSE). The CSE creation process is known as Instancing and leads to specific occurrences of a particular ASE. This explicitly implies that the new entity created must have values which fill the empty ASE structure from which it originates: that is, to give values to the attributes and implementations to their network services.

Therefore, the attributes defined in the ASE will now take the specific values of that particular entity (a machine number, a warehouse identifier, etc.), and the corresponding electronic services will also have an implementation that is typical of the Entity; access to these services, and the request for them to be executed, will be via web.

## 2.5 Service Entities Life Cycle

As defined, Service Entities will also have their own lifecycle. In Figure 1, it is possible to identify some of their main activities.

At their first stage, ASE must be modelled into the VBE Engineering Environment (Figure 1, Step 1). At this stage, and as in the object orientation paradigm, ASE may be refined or generalized as needed. In this way, each specific VBE will count with a repository of ASE that will be used during the instantiation process (Figure 1, Step 2). During the instantiation process, CSE are registered in an Open Repository which can be, later on, accessed from the VO Engineering Environment. This instantiation process provides the membership applicants with the service interfaces that they ought to locally deploy and integrate at level.
<figure><img src="image_2.png" /><figcaption>Fig. 1. Main activities of the SE lifecycle.</figcaption></figure>

From now on, they are prepared to be involved into as many VOs as they can be granted to be (Figure 1, step 3).

## 3 Service Entities Modeling in Manufacturing Networks

An experiment carried out for the purpose of applying the ASE and CSE concepts to the modeling and coordination of manufacturing network processes is now introduced.

First, a description of the manufacturing network and the main manufacturing process characteristics will be given. Then, how modeling the SEs has been done in this scenario will be shown. Finally, a component of the Technological Platform which will support the network Production Planning process will be described, this being a ASE/CSE-based manufacturing processes editor.

### 3.1 Description of a manufacturing network

The Manufacturing/Supply Network on which this study is based is made up of a series of actors from the automobile sector. The company with which the case is developed (a manufacturer) is, at the same time, a first-tier supplier as it directly supplies the OEM, and is also a second-tier supplier as it supplies components to the second-tier suppliers. Both the OEM and the first-tier suppliers, and in some cases other end clients, are those which generate demand for the manufacturer and, for the purposes of this case, they only play this role with which the references made to finished products, half-finished products, or raw materials actually refer to those originating from the manufacturer (in this case, Molding).

At the same time, the manufacturer not only relates to suppliers of raw materials (RM), which are other second-tier (or third-tier) suppliers, but also to subcontractors
to manufacture the ordered products. Finally, the network counts on various logistics operators to move the RM, half-finished products, and finished products.

The manufacturing process starts by receiving RM (spools of steel) in the manufacturer's warehouse. According to the Production Plan, the spools of steel are transported (internally) to the Molding area where a first operation is carried out. There are two possibilities at this stage: a readily available finished product (which will be sent to the Client and, also in accordance with the Production Plan), or a half-finished product, in which case it will remain in the warehouse until required. Once again in accordance with the Production Plan, and for this particular case, the process requires a welding operation which is subcontracted. The Logistics Operator is in charge of transporting the half-finished products between the manufacturer and the subcontractor.

Once this part of the process has been completed, the half-finished product returns to the manufacturer's warehouse where other operations are carried out (washing, oiling, labeling, etc.) until the finished product is made which the Logistics Operator is in charge of transporting to the client's facilities.

From the planning and control perspective of the Manufacturer's Production Department operations, internal processes could be efficiently monitored. However, when the manufacturing process would need to mobilize half-finished products (WIP) to subcontractors, difficulties would arise in the visibility and control of the operations. Furthermore, the company would be starting to increase its production volume and, as a result, would also increase the need to resort to contracting additional productive capacity.

## 3.2 Modeling service entities

The following approach has been based on the use of Service Entities as constructive elements which could provide solutions to this kind of problems from an integrated business and technology point of view.

After first analyzing the Manufacturing/Supply Network, three types of main ASE were identified (see Fig. 2):

<figure><img src="image_3.png" /><figcaption>Fig. 2. Main ASEs in a manufacturing network</figcaption></figure>
- **Productive** entities: those in charge of totally or partially transforming some reference. In the case of this network, both the Molding section and the subcontractor are examples of productive entities.

- **Warehouse** entities: destined to store both finished and half-finished products in the network domain. In the example, even though others existed, only the stocks of one warehouse belonging to the manufacturer would be considered.

- **Transport** entities: these are in charge of moving materials from any possible combination of the two aforementioned entities both internally and externally.

In this case, there are two transport entities: the Logistic Operator and Internal Transport. For each of these entities, the main attributes were defined and a preliminary design of their services was done.

If we start with this ASE definition, it is possible to rapidly define the manufacturing network structure by making a request (CSE, Concrete Service entities) for each node by assigning values to its attributes. By way of example:

- ASEProductive = {'Molding', 'Subcontractor'}

- ASEWarehouse = {'WarehouseManufacturer'}

- ASETransport = {'LogisticOperator', 'InternalTransport'}

One direct benefit that this approach offers is that it is possible to vary the network structure, if it were necessary. For example, should the idea be to incorporate new subcontractors, suppliers of RM or Logistics Operators, all that needs to be done is to use the same request process and register for each new node.

Having defined the structural aspects, we now go on to analyze how ASEs contribute to facilitate the interoperability in the extended processes domain.

As previously mentioned, each ASE possesses a “homogenized” series of services interfaces, $S = \{s1, s2, ..., sn\}$, which may encompass different business activities (or processes) when they are called upon. These services interfaces are defined generically for the ASEs and they are specified for each CSE, depending on each node’s requirements.

In the example, the “Logistics Operator” and the “Internal Transport” transport entities, which are requests of the same Transport ASE, share the same service interface ($s = \“createTransportOrder()\“$) intended to receive the order to organize the transport of the materials involved. What varies in each case is the **implementation** of this service, that is, the way in which each implementation is carried out. For one entity it will mean a simple internal warehouse operation to the Molding section, while for the other it will involve transferring half-finished products from the Manufacturer to the Subcontractor.

Having defined the entity's services, the interfaces are implemented in a corporate computer (or similar) with Web capacities. At this stage, the link with the internal information systems of each node is created.

With a subsequent request, the extended processes are modeled as an orchestration of the activations of the services which the various participating ASE/CSE may supply. For instance, Fig. 3 depicts a simplified representation of the reserveStocks() service of a warehouse-type entity.
<figure><img src="image_4.png" /><figcaption>Fig. 3. Business service example of inventory reservation in Warehouse ASEs</figcaption></figure>

After the extended processes model has been created, the interface may be used to define, for example, that a Productive Entity requests a Warehouse to reserve the stocks of a given material. In this way, the following representation would be obtained (see Fig. 4):

<figure><img src="image_5.png" /><figcaption>Fig. 4. Process models in manufacturing networks may use ASE Services</figcaption></figure>

From the network processes management viewpoint, the second interesting aspect of this study, this approach is also very useful for solving the interoperability problems at this level.

If the process has been modeled with the services of an ASE, any of the concrete requests of this type (CSE) which was registered **could provide the network with the execution of this service**.

## 4 Conclusions and Further Research

The main goal of this study has been to explore the suitability of the Service Entities approach for manufacturing networks support.

As it has been presented, service entities modeling seems to be a promising approach when engineering next-generation manufacturing ecosystems. By means of abstract service entities and concrete instances implementing each business service interface, partners involved in a manufacturing network can be easily integrated into the collaborative processes execution.

Since ASEs modeling and CSE intantiation is just a first step in the whole process of creating manufacturing ecosystems, next research actions will cover a fully
implemented scenario where collaborative manufacturing processes can be tested and
validated.

Additionally, authors are working in a fully functional platform that will be used
as ecosystem management system for those manufacturing networks.

References

[1] H.S. Jagdev y K. Thoben, "Anatomy of enterprise collaborations.," *Production Planning & Control*, vol. 12, Jul. 2001, p. 437-451.

[2] L.M. Camarinha-Matos y H. Afsarmanesh, "Collaborative networks: a new scientific discipline," *Journal of Intelligent Manufacturing*, vol. 16, Oct. 2005, p. 439-452.

[3] R. Ruggaber, "ATHENA-Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications," *Interoperability of Enterprise Software and Applications*, pp.460-463, Springer London, 2006.

[4] L. Camarinha-Matos y H. Afsarmanesh, "A comprehensive modeling framework for collaborative networked organizations," *Journal of Intelligent Manufacturing*, vol. 18, Oct. 2007, p. 529-542.

[5] Q. Ni, W.F. Lu, P.K. Yarlagadda, y X. Ming, "A collaborative engine for enterprise application integration," *Computers in Industry*, vol. 57, Sep. 2006, p. 640-652.

[6] K. Kosanke, F. Vernadat, y M. Zelm, "CIMOSA: enterprise engineering and integration," *Computers in Industry*, vol. 40, Nov. 1999, p. 83-97.

[7] R. Franco, Á. Ortiz Bas, y F. Lario Esteban, "Modeling extended manufacturing processes with service-oriented entities," *Service Business*, vol. 3, Mar. 2009, p. 31-50.

[8] R. Franco, Á. Ortiz Bas, Prats, G. and Navarro, R., "Supporting Structural and Functional Collaborative Networked Organizations Modeling with Service Entities," IFIP Advances in Information and Communication Technology. *Leveraging Knowledge for Innovation in Collaborative Networks*. Volume 307/2009, pp. 547-554

[9] Ecolead, "D21.1 Characterization of Key Components, Features and Operating Principles of the Virtual Breeding Environments," 2005. Available at: www.ve-forum.org/projects/284/Deliverables/d21_1_vbe.pdf