# A Proposal of Standardised Data Model for Cloud Manufacturing Collaborative Networks

Beatriz Andrés, Raquel Sanchis, Raul Poler, Leila Saari

► To cite this version:

Beatriz Andrés, Raquel Sanchis, Raul Poler, Leila Saari. A Proposal of Standardised Data Model for Cloud Manufacturing Collaborative Networks. 18th Working Conference on Virtual Enterprises (PROVE), Sep 2017, Vicenza, Italy. pp.77-85, 10.1007/978-3-319-65151-4_7. hal-01674892

HAL Id: hal-01674892

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

Submitted on 3 Jan 2018

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
# A Proposal of Standardised Data Model for Cloud Manufacturing Collaborative Networks

Beatriz Andres¹, Raquel Sanchis¹, Raul Poler¹ and Leila Saari²

¹ Research Centre on Production Management and Engineering (CIGIP). Universitat Politècnica de València (UPV). Calle Alarcón, 03801 Alcoy, Spain
{bandres, rsanchis, rpoler}@cigip.upv.es

² Data-driven solutions, Technological Research Centre of Finland Ltd. (VTT). Kaitoväylä 1, 90570 Oulu, Finland
{leila.saari}@vtt.fi

**Abstract.** The growing amount of data to be handled by collaborative networks raises the need of introducing innovative solutions to fulfil the lack of affordable tools, especially for Small and Medium-Sized Enterprises, to manage and exchange data. The European H2020 Project Cloud Collaborative Manufacturing Networks develops and offers a structured data model, called Standardised Tables, as an organised framework to jointly work with existing databases to manage big data collected from different industries belonging to the CNs. The information of the Standardised Tables will be mainly used with optimisation and collaboration purposes. The paper describes an application of the Standardised Tables in one of the pilots of the aforementioned project, the automotive industry pilot, for solving the collaborative problem of a Materials Requirement Plan.

**Keywords:** standardised data model, management information systems, manufacturing, data handling, modelling, cloud, collaborative networks

## 1 Introduction

Collaborative approaches have been spreading over the last years due to the advantages associated with the enterprises that take part in collaborative networks (CN). Different areas of research have been studied, such as collaborative planning, performance measurement, strategies alignment, partners' selection, interoperability, data sharing [1]. Current globalised market environments involve open data movement contributing to the wide availability of such data. Nevertheless, earlier approaches to collaborative networking are constrained by the scarcity of data and technologies to deal with the fast evolving scenarios, in terms of data (data exchange/change, and data management). Big data focuses on processing and analysing large data repositories that with the conventional tools of analytical databases will be very difficult to treat. Large data repositories are fed by Radio Frequency IDentification, (RFID) sensors and other Internet of Things (IoT) devices that generate data, faster than people do. To this regard, big data requires smart technologies to efficiently process large quantities of data within a tolerable amount
of time. Technologies being applied to big data include, amongst others,
manufacturing execution system (MES), business intelligent systems (BI) or cloud
computing platforms, allowing to process big data or repositories based on
distributed, cloud and open source systems [2]. In terms of MES, some authors
fulfilled a fundamental need of designing data model for MES [3] [4], which are
based on entities relationship models [5]–[7]. These data models are considered to
compose the standardised data model for cloud manufacturing collaborative networks.

The main drawback of acquiring technologies for handling big data in CNs, formed
by small and medium enterprises (SMEs), is the lack of affordable tools. To achieve
the advantages offered from cloud computing capabilities (complex event processing,
collaboration technologies, big data management and knowledge processing)
enterprises need to start the process of ICT transformation to fulfil the requirements
for business innovation and turn technology into competitive advantage. Adopting
technologies to deal with collaborative relationships within networked enterprises and
adopting future Internet technologies such as cloud computing and data analytics are
core competences researchers must deal with in order to support the enterprises
technology change.

In this regard, the European H2020 Project Cloud Collaborative Manufacturing Networks (C2NET) develops methods and tools to collect data from real-world and virtualise resources, to collaborate in this data rich world. Addressing data acquisition from different sources interconnected to the C2NET platform and its cloud. Taking into account the diversity and heterogeneity of data resources in CN a proposal of Standardised Data Model is presented to jointly work with existing databases to manage big data collected from different industries belonging to the CN.

In this regard, this paper is structured as follows: Section 2 presents a brief overview of the C2NET project in which the paper is contextualised; in Section 3 the methodology followed in C2NET project to create the standardised data model is presented; in Section 4 the skeleton of the standardised data model is presented with the Standardised Tables (STables) created; Section 5 presents the application of the STables in one of the pilots in the C2NET project, the automotive industry pilot; finally, in Section 6 the conclusions and future research lines are addressed.

## 2 C2NET Overview

Cloud Collaborative Manufacturing Networks project (C2NET) [8] [9], will build a
Cloud Architecture to support SMEs with affordable tools to help them to overcome
the barriers appearing when they are willing to participate in a CN. C2NET Project
generates a Cloud Architecture composed by [10]: (i) The Data Collection Framework
(C2NET DCF) to provide continuous data collection from supply network resources;
(ii) The Optimiser (C2NET OPT) to support SMEs belonging to the CN in the
optimisation of collaborative manufacturing and logistics assets. C2NET OPT
contains a repository of algorithms that compute and optimise different set of
individual or collaborative plans related to replenishment, production and delivery;
(iii) The Collaboration Tools (C2NET COT), a set of tools in charge of managing the
agility of the collaborative processes; and (iv) The Cloud Platform (C2NET CPL) to
integrate the data collection module, the optimisers and the collaborative tools in the
cloud and allow the access to process collaboration and optimisation resources to all
CN partners.

This paper presents part of the results obtained in C2NET project and provides the
standardised data model of the C2NET database for gathering structured information
in the C2NET DCF. The stored data will be used by: (i) the C2NET OPT as input of
the optimisation algorithms designed in the scope of automatically solving
replenishment, production, and delivery plans; (ii) the C2NET COT as an input for
collaboration workflows, and monitoring of the optimised plans.

The validation of C2NET project is performed through the implementation of the
results in four pilots representing the automotive industry, dermo-cosmetics,
metalworking SMEs and OEM equipment manufacturer.

## 3 Data Base Requirement Analysis

The design of C2NET database raises from the need to define standardised
terminologies to manage information in multiple locations and with multiple
conceptual areas. A common and structured terminology is created in form of
Standardised Tables (STables) to have a shared understanding of all the different
needs in terms of collaboration and optimisation, for supporting the definition and
calculation of replenishment, manufacturing and delivery plans. Namely, C2NET
software developers can develop all kinds of functions for collaboration and
optimisation planning, on the basis of the database system. In order to build the
C2NET database and STables, two approaches have been considered:

The generic approach: A set of generic problems have been identified from the literature, which were classified using the Supply Chain Operations Reference (SCOR) [11]in Source (S), Make (M) and Deliver (D) plans, and combinations SM, MD and SMD. Each plan type classifies the plan subtypes (see figure 1). Around half thousand potential plans were identified in the literature, among which 101 were thoroughly analysed. A detailed analysis has been performed for each of the Literature Plans, regarding the modelling approach, the solution approach, the planning horizon and period, the collaboration level, the algorithm proposed, and the input data, objectives, and output data associated to the algorithm.

The Pilots approach: Some of the generic problems identified in the literature can solve the Pilot problems, while others not. For that reason, the Pilots approach has allowed to identify the Pilot Plans. The input received from the Pilots has allowed identifying problems that include new restrictions to solve the problems that in the generic algorithms have not been considered. Moreover, from the Pilot Plans, a set of input data, objectives and output data have been identified; considering a widespread number of scenarios for building the C2NET database. In this approach, the data that the pilots can provide has been checked, due to sometimes the enterprises do not have available the data required by the algorithms. In this regard, the algorithms must be adapted to the input data that enterprises can provide.
The STables have been built based on the homogenised categories, created to develop a common terminology in C2NET.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Plan Types and Plan Subtypes [12][13][14]</figcaption></figure>

## 4 Data Model: Standardised Tables

The input data, objectives and output data derived from the algorithms reviewed (generic problems) and from the Pilots problems have allowed the completion and refinement of the STables data, according to the needs of the domain modules C2NET DCF, C2NET OPT and C2NET COT. In this regard, STables are built to provide in a structured and standardised way the C2NET data needed.

The STables meta-structure is currently composed by 67 STables (a brief description of each STable is shown in Table 1). The STables are classified into two types: (i) One-dimensional STables which are the master data representing the main entities of C2NET, e.g. the STable *Machine*. This means that the table of *Machine* will only contain data related to *Machine*; and (ii) Combined STables, contains the relations of one or several one dimensional STables; e.g. the STable *Machine Tool* contains data related to a unique set of machine and tool. This STable contains the field *Setuptime* that is the time needed to setup a specific tool in a specific machine. Each STable contains four fields: (i) fieldname, designation of the field (data) with which the data is identified and/or known; (ii) fieldType, category of the data (string, integer, real, floating-point real number, date, boolean etc.); (iii) fieldUnit, magnitude of the data (length in meters, mass in kilograms, time in hours, etc.); and (iv) fieldDescription, characterisation of the data representing its meaning.
<table><caption>Table1. The Stables of C2NET</caption><thead><tr><td>STable</td><td>Definition</td></tr></thead><tbody><tr><td>Container</td><td>Containers hold Parts for delivery, supply, storage or transport</td></tr><tr><td>Customer</td><td>Customers buy Parts to the Company</td></tr><tr><td>Customer_OOrder</td><td>Associates an Order with a Customer</td></tr><tr><td>Customer_Part</td><td>Associates a Part with a Customer (parts purchased by the customer to the company)</td></tr><tr><td>Customer_Site</td><td>Associates a Customer with a Site</td></tr><tr><td>Customer_TimeFrame</td><td>Associates a TimeFrame with a Customer (available timeslots for supplying parts to the customer)</td></tr><tr><td>Labour</td><td>Type of Labour of the company</td></tr><tr><td>Labour_Period</td><td>Associates a Period with a Labour (the number of labours can vary along periods)</td></tr><tr><td>Machine</td><td>Machines of the company</td></tr><tr><td>Machine_Container</td><td>Associates a Container with a Machine (the machine needs a number of empty containers to work)</td></tr><tr><td>Machine_Labour</td><td>Associates a Labour (type of) with a Machine (the machine needs the labour to work)</td></tr><tr><td>Machine_Period</td><td>Associates a Period with a Machine (the machine can be available or not in such period, or other status)</td></tr><tr><td>Machine_Site</td><td>Indicates the Site in which the Machine is</td></tr><tr><td>MachineToo</td><td>Associates a Tool with a Machine (the machine needs the tool to work)</td></tr><tr><td>MachineToo_Labour</td><td>Associates a Tool and a Labour (type of) with a Machine (machine needs the tool to work, the tool needs the labour to be setup</td></tr><tr><td>MachineToo_Period</td><td>Associates a Tool with a Machine in each period (the machine and tool can be available or not in such period)</td></tr><tr><td>MachineTooToo</td><td>Associates two Tools with a Machine (indicates some characteristics when a tool is setup in the machine having another tool)</td></tr><tr><td>Operation</td><td>An Operation is a generic phase for changing a thing from one state to another state</td></tr><tr><td>Operation_Labour</td><td>Associates a Labour (type of) with an Operation (the operation needs the labour to be performed)</td></tr><tr><td>Operation_Machine</td><td>Associates an Operation with a Machine (the operation needs the machine to be performed)</td></tr><tr><td>Operation_Oper</td><td>Relate 2 Operations (for establishing sequences)</td></tr><tr><td>Operation Part</td><td>Associates a Part with an Operation (the operation needs the part to be performed or generates the part)</td></tr><tr><td>Operation Too</td><td>Associates an Operation with a Tool (the operation needs the tool to be performed)</td></tr><tr><td>Order</td><td>Generic Order (from a Customer to the Company, or from the Company to a Supplier)</td></tr><tr><td>Order Part</td><td>Associates an Order with a Part (the part should be delivered in such order)</td></tr><tr><td>Order Part_Site</td><td>Associates an Order of the part with a Site (the part of the order should be delivered in such site)</td></tr><tr><td>Order Period</td><td>Associates an Order with a Period</td></tr><tr><td>Order Site</td><td>Associates an Order with a Site (the order should be delivered in such site)</td></tr><tr><td>Part</td><td>Generic Part (raw material, component, final product; purchased or sold by the Company)</td></tr><tr><td>Part_Container</td><td>Associates a Part with a container (the part needs the container to be stored or transported)</td></tr><tr><td>Part_Container Customer</td><td>Associates a Part with a container of a customer (the part of a customer needs the container to be stored or transported)</td></tr><tr><td>Part_Container Machine</td><td>Associates a Part with a Container and a Machine. Modelling the picking activity whom load and cost depend on the container (unit, pack, factory box, distribution box, pallet) and the machine used to make the picking activity of the part in the container</td></tr><tr><td>Part_ContainerSupplier</td><td>Associates a Part with a container of a supplier (the part of a customer needs the container to be stored or transported)</td></tr><tr><td>Part_Container Period</td><td>Associates a Part with a Customer in a Period (information on such part in the customer in that period)</td></tr><tr><td>Part_Machine</td><td>Associates a Part with a Machine (the machine produces the part) [a more detailed modelling can be defined using Operation]</td></tr><tr><td>Part Part</td><td>Bill of Materials (amount of a part for obtaining one unit of another part)</td></tr><tr><td>Part PartGroup</td><td>Associates a Part with a PartGroup (group to which the part belongs)</td></tr><tr><td>Part Period</td><td>Associates a Period with a Part (information of the part in such period)</td></tr><tr><td>Part Site</td><td>Associates a Part with a Site (the site in which the part is)</td></tr><tr><td>Part Supplier Period</td><td>Associates a Part with a Supplier in a Period (information on such part in the supplier in that period)</td></tr><tr><td>Part Tool</td><td>Associates a Part with a Tool (the part needs the tool to be produced)</td></tr><tr><td>Part Vehicle</td><td>Associates a Part with a Vehicle (the part needs the vehicle to be transported)</td></tr><tr><td>Part Warehouse</td><td>Associates a Part with a Warehouse (the part needs the warehouse to be stored)</td></tr><tr><td>PartGroup</td><td>Group of Parts</td></tr><tr><td>Period</td><td>Specifies periods of time (hours, days, week, months, ...)</td></tr><tr><td>Person</td><td>An individual employee</td></tr><tr><td>Person_Labour</td><td>Associates a Person with a Labour (a worker able to perform certain type of labour)</td></tr><tr><td>Person Period</td><td>Associates a Person with a Period (availability of the worker in such a period)</td></tr><tr><td>Route</td><td>Generic route</td></tr><tr><td>Route Site Site</td><td>Associates a pair of Sites with a Route (for creating a complete route from the initial site to the end site)</td></tr><tr><td>Route Vehicle</td><td>Associates a Vehicle with a Route</td></tr><tr><td>Site</td><td>Specifies a Site (a location, for a factory, distribution centre, customer, supplier, etc.)</td></tr><tr><td>Site Site</td><td>Associates a Site with another Site (information between both Sites)</td></tr><tr><td>Site Site Vehicle</td><td>Associates a Site with another Site and a Vehicle (information between both Sites using the Vehicle)</td></tr><tr><td>Supplier</td><td>Suppliers deliver Parts to the Company</td></tr><tr><td>Supplier Order</td><td>Associates an Order with a Supplier</td></tr><tr><td>Supplier Part</td><td>Associates a Part with a Supplier (parts purchased by the company to the supplier)</td></tr><tr><td>Supplier Site</td><td>Associates a Supplier with a Site</td></tr><tr><td>SupplierTimeFrame</td><td>Associates a TimeFrame with a Supplier (available timeslots for receiving part from the supplier)</td></tr><tr><td>TimeFrame</td><td>Generic timeframe</td></tr><tr><td>Tool</td><td>Tools of the company</td></tr><tr><td>Tool_Labour</td><td>Associates a Labour (type of) with a Tool (the tool needs the labour to setup)</td></tr><tr><td>Tool Period</td><td>Associates a Period with a Tool (the tool can be available or not in such period, or other status)</td></tr><tr><td>Vehicle</td><td>Vehicles of the company</td></tr><tr><td>Vehicle Period</td><td>Associates a Vehicle with the period (the vehicle can be available or not in such period, or other status)</td></tr><tr><td>Warehouse</td><td>Warehouses of the company</td></tr><tr><td>Warehouse Site</td><td>Associates a Warehouse with a Site</td></tr></tbody></table>
## 5 Application Example of C2NET Standardised Data Model

The application is performed in the automotive pilot of C2NET that is specifically for solving the collaborative problem of a Materials Requirement Plan (MRP) between the First Tier and the Second Tier suppliers of an automotive enterprise. The structure of the STables and Fields required for solving the collaborative MRP are presented in Figure 2.

<figure><img src="image_3.png" /><figcaption>Fig. 2. Data structure required to solve the collaborative MRP.</figcaption></figure>

Table 2 shows the description of each of the fields required for solving the collaborative MRP as an illustrative example of the input data sets needed and how they are structured.

<table><caption>Table 2. Description of each of the fields</caption><thead><tr><td>STable Field</td><td>Description</td></tr></thead><tbody><tr><td>Part.PartID</td><td>C2NET unique identifier (autonumeric) for a part (product, raw material, component...)</td></tr><tr><td>Part.Code</td><td>Company unique identifier for a part</td></tr><tr><td>Part Description</td><td>Company description of a part</td></tr><tr><td>Part.LeadTime</td><td>Supply time of the raw material/component from the supplier to the manufacturer or delivery time of the product from the manufacturer to its customer</td></tr><tr><td>Part Availability Minimum Amount</td><td>Minimum inventory of parts, e.g. safety stock</td></tr><tr><td>Part.OrderCost</td><td>Cost of order release</td></tr><tr><td>Part.PartPartLevel</td><td>0: product; 1: subassembly; 2: semi-finished; 3: standard; 4: raw material</td></tr><tr><td>Part Availability Cost</td><td>Inventory cost per unit of the part</td></tr><tr><td>Part Availability Amount</td><td>Current amount of parts available in the inventory</td></tr><tr><td>Part.BatchMinimumAmount</td><td>Minimum lotsize of parts</td></tr><tr><td>Part.BatchAmount</td><td>Lotsize of parts taken</td></tr><tr><td>Part Utilisation Factor</td><td>Percentage of parts with the required quality (e.g. 85% of the produced parts are within the quality boundaries, the other 15% remaining parts are scrap). The value is given</td></tr></tbody></table>
<table><thead><tr><td>STable Field</td><td>Description</td></tr></thead><tbody><tr><td>Period.PeriodID</td><td>in base 1. C2NET unique identifier (autonumeric) for a period (hour, day, week, month...)</td></tr><tr><td>Period Description</td><td>Company description for the period</td></tr><tr><td>Supplier. SupplierID</td><td>C2NET unique identifier (autonumeric) for a supplier</td></tr><tr><td>Supplier.Code</td><td>Company unique identifier for a supplier</td></tr><tr><td>Supplier Description</td><td>Company description of a supplier</td></tr><tr><td>Supplier Location</td><td>Location of a supplier (e.g. address)</td></tr><tr><td>Supplier Type</td><td>Types of suppliers e.g. potential suppliers, current suppliers...</td></tr><tr><td>Part Part. Part1ID</td><td>C2NET unique identifier (autonumeric) for a Part1 that is the parent item of Part2</td></tr><tr><td>Part Part. Part2ID</td><td>C2NET unique identifier (autonumeric) for Part2 that is the child item of Part1</td></tr><tr><td>Part Part. Consumption Amount</td><td>Amount of a Part2ID consumed to create one unit of Part1ID</td></tr><tr><td>Part Period. Part</td><td>C2NET unique identifier (autonumeric) for a part</td></tr><tr><td>Part Period. Period</td><td>C2NET unique identifier (autonumeric) for a period</td></tr><tr><td>Part Period. Requirement Amount</td><td>Demand of a part in a period</td></tr><tr><td>Supplier Part. Supplier</td><td>C2NET unique identifier (autonumeric) for a supplier</td></tr><tr><td>Supplier Part. Part</td><td>C2NET unique identifier (autonumeric) for a part</td></tr></tbody></table>

## 6 Conclusions and Future Work

The growing amount of data to be handled by CNs, raises the need of introducing innovative solutions to fulfil the lack of affordable tools, especially for SMEs, to manage and exchange data. Considering that there is a need to better understand the potential for value creation through collaborative approaches, this paper presents a standardised data model for manufacturing CN, where organisational data exchange can be highly improved, from the proposed generic and adaptable standardised data model, playing an important role when data sharing and management is carried out in manufacturing CNs.

The STables were defined with the aim of creating a common terminology of C2NET data from the input data, objectives and output data extracted from the generic problems (literature algorithms) and the Pilot problems (developed algorithms).

The process of defining STables is not considered as completely finished, on the contrary, it is under continuous development. The generation of STables depends on (i) the results obtained in the work developed in C2NET project (ii) the new requirements appearing in the implementation and validation of C2NET project, and (iii) further needs that could emerge a posteriori in the exploitation phase, when C2NET project finishes, and when C2NET is implemented in other industrial sectors and contexts.
**Acknowledgments.** The research leading to these results is in the frame of the “Cloud Collaborative Manufacturing Networks” (C2NET) project, which has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 636909.

## References

[1] B. Andres and R. Poler, “Models, guidelines and tools for the integration of collaborative processes in non-hierarchical manufacturing networks: a review,” *Int. J. Comput. Integr. Manuf.*, vol. 2, no. 29, pp. 166–201, 2016.

[2] P. Zikopoulos and C. Eaton, *Understanding big data: Analytics for enterprise class hadoop and streaming data*. McGraw-Hill Osborne Media, 2011.

[3] B. Zhou, S. Wang, and L. Xi, “Data model design for manufacturing execution system,” *J. Manuf. Technol. Manag.*, vol. 16, no. 8, pp. 909–935, 2005.

[4] W. Steven, “Getting the MES model – methods for system analysis,” *ISA Trans.*, vol. 35, no. 2, pp. 95–103, 1996.

[5] A. Reda, “Extracting the extended entity-relationship model from a legacy relational database,” *Inf. Syst.*, vol. 28, no. 6, pp. 597–618, 2003.

[6] T. J. Teorey, D. Yang, and J. P. Fry, “A logical design methodology for relational database using the extended entity-relationship model,” *ACM Comput. Surv.*, vol. 18, no. 2, pp. 197–222, 1986.

[7] M. Victor and S. Arie, “Representing extended entity-relationship structures in relational databases: a modular approach,” *ACM Trans. Database Syst.*, vol. 17, no. 3, pp. 423–464, 1992.

[8] CORDIS Europa, “Factories of the Future,” *H2020-EU.2.1.5.1. - Technologies for Factories of the Future*, 2014.

[9] H2020 Project C2NET, “http://cordis.europa.eu/project/rcn/193440_en.html,” 2015.

[10] B. Andres, R. Sanchis, and R. Poler, “A Cloud Platform to support Collaboration in Supply Networks,” *Int. J. Prod. Manag. Eng.*, vol. 4, no. 1, pp. 5–13, 2016.

[11] APICS, “SCOR Framework,” *Supply Chain Operations Reference model (SCOR)*, 2017.

[12] A. Orbegozo, B. Andres, J. Mula, M. Lauras, C. Monteiro, and M. Malheiro, “An overview of optimization models for integrated replenishment and production planning decisions,” in *Building bridges between researchers and practitioners. Book of Abstracts of the International Joint Conference CIO-ICIEOM-IISE-AIM (IJC2016)*, 2016, p. 68.

[13] B. Andres, R. Poler, L. Saari, J. Arana, J. V. Benaches, and J. Salazar, “Optimization models to support decision-making in collaborative networks: A review,” in *Building bridges between researchers and practitioners. Book of Abstracts of the International Joint Conference CIO-ICIEOM-IISE-AIM (IJC2016)*, 2016, p. 70.

[14] B. Andres, R. Sanchis, J. Lamothe, Saari, L., and F. Hauser, “Combined models for production and distribution planning in a supply chain,” in *Building bridges between researchers and practitioners. Book of Abstracts of the International Joint Conference CIO-ICIEOM-IISE-AIM (IJC2016)*, 2016, p. 71.