Keywords

1 Introduction

Management of manufacturing resources is of primary concern for manufacturing enterprises. Resources have indeed to be managed for various purposes like process or resource planning, resource scheduling, and work improvement study, just to mention a few tasks. As a consequence, enterprises require models to handle resource information in a uniform and transparent manner to smooth data exchange across the actors involved in the manufacturing chain.

Various data modeling standards, conceptual models, and ontologies have been proposed over the years for this goal. In particular, the use of the latter is increasing in application domains that require heterogeneous data to be consistently organized and exchanged while preserving their original meaning. Examples are Product Lifecycle Management (PLM) systems [1], but also emerging paradigms like Cyber Physical Production Systems (CPPS) [2], Smart-Sensitive-Sustainable (S3) Manufacturing [3], and Cloud Manufacturing [4].

Several information models addressing such domains have been developed, each one with its own specific view and application context. Consequently, various and not well-aligned modeling frameworks co-exist, a fact that complicates the efficient interoperation of organizations and information systems [5]. This situation has stimulated the creation of the international effort called Industrial Ontologies Foundry (IOF)Footnote 1 aimed at the design of a library of open-source ontologies to facilitate the interaction between applications and communities. ‘Resource’ is one of the key notions being analyzed within the IOF, which calls for a conceptual clarification despite the plethora of models proposed over the years.

The aim of this work is to contribute to this clarification with the ultimate purpose of supporting the development of an ontology for manufacturing resources based on principled modeling choices. Instead of presenting a computational ontology, we provide here a reference conceptual framework that can be used to both harmonizing existing models and develop domain ontologies tuned on specific requirements.

As a modelling notation, we shall rely on OntoUML to convey graphically the core meanings of the notions at stake. OntoUML is a UML extension for ontology-driven conceptual modeling [6] that has been successfully employed in a number of industrial projects in several different domainsFootnote 2. Thanks to its formal semantics, OntoUML diagrams can be straightforwardly translated (with some loss of expressivity) in a computational language like the Web Ontology LanguageFootnote 3 (OWL).

The paper is structured as follows. In Sect. 2 we give an overview of the state of the art on resource modeling. In Sect. 3 we analyze the notion of manufacturing resource and propose a conceptual analysis based on ontological theories like [6, 7]. Section 4 shows how the analysis can be extended to integrate resource classifications based on multiple criteria. Section 5 concludes the paper by addressing the advantages and limits of our work.

2 Manufacturing Resource Modeling: A Conceptual Overview

The interpretation of what can be considered as manufacturing resource changes considerably across the literature. According to the standard MANDATE [8], a resource is “any device, tool and means, except raw material and final product components, at the disposal of the enterprise to produce goods and services”. The standard hence distinguishes what is transformed during a manufacturing activity (e.g., raw materials) from its final outcomes (products), and the physical means (machines, etc.) that bring about the transformation. From the definition, only the latter – humans included – are manufacturing resources. Differently, other proposals identify incoming material and/or transformed entities as resources as well [9, 10].Footnote 4

Several approaches rely explicitly on the relationship with (manufacturing) processes to characterize the notion of resource (e.g., [12,13,14]), while others complement this approach with the modeling of capabilities [14, 15]. According to ISO 15704 [16], for example, a resource is “an enterprise entity that provides some or all of the capabilities required by the execution of an enterprise activity and/or business process.” Hence, the idea is that a resource can be employed for manufacturing because of its capabilities or – more generally – attributes [17] that are relevant to execute the desired processes. This idea leads us to think of resources in tight connection with application contexts, since one and the same resource can be ascribed with different attributes in relation to the process where it is employed.

The diversity concerning the conceptualization of manufacturing resources has a radical impact on how data is organized; it can also hamper data exchange if not properly handled. For example, by relying on MANDATE, reference to capabilities and processes is not required, differently from the case in which data is structured on the basis of ISO 15704. Additionally, if one takes seriously the contextual nature of resources, it should be possible for the same entity to be and not to be a resource across different contexts, as suggested in [12, 18]. Current approaches have not treated contextual knowledge in a systematic manner. This easily leads to undesired interpretations, since persons, materials or tools, among others, are classified as resources independently of the contexts where they may happen to be in.

In the next section we dig into the analysis of manufacturing resources. By the end of the paper, we show how the proposed framework can deal with the diversity of views found in the literature.

3 Foundational Aspects of Manufacturing Resources

In order to represent manufacturing resources in a manner that is coherent with both ontological and engineering knowledge, we first need to introduce some general notions, which are then specified to the manufacturing domain.

Following existing standards [19] and ontologies [10, 20], we hold a basic distinction between (physical) objects and processes, e.g., drillers and drilling operations. The former are primarily extended in space, whereas the latter unfold through time. Participation is the most general link between objects and processes. Objects, but also processes, are characterized by qualities (attributes in the terms of [17]) like weights, which are said to inhere in objects (processes). Some objects are made of material, while others lack material constitution. Among the latter, information objects stand for the immaterial content of technical documents, e.g., Computer-Aided Design (CAD) models encoded on a physical support. For instance, when two computer files are copies of the same CAD model, in our framework this means that they share the same information object. Accordingly, an information object can be encoded in multiple supports, for instance, different computer files.

With these basic notions, we now dig into the OntoUML diagram showed in Fig. 1.Footnote 5 The idea is to consider a manufacturing resource as an entity that is related to a manufacturing process plan because it is relevant for some goal specified in the plan. We shall see throughout the section how this is represented in the model.

Fig. 1.
figure 1

Core elements for the conceptual representation of manufacturing resources

Full size image

For our purposes, we understand agents as (physical) objects with sensors, actuators, and the capability of acting on the environment by adopting plans to reach some goals. Goals are intentional states inhering in agents and referring to desired states of the world. We assume that agents have at least one goal,Footnote 6 whereas plans are ways (strategies) to achieve goals. For example, if an agent has the goal of creating a table, this goal is satisfied in all states of the world where a physical table, bearing the qualities desired by the agent, exists. To achieve one of such states, a suitable plan must be realized.

Manufacturing plans (MfgPlan) are information objects (like workflows) that specify the sequence of actions to be performed to realize a goal. We assume that manufacturing goals are goals such that a manufacturing plan exists for them. So we assume a relation has-plan between manufacturing goals and manufacturing plans such that for a manufacturing goal there is at least a plan, and vice versa.

The class MfgPlanRealization, subsumed by Process, refers to the actual manufacturing processes that realize manufacturing plans. A plan may not be always realized; this is why the multiplicities of the relation realizes from MfgPlanRealization to MfgPlan is 0..* on the side of the former class.

For the purposes of this paper, an important part of a manufacturing plan is the description of the various resources to be used to realize the plan. We introduce therefore the class MfgResourceDescription, whose instances are proper parts of a MfgPlan. For each MfgPlan, at least one MfgResourceDescription must exist. Like manufacturing plans, manufacturing resource descriptions are information objects

We are now in the position to define a manufacturing resource as something that satisfies a MfgResourceDescription that is part of a MfgPlan. A resource is relevant-for a specific plan if and only if it satisfies a resource description that is part of that plan (the relevant-for relation appearing in Fig. 1 is therefore a derived relation). The notion of satisfaction of a description has been discussed in [21], and will be taken here as a primitive. In general, a given entity may satisfy or not a resource description depending on its qualities. Within manufacturing resources, we distinguish between physical objects and amounts of matter, since these are the most general classes of entities to which one commonly refers (see Sect. 2).

An instance of MfgResource has to satisfy at least one instance MfgResourceDescription. On the contrary, a MfgResourceDescription may have no resources that satisfy it. Note that a resource may be relevant-for a certain plan even if it does not participate in its realization. For instance, we typically require that all the resources that are relevant for a certain plan must exist (and be available, see below) before a realization process starts. On the contrary, entities of different kinds (such as air or dust particles) may actually participate in a process without being considered as resources. In conclusion, we can see resources as entities such that, in virtue of their qualities, are considered as relevant for a manufacturing plan and may therefore play the role in manufacturing processes by participating to certain activities.

As a final comment, let us highlight the role nature of resources that emerges from the analysis of the state of the art.Footnote 7 In ontology engineering, roles are properties which are always contingent, being satisfied only within certain contexts [6, 7, 21]. Generalizing, the idea is that talking of manufacturing resources means referring to entities that are primarily classified by non-role classes and that may play certain roles when employed for manufacturing. This is why in Fig. 1 MRPhysicalObject and MRAmountOfMatter, referring to object and amount of material resources, are subsumed by both MfgResource (role class) and PhysicalObject and AmountOfMatter, respectively, the latter two being non-role classes. With this approach, based on [6, 7], the conceptual model provides the flexibility to isolate manufacturing resources in their contexts. It is important to stress that the attribution of a (manufacturing) resource role is strictly dependent on a process plan. By looking at Fig. 1, the relation relevant-for between MfgResource and MfgPlan means that a manufacturing resource role is necessary to achieve some goal specified in the plan.

4 High-Level Classification of Manufacturing Resources

We now distinguish between different manufacturing resource roles according to both ontological and engineering criteria. In particular, the classification is based on three orthogonal principles: (i) agentivity, (ii) mode of deployment, and (iii) control. The classification is not meant to be exhaustive; it rather provides a high-level taxonomy that can be extended to cover specific scenarios. For simplicity, we refer only to physical resources, whereas their corresponding descriptions can be easily introduced.

First, we distinguish between agentive and non-agentive resources, depending on whether the entity ascribed with the resource role is an agent or not. A standard milling machine is an example of non-agentive resource; a milling machine embedded with a cyber-physical architecture may be an example of agentive resource.Footnote 8

Second, in line with the engineering literature, we want to make sense of the distinction between (i) resources that ‘passively’ undergo manufacturing processes, e.g., planks of wood, (ii) resources that ‘actively’ act on the former, e.g., milling machines, and (iii) resources that result from manufacturing processes, e.g., products. Taking inspiration from IDEF0Footnote 9 and previous works [10, 14], these correspond in our approach to input, mechanism, and output manufacturing resources, respectively. Differently from the agent vs non-agent dichotomy, the latter notions are not disjoint, since one object can act on itself, i.e., it can be input, mechanism, and output in the same process like a robot changing its configuration.

Third, we distinguish between allocated, dedicated, and available manufacturing resources, which refer to temporary states. Allocated resources are assigned and employed in manufacturing processes (plan realizations). Dedicated resources are assigned to processes, which may not however employ them. The fact that a resource is dedicated to an individual process p implies that it cannot be assigned to another process occurring at the same time of p. Available resources are present (in a factory), although they are neither allocated nor dedicated. An example is a screwdriver available at the shop floor meaning that any agent in the shop floor could use it if necessary.

Since the classification criteria are orthogonal, they can be (consistently) combined. Figure 2 shows the extension of the class MfgResource with the classes presented above,Footnote 10 whereas Table 1 suggests some examples at the intersection between the agentivity and mode of deployment criteria.

Table 1. Intersection between agentivity and mode of deployment
Full size table
Fig. 2.
figure 2

High-level taxonomy of manufacturing resources

Full size image

The classification presented in Fig. 2 can be used as high-level taxonomy to integrate multiple classifications. For instance, following [13], mechanism resources may be further specialized into primary and auxiliary resources to emphasize the distinction between resources “that are in charge of executing operations”, and resources “that are defined in relation to primary resources that employ them”, respectively. In Industry 4.0 contexts [2], the classification of resources with a cyber-physical architecture plays a fundamental role, and different classes of cyber-physical systems (CPS) can be distinguished because the characteristics that must be shown for each level of abstraction may be different [22]. Also, for specific application domains, the taxonomy may be extended to cover, e.g., machining or additive manufacturing resources, among others.

5 Discussion and Conclusions

The conceptualization of manufacturing resources presented in the paper provides a general framework for their representation in application ontologies and data models for manufacturing. As said, our purpose was not the proposal of an ontology for computational applications. Rather, we presented a conceptual analysis with the purpose of making clear the properties that manufacturing resources have to satisfy independently from specific application requirements. The proposed framework gives a high-level perspective on manufacturing resources, and needs therefore to be extended to cover specific domain knowledge. The generality of the proposal makes it suitable to harmonize various views under the same umbrella, which has therefore the potentiality of acting as integration schema across multiple sources. Consider, e.g., the notion of resource in MANDATE [8] that, as we saw in Sect. 2, is restricted to what we call mechanisms, differently from the approaches in [10, 12] which cover products (outcomes) and raw materials (inputs), too. At the current state, these models are not interoperable, whereas their alignment to our ontology can enable their smooth interaction. From this perspective, the ontology can be used to compare various approaches and to assess their (conceptual) similarities and differences.

Additionally, differently from the state of the art, the proposed framework allows one to consider explicitly the contextual dimension of manufacturing resource classes, an approach that is coherent with both ontological and engineering knowledge. Consider, e.g., the specific milling machine mch_id21. From an ontological perspective, mch_id21 is an artifact, i.e., an object intentionally designed and created to satisfy customers’ needs. For manufacturing purposes, we want to say that mch_id21 can be a mechanism resource if employed to perform certain processes. This means that mch_id21 is an artifact for its very nature, whereas it is considered as a mechanism resource only with respect to certain manufacturing contexts. Hence, if mch_id21 is never considered as relevant with respect to a manufacturing goal, it is never a resource, while it remains a machine with specific qualities and capabilities. The same reasoning applies to human resources, among others.

The proposed approach has interesting consequences from a modeling perspective. First, objects (and amounts of matter) can assume different resource roles within and across manufacturing processes and organizations. For example, one and the same machining tool can be the outcome resource of process p1 and the mechanism resource of process p2 occurring after p1. Also, as previously seen, nothing prevents the same object to participate consistently as input, mechanism, and output resource in the same process. Second, by using our approach, one can revise models like, for instance, that in [17], where classes like Person, Tool, and Material are subsumed by Resource, to make them ontologically more tenable and, in turn, more reusable. Indeed, once we take Resource as a role, the taxonomical link between these classes cannot hold, since it would lead to the undesired classification of instances of the former classes as being always instances of Resource. Differently, our ontology allows referring to, e.g., tools independently from the resource role they may have in manufacturing processes, hence to classify them as resources only when needed.

Further work on our proposal is necessary to consolidate the approach with respect to both ontological modeling principles and engineering application scenarios. For example, a deeper analysis of resources’ capabilities is necessary to establish a stronger link with processes. Also, even though our OntoUML model can be straightforwardly translated into computational languages like OWL, further work is required to a more expressive ontology in formal languages like first-order or common logics; these would allow exploring the semantic of the employed terms in a broader manner to check coherence with respect to the engineering domain.