The University of Manchester Research

A Rule-Based Approach Founded on Description Logicsfor Industry 4.0 Smart FactoriesDOI:10.1109/TII.2019.2916622

Document VersionAccepted author manuscript

Link to publication record in Manchester Research Explorer

Citation for published version (APA):Kourtis, G., Kavakli, E., & Sakellariou, R. (2019). A Rule-Based Approach Founded on Description Logics forIndustry 4.0 Smart Factories. IEEE Transactions on Industrial Informatics, 15(9), 4888-4899.https://doi.org/10.1109/TII.2019.2916622

Published in:IEEE Transactions on Industrial Informatics

Citing this paperPlease note that where the full-text provided on Manchester Research Explorer is the Author Accepted Manuscriptor Proof version this may differ from the final Published version. If citing, it is advised that you check and use thepublisher's definitive version.

General rightsCopyright and moral rights for the publications made accessible in the Research Explorer are retained by theauthors and/or other copyright owners and it is a condition of accessing publications that users recognise andabide by the legal requirements associated with these rights.

Takedown policyIf you believe that this document breaches copyright please refer to the University of Manchester’s TakedownProcedures [http://man.ac.uk/04Y6Bo] or contact uml.scholarlycommunications@manchester.ac.uk providingrelevant details, so we can investigate your claim.

Download date:12. Dec. 2020

1

A Rule-Based Approach Founded on DescriptionLogics for Industry 4.0 Smart Factories

Georgios Kourtis, Evangelia Kavakli, and Rizos Sakellariou, Member, IEEE

Abstract—This paper develops a formal framework, foundedon description logics, to assist decision making in relation to themanufacturing operation and control in modern enterprises thatstand to benefit from the transition to Industry 4.0. The objec-tive is to provide sophisticated support to individuals makingdecisions in the area of production operations management andin particular production scheduling and material requirementsplanning. Using this framework, the paper demonstrates anapproach to encode the domain knowledge of human expertsmanaging the production as sets of formal rules. These rulescan be implemented in an intelligent system that can assistand empower human experts, reducing difficulty when makingdecisions in complex manufacturing environments.

Index Terms—Industry 4.0, description logics, industrial pro-duction modelling.

I. INTRODUCTION

Modern industrial production is undergoing radical changes,due to the advent of new technologies such as cloud com-puting [40], the Internet of Things [12], and cyber-physicalsystems [27]. The emerging new ways of production areusually classified under the term Industry 4.0 [20]. Oneof the motivating challenges of Industry 4.0 is to providefaster time to market while responding to a rise in consumerdemand. This requires an optimal utilization and orchestrationof industrial resources as well as quick response to disruptionsin production.

Traditionally, decision making in relation to productionand resource management relies on human experts who aresupported by specialized software, such as business processesmanagement [42], database and data analytics [30], or en-terprise resource management software [14], [38]. Despitethe abundance of such software, the complexity of mod-ern industrial tasks combined with an exponential growthof available information related to production (e.g. due toadvances in computer-integrated manufacturing and cyber-physical systems) makes it exceedingly difficult for humans

Georgios Kourtis is with the Department of Computer Science, Uni-versity of Liverpool, Liverpool L69 3BX, United Kingdom (e-mail:G.Kourtis@liverpool.ac.uk).

Evangelia Kavakli is with the Department of Cultural Technology andCommunication, University of the Aegean, Mitilini 81100, Greece (e-mail:kavakli@ct.aegean.gr) and with the School of Computer Science, The Uni-versity of Manchester, Manchester M13 9PL, United Kingdom (e-mail:evangelia.kavakli-2@manchester.ac.uk).

Rizos Sakellariou is with the School of Computer Science, The Uni-versity of Manchester, Manchester M13 9PL, United Kingdom (e-mail:rizos@manchester.ac.uk).

Manuscript received November 20, 2017; revised June 20, 2018; acceptedApril 10, 2019.

The work in this paper was partially supported by the H2020 project DIS-RUPT (project no 723541). Georgios Kourtis would also like to acknowledgesupport from the FAIR-SPACE EPSRC project (EP/R026092/1).

to make optimal decisions. Nevertheless, the knowledge ofexperts remains an indispensable part of production planning.It is sensible, then, to consider whether the domain knowledgeof human experts responsible for organizing the production canbe systematized and incorporated into intelligent systems, soas to enable sophisticated decision making in complex settings.

We argue that any attempt for a systematic representation ofthe knowledge in the above domain would benefit from recentadvances in knowledge representation. For, any intelligentsystem that aims to encapsulate human expert knowledge hasto be able to perform reasoning. Reasoning, in the contextof intelligent systems, is the process in which a systemautomatically makes logical deductions based on rules andfacts in a given universe of discourse. In general, reasoningproblems are known to be among the hardest when it comes totheir computational complexity [7]. Thus, apart from providingan effective way to represent and store knowledge, an ad hocintelligent system for the management of production also hasto implement an optimized reasoner, which is an error-proneand difficult task [4], [5]. It is our view that to facilitate thetransition to the Industry 4.0 vision, manufacturing enterprisescan benefit from a generic, standardized formalism for thedescription of their organizational structure with regard toproduction. Most importantly, such a formalism could lay thefoundations for the implementation of an intelligent productionmanagement system, i.e., a system capable of reasoning basedon facts and sets of predefined rules, an application area thathas not yet received much attention. Unfortunately, at themoment, there is no widespread formalism of this kind.

Existing approaches (e.g. [8], [19], [29]) mainly focuson describing the entities involved in production and theirinteractions; that is, their main concern is modeling rather thanhow modeling can enable reasoning. Although modeling ishelpful for humans to structure their understanding of a givendomain, it is not sufficient on its own to assist in decisionmaking. In this respect, the main focus in this paper is tomodel knowledge in such a way that it enables reasoning.Our intention is to lay the foundations for an automatedsystem which, based on predefined facts and rules set bydomain experts, can make logical deductions and, by thosedeductions, assist decision making in a modern manufacturingenvironment, also catering for situations of disruption in theproduction or in the supply chain.

To this end, our contribution is twofold. First, we demon-strate how to build a formal framework based on descriptionlogics [4]. To keep the size of the problem manageable,we limit our scope to two aspects of production manage-ment, namely production scheduling and material requirements

2

planning. Special attention is placed on the modeling ofthe temporal progression of production, while the use ofdescription logics increases the practical effectiveness of theproposed framework as it can be relatively easily implemented.Second, we prescribe how to build, using the above formalism,a knowledge base (comprising various facts and rules) basedon which a reasoner can derive, for a given productionenvironment, the actions that need to be performed at a givenpoint in time or in response to an event. Using our framework,a manufacturing enterprise whose production is managed bya team of experts can encode the domain knowledge of theseexperts as sets of rules and, based on these rules, delegatemany important decisions to an intelligent system. Such deci-sions may range from simple tasks (such as arranging to ordera material when it runs out) to complex responses to events(such as dynamically distributing orders for a given materialto new suppliers when a given supplier is unable to fulfill arequest). The proposed approach consolidates and generalizesthe requirements of two end-users from the automotive andthe white goods sector in the context of the EU-fundedH2020 project DISRUPT1. The project aims to develop acomprehensive data-driven solution for automated vertical andhorizontal integration, facilitating the transition into smartmanufacturing [25]. It has a specific focus on decision makingin case of disruptions in production.

Description logics [4] were chosen as the formal underpin-ning of our approach because of their wide use in knowledgerepresentation. These languages are expressive enough tomodel complex situations while retaining good practical per-formance (and reasonable worst-case performance comparedto other expressive formal languages such as fragments of first-order logic). They also support various query languages andso-called justifications [21], i.e., human-readable explanationsof deduced facts. Thus, monitoring and understanding theactions of an intelligent system based on description logicsis relatively straightforward. In addition, there is an ongoingline of research to adapt description logics for reasoning withuncertainty (probabilistic description logics [35]), which mayturn out to be useful in the industrial setting, as modernproduction environments involve various degrees of uncer-tainty, often making these environments hard to model withdeterministic formal languages.

The remainder of the paper is structured as follows. InSection II we discuss related, knowledge-driven approachesto modeling various aspects of industrial production usingformal languages. Section III describes the abstract model ofproduction on which our approach is based and presents ageneral architecture for the type of intelligent system that wepropose. Section IV demonstrates how to build a knowledgebase using the above formalism. Section V discusses howto extend the above knowledge base with rules to form acomplete intelligent system and give some examples of rulesfor three specific use cases. Finally, Section VI concludes thepaper and discusses possible extensions of this research.

1http://www.disrupt-project.eu/

II. RELATED WORK

It has long been understood that the high complexity ofmodern industrial tasks makes it exceedingly difficult forhumans to organize and supervise the production in modernenterprise environments. As a result, there have been variousattempts to formalize different aspects of production, aimingto assist humans in their decisions and also as a first steptowards automating human tasks. Yet, manufacturing decisionsstill rely heavily on the knowledge of experienced engineers,something that results in prolonged lead-time and increasedengineering costs [16]. It has also been reported that enter-prises are often unaware of the extent of in-house knowledge,whilst different sources of information regarding products,processes, and resources are not effectively coupled [15].

Knowledge-driven approaches that adopt formal knowledgemodels such as ontologies have been proposed as enablers ofintelligent decision making. Formal knowledge models providea shared vocabulary between distributed systems thus enablingknowledge sharing and reuse. Furthermore, they support theexpression of domain specific rules that allows carrying out au-tomated reasoning procedures on the specified knowledge [3],[24], [41], [46]. As such, they are more powerful tools than theconceptual schemas defined in industry standards (e.g. ISA-95 [39]), which focus on the structure and not the semanticsof the manufacturing knowledge. Along these lines, a numberof publications report on the application of ontologies inspecific aspects of production, including: [17], [23], [43]–[45]on supply chain management; [2] on supply chain deployment;[11], [26], [32] on evolvable or reconfigurable productionsystems or processes; [36] on telecommunications productconfiguration; [31] on inter-enterprise collaboration; and [1] oninformation interoperability (introducing MSDL, the Manufac-turing Service Description Language). Although the proposedapproach has been informed by such works, it is not meant toprovide a generic production ontology, rather it is driven bythe specific requirements of our end-users.

In terms of modeling the whole production environment inan enterprise using a formal framework, proposed approachesinclude ADACOR [8], [9], [28], MASON [29], and ARUM[19], [37]. ADACOR (ADAptive holonic COntrol aRchitec-ture) enables the formal description of a production environ-ment using sets of autonomous, cooperative ‘holons’ corre-sponding to physical entities (e.g. machines or equipment)and logical entities (e.g. orders). The foundational frameworkfor this formalism is first-order logic, which makes it hardto use in an intelligent system because reasoning in first-order logic is an undecidable problem (i.e., it is unsolvableby computational means) [7]. In addition, even in restrictedcases where reasoning in first-order logic is possible, it ishard to incorporate in it data types (to reason, for example,about dates, numbers, etc.), thus making it unsuitable inpractice. MASON (MAnufacturing’s Semantics ONtology) isan ontology aiming to formalize the entities, processes, andresources involved in an enterprise production environment.Its formal underpinning is the OWL Web Ontology Language[18], which is founded on top of description logics. Thus,this approach is close to the ideas underpinning our proposal.

3

However, MASON focuses mainly on structural aspects ofproduction (e.g. the individual parts that constitute a productor production operation), neglecting behavioral aspects suchas the temporal progression of production. As such it is notsuitable for modeling production scheduling. In addition, theauthors state that MASON has been used to automaticallyestimate the cost of new products; reasoning on top of theontology is not a central consideration, which, in contrast, isimportant to our paper.

ARUM (Adaptive Production Management) [19], [37] is aproject that aims to improve planning and control for industrialtasks in the context of aircraft manufacturing. It incorporatesthree main ontologies, the core ontology (aiming to describethe main aspects of production), the scene ontology (aiming todescribe the state of production at a given point in time), andthe events ontology (aiming to describe the entities involvedin events related to production). Although this approach iscloser to ours compared to the first two (i.e., ADACOR andMASON), there are differences that made it hard to adapt forour purposes. In particular, ARUM ontologies are descriptivein nature, in a sense that they provide the required means fordescribing concepts used by operational planners and sched-ulers. However, they do not aim to describe how, when, andin what way scheduling and material requirements planningtakes place. In contrast, we attempt to formalize these issuesand even describe formally the interactions with schedulingand material requirements planning software. Furthermore, weaim to provide a formal framework that takes into accountthe temporal progression of the production and describeshow the progression is affected by disruptions to schedulingand material requirements planning. Finally, ARUM does notincorporate rule reasoning to encode the domain knowledgeof experts.

III. ASSUMPTIONS AND MODEL OF PRODUCTION

This section describes an abstract model of production onwhich the proposed approach is based and describes the highlevel architecture of a system implementing our approach.Recall from Section I that the aim is to develop a formalframework which: (i) can effectively describe the structure ofproduction knowledge with an emphasis on scheduling andmaterial requirements planning aspects; (ii) can effectivelymodel the temporal progression of production; and (iii) ispractical and easy to implement.

The initial motivation for these requirements stems from ourinvolvement in the DISRUPT project and reflects the strategicobjective of the two end-user companies, namely “to improvethe ability to have the materials and capability to producewithout interruption”. In more detail, the first company isan automotive manufacturer with multiple production sitesin several countries. Production planning and scheduling areautomated to a large degree according to the capabilities ofthe current software configuration. However, disruptions ineither inbound logistics or production, such as stock-outs orchanges in the delivery of components, may affect the carunits produced per person hour, something that may proveto be costly for the manufacturer. The actions to mitigate

these disruptions usually involve rescheduling the productionand rearranging/reviewing orders of materials. The secondcompany is a manufacturer of electronic boards used in severalplants that produce home appliances. Due to market-drivenrequirements, there is great variability in the received ordersfrom customer plants. More specifically, the quantities can bechanged as well as the type of units requested. For example,a new unit is often added in the same order a few days beforedelivery time, or ‘urgent orders’ may appear at short notice.As a result, production at the electronics factory needs to berescheduled frequently. A more elaborate description of thetwo use cases and their requirements can be found in [13],[33].

Taking into account the above, the following realistic as-sumptions are made to build the knowledge base. Theseassumptions are not meant to be generic; their main purposeis to use them to illustrate the proposed formal framework.Recall that, in the proposed framework, decision making thatcan help take appropriate actions has a central position, bothin the level of modeling and in the level of reasoning.

(a) A manufacturing enterprise owns multiple factories (man-ufacturing facilities) and each factory produces productsthrough production lines.

(b) Each production line involves certain machines, low levelequipment (tools), and personnel.

(c) Products are produced using parts and materials. Theparts are intermediate products produced by the enter-prise; the materials are ordered from external suppliers.

(d) Products and parts, as well as materials that have beendelivered, are stored in warehouses (inventories).

(e) The production is centered around a production plan,which is set by the management and dictates how manyunits of each product must be produced on given dates.

(f) To organize the production, a production schedule is de-rived from the production plan using scheduling software.The schedule is maintained for a fixed time period of Tdays. The schedule determines, for each day of this fixedtime period, the allocation of resources for the productionof a given family of products or parts.

(g) To accommodate the material requirements of the pro-duction, orders of materials are arranged by specializedsoftware for material requirements planning.

(h) The production is supervised by a team of experts,who are responsible for ensuring that everything goesaccording to plan. It is also their responsibility to devise acourse of action in response to any disruption that arisesin production.

The role of the experts in the above model of productionis summarized in Fig. 1. In this case, the experts have acentral position, supervising and organizing the productionwith the help of material requirements planning and schedulingsoftware (respectively, M.R. PLANNER and SCHEDULER inFig. 1); they are also responsible for devising an appropriateaction in response to an event.

The change that this paper advocates is shown in Fig. 2.In this case, the knowledge base plays a central role: it isresponsible for arranging necessary actions at each point where

4

EXPERTS

EVENT

M.R. PLANNER

SCHEDULER

ACTION

Fig. 1. Production wholly managed by a team of experts.

CONTROLLER

EVENT

KNOWLEDGEBASE & RULES

M.R. PLANNER

SCHEDULER

ACTION

EXPERTS

Fig. 2. Production centered around a controller/knowledge base.

a decision has to be made. The way that the knowledge basedetermines what needs to be done is by reasoning, based onthe facts it contains and a set of rules encoding the knowledgeof domain experts.

The interface between the knowledge base and other com-ponents is the CONTROLLER. The controller updates theknowledge base with the ‘state of the world’ at each pointin time, and is responsible for executing any action that theknowledge base determines to be necessary. For example, theknowledge base might determine that, given the circumstancesat a given point in time and based on the rules it must follow,the production of a certain product must be rescheduled. Thus,it is convenient to view the knowledge base and the controlleras a unit, hence the use of a thick double arrow connectingthese two components.

Experts in this model are responsible for setting and updat-ing the rules of the knowledge base, and may not always bedirectly involved in production management. For this reason,the experts are depicted using dashed lines in Fig. 2. In specialcases, the experts are able to override the function of thecontroller; this is also denoted in Fig. 2 with a double dashedarrow connecting the experts and the controller.

IV. BUILDING THE KNOWLEDGE BASE

This section provides a high-level description of a knowl-edge base corresponding to the description of the productionenvironment given in Section III. For our knowledge base,we adopt the open-world assumption by standard convention.Recall that a knowledge base consists of a set of terminologicalaxioms (called the TBox), a set of assertions (called the ABox),

and, often, in conjunction with these sets, a set of rules(involving relevant terms and individuals) in an appropriatelanguage.

For a detailed example in RDF/XML syntax of ourknowledge base we refer to https://github.com/disrupt-project/factory. This can be viewed in human-readable formusing Protege2 or other such programs.

A. Basic concepts and roles

The first step towards building our knowledge base is theidentification of the entities involved in production and theirarrangement in a conceptual hierarchy. Based on the produc-tion environment described in Section III, our knowledge basefeatures the following concepts. Note that these concepts arenot meant to be a substitute for comprehensive work such asthe ISA-95 standard [39] or other standardized activities [34].These concepts are derived through our project requirementsanalysis and they are supposed to provide a concise, yetmeaningful set to illustrate the feasibility of the proposedframework in this paper. To a large extent they can be easilymapped to the concepts of the ISA-95 standard as explainednext.

Factory Each individual of this concept corre-sponds to a factory, i.e., a physical, geo-graphical, or logical grouping determinedby the enterprise.

Machine Each individual of this concept corre-sponds to a machine, i.e., a specifictype of automated resource with specificcapability.

Equipment Each individual of this concept corre-sponds to a piece of equipment, i.e., alower-level resource not defined in ISA-95, might be a tool.

ProdLine Each individual of this concept corre-sponds to a production line, i.e., a series ofpieces of machines dedicated to the man-ufacture of a specific number of productsor families of products.

Personnel Each individual of this concept corre-sponds to a person (worker), i.e., a humanresource with specific capability.

Material Each individual of this concept corre-sponds to (possibly raw) material that isused in the production of a part or product.

Part Each individual of this concept corre-sponds to a part produced in a givenfactory. Parts are used with materials whenproducing products, they can be viewed asintermediate materials.

Product Each individual of this concept corre-sponds to a final product.

2https://protege.stanford.edu

5

Plan This concept is used to group individualdays of the monthly production plan forany given factory.

Schedule This concept is used to group individualdays of the monthly production schedule(i.e., the allocation of resources) for eachproduction line of any given factory.

Order This concept is used to track daily orderarrangements to enable the production ofa product or part in a given factory.

Event This concept is used to refer to eventshappening (in production) on individualdays of a month.

Warehouse Each individual of this concept corre-sponds to a warehouse.

We now introduce several roles for the formal descriptionof various basic aspects of the production. We start withsome abstract roles, which we use for a general description ofthe production, i.e., the arrangement of machines, equipment,and workers into production lines, and the dependencies forproducts:

hasProdLine To specify the production lines ina factory.

hasMachine To specify the machines used in aproduction line.

hasEquipment To specify the equipment used in aproduction line.

hasPersonnel To specify the personnel workingin a production line.

requiresPart To specify the parts required toproduce a certain product.

requiresMaterial To specify the materials required toproduce a certain product.

isAvailable To specify the availability of agiven machine, piece of equipment,or person (worker).

producedIn To specify the production line inwhich a product or a part is pro-duced.

Using the above roles, the knowledge base (and, in partic-ular, its TBox for the rest of this subsection) contains conceptinclusions specifying that: a factory contains at least one pro-duction line; a production line consists of machines and alsoutilizes equipment and workers; a product (or part) requiresparts and materials; materials, parts, and products are stored ina warehouse; each material, piece of equipment, and personnelhas an ‘availability status’ which is of type boolean (i.e., it istrue or false). Fig. 3 contains a diagrammatic representationof these inclusions (dashed lines represent optional roles).

The above inclusions give a qualitative description of theproduction. For a quantitative description, i.e., for the materialrequirements of products and the production schedule, we

Fig. 3. Concepts and roles involved in the production of products and parts.Dashed lines indicate optional roles.

need to introduce some concrete roles. The first concrete rolesthat we introduce are used to record how many parts andunits of materials a given product (or part) requires for itsproduction. To this end, suppose that a company C requiresfor the production of its products the parts Part1, . . . ,Partζand the materials Mat1, . . . ,Matη . We introduce, for each i(1 ≤ i ≤ ζ) and j (1 ≤ j ≤ η), the following roles:

requiredUnitsOfParti To specify the number ofunits of the part Part i re-quired for the production ofa given product.

requiredUnitsOfMaterialj To specify the number ofunits of the material Matjrequired for the production ofa given product.

inventoryUnitsOf To specify the number ofunits of a product, part, ormaterial that are available inthe inventory.

Based on the above roles, the knowledge base containsconcept inclusions stating that each individual of the conceptProduct (corresponding to a product) or Part (correspondingto a part) has, for each i (1 ≤ i ≤ ζ), a data propertyrequiredUnitsOfParti of type integer, which we shall interpretas the number of units of the part Part i required for theproduction of the corresponding product or part; and, similarly,the data property requiredUnitsOfMaterialj (1 ≤ j ≤ ξ)records the number of units of the material Matj required forthe production of that product or part. Similarly, inclusionsinvolving the roles inventoryUnitsOf state that each product,part, or material has a data property that records how manyunits of this product, part, or material are in the inventory.Fig. 4 contains a diagrammatic representation of these inclu-sions.

As described in Section III, the production is organizedaround a set of goals about how many units of each productshould be produced in any given factory. This set of goalsis set by management for every single day of a given monthand encoded in the knowledge base using individuals of the

6

Fig. 4. Roles to describe the production in more detail.

concept Plan. Based on these goals, a production schedule(which specifies the allocation of resources within each factoryfor the production of a given product) arises as well asa set of order arrangements to accommodate the materialrequirements of the production schedule. The schedule and theorder arrangements are encoded in the knowledge base usingindividuals of the Schedule and Order concepts, correspondingto individual days of the schedule and order arrangements,respectively.

We now introduce the roles to encode all the rele-vant information for the concepts Plan, Schedule, and Or-der. Supposing that the company produces the productsProd1, . . . ,Prodξ and the parts Part1, . . . ,Partζ using thematerials Mat1, . . . ,Matη , we introduce for each i (1 ≤ i ≤ξ), j (1 ≤ j ≤ ζ), and k (1 ≤ k ≤ η) the following roles:

produceUnitsProdi To specify the number of unitsof the product Prod i that themanagement wants to produce.

scheduleUnitsProdi To specify the number of unitsof the product Prod i that needto be scheduled.

scheduleUnitsPartj To specify the number of unitsof the part Partj that need to bescheduled.

schedStartTimeProdi To specify a start time for theproduction of the product Prod i.

schedEndTimeProdi To specify an end time for theproduction of the product Prod i.

schedStartTimePartj To specify a start time for theproduction of the part Partj .

schedEndTimePartj To specify an end time for theproduction of the part Partj .

orderUnitsMaterialk To specify the number of unitsof the material Matk that mustbe ordered.

Based on the above roles, the knowledge base containsconcept inclusions determining the possible data properties forindividual plan, schedule, and order days. In particular, it con-tains inclusions stating that each individual plan day may have,for each product Prod i, a data property produceUnitsProdiof type number, which, as discussed above, is meant tospecify the number of units of the product Prod i that haveto be produced. The knowledge base also contains similarinclusions for the data properties scheduleUnitsProdi andscheduleUnitsPartj .

Additionally, the knowledge base contains inclusions as-sociated with days of the production schedule that definethe data types of relevant data properties. Using these prop-erties it is possible to specify a schedule to produce theproduct Prod i (resp. the part Partj), in the form of (pos-sibly multiple) intervals [start-time, end-time], where start-time is of data type time and specified by the data propertyschedStartTimeProdi (resp. schedStartTimePartj), and sim-ilarly for end-time and the data property schedEndTimeProdi(resp. schedEndTimePartj).

Finally, the knowledge base contains inclusions stating thateach individual order day may have, for each material Matk adata property orderUnitsMaterialk of type number, which, asdiscussed, is meant to specify how many units of the materialMatk must be ordered this day.

All the inclusions associated with the last set of rolesare depicted in Fig. 5. The properties depicted using dashedlines are built with universal restrictions, thus they are notmandatory; but, if they exist (for a given individual), theircorresponding data types must be as shown. Note that, inthe second sub-figure (in the middle), the arrows labeled withranges of indices (e.g. 1.. ξ) are not single arrows, but representfamilies of arrows involving a different arrow for each of thecorresponding indices (each one pointing to a box labeled‘integer’).

B. Operational workflow

In the architecture we propose (recall Section III), schedul-ing is delegated to external scheduling software and orderingmaterials is delegated to software for material requirements

7

Fig. 5. Concepts and roles to describe the interaction with schedulingand material requirements planning software. Dashed lines indicate optionalproperties.

planning. The expected use of the last set of roles in theprevious section is the following:(a) The roles produceUnitsProdi are used to express the

management’s intention to produce a certain number ofunits of the corresponding product at a given set of days.

(b) This intention is realized as a production schedule gen-erated by the scheduler. That the scheduler should beinvoked (for the corresponding product and with the aimto schedule the given number of units) is signified by thepredicates scheduleUnitsProdi. Note that the schedulermay also schedule the production of parts, as needed.The scheduler, which is assumed to be external to ourframework software and can be viewed as a black box, iscalled with the time needed to produce each product partand its dependencies. Using this input as well as informa-tion about machine configurations and their constraints,the scheduler will use appropriate scheduling algorithmsto generate a plan [6], [10].

(c) If no conflicts arise during (b), the resultingschedule is stored in the knowledge base using theroles schedStartTimeProdi, schedEndTimeProdi,schedStartTimeParti, and schedEndTimeParti.

(d) Further to (b) and (c), the intention to produce a givenproduct (and the parts that it requires) may necessitatethe ordering of materials. This task is delegated to thematerial requirements planner, which arranges the corre-sponding orders.

(e) If no conflicts arise during (d), the resulting set oforders is stored in the knowledge base using the rolesorderUnitsMaterialk.

To make the knowledge base aware of possible conflicts in

the above process, we introduce the following roles:

successSchedProdi To signify the successful gener-ation of the production schedulefor the production of Prod i on agiven day.

successSchedPartj To signify the successful gener-ation of the production schedulefor the production of Partj on agiven day.

successOrderMaterialk To signify a successful comple-tion of order arrangements ofMatk.

Based on the above roles, the knowledge base containsconcept inclusions stating that each day of the schedule mayhave a data property signifying the successful completion of aninteraction with the scheduler (to schedule the production ofa product or part), and if this data property exists it is of typeboolean (i.e. true for success and false for failure); similarly,each day of the concept Order (corresponding to orders) mayhave a data property signifying the successful completion ofan interaction with a material requirements planner, and if thisdata property exists it is of type boolean as above. To simplifythe ensuing analysis, we will assume that no failures occurwhen interfacing external programs, although it is not hard toincorporate possible failures in rules if one wishes to do so.

C. Individuals and assertionsAs detailed in the previous section, the production within a

company of a particular type (as in Section III) can be formallydescribed in a knowledge base using various sets of conceptinclusions. These inclusions describe the individual entitiesinvolved in production and how individuals of certain conceptsare expected to relate to individuals of other concepts. We nowstart building the assertional part of such a knowledge base: weintroduce the individuals themselves for each concept definedearlier and we define relations among those, thus completingthe knowledge base.

We start with the introduction of individuals. Let us take theconcepts in Section IV-A, one by one, for a given companyof interest, C.• Factory: Suppose that C owns the factories F1, . . . , Fn

(n is a positive integer); for each factory Fϕ (1 ≤ ϕ ≤ n)we introduce an individual Fϕ. Thus, the set

A0 = {Factory(Fϕ) | 1 ≤ ϕ ≤ n},

contains the assertions that each of these individualsbelongs to the concept Factory.

• Machine: Suppose that each factory Fϕ (1 ≤ ϕ ≤ n)contains the machines Mϕ

1 , . . . ,Mϕµϕ

. Associating to eachof those machines an individual Mϕ

µ (1 ≤ µ ≤ µϕ), theset

A1 = {Machine(Mϕµ) | 1 ≤ ϕ ≤ n, 1 ≤ µ ≤ µϕ}

contains the assertions that each individual Mϕµ belongs

to the concept MFactoryϕ and, thus, corresponds to amachine (namely, Mϕ

µ ) at the factory Fϕ.

8

• Equipment: Suppose that each factory Fϕ owns the piecesof equipment Eϕ1 , . . . , E

ϕνϕ (1 ≤ ν ≤ νϕ). As in the

above, the set

A2 = {Equipment(Eϕν ) | 1 ≤ ϕ ≤ n, 1 ≤ ν ≤ νϕ}

contains the corresponding assertions.• ProdLine: Suppose that the production lines in the factoryFϕ are Lϕ1 , . . . , L

ϕλϕ

(1 ≤ λ ≤ λϕ). Then, the set

A3 = {ProdLine(Lϕλ) | 1 ≤ ϕ ≤ n, 1 ≤ λ ≤ λϕ},

contains the corresponding assertions.• Personnel: Suppose that the personnel working in produc-

tion at the factory Fϕ are Pϕ1 , . . . , Pϕκϕ

(1 ≤ κ ≤ κϕ).Then, the set

A4 = {Personnel(Pϕκ) | 1 ≤ ϕ ≤ n, 1 ≤ κ ≤ κϕ},

contains the corresponding assertions.• Material: Suppose that the materials used in production

at any factory of the company C are Mat1, . . . ,Matη .Then, the set

A5 = {Material(Mati) | 1 ≤ i ≤ η},

contains the corresponding assertions.• Part: Suppose that the parts used or produced at any

factory of the company C are Part1, . . . ,Partζ . Then,the set

A6 = {Part(Parti) | 1 ≤ i ≤ ζ},

contains the corresponding assertions.• Product: Suppose that the products produced by the

company C are Prod1, . . . ,Prodξ. Then, the set

A7 = {Product(Prodi) | 1 ≤ i ≤ ξ},

contains the corresponding assertions.• Plan: Individuals of this concept correspond to individual

days within a fixed time period of T days (as describedin Section III) for each given factory. These days areused to set the production goals (e.g. to produce 200units of the product P25 at the factory F3 on the 18thday of the production period) by the logistics team.Thus, the plan for each factory Fϕ comprises T daysPDayϕ1 , . . . ,PDayϕT ; to these days we associate theindividuals PDayϕ1 , . . . ,PDay

ϕT , respectively. Then the set

A8 = {Plan(PDayϕj ) | 1 ≤ ϕ ≤ n, 1 ≤ j ≤ T},

contains the assertions that each PDayϕj corresponds toa day (namely, PDayϕj ) of the production plan for thefactory Fϕ.

• Schedule: Individuals of this concept correspond to in-dividual days within a fixed time period of T days (asdescribed in Section III) for each given factory. These areused to set the production schedule for each productionday, i.e., to specify the allocation of production linesfor each product within any factory. Thus, if Fϕ isa factory containing the production lines Lϕ1 , . . . , L

ϕ`ϕ

,the production schedule for each production line Lϕj(1 ≤ j ≤ `ϕ) within a given factory Fϕ comprises T

days SPLineDayϕ,j1 , . . . ,SPLineDayϕ,jT ; to these dayswe associate the individuals SDayϕ,j1 , . . . ,SDayϕ,jT , re-spectively. Then the set

A9 = {Schedule(SDayϕ,jk )

| 1 ≤ ϕ ≤ n, 1 ≤ j ≤ `j , 1 ≤ k ≤ T},

contains the assertions that each SDayϕ,jk corresponds to aday (namely, SPLineDayϕ,jk ) of the production schedulefor the line Lϕj in the factory Fϕ.

• Order: Individuals of this concept correspond to indi-vidual days within a fixed time period of T days (asdescribed in Section III) for each given factory. Thesedays are used to arrange orders for the production of eachgiven factory. Thus, the order arrangements for each fac-tory Fϕ consist of T days ODayϕ1 , . . . ,ODayϕT ; to thesedays we associate the individuals ODayϕ1 , . . . ,ODay

ϕT ,

respectively. Then the set

A10 = {Order(ODayϕj ) | 1 ≤ ϕ ≤ n, 1 ≤ j ≤ T},

contains the assertions that each ODayϕj corresponds toa day (namely, SDayϕj ) of order arrangements regardingthe factory Fϕ.

• Event: Individuals of this concept correspond to indi-vidual days within a fixed time period of T days (asdescribed in Section III) for each given factory. Thesedays are used to specify events in production for eachgiven factory. Thus, the production for each factory Fϕconsists of T days EDayϕ1 , . . . ,EDayϕT on each of whichmultiple events can occur; to these days we associate theindividuals EDayϕ1 , . . . ,EDay

ϕT , respectively. Then the set

A11 = {Event(EDayϕj ) | 1 ≤ ϕ ≤ n, 1 ≤ j ≤ T},

contains the assertions that each EDayϕj corresponds toa day (namely, EDayϕj ) on which multiple events canoccur regarding the production in the factory Fϕ.

• Warehouse: Suppose that C owns the warehousesW1, . . . ,Wq (q is a positive integer); for each warehouseWi (1 ≤ i ≤ q) we introduce an individual Wi. Thus, theset

A12 = {Warehouse(Wi) | 1 ≤ i ≤ q},

contains the assertions that each of these individualsbelongs to the concept Warehouse.

Let us now move to assertions about roles. For the rest ofthe section, the ranges of the subscripts are as above. We firstturn our attention to roles associated with Fig. 3. Let A13 bethe ABox comprising the following assertions:• hasProdLine(Fϕ, L

ϕλ ), if the factory Fϕ contains the pro-

duction line Lϕλ ;• hasMachine(Lϕλ ,M

ϕµ), if the production line Lϕλ uses the

machine Mϕµ ;

• hasEquipment(Lϕλ ,Eϕν ), if the production line Lϕλ in-

volves the piece of equipment Eϕν ;• hasPersonnel(Lϕλ ,P

ϕκ ), if Pϕκ works at the production line

Lϕλ ;• requiresPart(Prodi,Partj), if Prod i requires Partj for

its production;

9

• requiresMaterial(Prodi,Matj), if Prod i requires Matjfor its production;

• isAvailable(Mϕµ , true), if the machine Mϕ

µ is available,isAvailable(Mϕ

µ , false) if not;• producedIn(Prodi, L

ϕλ), if Prod i is produced in the pro-

duction line Lϕλ ; and• producedIn(Parti, L

ϕλ), if Part i is produced in the pro-

duction line Lϕλ .

For the roles associated with Fig. 4, let A14 be the ABoxcomprising the following assertions:

• requiredUnitsOfParti(Prodk, u) if Prodk requires u unitsof Part i for its production;

• requiredUnitsOfParti(Partk, u) if Partk requires u unitsof Part i for its production;

• requiredUnitsOfMaterialj(Prodk, u) if Prodk requires uunits of Matj for its production;

• requiredUnitsOfmaterialj(Partk, u) if Partk requires uunits of Matj for its production;

• inventoryUnitsOf(Prodi, u) (respectivelyinventoryUnitsOf(Partj , u)), if there are u units ofProd i (respectively Partj) in the inventory.

Finally, for roles produceUnitsProdi associated with Fig. 5,let A15 be the ABox comprising the following assertions:produceUnitsProdi(PDay

ϕt , u), if the management wants to

produce u units of Prod i on day t of the production month atfactory Fϕ. Recall, as discussed in Section IV-B, that the restof the roles shown in Fig. 5 are not to be used by humans:they are set by the controller as a result of its interactionwith scheduling and material requirements planning software.The same applies to the roles appearing in Section IV-B.)Then, the ABox A = A0 ∪ · · · ∪ A15 contains the assertionsdescribing the whole production (with respect to our model;recall Section III).

V. A PRODUCTION MANAGEMENT SCENARIO

In the previous sections we built the necessary formalframework to define rules for production management. Wenow develop a set of rules on top of this framework basedon realistic use cases. The rules are written in the SWRL[22] language, which is very commonly used with descriptionlogics. To save space, we prefix SWRL built-in functions with‘:’ instead of ‘swrlb:’. We also remark that there are variousother languages for the specification of rules, as, for example,SPIN 3 to represent SPARQL rules.

Let K be the knowledge base comprising the TBox de-scribed in Section IV-A and the ABox A0 ∪ · · · ∪ A15 asdescribed in Section IV-C. All the following rules should beused in conjunction with K. We remark that the rules writtenbelow are not single rules, but families of rules for differentvalues of their indices (the ranges of the indices are as inSection IV-C). The process of writing these rules is tedious,but, at the same time, demonstrates the large number of casesand interactions that human experts need to consider to makedecisions and, thus, the difficulty of this task.

3http://spinrdf.org/

Basic production management

When the management has set a plan to produce x unitsof Prod i (1 ≤ i ≤ ξ) on day t (1 ≤ t ≤ T ) of the fixedtime period of T days (recall Section III) at the factory Fϕ(1 ≤ ϕ ≤ n), the production of this product at the appropriateproduction line Lϕλ (1 ≤ λ ≤ λi) must be scheduled to meetthis goal:

produceUnitsProdi(PDayϕt , ?x) ∧ producedIn(Prodi, L

ϕλ)

→ scheduleUnitsProdi(SDayϕ,λt , ?x).

Further, the orders of necessary materials must be arranged.That is, for each material Matk (1 ≤ k ≤ η), if the productionof Prod i requires Matk, the required number of units for thatmaterial must be ordered:

produceUnitsProdi(PDayϕt , ?x)

∧ requiresMaterial(Prodi,Matk)

∧ requiredUnitsOfMaterialk(Prodi, ?u)

∧ :multiply(?xTimesU, ?x, ?u)

→ orderUnitsMaterialk(ODayϕt , ?xTimesU).

The production of Prod i may also require the production ofparts. Thus, the production of the necessary parts must bearranged. That is, for each part Partj (1 ≤ j ≤ ζ), if Prod irequires Partj , then Partj must also be produced:

produceUnitsProdi(PDayϕt , ?x)

∧ requiresPart(Prodi,Partj)

∧ requiredUnitsOfPartj(Prodi, ?u)

∧ :multiply(?xTimesU, ?x, ?u)

→ produceUnitsPartj(PDayϕt , ?xTimesU).

Just like with products, each part Partj (1 ≤ j ≤ ζ) thatis to be produced must be scheduled for production at theappropriate production line Lϕλ :

produceUnitsParti(PDayϕt , ?x) ∧ producedIn(Parti, L

ϕλ)

→ scheduleUnitsParti(SDayϕ,λt , ?x).

In addition, the production of a part may require certainmaterials to be ordered and other parts (recursively) to beproduced. For each material Matk (1 ≤ k ≤ η), if theproduction of Partj requires Matk, the required number ofunits for that material must be ordered:

produceUnitsPartj(PDayϕt , ?x)

∧ requiresMaterial(Partj ,Matk)

∧ requiredUnitsOfMaterialk(Partj , ?u)

∧ :multiply(?xTimesU, ?x, ?u)

→ orderUnitsMaterialk(ODayϕt , ?xTimesU).

For each part Partj′ (1 ≤ j′ ≤ ζ), if Partj requires Partj′ ,then Partj′ must also be produced:

produceUnitsPartj(PDayϕt , ?x)

∧ requiresPart(Partj ,Partj′)

10

∧ requiredUnitsOfPartj′(Partj , ?u)

∧ :multiply(?xTimesU, ?x, ?u)

→ produceUnitsPartj′(PDayϕt , ?xTimesU).

Note that we have now handled (recursively) all possiblerequirements for the production.

Disruptions in inbound logistics

An important source of disruptions is related to inboundlogistics. These are handled by a (dedicated to this task) humanexpert, whose responsibility is to ensure the timely deliveryof components to the lineside. This person’s work is to updatedelivery plans (up to several times per day) in case of eventsoccurring in supplier production and transportation. The mostcommon events related to a supplier’s production are delaysas well as availability, quantity, and quality issues. When theproduction of a certain component is delayed, the componentis not available (either at all or at the required quantity), orits production quality is not as expected, the expert picks anappropriate supplier as a replacement (using the SAP® ma-terial requirements planner) and reschedules the production ifnecessary. Common events related to transportation includevehicle breakdown, delay, and errors in delivery. Based onexperience and with the help of the appropriate software (asabove), the expert selects another carrier and/or reschedulesthe production.

To automate the above decisions, we assume that an in-tegrated cyber-physical system [27] provides data to trackdelays as well as availability, quality, and/or quantity issueson behalf of each supplier, and, in addition, movement oftrack delivery vehicles and their deliveries. We assume thatthe knowledge base has access to such data through certainpredefined roles. For example, in the following set of ruleswe use the roles supplierDelayMatk (1 ≤ k ≤ η), which weassume track (through access of collected data) delays on asupplier’s production of Matk (1 ≤ k ≤ η).

Suppose that Prod i (1 ≤ i ≤ ξ) requires material Matk(1 ≤ k ≤ η); then the rule

produceUnitsProdi(PDayϕt , ?u)

∧ requiresMaterial(Prodi,Matk)

∧ supplierDelayMatkODayϕt , ?d)

→ scheduleUnitsProdi(SDayϕ,λt , ?u)

states that if there is a delay on behalf of the supplier of arequired material for the production of a given product, thenthe production of that product must be rescheduled. This in-cludes possibly ordering the material from a different supplierif necessary, something decided by the material requirementsplanner. And, similarly, for parts:

produceUnitsPartj(PDayϕt , ?u)

∧ requiresMaterial(Partj ,Matk)

∧ supplierDelayMatk(ODayϕt , ?d)

→ scheduleUnitsProdi(SDayϕ,λt , ?u).

In an analogous manner, one can write similar rules tohandle possible availability, quantity, or quality issues onbehalf of the supplier, as well as transportation delays.

Disruptions in production scheduling

Another important source of disruptions is related to pro-duction scheduling. Such disruptions are handled by a humanexpert (different to the one handling disruptions in inboundlogistics), who is responsible for the production scheduling ofa whole plant. This person’s job is to replan (possibly severaltimes per day) the sequence of vehicles going through body-in-white, painting, and assembly. The sequence break (‘rotturasequenza’) is motivated by process events such as machinebreakdown, unscheduled maintenance, software problems, etc.

According to the above, suppose that Prod i (1 ≤ i ≤ ξ)is produced at production line Lϕλ of the factory Fϕ, and thatmachine Mϕ

µ becomes unavailable. Then, the rules

produceUnitsProdi(PDayϕt , ?u) ∧ producedIn(Lϕλ ,Prodi)

∧ hasMachine(Lϕλ ,Mϕµ) ∧ isAvailable(Mϕ

µ , false)

→ scheduleUnitsProdi(SDayϕ,λt , ?u)

and

produceUnitsParti(PDayϕt , ?u) ∧ producedIn(Lϕλ ,Parti)

∧ hasMachine(Lϕλ ,Mϕµ) ∧ isAvailable(Mϕ

µ , false)

→ scheduleUnitsParti(SDayϕ,λt , ?u)

state that if a machine becomes unavailable, the products andparts produced at the production line to which that machinebelongs must be rescheduled. We assume that the schedulercan take the availability of machines into account by accessingthe isAvailable property. Similar rules can be written to handleadditional disruptions like the ones mentioned above.

VI. CONCLUSIONS AND FUTURE WORK

The paper has demonstrated that it is possible to develop aformal framework for describing the organizational structureof production in modern manufacturing enterprises, with anemphasis on production scheduling and material requirementsplanning, and which can lay the foundations for an intelligentsystem that encodes the domain knowledge of experts assets of rules. Such a system can be an invaluable tool inhelping humans manage the complexities of decision makingin modern production scenarios. The rules provided in thispaper only cover a small spectrum of the potential of sucha framework. The underlying concepts may form a basisto investigate the possibility of extending coverage to otherproduction management activities. Although a complete setof rules for a modern manufacturing enterprise could easilyconsist of thousands of rules, it may be the case that manyof these rules would be instances of a much smaller set ofdistinct classes of rules.

One the other hand, it is recognized that building a systembased on the proposed framework may have a significant initialcost. Some of the framework’s expressiveness may have to becompromised to reduce the overall complexity of reasoning;

11

for example, a fixed time period helps dealing with temporalproperties without resorting to temporal logics. In addition,determining what aspects of production management may haveto be given priority when building the system’s formalismmay, in general, be challenging. The counter-argument is thatfor specific scenarios, as the ones discussed in the paper,the proposed framework may empower decision makers whenfacing complex decision making processes. In this direction,an important extension of this research would be to incorporatereasoning under uncertainty. Indeed, the framework presentedin this paper can only handle definitive knowledge. However,in modern production, one cannot always make definitivestatements about the state of a given system. As humanshave difficulties with uncertain reasoning, the proposed systemcould be adapted to include rules capturing uncertain knowl-edge. As mentioned in Section I, there are various interestingresults and research directions regarding, for example, proba-bilistic description logics, and, in this connection, our researchcould provide a bridge towards production management underuncertainty.

REFERENCES

[1] Farhad Ameri and Debasish Dutta. An upper ontology for manufacturingservice description. In ASME 2006 international design engineeringtechnical conferences and computers and information in engineeringconference, pages 651–661. American Society of Mechanical Engineers,2006.

[2] Farhad Ameri and Lalit Patil. Digital manufacturing market: A semanticweb-based framework for agile supply chain deployment. Journal ofIntelligent Manufacturing, 23:1817–1832, 2012.

[3] Farhad Ameri, Colin Urbanovsky, and Christian McArthur. A systematicapproach to engineering knowledge organization and modeling. InASME 2012 International Design Engineering Technical Conferencesand Computers and Information in Engineering Conference, pages 947–958. American Society of Mechanical Engineers, 2012.

[4] Franz Baader, Maurizio Lenzerini, and Riccardo Rosati. The descriptionlogic handbook: theory, implementation, and applications. 2003.

[5] Armin Biere, Marijn Heule, and Hans van Maaren. Handbook ofsatisfiability, volume 185. IOS press, 2009.

[6] Jacek Blazewicz, Klaus H. Ecker, Erwin Pesch, Gunter Schmidt, and JanWeglarz. Scheduling computer and manufacturing processes. springerscience & Business media, 2013.

[7] Egon Borger, Erich Gradel, and Yuri Gurevich. The classical decisionproblem. Springer Science & Business Media, 2001.

[8] Stefano Borgo and Paulo Leitao. The role of foundational ontologies inmanufacturing domain applications. On the Move to Meaningful InternetSystems 2004: CoopIS, DOA, and ODBASE, pages 670–688, 2004.

[9] Stefano Borgo and Paulo Leitao. Foundations for a core ontology ofmanufacturing. In Raj Sharman, Rajiv Kishore, and Ram Ramesh,editors, Ontologies: A Handbook of Principles, Concepts and Appli-cations in Information Systems, pages 751–775. Springer US, Boston,MA, 2007.

[10] Peter Brucker. Scheduling algorithms, volume 3. Springer, 2007.[11] Goncalo Candido, Armando W. Colombo, Jose Barata, and Francois

Jammes. Service-oriented infrastructure to support the deploymentof evolvable production systems. IEEE Transactions on IndustrialInformatics, 7(4):759–767, Nov. 2011.

[12] Li Da Xu, Wu He, and Shancang Li. Internet of things in industries: Asurvey. IEEE Transactions on Industrial Informatics, 10(4):2233–2243,2014.

[13] Pavlos Eirinakis, Jorge Buenabad-Chavez, Rosanna Fornasiero, HalukGokmen, Julien-Etienne Mascolo, Ioannis Mourtos, Sven Spieckermann,Vasilis Tountopoulos, Frank Werner, and Robert Woitsch. A proposalof decentralised architecture for optimised operations in manufacturingecosystem collaboration. In Luis M. Camarinha-Matos, Hamideh Afsar-manesh, and Rosanna Fornasiero, editors, Collaboration in a Data-RichWorld, pages 128–137. Springer International Publishing, 2017.

[14] Soumaya El Kadiri, Bernard Grabot, Klaus-Dieter Thoben, KarlHribernik, Christos Emmanouilidis, Gregor Von Cieminski, and DimitrisKiritsis. Current trends on ICT technologies for enterprise informationsystems. Computers in Industry, 79:14–33, 2016.

[15] Borja Ramis Ferrer, Bilal Ahmad, Andrei Lobov, Daniel AlexandreVera, Jose Luis Martinez Lastra, and Robert Harrison. An approach forknowledge-driven product, process and resource mappings for assemblyautomation. In Automation Science and Engineering (CASE), 2015 IEEEInternational Conference on, pages 1104–1109. IEEE, 2015.

[16] Borja Ramis Ferrer, Sergii Iarovyi, Andrei Lobov, and Jose L. Mar-tinez Lastra. Towards processing and reasoning streams of eventsin knowledge-driven manufacturing execution systems. In IndustrialInformatics (INDIN), 2015 IEEE 13th International Conference on,pages 1075–1080. IEEE, 2015.

[17] Guido L. Geerts and Daniel E. O’Leary. A supply chain of things: TheEAGLET ontology for highly visible supply chains. Decision SupportSystems, 63:3–22, 2014.

[18] W3C Owl Working Group et al. OWL 2 web ontology languagedocument overview. 2009.

[19] Ondrej Harcuba and Pavel Vrba. Ontologies for flexible productionsystems. In Emerging Technologies & Factory Automation (ETFA), 2015IEEE 20th Conference on, pages 1–8. IEEE, 2015.

[20] Mario Hermann, Tobias Pentek, and Boris Otto. Design principles forindustrie 4.0 scenarios. In System Sciences (HICSS), 2016 49th HawaiiInternational Conference on, pages 3928–3937. IEEE, 2016.

[21] Matthew Horridge, Bijan Parsia, and Ulrike Sattler. Justification orientedproofs in OWL. In Lecture Notes in Computer Science, volume 6496,pages 354–369, 2010.

[22] Ian Horrocks and Peter F. Patel-Schneider. A Proposal for an OWLRules Language. In Proceedings of the 13th International Conferenceon World Wide Web, WWW ’04, pages 723–731, New York, NY, USA,2004. ACM.

[23] Michael N. Huhns, Larry M. Stephens, and Nenad Ivezic. Automatingsupply-chain management. In Proceedings of the First InternationalJoint Conference on Autonomous Agents and Multiagent Systems: Part3, AAMAS ’02, pages 1017–1024, New York, NY, USA, 2002. ACM.

[24] Sergii Iarovyi, Wael M. Mohammed, Andrei Lobov, Borja RamisFerrer, and Jose L. Martinez Lastra. Cyber–physical systems for open-knowledge-driven manufacturing execution systems. Proceedings of theIEEE, 104(5):1142–1154, 2016.

[25] Evangelia Kavakli, Jorge Buenabad-Chavez, Vasilios Tountopoulos, Per-icles Loucopoulos, and Rizos Sakellariou. An architecture for disruptionmanagement in smart manufacturing. In 2018 IEEE InternationalConference on Smart Computing (SMARTCOMP), pages 279–281, June2018.

[26] Jose L. Martinez Lastra and Ivan M. Delamer. Semantic web services infactory automation: Fundamental insights and research roadmap. IEEETransactions on Industrial Informatics, 2:1–11, 2006.

[27] Paulo Leitao, Armando Walter Colombo, and Stamatis Karnouskos.Industrial automation based on cyber-physical systems technologies:Prototype implementations and challenges. Computers in Industry,81:11–25, 2016.

[28] Paulo Leitao and Francisco Restivo. ADACOR: A holonic architecturefor agile and adaptive manufacturing control. Computers in Industry,57(2):121–130, 2006.

[29] Severin Lemaignan, Ali Siadat, Jean Yves Dantan, and Anatoli Seme-nenko. MASON: A proposal for an ontology of manufacturing domain.In Proceedings DIS 2006: IEEE Workshop on Distributed IntelligentSystems: Collective Intelligence and Its Applications, pages 195–200,2006.

[30] Pedro Lima-Monteiro, Mafalda Parreira-Rocha, Andre Dionisio Rocha,and Jose Barata Oliveira. Big Data Analysis to Ease Interconnectivityin Industry 4.0 – A Smart Factory Perspective. In Service Orientationin Holonic and Multi-Agent Manufacturing, pages 237–245. Springer,2017.

[31] H. K. Lin and J. A. Harding. A manufacturing system engineeringontology model on the semantic web for inter-enterprise collaboration.Computers in Industry, 58:428–437, 2007.

[32] Niels Lohse, Hitendra Hirani, and Svetan Ratchev. Equipment ontologyfor modular reconfigurable assembly systems. International Journal ofFlexible Manufacturing Systems, 17(4):301–314, Oct 2006.

[33] P. Loucopoulos and E. Kavakli. Analysis of requirements for a cyberphysical production system in the automotive industry. In AMCIS 2017,Boston, USA, 2017.

[34] Arndt Luder, Nicole Schmidt, and Rainer Drath. Standardized in-formation exchange within production system engineering. In StefanBiffl, Arndt Luder, and Detlef Gerhard, editors, Multi-Disciplinary

12

Engineering for Cyber-Physical Production Systems: Data Models andSoftware Solutions for Handling Complex Engineering Projects, pages235–257. Springer International Publishing, 2017.

[35] Thomas Lukasiewicz. Expressive probabilistic description logics. Arti-ficial Intelligence, 172:852–883, 2008.

[36] Deborah L. McGuinness and Jon R. Wright. An industrial-strengthdescription logic-based configurator platform. IEEE Intelligent Systemsand Their Applications, 13:69–77, 1998.

[37] Despina T. Meridou, Andreas P. Kapsalis, Maria-Eleftheria Ch. Pa-padopoulou, Emmanouil G. Karamanis, Charalampos Z. Patrikakis,Iakovos S. Venieris, and Dimitra-Theodora I. Kaklamani. An Ontology-Based Smart Production Management System. IT Professional, 17:36–46, 2015.

[38] David Romero and Francois Vernadat. Enterprise information systemsstate of the art: past, present and future trends. Computers in Industry,79:3–13, 2016.

[39] Bianca Scholten. The Road to Integration. A Guide to Applyingthe ISA-95 Standard in Manufacturing. Instrumentation, Systems andAutomation Society, 2007.

[40] Fei Tao, Ying Cheng, Li Da Xu, Lin Zhang, and Bo Hu Li. CCIoT-CMfg: cloud computing and internet of things-based cloud manufac-turing service system. IEEE Transactions on Industrial Informatics,10(2):1435–1442, 2014.

[41] Zahid Usman, R.I.M. Young, Nitishal Chungoora, Claire Palmer, KeithCase, and J.A. Harding. Towards a formal manufacturing referenceontology. International Journal of Production Research, 51(22):6553–6572, 2013.

[42] Jan Vom Brocke and Michael Rosemann. Handbook on business processmanagement. Springer, 2010.

[43] Xiaohuan Wang, T. N. Wong, and Zhi Ping Fan. Ontology-based supplychain decision support for steel manufacturers in China. Expert Systemswith Applications, 40:7519–7533, 2013.

[44] Yan Ye, Dong Yang, Zhibin Jiang, and Lixin Tong. An ontology-basedarchitecture for implementing semantic integration of supply chain man-agement. International Journal of Computer Integrated Manufacturing,21:1–18, 2008.

[45] Yan Ye, Dong Yang, Zhibin Jiang, and Lixin Tong. Ontology-basedsemantic models for supply chain management. International Journalof Advanced Manufacturing Technology, 37:1250–1260, 2008.

[46] Yingzhong Zhang, Xiaofang Luo, Hong Zhang, and John W. Sutherland.A knowledge representation for unit manufacturing processes. TheInternational Journal of Advanced Manufacturing Technology, 73(5-8):1011–1031, 2014.

Georgios Kourtis holds a PhD in Computer Sciencefrom the University of Manchester (UK), an MSc inLogic, Algorithms, and the Theory of Computationfrom the University of Athens (Greece) and the Na-tional Technical University of Athens (Greece), anda BSc in Computer Science from the University ofPiraeus (Greece). His research interests are broadlyon the applications of logic in computer science,and, in particular, on the complexity of reasoningin various decidable logics (e.g. fragments of first-order logic, description logics, temporal logics) and

their connections to knowledge representation, database theory, and formalverification.

Evangelia Kavakli is an Associate Professor at theDepartment of Cultural Technology and Communi-cation of the University of the Aegean (Greece) anda Research Associate in the School of Computer Sci-ence of the University of Manchester (UK). She ob-tained her PhD in Computation from the Universityof Manchester, Institute of Science and Technologyin 1999. She is in charge of the Cultural InformaticsLaboratory of the University of the Aegean. Herresearch on the topics of goal-oriented requirementsengineering, enterprise knowledge modelling, infor-

mation systems privacy and cultural informatics, has been supported in thecontext of national and EU funded projects. Her current research focuseson requirements engineering for Big Data applications and the design ofsocio-cyber-physical systems. She has published over 60 peer-reviewed papersin reputed international journals and conferences and edited books. She ismember of the editorial board of the Requirements Engineering Journal andhas served in the program committee of a substantial number of internationalconferences in the field of information systems.

Rizos Sakellariou obtained his PhD in ComputerScience from the Victoria University of Manch-ester in 1997. Following positions with Rice Uni-versity and the University of Cyprus he has beenan academic member of staff of the Universityof Manchester since 2000, currently Professor ofComputer Science and leader of a laboratory thatcarries out research in High-Performance, Paralleland Distributed Software Systems. He has publishedover 150 research papers, his research has beensupported by several UK and EU projects and has

served on the Program Committee of over 160 conferences and workshops.He values collaboration and a strong work ethic.