7th IFAC Conference on Manufacturing Modelling, Management, and Control International Federation of Automatic Control June 19-21, 2013. Saint Petersburg, Russia
The exploitation of an ontology-based model of PLM from a SME point of view Giulia Bruno, Agostino Villa
Department of Management and Production Engineering, Politecnico di Torino Torino, Italy (e-mail: {giulia.bruno,agostino.villa}@polito.it)
Abstract: The wide range of functionalities offered by PLM systems are often not fully exploited by companies, especially small and medium enterprises, in which the management of data and information about product lifecycle is done without computer software systems. Consequently, a lot of time is spent in managing information “by hand”. In this paper we aim at providing an example of a methodology to exploit the potentiality of PLM systems from the point of view of a SME, by using an ontology-based model of PLM. The presented case study regards an assembly process of a small Romanian enterprise. Keywords: PLM, knowledge management, ontology, UML, IDEF0.
1. INTRODUCTION One of the key points of the success of enterprises, especially SME that are part of a supply chain, is the ability to communicate about and around their product. In fact, products generate a large amount of information during their lifecycles and the classical communication systems (e.g., phone/fax/email) used by 90% of companies are not structured enough to enable efficient cooperation (Le Duigou et al. 2012). For many years, software as Product Lifecycle Management (PLM) was developed to pool all this information. However, recent surveys evaluate the main difficulties in the implementations of PLM systems in SMEs, such as (i) the gap between the functionalities proposed by the actual software and the needs of some kind of enterprise, especially the raw part makers, (ii) the difficulty of modelling business processes and data models because modelling skills are not sufficiently present in SMEs, and (iii) the lack of interoperability between PLM and specific software used by enterprises (El Kadiri, 2009). PLM is first of all an enterprise strategy (Stark, 2005), because it involves managing all the data concerning a product, throughout its lifecycle, and all the internal and external actors involved in the development of it. The main goal of PLM is the management of all the business processes and associated data generated by events and actions of various lifecycle agents (both human and software systems) and distributed along the product's lifecycle phases: Beginning of Life (BOL) including design and manufacturing, Middle of Life (MOL) including usage and maintenance and End of Life (EOL) including recycling, disposal or other options (Kiritsis et al. 2003). PLM systems are mostly used in the product design phases, due to their capability of integrating drawing tools, 3D visualization, etc. However, a PLM system can be used in each stage of the product lifecycle, to manage the information and data generated from different people and different tools. Companies usually do not exploit the full potentiality of PLM 978-3-902823-35-9/2013 © IFAC
systems and a big amount of information-knowledge is being lost or requires a higher human effort to be preserved. The first problem for small and medium enterprises in the exploitation of a PLM system is the lack of process models to represent in it. In fact, PLM is a software platform for integrating various tools needed by a production process, but it is not a methodology for process modeling. Thus, to be able to exploit the potential of PLM, a company has to first define their processes and then set them in the PLM system. This article focuses on the modeling of a process, oriented to the use of a PLM system, to help companies in understanding the process of using a PLM and highlighting the benefits to be gained for a specific case. We adopt as a case study a real assembly process of a small Romanian enterprise. The rest of the paper is organized as follows. Section 2 describes the ontology-based model of PLM by presenting the concepts and properties involved in PLM. Section 3 provides the description of the real process used as a case study, while Section 4 contains the representation of the process in the IDEF0 formalism. In Section 5 the ontology filled with data of the case study is presented. Finally, Section 6 draws conclusions and states future works. 2. THE ONTOLOGY-BASED MODEL OF PLM An ontology formally represents knowledge as a set of concepts, properties and relationships within a domain. Thus, it can be seen as a structural model. However, it is also possible to instantiate an ontology, i.e., assign real values to class properties and relationships. Thus, the ontology also includes information deriving from a behavioural model. Furthermore, an ontology is useful to share common understanding of the structure of information among people or software agents, to analyse domain knowledge, to enable reuse of domain knowledge, to make domain assumptions explicit, to separate domain knowledge from the operational knowledge and to make reasoning and logical inference
1447
10.3182/20130619-3-RU-3018.00141
2013 IFAC MIM June 19-21, 2013. Saint Petersburg, Russia
among data. For these reasons we decided to resort to an ontology to provide a way to fully model a PLM system. Ontologies have already been proposed for knowledge management in product design processes (Brandt et al. 2007, Kumar and Park 2010). Ontologies have been developed for closed-loop PLM (Jun et al. 2007), for the Open Assembly Model (Fiorentini et al. 2007), and for STEP (Standard for the Exchange of Product Model, Wang et al 2010). A product design ontology that formalizes the functionality of shape processing methods in the design workflow is defined in (Catalano et al. 2009), while an ontology to manage both the product and the PLM is proposed in (Matsoki and Kiritsis 2010). A method for semantic integration of PLM objects based on an integrated ontology is described in (Kwak and Yong 2008). Differently from the previous works, in which the ontologies were developed starting from general concepts of the product processes or from general models of PLM, we generated an ontology from the integration of the static structure of PLM and the dynamic description of the product lifecycle processes (Antonelli et al. 2012). An ontology can be expressed as a set of classes, relations among classes and properties of classes. Classes represent concepts and could be organized in taxonomies to define a
hierarchical structure among classes. Relations represent associations between concepts and are usually binary. Attributes (also called properties) describe the features of the concepts. Finally, instances represent the real elements or individuals in an ontology. The ontology of the PLM is represented in the form of a UML class diagram in Fig.1. The upper part of the diagram contains information about the product and its characteristics, while the most consistent part is focused on the product lifecycle management. Since we are not interested in providing a detailed description of the product, we modelled the most important concepts of product in three classes. The class Product contains the information about products. It is associated to the Product_Family class, which contains information about the product group it belongs to. The composition association between the Product class and the Product_Component class represents the fact that each product can be made of several components, and each of them can have associated files that describe their state in the PLM. The Product class is associated with the Life_Cycle_Phase class. The association between Life_Cycle_Phase and Activity means that each phase contains several activities.
Figure 1. UML class diagram of PLM.
1448
2013 IFAC MIM June 19-21, 2013. Saint Petersburg, Russia
There are several kind of association between Activity and File, due to the different kind of usage of the file done by the activity. An activity can (i) consult a file, if it is simply read, (ii) use a file, if it is imported and used to create a new file but the original file is not modified, (iii) have a file as input, if it is modified by the activity, and (iv) produce a new file as output. A file can be also connected to the product or product component it refers to. Furthermore, files or groups of files can be linked in a Document (e.g. a report). For each file is known the Tool exploited to produce it. To keep trace of the persons involved in the activities, the Person class, which is a specialization of the Resource class, was introduced, which include personal data, contacts, etc. To each person is assigned a Role, which specifies if a person can see an Activity, can use a Tool or can access to a File. In the last case, the access right can be specified as reading or writing by means of the associative class Access_Rights. 3.THE CASE STUDY: AN ASSEMBLY PROCESS As a use case, we consider an electronic assembly process of the Romania Telecommunication Trading srl (RTT). RTT is a manufacturer of precision microwave, coaxial cable assemblies, harnesses and looms in the electronics and telecommunication industry throughout the EEC, mechanical assembly, filters for mobile telephony, complete assembly of racks, junction box and electronic equipments, especially for aerial, naval means, for civil and military use. RTT is able to design and produce bespoke tooling for close tolerance assemblies with the repeatability required for easy fitting. With their in-house test facilities they can guarantee that assemblies meet customers’ specifications. The supporting Operating Procedures define in detail how each element of the system is applied. Written procedures exist to enable the Company to quickly establish the identification of any product or material in either storage or production areas. The RTT departments concerned with the production management are the Administration Department, the Human Resource Department, the Quality Department, the Production Department, the Planning Department, and the Warehouse Department. Once the collaborating relationship with a customer is set up, the customer sends all the materials to RTT (e.g., technical drawings, operating parameters, raw materials, components, equipment). Presently 95 % of RTT’s production is based on raw materials supplied directly by the client. The Warehouse Department receive the raw materials from the customer and perform a data inventory. The Quality Department checks the conformity of the received materials and notifies if there are any flaws. The production orders received from the customers (in the form of a weekly production plan in Excel format) arrive at the Planning Department and they are processed to generate the internal production plan and the assembly plan. They are also introduced in the management software which automatically generates the necessary materials to perform the internal production and the assembly. The necessary production time for the week is checked.
The Human Resources Department consults the file ''Employees.xls” to check if the Production Department has enough resources to meet the production and the assembly plans and it notifies any possible shortage of personnel and emergencies. If all is ok, the customer is sent via e-mail the confirmation of the production plan. Then, the four sectors of the Production Department (assembly, tuning, FT line and low frequency) perform the production of internal components (if needed) and then the assembly, according to customer specification. The daily production file is constantly updated. The Quality Department visually inspects all finished products based on technical specifications, and the checked products go back to the Warehouse Department where they are packaged, labelled and prepared for delivery. 4. PROCESS REPRESENTATION A lot of formalisms have been proposed in literature to represent production processes. In this paper we exploit the IDEF0 formalism. IDEF refers to a family of languages, starting from IDEF0 to IDEF14 (Menzel and Mayer 1998). IDEF0 is a business process modelling language used to model decisions, actions, and activities of an organization or system. The resulting model expresses knowledge about how a system, process, or organization works. IDEF0 describes the specific steps of a process and the relationships developed, through a set of syntax components essential for Business Process integration. In this paper we exploit the IDEF0 formalism due to the two following reasons (i) it is a well-established methodology in the industrial environment, and (ii) it is suitable to our scope because it allows the separate identification of resources, files and tools inside activities (Kima et al. 2003, Chen et al. 2008). An alternative to IDEF0 is BPMN. However, IDEF0 is best used for top-down modelling, starting with the top processes and breaking down to appropriate level, to have a common understanding the process structure. This makes the IDEF0 model a good mean to define the enterprise terminology. Since we are interested in describing the process at a quite high level, we chose the IDEF0 as the more suitable formalism. The syntax components of an IDEF0 diagram include boxes and arrows. In particular it shows the functional process as a box and the interfaces to or from the manufacturing function as arrows entering or leaving the box. Different position of arrows have different meaning. Arrows entering the box from the left are the input of the process, arrows exiting to the right are the outputs of the process, arrows entering from the top are the constraints while arrows entering from the bottom are the resources of the process. The first level of the BOL process is reported as IDEF0 diagram in Fig.2, being it composed by four phases, i.e., Concept Design, Preliminary Design, Detailed Design, and Development. The assembly process taken as a case study belongs to the Development phase, thus we focused on it in the following.
1449
2013 IFAC MIM June 19-21, 2013. Saint Petersburg, Russia
Fig. 2. IDEF0 diagram of product Beginning of Life.
Fig. 3. IDEF0 diagram of the RTT assembly process. 1450
2013 IFAC MIM June 19-21, 2013. Saint Petersburg, Russia
To represent the process as an IDEF0 diagram, firstly we identified the activities done by the company, and then we listed for each one the files that are consulted, used and produced in output, and also which department is involved in it. The list of considered activities is reported in Table 1. Then, the IDEF0 diagram is a direct representation of this information, and it is reported in Fig.3. Since we do not have enough details on the tools exploited during the activities, we provided the information about the company department that performs the activity, meaning that the tools exploited by that department can be involved in the corresponding activity.
In Figure 4 a screenshot of the OntoStudio software (http://www.ontoprise.de/de/produkte/ontostudio/) exploited to implement the ontology is reported, particularly the property of the Production Planning activity. By using the ontology visualization tool it is possible to navigate the ontology and expand the activities of interest. For example, in Figure 5 the visualization of the instances related to the Production Planning activity is shown. Three classes are involved, indicated as the C letter, i.e., Activity, File and Role. For each class, the instances of the class are shown.
Table 1. Activities and properties of the assembly process Activity Raw Material Inventory
Property Consults Has input Has output Performed by Consults Has input
Production Planning
Has output Performed by
Internal production
Consults Has input Has output Performed by Consults Has input
Assembly
Quality assessment
Packaging and delivery
Has output Performed by Consults Has input Has output Performed by Consults Has input
Value - Transport documents - Non-Conformity document - List of received materials - Warehouse Department - Quality Department - Table of Employees - Client production design - Client production plan - List of received materials - Confirmation to client - Assembly plan - Internal production plan - Planning Department - Human Resources Department - Internal production plan - List of internal products List - Production Department - Client production design - Assembly plan - List of internal products - Assembly report - Production Department - Client quality parameters - Assembly report - Quality report - Quality Department - Client packaging requirements - Client delivery information - Assembly report - Quality report
Has output
- Delivery report
Performed by
- Warehouse Department
Fig. 4. Properties of the Production Planning activity.
5. ONTOLOGY INSTANCE FOR THE CASE STUDY The assembly process described in the previous section has been implemented as an instance of the PLM ontology. We do not include the information referring to the specific product because these are general classes that are valid for all the products produced by the company. If more details were available, they can be easily included in the ontology by adding a further level of detail in the hierarchical structure.
Fig. 5. Visualization of the instances of files and roles involved in the Production Planning activity.
1451
2013 IFAC MIM June 19-21, 2013. Saint Petersburg, Russia
6. CONCLUSIONS Due to globalisation, the enterprises have to work in networks more and more diversified and geographically dispersed. To allow this, optimizing the cost, quality and delay, enterprises have implemented new information and communication technologies. But those enterprises, even if they are more flexible, have difficulties in front of those new possibilities of exchange and share of information. PLM systems are one solution to structure and share product information. Nevertheless, only few enterprises have implemented such a system, probably because the functionalities of the actual PLM systems are not fully understood by enterprises. With our paper we tried to solve this problem by providing an example of exploitation of the potentiality of PLM systems from the point of view of SMEs, by using an ontology-based model of PLM. As future works we are planning to develop a new instantiation of the PLM ontology related to another phase of the product lifecycle, to see how it integrates the present model and to demonstrate the possibility of reusing the PLM model for different phases of product lifecycle. ACKNOWLEDGMENT The research presented in this paper is supported by the EUFP7 research project on Advanced Platform for Manufacturing Engineering and Product Lifecycle Management (amePLM). The authors would like to thank Alina Echert, from Romania Telecommunication Trading srl, for her kindness in providing the material for the use case. REFERENCES Antonelli, A., Bruno, G., Schwichtenberg, A., Villa, A. (2012). Full exploitation of Product Lifecycle Management by integrating static and dynamic viewpoints, International Conference on Advances in Production Management Systems. Brandt, S.C., Morbach, J., Miatidis, M., Theißen, M., Jarke,M., Marquardt, W. (2007). An ontology-based approach to knowledge management in design processes. Computers and Chemical Engineering, 32, pp. 320–342. Catalano, C.E., Camossi, E., Ferrandes, R., Cheutet, V., Sevilmis, N. (2009) A product design ontology for enhancing shape processing in design workflows. J Intell Manuf, 20, pp. 553-567. Chen Y.-Q., Hu, J., Mo, P. (2008) The Development of The Lifecycle Function Model By IDEF0 For Construction Projects. International Conference on Wireless
Communications, Networking and Mobile Computing, pp. 1-4. El Kadiri, S., Pernelle, P., Delattre, M., Bouras, A., (2009). Current situation of PLM systems in SME/SMI: Survey’s results and analysis. Proceedings of 6th International Conference on Product Lifecycle Management. Fiorentini, X., Gambino, I., Liang, V.-C., Foufou, S., Rachuri,S., Bock, C., Mani, M. (2007). Towards an Ontology for Open Assembly model. Proceeding of the International Conference on Product Lifecycle Management, pp. 445-456. Fowler, M., Scott, K (2000). UML distilled, Addison-Wesley. Jun, H.-B., Kiritsis, D., Xirouchakis, P. A. (2007) Primitive ontology model for product lifecycle meta data in the closed-loop PLM. Enterprise Interoperability II: New Challenges and Approaches, Springer Verlag London, pp.729–740. Kima, C.-H., Westonb, R.H., Hodgsonb, A., Leea, K.-H. (2003) The complementary use of IDEF and UML modelling approaches. Computers in Industry, 50, pp. 35–56. Kiritsis, D., Bufardi, A., Xirouchakis, P. (2003). Research issues on product lifecycle management and information tracking using smart embedded systems. Advanced Engineering Informatics, 17, pp. 189–202 Kumar, H., Park, P.S. (2010). Know-Ont: A Knowledge Ontology for an Enterprise in an Industrial Domain. International Journal of Database Theory and Application, 3(1), pp. 23-32. Kwak, J.-A., Yong, H.-S. (2008). An Approach to OntologyBased Semantic Integration for PLM Object, IEEE International Workshop on Semantic Computing and Applications, pp.19-26. Le Duigou, J., Bernard A., Perry, N., Delplace, J.C. (2012). Generic PLM system for SMEs: application to an equipment manufacturer, Int. J. of Product Lifecycle Management, 6(1), pp.51 – 64. Matsokis, A., Kiritsis, D. (2010). An ontology-based approach for Product Lifecycle Management. Computers in Industry, 61, pp. 787–797. Menzel, C., Mayer, R.J. (1998) The IDEF Family of Languages. Handbook on Architectures of Information, Springer Verlag, 209-242. Stark, J. (2005) Product lifecycle management: 21st century paradigm for product realization. Springer-Verlag, London. Wang, Q., Peng, W., Yu, X. (2010). Ontology based geometry recognition for STEP. IEEE Inter-national Symposium on Industrial Electronics, pp.1686-1691.
1452