# A Knowledge Based Collaborative Platform for the Design and Deployment of Manufacturing Systems

George Pintzos, Loukas Rentzos, Konstantinos Efthymiou, Nikolaos Papakostas, George Chryssolouris

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

## To cite this version:

George Pintzos, Loukas Rentzos, Konstantinos Efthymiou, Nikolaos Papakostas, George Chryssolouris. A Knowledge Based Collaborative Platform for the Design and Deployment of Manufacturing Systems. 10th Product Lifecycle Management for Society (PLM), Jul 2013, Nantes, France. pp.268-276, 10.1007/978-3-642-41501-2_27. hal-01461852

HAL Id: hal-01461852

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

Submitted on 8 Feb 2017

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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_2.png" /></figure>
# A Knowledge based collaborative platform for the design and deployment of manufacturing systems

George Pintzos, Loukas Rentzos, Konstantinos Efthymiou, Nikolaos Papakostas, George Chryssolouris<fnref n="1" />

Laboratory for Manufacturing Systems and Automation, Department of Mechanical Engineering and Aeronautics, University of Patras, 26500 Patras, Greece

**Abstract** The PLM systems do not provide any link to actual performance indicators, related to cost, time, and quality parameters. This paper describes a collaboration platform, based on a semantic core that expresses knowledge about Products, Processes and Resources. The platform is internet based, connecting engineers in the extended enterprise with shopfloor personnel. The concept is based both on a series of distinct components and elements comprising the knowledge base, and on a set of software agents. The latter are interfaced with a set of Computer Aided (CAx) systems and provide decision support capabilities for the design of a production line.

**Keywords** Collaboration platform, Production design, Ontology

## 1. Introduction

Most industrial sectors strive to find methods to reduce costs, time-to-market as well as to improve quality and expand market opportunities [1]. Production line design and development can be regarded as one of the most challenging decision-making processes, since it is affected by numerous design factors and criteria. Furthermore, it involves collaborative work carried out by several engineers such as process, industrial, and manufacturing equipment engineers [2]. Thus, different models, methods, techniques and technologies have been researched and developed to aid engineers in managing the complexity of production line design and development. Khan and Day in 2002, introduced a knowledge-based conceptual design methodology for single, multi- and mixed-product assembly lines; this methodology, based upon a selection of a suitable assembly systems can decide on suitable cycle times, parallel work station requirements, and parallel line imple-

<footnote n="1">¹ Corresponding author, e-mail: xrisol@lms.mech.upatras.gr</footnote>
mentation achieving an economical number of work stations [3]. Several system
analysis methods were developed for assisting engineers with the optimization of
their design, namely in [4, 5] where dynamic programming algorithms and Taylor
series expansions were used in order to determine values such as the number of
machines for each station and analyse the average steady-state throughput of cy-
clic production lines, respectively. Two noticeable examples of integrated simula-
tion models, in production design processes, comprise a method of the simulation
tools being used as modules for JIT manufacturing design [6] and an integration
framework of analytic and simulation tools for the assembly line design [7]. A lat-
er approach has discussed the implementation of a web-based workflow manage-
ment system for integrated production engineering, where the workflow of a pro-
duction engineering project could be configured within a BPEL Engine layer [8].

These simulation tools can demonstrate the behaviour of production lines, be-
fore their implementation, and contribute to a reduction in the development lead-
time. However, they are subject to the availability of detailed engineering infor-
mation, before useful simulation models for analysis can be developed. Conse-
quently, these tools are usually utilized during the final stages of the design pro-
cess in order for the configurations of design solutions, already planned in detail,
to be verified [2], whereas analytical methods are applied during the conceptual
design stage, when design solution outlines are constructed [12]. Furthermore,
these design methodologies do not consider the collaborative aspect of the design
and the development processes, meaning that similarly to the product development
process, the production line design process is a very knowledge-intensive and col-
laborative task that involves different stakeholders and knowledge bearers [9].
While knowledge-intensive collaboration has emerged as a promising discipline
for dealing with the modelling and decision-making processes, in distributed
product design systems, the same cannot be said for the design of manufacturing
systems and production lines [10]. However, with the advent of the Internet, soft-
ware frameworks will continue being developed for improving the ability to repre-
sent, capture and reuse design knowledge [11].

## 2. Platform architecture

The proposed platform is expanded into four main domains; the Execution, the
Workflow, the Interface and the Knowledge domain (Figure 1). The Knowledge
and Workflow domains include the so-called “Knowledge base”, which is a se-
mantic description of the acquired knowledge and workflow structure of produc-
tion design processes, comprising production data structures as well as infor-
mation about the production parameters. Further details concerning the
Knowledge domain will be given in the next section.
The Execution domain includes software agents and applications that directly assist the production design participants in performing various tasks, with reference to project execution and project management. The latter is supported by separate agents (Workflow agents), which inform engineers of their task (e.g. regarding the location of necessary input data files) on the basis of a project's latest progress and keep track of it (through the Workflow domain). The execution of tasks is supported by specific agents that, depending on the expected results of a task, provide links to either web-services working as tools for specific steps (e.g. for line balancing, cycle time calculation) or translation services, regarding the possible incompatibility of file formats (e.g. translation of proprietary file formats to open standard formats, such as PLCopen or STEP).

<figure><img src="image_3.png" /><figcaption>Fig. 1: Specific domains of the proposed platform.</figcaption></figure>

The Engineering data represent a cloud service in the form of an Infrastructure as a Service (IaaS) that includes a common database. It is connected to the knowledge repository and the physical data repositories placed in each stakeholder's facilities. When data have to be shared, the Workflow agents use the Project management information model, in the Knowledge base, for the calculation of the access rights that either provide the relevant link to the file or not. Finally, the interface domain includes all the necessary interfaces among the SW agents, the web-based services and the production design participants that work in the various projects.
**3. Knowledge structure in the extended engineering**

The structure of the information and consequently the formation of knowledge, as regards production design and deployment, was realised with the use of an ontology modelling and it was based on two main requirements:

* The model that will be used should have a very definite set of concepts including the relations between the concepts.

* The concepts should be as generic as possible in order to satisfy possible differences within the organisations in extended engineering.

These requirements are somewhat contradictory, since the greater the depiction of concepts, the lower the generic character of the model. Therefore, the modelling was performed on the basis of cases created by industry partners that served as Original Equipment Manufacturers (OEM), production system Integrators and parts/equipment suppliers.

**3.1 Product-Process-Resource model and relevant files**

The Product, Process and Resource views are common terms in PLM systems and represent the different views that engineers have on CAx files during the production design execution. In the proposed platform, the first sets of concepts of the Product-Process-Resource (PPR) include the modelling of the actual digital, production planning related data. The main concepts here are Product, Process and Resource. The modelling of these concepts derives from the higher level structures of relevant files, used by commercial CAx products and STEP Part 21, at the extent of their being considered consistent with each other. The selection of the CAx tools was based on questionnaires, delivered both to OEMs and SMEs, as well as a production system integrator. The lower levels of the structures were not used since there were inconsistencies between the different CAx products' file structures. In cases that information from the lower levels of a file's structure needs to be extracted, e.g. for the identification of process times from a CAM file, this can be done through the parsing of files or the direct input by the user of the relevant attribute values through a Graphical User Interface.
<figure><img src="image_4.png" /><figcaption>Fig. 2: Product-Process-Resource model.</figcaption></figure>

The product data have their own structure that links them to the part data with a simple object relation. The processes can also be depicted as a CAx file, while the resource files are also described as product data through a simple “has” relation. The relevant data objects are not only CAx files. Therefore, a special concept named *DesignDataObject*, was defined as shown in the figure below. The specific components of this concept represent documents, spreadsheets and files, relevant to one or more tasks of the design process and the creation of various documentations.

<figure><img src="image_5.png" /><figcaption>Fig. 3: Design data objects’ structure.</figcaption></figure>

The specific concept also includes XML files that can be manufacturing related, such as machine controller programs (e.g. PLCopen XML format) or they can express process sequences or even support business processes such as tendering (selection of suppliers).
## 3.2 Workflow and Human resources

This section describes the main concepts that are related to project workflow management and human resources. The term *human resources* here is used to describing the relevant actors participating in the design of a production system. The main concept, regarding project workflow management, is the *Project Element*, which has as subclasses the project, the phases and tasks of a certain project. The project individuals coming from the *Project* subclass serve as a reference that lasts throughout the design and deployment phases. The data attributes can be filled in through a web-application that works by means of collecting all the initial specifications for the design project (e.g. by an OEM to the Integrator). Each project element is linked to another through relations, namely the *hasTask* or *hasPhase*. When a new project concept is created, the individuals of the *Phase* concept are already set: Planning Process/ Layout, Planning of tools and equipment, Line balancing, Specification of tools & equipment, Purchasing of equipment, Realisation/Ramp up.

<figure><img src="image_6.png" /><figcaption>Fig. 4: Project elements' concept.</figcaption></figure>

The tasks of each phase can also be copied from the previous versions on the basis of similarity measurements, regarding the initial specifications of the project. Each Project element is linked to one or more Design data object(s) (described in the previous section) through relations such as *hasInput* and *hasOutput*. Therefore, the workflow also represents a data flow in the sense of certain files, required as input or output from each phase.

As regards human resources, the main concept connecting people to tasks is that of the *Role* (Figure 5). Each person is inserted into the platform as an *Actor*, a concept which includes information with reference to a person's experience and background. At each time instance of the project, the information about a person's
involvement in the project is described. Furthermore, the most relevant people that
can fit in a role can be identified by simple queries that can be performed by SW
agents. In the following section, the technological implementation that allows the
mapping and the data exchange between the central ontology and the local data
bases of the project's stakeholders is presented.

<figure><img src="image_7.png" /><figcaption>Fig. 5: Human resource model.</figcaption></figure>

4. Knowledge base mapping

Although the models presented fulfil the requirements of the end users, the ele-
ments that represent the actual files, used by engineers, should be somehow linked
to the locations of the actual data. This section describes the way that the ontolo-
gy elements' structure described in section 3.1 can be mapped to the local data-
base structures of the various stakeholders, participating in a collaborative project.
The knowledge base mapping refers to the linking of the corresponding elements
and the data exchange between the central ontology and the local data bases of the
project stakeholders.

<figure><img src="image_8.png" /><figcaption>Fig. 6: Knowledge base mapping.</figcaption></figure>

The implementation is made through a middle step (Figure 6, Connector), in
the Jena framework (Java). Via Jena, all the relevant ontology objects can be
linked to the corresponding files in local data repositories. The persistence layer is
the main link between the different objects, while the service layer is where differ-
ent web-services and agents can interact with the ontology model and in the
course of it with the relevant data attributes, files etc. Since the ontology describes
a number of projects (complete and on-going), the relevant concepts are not used
as they are, but are automatically recreated each time that a new project is set up.
These concepts are included in separate OWL files, connected to the main ontolo-
gy through uniform resource identifiers (URIs). This helps boost the editing, read-
ing and reasoning functionalities of the model. The re-instantiated concepts in-
clude all the PPR models as well as the relevant tasks, roles etc.

5. Case study

In order for the utilization of the proposed platform to be demonstrated, a case
study is presented below. The actors belong to a system integrator that has been
commissioned by an OEM to design a new line.

One of the platform's main functionalities is the use of web-based applications
that can interact with the ontology. In this case study, the application considers the
initial rough line balancing from an assembly line that has to be performed at the
initial steps of the line balancing phase. The application can be provided as a link
to the relevant actor that has the corresponding role. The application reads the on-
tology of the project and calculates the cycle time using data from the project's in-
stance (individual). More specifically, the application automatically uses capacity,
working days, shifts and working time per shift values (see Figure 4) and provides
the value of the cycle time. Then, the user is requested to input the number of pro-
cesses, including their expected times as well as any alternatives that derive from
the use of different equipment. This can be done through a common web-based in-
terface, where the information from the engineer is sent to the application through
XML (Figure 7). Finally, the application forwards the results, which the user can
either accept or try using different data, or even inform the relevant actors that the
setup has to change (change request). In this case, the platform agents can inform
the other participants of the change requests, by reasoning through the *hasInput*
and *hasOutput* semantic relationships for the identification of the tasks that pro-
vide the input to this task, the relevant *Roles* and subsequently, the *Actors*.
<figure><img src="image_9.png" /><figcaption>Fig. 7: Rough line balancing using the platform components.</figcaption></figure>

Since, the initial rough process times have been inserted into the line's description, another actor can use the semantic repository available in order to identify appropriate equipment for the rest of the processes (e.g. electric screwdrivers). The platform uses a semantic Rule that groups from previous projects processes similar to the ones that the user has defined based on their name (e.g. transmission tightening), the type (e.g. manual) along with their corresponding duration. After the grouping, a query that provides the resources belonging to the similar processes is executed. The engineer can now select the equipment that can be reused in the new project and automatically, the project's data including the line's cost are updated in the repository.

## 6. Conclusions

In this paper, there is a presentation of a collaborative platform that uses an ontology model for the description of different engineering files, business processes and human resources. The ontology serves as a communication layer between the different organisations, within extended engineering and can be handled by different SW agents as well as by engineering related web-based applications. The ontology is used not only as a representation of the engineering processes but also as a description and a mapping between engineering and business processes, which can be regarded as an extension of the current PLM approaches to production design. It is anticipated that this approach will enable the boosting of collaborative processes, including project management and data exchange between different stakeholders. Furthermore, the ontology can be used for the storage of knowledge with reference to certain business and engineering processes that can be identified by SW agents in new projects. Possible challenges that should be addressed in the future are the access rights management, concerning files shared by different companies as well as the support for the exchange of open standards by commercial CAx tools. Moreover, ontology related technologies need to be further
evolved as regards their integration with various database technologies. Incorporating human-centred interface technologies, such as Augmented and Virtual Reality into the platform and expanding the business processes could be two very interesting paths to be explored in a future study.

## Acknowledgments

This study was partially supported by the IP project Know4Car/ FoF-ICT-2011.7.4 - 284602, funded by the European Commission in the 7th Framework Programme.

## References

[1] Chryssolouris, G. (2006). Manufacturing Systems: Theory and Practice, third ed., Springer-Verlag, New York.

[2] Yoshimura, M., Yoshida, S., Konishi, Y., Izui, K., Nishiwaki, S., Inamori, Y., et al. (2006). A rapid analysis method for production line design. International Journal of Production Research, Vol. 44, No. 6, 1171-1192.

[3] Khan, A., & Day, A. J. (2002). A Knowledge Based Design Methodology for manufacturing assembly lines. Computers & Industrial Engineering, 441-467.

[4] Donohue, K. L., Hopp, W. J., & Spearman, M. L. (2002). Optimal design of stochastic production lines: a dynamic programming approach. IIE Transactions, 891-903.

[5] Han, M.-S., & Park, D.-J. (2002). Performance analysis and optimization of cyclic production lines. IIE Transactions, 411-422.

[6] Martínez, F., & Bedia, L. (2002). Modular simulation tool for modelling JIT manufacturing. International Journal of Production Research, 1529-1547.

[7] Hsieh, T. S.-J. (2002). Hybrid analytic and simulation models for assembly line design and production planning. Simulation Modelling Practice & Theory, 87-108.

[8] Alexopoulos K., Makris S., Xanthakis V. and Chryssolouris G. (2010), A Web-Services oriented workflow management system for integrated production engineering, Proc. of the 43rd CIRP Int. Conf. on Manuf. Sys., 351.

[9] Wang, L., Keshavarzmanesh, S., Feng, H.-Y., & Buchal, R. O. (2009). Assembly process planning and its future in collaborative manufacturing: a review. The International Journal of Advanced Manufacturing Technology, 132-144.

[10] Zha, X. F., & Dub, H. (2006). Knowledge-intensive collaborative design modeling and support. Part I: Review, distributed models and framework. Computers in Industry, 39-55.

[11] Chandrasegaran, S. K., Ramani, K., Sriram, R. D., Horváth, I., Bernard, A., Harik, R. F., Gao, W. (2013). The evolution, challenges, and future of knowledge representation in product design systems. Computer-Aided Design, 204-228.

[12] Daaboul, J., Cunha, C.-D., Bernard, A., Laroche, F. (2011). Design for mass customization: Product variety vs. process variety. CIRP Annals - Manufacturing Technology 60, 169-174.