Capability matchmaking software for rapid production system design and reconfiguration planning

ContentslistsavailableatScienceDirect

Procedia CIRP

journalhomepage:www.elsevier.com/locate/procir

Capability matchmaking software for rapid production system design and reconfiguration planning

Eeva Järvenpää

, Niko Siltala

, Otto Hylli

, Minna Lanz

aFaculty of Engineering and Natural Sciences, Tampere University , Tampere , Finland

bFaculty of Information Technology and Communication Sciences, Tampere University , Tampere , Finland

a rt i c l e i nf o

Keywords:

Production system design Production system reconfiguration Capability matchmaking Matchmaking software Resource modelling Ontology

a b s t r a c t

Traditionally,the productionsystemdesign and reconfigurationplanningaremanual processes, which relyheavilyonthedesigners’expertiseand tacitknowledgetofindfeasiblesystemconfigurationsolu- tions.Rapidresponsivenessoffutureproductionsystemscallsfornewcomputer-aidedintelligentdesign andplanningsolutions,thatwouldreducethetimeandeffortputintosystemdesign,bothinbrownfield andgreenfieldscenarios.Thispaperdescribestheimplementationofacapabilitymatchmakingsoftware, whichautomatizesthematchmakingbetweenproductrequirementsandresourcecapabilities.Theinter- actionofthematchmakingsystemwithexternaldesign andplanningtoolsisexplainedandillustrated withacaseexample.The matchmakingapproachsupports productionsystemdesignand reconfigura- tionplanningbyprovidingautomaticmeansforcheckingiftheexistingsystemalreadyfulfillsthenew productrequirements,andforfindingalternativeresourcesandresourcecombinationstospecificproduct requirementsfromlargesearchspaces,e.g.fromglobalresourcecatalogues.

© 2020 The Author(s). Published by Elsevier B.V.

ThisisanopenaccessarticleundertheCCBY-NC-NDlicense (http://creativecommons.org/licenses/by-nc-nd/4.0/)

1. Introduction

Responsiveness is an important strategic goalfor manufactur- ing companies operating in a highlydynamic environment char- acterizedby constant change.Such responsiveness andadaptivity is related to theneed to design, reconfigure andadjust the pro- ductionandcorrespondingproductionsystemasefficientlyaspos- sible to the requiredchanges in processingfunctions, production capacity, anddispatchingof theorders. Traditionally,the produc- tion systemdesign andreconfigurationplanningare manual pro- cesses,andheavilydependentonthedesigners’expertiseandtacit knowledgetofindfeasiblesystemsolutionsbycomparingthechar- acteristics of theproduct tothe technicalpropertiesof theavail- able resources.This processis slow,anditsets limitationstothe amount ofpotentialsystemconfigurationalternatives that canbe considered. Meeting therequirements of fastadaptation calls for newcomputer-aidedintelligentplanninganddecisionsupportso- lutions,thatwouldreducethetimeandeffortputintosystemde- sign,bothinbrownfield(reconfiguration)andgreenfield(newsys- temdesign)scenarios.

∗Corresponding author.

E-mail address: eeva.jarvenpaa@tuni.fi(E. Järvenpää).

A key enabler ofsmart manufacturing is the virtualization of physicalassetsofthemanufacturing, namelyresourcesandprod- ucts(Lu andXu,2018; Tao etal., 2018). There isa need forfor- mal,structured representation ofresources andproducts that al- lowtheresourcevendorstodescribethefunctionalityoftheirof- feringsina comparablemanner,andsystemdesignerstomake a matchbetweentheproductrequirementsandresourcecapabilities.

Formal engineeringontologiesandotherSemantic Webtechnolo- gies have become popular solutions for addressing the semantic interoperability issue in heterogeneous distributed environments (Ameri et al., 2012; Jardim-Goncalves et al., 2016; Leitão et al., 2016).Severaldifferentsemanticontology-baseddescriptionshave beenproposedfortheservicedescriptioninCloudManufacturing context(e.g.(Luoetal.,2013;Yuanetal.,2017;LuandXu,2018)).

Lu and Xu (2018) presented a service composition and mapping approachbasedonontologicaldescriptionoftheservicesandJena rules to comparethe servicerequest withthe offering.Manufac- turing Service Description Language (MSDL) was developed as a formal domainontology forrepresenting thecapabilitiesofman- ufacturingservices, focusing on mechanicalmachining andmetal castingservices(Amerietal., 2012),andusedforamatchmaking methodology, which aims to connect buyers andsellers ofman- ufacturing services in distributed digital manufacturing environ- ments (Ameri and Patil, 2012). Ameri and McArthur (Ameri and

https://doi.org/10.1016/j.procir.2020.05.264

2212-8271/© 2020 The Author(s). Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license ( http://creativecommons.org/licenses/by-nc-nd/4.0/ )

ductionsystemdesignandreconfigurationplanning.

DuringtheEUfundedprojectReCaM,wehavedevelopedcom- puterizedsupportforthesystemdesignandreconfigurationplan- ning process. The approach relies on formal description of re- sources andproducts,providingafoundationforrapidcreationof newsystemconfigurationsthroughcapability-basedmatchmaking of product requirements and resource offerings (Järvenpää et al., 2018a,2018b,2018c,Siltalaetal.,2018a,2018b).Thematchmaking system allows the designer tosearch through large resource cat- aloguestofindfeasibleresourcecombinationalternativeswithout manualeffort.

In this paper, we will introduce the implementation of the matchmaking software, and how it can be utilized by external design andplanning tools. The paper is organized as follows.In Section 2 we will introduce the capability matchmaking system andits associatedconcepts, informationmodels,andsoftwarear- chitecture. In Section 3 we willexplain how external design and planning tools can utilize the matchmaking software through its WebServiceinterface.InSection4wewillgiveanexampleofthe use ofthe matchmakingsystemand itsinternal functionality. Fi- nally,wewillendwithdiscussionsandconclusionsinSection5.

2. Capabilitymatchmakingsystem

Thematchmakingsystemintendstoeaseupthesystemdesign andreconfigurationplanning procedureby automaticallysuggest- ing alternativeresourcecombinationsforspecificproductrequire- ments. In this section we will first discuss about the formal in- formationmodelsusedasaninputforthematchmaking.Secondly, wewillshortlyexplainthematchmakingprocedurerelyingofrule- basedreasoning.Thirdly,wewillintroducetheimplementedsoft- warearchitectureforthematchmakingsystem.

2.1. Involvedinformationmodels

The foundation of the capability matchmaking is the for- mal information models representing the product requirements and available manufacturing resources. We have developed OWL (WebOntologyLanguage)-basedinformationmodelstorepresent this information,andintroduced them inourearlier publications (Järvenpää etal.,2018a,2018b, 2018c,Siltalaetal., 2018a,2018b).

OntologyEngineeringMethodology(Sureetal.,2009)wasfollowed duringthemodeldevelopment.Themodelsareavailablefordown- loadin(Järvenpää etal.,2019a).

The Resource Model ontology is used to describe the avail- able manufacturing resources, including their capabilities, inter- faces and other characteristics, as well as systems composed of multiple resources. The Resource Model (Järvenpää et al., 2018a) imports two other ontologies, namely Resource Interface Model andCapability Model.The ResourceInterfaceModel(Siltalaetal., 2018a)isused togive a formal description oftheresource inter- faces.

Fig. 1. Internal process phases in Capability Matchmaking.

TheCapabilityModel(Järvenpää etal., 2018b)formalizesfunc- tionalities ofresources andparameters related tothese function- alities.Italsodefinesrelationsbetweensimple(atomic)andcom- bined capabilities. Forinstance, a robot can have a simple capa- bility“Moving” andagrippercanhavesimplecapabilities“Grasp- ing” and“Releasing”.Together theycancreatecombinedcapabili- ties“PickandPlace” and“Transporting”.Basedontheseformalized relations,the potential resourcecombinations that haveacertain combinedcapabilitycan be identifiedprogrammatically byutiliz- inginformationprovidedbySPARQLqueries.TheCapabilityModel imports another ontology calledProcess Taxonomy Model, which categorizes different manufacturing and assembly processes in a hierarchicalstructure.

ProductModel ontology (Järvenpää et al., 2018c),can be used to describe the product requirements for the matchmaking. The ProductModel describesthe partsandtheir basic characteristics, sub-assembliesandtheircontainedparts,processesrelatedtothe parts and sub-assemblies, capability requirements related to the processes,andsequenceoftheprocesses.TheProductModelalso imports the Process Taxonomy,which allows to build a link be- tween theproduct requirementsandprovided capabilitiesduring thematchmaking.

The matchmaking is performed with Matchmaking ontology, whichimportsbothResourceandProductModelontologies.Itin- cludesalsothematchmakingrulesdiscussedinthefollowingsec- tion.

2.2. Matchmakingstagesandrules

The capability matchmaking involves two aspects:Generation of new resource combinations and matching the capabilities of these combinations with the product requirements. The process flowis illustratedin Fig.1.First,the matchmakingsystemgener- ates new resource combinations that have capabilitiesrequested by the product, e.g. “Screwing”. Next,the interface compatibility of the resources is checked based on the interface matchmaking rules(Siltalaetal.,2018b).Afterthat,thecombinedcapabilitypa- rameters are calculated for the remaining resource combinations basedonthecombinedcapabilityrules.Finally,whentheresource combinations have been created and their combined capabilities havebeencalculated,thesecombinedcapabilitiesarecomparedto thecharacteristics andrequirementsofthe product.Forthispur- pose,capabilitymatchmakingrulesare used.The combinedcapa- bilityrules havebeen introducedin (Järvenpää et al., 2018a)and matchmakingrulesin(Järvenpää etal.,2019a).Bothhavebeenim- plementedwithSPINrulelanguage(SPARQLInferencingNotation), whichisaW3CMemberSubmissionthathasbecomethede-facto industrystandardtorepresentSPARQLrulesandconstraintsonSe- manticWebmodels(SPINworkinggroup2017).SPINcanbeused tolinkclassdefinitionswithSPARQLqueriestocaptureconstraints andrules thatformalizetheexpectedbehaviorofthoseclasses.A

Fig. 2. Overall software architecture of the capability matchmaking system, modi- fied from ( Järvenpää et al., 2019b ).

suitablereasonertoolsuchasSPINAPI(Knublauch,2016)canthen infernewinformationcreatedbytherules,andassertittotheon- tologyforlaterusee.g.inSPARQLqueryexecution.

2.3. Implementationofthecapabilitymatchmakingsoftware

The capabilitymatchmaking softwarefollowsthe principlesof client-server architecture.It isconstructed fromthreemain com- ponents: the capability matchmaking web service; the software packages for executing the capability matchmaking process; and the formalinformationmodels, discussedintheprevious section.

The web service and associated software modules are deployed andhostedonApacheTomcatserver.

Fig.2outlines thelayeredarchitectureofthecapabilitymatch- makingsystem,andinteractionsbetweenthevariouslayers.Italso illustrates the technologies and languages used for the software implementation.The DataModelLayer containstheontology and other data models needed for the matchmaking. The Data Layer represents the actual data,i.e.instances, used duringthe match- making. TheBusinessandDataAccess layersrunandexecutethe matchmaking procedures.The top mostlayerrepresents different client systems, which interact with the web service component of the system in order to trigger matchmaking or to obtain the matchmakingresults.

TheWebServicelayerisimplementedasaRESTfulwebservice.

Thischoice forinterfaceallows easyandloosecouplingforclient applicationsto connectwiththematchmakingsysteminorderto sendrequestsandreceiveresponses.

The most important packages in the architecture from the matchmaking reasoning perspective are the Capability Query Li- brary(CQL)andtheMatchmakerontheBusinesslayer.TheMatch- makerisresponsibleforsequencingandmanagingthematchmak- ing process, and performing the actual matchmaking forthe in- comingrequests.IttakescareoftheexecutionofthevariousSPIN

Fig. 3. Interaction of the capability matchmaking software with other external tools and databases.

rules through the Java-based CQL API (Application Programming Interface).It creates resource combinationpossibilities, calculates thecombinedcapabilityparametersfortheinvolvedresourcecom- binations, checksthe interfacecompatibility oftheresources, ex- ecutes matchmaking rules from the Matchmaking Ontology and constructs the matchmakingresult fromthe rule inferences. CQL usestheopensourceJenasemanticwebframework(ApacheSoft- wareFoundation2017)andOpenlletreasoner(OpenlletAPI,2019) for workingwith the ontology models. Jena and Openllet them- selvesdonotsupportSPIN.Thus,anotheropensourcelibrarythat buildsontopofJena,calledSPINAPI(Knublauch,2016),isusedto executetheserules.

3. Interactionofthecapabilitymatchmakingsystemwith externalsoftware

TheCapability Matchmakingisimplemented asa webservice, andthereiscurrentlynointegratedgraphicaluserinterface(GUI) forit.Theaimedusecaseisthatthesystemdesignercallstheser- vicethroughhisdesiredplanningsystem,whichfollowsthespeci- fiedXMLmessageschemas(XSD)orJSONmessagesforinteracting withthewebservice.Eventhematchmakingsystemitselfdoesn’t haveaGUI,itcanbecalledmanuallybysendingtherequests(and receivingresults)throughtheserviceURLasXMLorJSONformat- tedtext.

Asaninput,thematchmakingsystemneedsthesearchspaceto consider.ThisincludestheProductRequirementDescription(PRD) andasetofResourceDescriptions(RD)formingtheResourcePool that ought to be considered duringthe matchmaking process. In caseofreconfigurationscenario,alsothedescriptionoftheexisting systemlayoutshould beincluded.The inputsareprovided tothe matchmakingsoftwarebytheclientapplicationintheformofPRD IDsandRDIDs. The search spaceisthen retrievedandread into theMatchmakingOntologyfromvariouscataloguesstoringtheac- tualinformationcontent.Forinstance,theresourceinformationis collectedfromResourceCatalogue whereresource providershave supplieddescriptionsoftheirofferingsintheResourceDescription format(Siltalaetal.,2018a).ThePRDisrepresentedwiththeProd- uctModelontologyformat(Järvenpää etal.,2018a).

The Capability matchmaking system takes the capability re- quirementsandmatchthem withthe capabilitiesexistingon the currentsystem(incaseofreconfigurationscenario),orcreatenew resource combinations that match with the requirements. As an output,it providesthematchmakingresult. It includestheIDsof theresourcesandresourcecombinationsmatchingtoeachprocess stepdefinedinthePRD.

The matchmaking isa time-consumingprocess, andtherefore the interaction was implemented as asynchronous calls. Fig. 3 showstheinteractionbetweenanexternalapplication(client)with

ofreconfigurations,orcosts.Thedesignerwillthenallocatethere- sources tospecificproductiontasksandworkstations. Thematch- makingprocesscanberepeated,withdifferentinputs,untilallthe tasks haveamatchorotheroptimizationcriteriaforresourcese- lectionisachieved.

The matchmaking resultdelivered to the clientdoes not con- sidertheallocationofresourcesforaspecificprocesssteporwork- station. It dealseach process step individually,andthus it isthe dutyoftheclientapplication(orthedesigner)toconsidertheop- timumresourceallocationandlayoutoftheproductionsystem.For example,ifthedesignerallocatesaresourceinstancetoaspecific processstepandaphysicallocation(e.g.workstation),he/shecan- not usethesameresourceforsomelaterprocessstepindifferent location,withouthavingmoreresourceinstancesofthesamekind.

Inthissense, thematchmakingresultdelivers onlypotentialpos- sibilities fromtheperspectivesofcapabilityparametersandphys- ical interfaceconnectivity,andtheclientapplication(or designer) needs to ensurethat the productionsystemcan actually be built fromtheavailableresources.

DuringtheReCaMproject,interactionofthematchmakingsys- temwithtwoclientapplicationswastested.TheseweretheFlex- ible SystemEngineeringPlatformmeantforgreenfieldsystemde- sign, andIntegratedReconfigurationandProductionPlanning tool intendedforbrownfieldsystemdesign(Colledanietal.,2018).See (Järvenpää etal.,2019b)formoredetailsoftheinteractiontesting.

4. Matchmakingcaseexample

This section will explain the usage and internal functionality of the matchmaking system by an example scenario. In the sce- nario, the production system designer designs a new production system for a switch valve assembly process and utilizes the ca- pability matchmakingsystemtofindfeasibleresources and/orre- sourcecombinations.Thefiguresshowrealtestdatafromrunning thematchmakingsystemthroughitswebserviceinterface.

Fig. 4a demonstrates the inputs provided by and outputs re- ceived by the client system. The left side of Fig. 4a illustrates the matchmakingrequest andrightside the matchmakingresult.

Firstly, the requestcontainsa referencetothe PRDofthe switch valve product. This PRD contains all the process steps and their requirements included in the valve assembly process, butfor il- lustration, wefocushereonone processstep“sticksub-assembly screwing” (greenarrow).ItrequiresscrewingaM6hexagonsocket headscrewtotheendtorquebetween13and17Nm.ThePRDis graphically illustrated inthe top left cornerofFig. 4a.The lower left cornerillustrates theactualrequestmessagesentthroughthe webserviceinterfaceinXML-format.

Secondly,therequestcontainsreferencetotheresourcesearch space. In brownfield case it wouldbe an existing systemlayout, butinthiscasethedesigner isworkingwithgreenfieldcase, and such productionsystemdoesnotexist.Thus, he/sheselectssome productionresourcecatalogue(s)andspecificresources(ifnotall), andcreatesaResourcePooloutofthem(Fig.3/Sequence1).The

makingsoftware(i-iv).Whilecreatingthesecombinations,match- making software willsimultaneously check that theinterfaces of theresources arecompatible,andthe resourcescan bephysically connected.Incaseoftheresourcecombination(ii)onthesecond phase,thetoolbitdoesnotfitintothescrewdriver’stoolinterface andthustheincompatiblecombinationfrominterfaceperspective isfilteredout.

Afterthat,thematchmakingsystemwillcalculatethecombined capability parameters for the remaining combinations andcheck thatthecapabilityparametersmatchwiththeparametricrequire- mentsoftheproduct.Duringthecombinedcapabilitycalculation, the matchmaking system considers each individual resource and calculatestheviablerangeforthewholecombination.I.e.ifatool bitcan bear onlya certaintorque,it willlimit theoverall torque forthewholecombination.ThecombinedcapabilitySPINrulesare used forinferring the combinationparameters andmatchmaking SPIN rules are used to compare the parametric requirements of the productwith thecapability parameters. Inthis examplecase thematchmakingsystemwillcheckthatthescrewtypeandscrew head size matches with the tool type and size and that the re- quiredtorqueis withinthe rangeoftheprovided torque.Unsuit- ableresourcesandresourcecombinationsareagainfilteredout.In thiscasethecombinationpossibility(i) (inphasethree) doesnot provideenoughtorque,anditiseliminatedfromthisresult.Inthe end, only two resource combinations are left as feasible sugges- tions inthe matchmaking result. The alternative(iv) isthe same thatisvisualizedasaresultinFig.4a.

5. Discussionandconclusions

We presented the implementation of a capability matchmak- ing software and its interaction with external design and plan- ning toolsthrough its web service interface. This servicecan be exploitedbothduringgreenfieldandbrownfieldsystemdesign,to automatizethe searchfor suitableresources andresource combi- nations forspecific product requirements. The matchmaking sys- temutilizesformalOWL-basedinformationrepresentationsofboth products and resources, and SPIN rules to infer new knowledge from those representations. The matchmaking service and soft- ware take inputs fromdifferent clientsystems, executes the var- ious rules needed duringthe matchmaking process, and delivers theresultsbacktotheclients.

The developed approach contributes to the existing resource virtualization and matchmakingresearch by providing means for modellingandreasoningaboutthecombinedcapabilitiesofmul- tiple co-operating resources. It describesthe parameters relating tothecapabilities, andutilizesSPINrulestoinferthe parameters ofcombinedcapabilitiesfromtheparameters ofthesimplecapa- bilities andto insertthem to themodel. It isa unique approach andimplementation, which hasnot beenpresented by other re- searchers. Similar conceptual ideas for capability matching have been presented, e.g. in (Ameriand Patil, 2012). The main differ- ence, however, lies in the ability to automatically manage com-

Fig. 4. a) Matchmaking request and result; b) Internal process in the matchmaking system.

bined capabilities. First of all, it allows the resources to be de- scribedonalower levelofgranularity,andsecondly,iteliminates the needtodescribe thecombinedcapabilitiesmanuallyforeach possible resourcecombination. The resourcecombinationscan be dynamicallycreatedforcertainrequirementsbasedonthedescrip- tionsofthesingleresources.

Thecapabilitymatchingreasoningactions,discussedinthispa- per, can be performed automatically based on the defined SPIN rules.However,theresultsshouldbevalidatedbyhumandesigner duringthelayoutdesignandresourceselection,astheinformation modelsandrulesarealwaysasimplifiedrepresentationofthereal world.Someofthecapabilitiesdependonthephysicallocationbe- tween the combined resources. This informationis not currently handledwiththeResource Model,andcannotthusbetakeninto considerationduringthematchmaking.

Despite theseinaccuraciesinthe combined capabilitycalcula- tionandcapabilitymatchmaking,thepresentedapproachcanpro- videavaluableaidforthesystemdesigner.Itgivesapossibilityto automatically explore large resource catalogues and rapidly filter out the unsuitable resources, leaving only the possible resources andresourcecombinationsforthegivenrequirement.Thedesigner doesn’t needto doparameterorinterface compatibilitychecking, butmayconcentrateonthelayoutplanningandfinalresourcese- lection.Consequently,lessmanualandtime-consumingsearchand

filteringeffortisneededto findandevaluate differentalternative solutions, andmore alternative configurations can be considered, comparedtotraditionaldesignapproach,leadingtopotentiallyin- novativesystemsolutions.Thus,we expectthepresentedcapabil- itymatchmakingapproachandsoftwaretoeaseandspeedupthe systemdesignandreconfigurationplanningprocess.

Inthefuture,newindustrialprojectswillbeestablishedtotest the matchmakingapproach and softwarein wider industrial set- tingscoveringlargeramountofdifferentprocesscapabilities. Fur- thermore,thereliabilityandinformationcontentofthematchmak- ingresultshould beincreasedby extendingthecurrentapproach with automatic layout generation for feasibility checks and pro- cessingtimeestimations.

DeclarationofCompetingInterest None

Acknowledgments

Thisresearch hasreceived fundingfromthe European Union’s Horizon2020researchandinnovationprogramundergrantagree- mentno680759andprojecttitleReCaM(RapidReconfigurationof FlexibleProduction Systemsthrough Capability-based Adaptation, AutoconfigurationandIntegratedToolsforProductionPlanning).

Ameri, F. , McArthur, C. , 2014. Semantic rule modelling for intelligent supplier dis- covery. Int. J. Comput. Integr. Manuf. 27, 570–590 .

Ameri, F. , Patil, L. , 2012. Digital manufacturing market: a semantic web-based framework for agile supply chain deployment. J. Intell. Manuf. 23, 1817–1832 . Ameri, F. , Urbanovsky, C. , McArthur, C , 2012. A systematic approach to developing

ontologies for manufacturing service modeling. Proc. Work. Ontol. Semant. Web Manuf. 1–14 .

Apache Software Foundation, Apache Jena – A free and open source Java frawe- work for building semantic web and linked data applications. 2017. Available in: https://jena.apache.org/ [Accessed 10.8.2017].

Colledani, M. , Yemane, A. , Lugaresi, G. , Borzi, G. , Callegaro, D , 2018. A software plat- form for supporting the design and reconfiguration of versatile assembly sys- tems. Proc. CIRP 72, 808–813 .

Järvenpää, E. , Siltala, N. , Hylli, O. , Lanz, M , 2018a. The development of an ontology for describing the capabilities of manufacturing resources. J. Intell. Manuf. 30, 959–978 .

Järvenpää, E. , Siltala, N. , Hylli, O. , Lanz, M , 2018b. Product model ontology and its use in capability-based matchmaking. Proc. CIRP 72, 1094–1099 .

Järvenpää, E. , Siltala, N. , Hylli, O. , Lanz, M , 2018c. Utilizing SPIN rules to infer the parameters for combined capabilities of aggregated manufacturing resources.

IFAC-PapersOnLine 51, 84–89 .

manufacturing system. Int. J. Adv. Manuf. Technol. 69, 961–975 .

Openllet API. Available in: https://github.com/Galigator/openllet . [Accessed 26.2.2019]

Siltala, N. , Järvenpää, E. , Lanz, M , 2018a. Creating resource combinations based on formally described hardware interfaces. In: Ratchev, S. (Ed.). In: Precision As- sembly in the Digital Age. IPAS 2018. IFIP Advances in Information and Commu- nication Technology, 530. Springer, Cham, pp. 29–39 .

Siltala, N. , Järvenpää, E. , Lanz, M , 2018b. Value proposition of a resource description concept in a production automation domain. Proc. CIRP 72, 1106–1111 . SPIN working group, SPIN – SPARQL Inferencing Notation. 2017. Available in: http:

//spinrdf.org/ . [Accessed 15.10.2017].

Sure, Y. , Staab, S. , Studer, R , 2009. Ontology engineering methodology. In: Staab, S, Studer, R (Eds.), Handbook on Ontologies, pp. 135–152 .

Tao, F. , Qi, Q. , Liu, A. , Kusiak, A , 2018. Data-driven smart manufacturing. J. Manuf.

Syst. 48, 157–169 .

Yuan, M. , Deng, K. , Chaovalitwongse, W.A , 2017. Manufacturing resource modeling for cloud manufacturing. Int. J. Intell. Syst. 32, 414–436 .