Industrial engineers decide the production organization discussing possible processes and available resources. To reason on resources, ontologies for industrial engineering need to model their characteristics. Indeed, a resource available in the shop floor can be associated with a process plan only if the resource has the capability to satisfy the plan requirements. Existing ontologies miss to characterize and distinguish the concept of capability, even when it is explicitly modeled, from other notions like capacity and functionality. We aim at filling this gap by enriching our previous work on manufacturing resources with an explicit representation of capabilities, capacities, functionalities and other related notions.
The modeling of capabilities plays a prominent role in the ontological representation of
manufacturing resources. For instance, capabilities can be useful to classify resources for cataloging
purposes, and are used to assess which type of resource meets the requirements in planning
scenarios and, consequently, to decide the assignment of a task to a physical resource in
scheduling contexts [
Before looking at our proposal, we report on some research results relevant for our study;
readers can refer to [
Sarkar and S˘ormaz [
Järvenpää et al. [
Solano et al. [12] discuss the use of ontologies for process planning, including how to conceive
resources and their capabilities with an ontological approach. Building on the dolce ontology
[13], the authors conceive capabilities as “the ability to carry out a type of activity” with a
certain performance level. Similarly to [
Finally, the standard ISO 15531 [15], informally known as MANDATE, conceives capability as the “quality of being able to perform a given activity”. Capacity refers to the “capability of a [...] resource to perform its expected function from a quantitative point of view”. An example of the latter is “the capacity of a [...] resource to produce a given quantity of output in a particular time period” (quotes from [15, p.5]).
To sum up, there is a general agreement in conceiving resources capabilities in tight
connec1To be more precise, in Sarkar and S˘ormaz’s view [
2Järvenpää et al. [
3Recall that dolce individual qualities inhere in and depend on single individual entities.
tion to the type of process in which resources can participate to contribute to achieving the
process goals. Disagreements however arise at the modeling level, especially with respect to the
notion of functionality. In particular, diferently from Solano et al. [ 12] where there is not an
explicit link between capabilities and functionalities, capabilities are functionalities according
to MANDATE [15] and Järvenpää et al. [
We shall see in the next sections how capabilities, capacities, and functions can be integrated in a unified approach, which is however introduced only in a preliminary way. The paper is structured as follows. Section 2 provides a brief overview of previous work on resource modeling that is now further extended. In Section 3 we enter into the characterization of functions, whereas capabilities and capacities are analyzed in Section 4. Section 5 concludes the paper.
We introduce in this section the ontological characterization of manufacturing resources
presented by Sanfilippo et al. [
According to [
We borrow the notions of activity and activity occurrence4 from the Process Specification Language (PSL; ISO 18629) [17]. An occurrence is a happening in time, a.k.a. event in the literature: e.g. a particular machining event 1 taking place in the manufacturing site 1 at
time 1. Activities stand for repeatable patterns of behavior, i.e., event types that occurrences instantiate. Following PSL, we write (, ) to mean that the activity occurrence satisfies (instantiate) . A manufacturing activity is a (possibly complex) transformation type whose occurrences take an input and transform it in the desired output; e.g., an activity establishing the conditions to give a certain shape to a plank (the input).
Definitions (D1)–(D3) introduce three relations which are used to define manufacturing
activity in (D4) and manufacturing resource in (D5). We shall provide here only a general
overview of the formulas; the reader can refer to [
Most of the predicates appearing in the right-hand side of the definitions are primitives. Also, types exist in the quantification domain, hence they are represented through standard FOL predicates. The (primitive) relation (, , ) tells that satisfies (instantiates) type at time (see formulas below). is satisfied by states; MfgActivityType by (manufacturing) activity occurrences; MfgCapabilityType by physical endurants bearing certain capabilities (see Sect. 4), and by either physical objects (e.g., a machine, tool, fixture, etc.) or amounts of matter (e.g., lubricant, amount of wood, glass, sand, etc.).6 The binary predicate ℎ(, ) is the most general relation to bind an activity to a type which is a requirement for executing the activity. For instance, a machining activity may require a resource with the capability of cutting certain material types with specific parameters while satisfying given tolerances.
With these clarifications, definition (D1) states conditions that must hold to initiate the execution of a manufacturing activity. The formula tells that when an activity has initial state requirement , for each of its occurrences , there is a state satisfying at the beginning of .
D1 ℎ (, ) ≡ () ∧ ℎ(, ) ∧ () ∧ ∀( (, ) → (, , ()))
Similarly, definition (D2) tells that when an activity has output and final state , each occurrence of ends with a physical item satisfying and in the state satisfying . The predicates and stands for proper parthood and participation, respectively (see [13]). ℎ(, , ) could be simplified to the binary ℎ(, ) if reference to the final state is not required. We find useful the ternary variant of this relation because planners often specify items’ states during production, e.g., cylinder head (in the state of being) held on pallet, valve (in the state of being) installed, etc.
D2 ℎ(, , ) ≡ () ∧ () ∧ () ∧ (, ) ∧ (, ) ∧ ∀( (, ) → ∃((, , ()) ∧
(, , ()) ∧ (, , ())))
Definition (D3) tells that an activity has either item types or manufacturing capability types as resource requirements.
5The formalization in this paper revises, and sometimes improves, the formulas in [
6Diferently from physical objects, amounts of matter are mereologically invariant physical endurants, that is, an amount of matter can not lose or acquire parts while keeping identity.
Definition (D4) states that a manufacturing activity is an activity that has initial state requirements (), resource requirements (), and expected outputs () in the final state ( ).
D4 MfgActivity () ≡ ∃ (ℎ(, ) ∧ ℎ(, ) ∧ ℎ(, , ))
Finally, a manufacturing resource is a physical endurant that satisfies the resource requirement of some manufacturing activity.
D5 MfgResource() ≡ ℎ() ∧ ∃(MfgActivity () ∧ ℎ(, ) ∧ (, , ))
As said above, the work in [
We shall see in the next sections how to treat resource capabilities by extending what done
in [
In manufacturing one distinguishes process plans from production plans [
More specifically, we take a task to be a pair of state types possibly with further constraints. The first state type constrains the state of the system for the task to be considered for realization (it constrains the so-called initial state). The second state type gives the task’s goal, i.e., the expected state of the system after the task execution. For example, referring to op40 in Table 1, we could have as initial state the presence of a cylinder head, valves and some tools for handling valves, and as goal the presence of a cylinder head with its installed valves. Further conditions might state that all valves must be installed in a specific position, the gripper must move along a specific direction to avoid damages, that no further tool or material is used, that the realization of the goal occurs within a certain time duration, etc.
Conceptually speaking, the comparison between the initial and final states in a task indicates a change which could (if realizable) be brought about via the realization of functions. For instance, the task identified by the presence of a cylinder head and valves as initial state, and the presence of a cylinder head with its installed valves as goal corresponds to a join function. Further conditions, like the participation of a gripper, may indicate how the change is expected to be performed. This simple idea, which guides our modeling approach, needs now to be refined.
We take a function to be a type of activity or, ontologically speaking, a class of events. For instance, the engineering function joining a plate steel and a pipe by welding collects the possible events whose starting point satisfies the initial state (the pre-conditions of the welding operation) and whose ending point satisfies the final state (the post-conditions of that welding operation). There can be ambiguities concerning the characterization of a function: functional talk by experts may not indicate to which object types (plate steel and pipe) the function (joining) applies nor the method (welding) with which to realize it. In a further example related to cutting wooden planks, the engineer may point to the need to have the plank (object) divided (function) in two pieces without worrying how this is achieved (method) perhaps because the tool to be used is already known, or perhaps because how to divide the plank is irrelevant for the plan.
Building on [
SENSE information collection
CONVERT BRANCH
JOIN RECLASSIFY hand, engineering functions are types of events in which the change given by initial and final states is required to satisfy further constraints among which, in particular, is the method with which the final state is achieved. These types of events are called accomplishment in dolce .
While a proper axiomatization is outside the scope of this paper, we can formally model the relationship between ontological and engineering functions as follows (here we assume that a classification of ontological functions is given, e.g., along the lines of the classification in Fig. 1, and that a list of engineering methods is fixed, e.g., as in the MTM methodology for the case of assembly tasks [20, 21]): Ax1 () → ∃( () ∧ ℎ() ∧ (, ) ∧ (, )) (if is an engineering function then there is an ontological function that satisfies, and a method that uses)
Ax2 MfgActivity () → ∃( () ∧
∀( (, ) → ((, , ()) ∧ (, , ())))) (if is a manufacturing activity then there is an engineering function such that every occurrence of satisfies the initial and final states of )7
For instance, an ontological function might tell us that at the beginning there are some entities (e.g., a cylinder head, valves) and these entities change resulting in a single entity (e.g., a cylinder head with installed valves). Following Fig. 1, this description is a case of join function. When dealing with engineering functions, the same change is described stating the presence of entities (cylinder head, valves) at the start of the event, then stating that an agentive entity uses a gripper for some amount of time, in a certain way and according to some instructions, and that ifnally there is one entity (cylinder head with installed valves) when the event is completed. We will see in the next section how the conceptual diference between capabilities and capacities matches the above distinction between ontological and engineering functions.8
Finally, an engineering function execution is an activity occurrence in the PSL terminology (ontologically speaking, an accomplishment), in which the participating devices contribute to the achievement of the activity goal. A function execution is also known as function realization.
Following the introduction of ontological and engineering functions, we now present capabilities
and capacities as ontologically distinct notions. The purpose is to fill the gap, theoretical
and practical, to enable engineers to generate, starting from a plan and a set of devices, the
assignments for the plan execution. As said, the plan is seen as a sequence of tasks, and tasks
are essentially sequences of functions. As mentioned, indeed, our previous work [
On the basis of what we discussed in the previous section, let us assume that a plan has been ifxed and that it consists of a list of (perhaps only partially ordered) tasks, namely, engineering functions, with the characteristics that participants to these tasks must satisfy. We now face the following question: is a physical endurant (machine, tool, trained worker etc.) satisfying the characteristics required to be a participant of the plan realization?
In order to answer the question, we set the theoretical framework with the information needed to answer it. We propose to take capability to be the individual quality (in the sense of dolce ) of an object that is associated with a function or with an activity. In particular, this means that a capability is a quality of an object relative to both an environment and an activity, i.e. a relational quality. Indeed, roughly speaking, what we have in mind corresponds to what one intends with expressions like ‘it has the capability to hold’ (said of a container), ‘it has the capability to carry’ (said of a truck), ‘it has the capability to cut’ (said of a blade). In these cases the quality is not of the object per se but of the object in a context (holding, carrying and cutting 7Note that there are two diferent predicates used in these formulas. The binary one in (Ax1) applies to pairs of types. The ternary in (Ax2) is temporalized: it applies to a triplet in which the first argument is an occurrent, the second a type and the third a time.
8Another important point in discussing functions is the level of granularity at which they are presented: functions can be simple (like transfer torque) or compound (like build a table). This is an important point that we leave for future work. are implicitly limited to objects of a certain size, weight and material, even though at this level of representation the specific constraints might not be explicit). For this reason, a proposal could be to distinguish the intrinsic (individual) qualities of an entity (e.g. shape, weight and color), from the relational (individual) qualities of the same entity (e.g. capabilities to hold, to carry, to cut, to acquire information and so on). Future work on our proposal needs to consider how to treat this distinction in the light of the debate about relationships [22].
In industrial scenarios, most of these capabilities, and in particular those relevant to participation in a manufacturing activity, are designed capabilities. By designed capability, we mean the attribution, made by the designer and/or the producer, of a capability to the designed/produced object. The attribution of a designed capability to an object characterizes artifacts and requires conditions like the (implicit or explicit) presence of causal relationships relative to that capability in the object’s design, and the successful result in a quality test [23]. The typical organization of work in industry ensures that among the capabilities of an object (i.e., the capabilities that it actually has at the time of consideration) there are its designed capabilities. Exceptions are assumed to occur in special cases known as failures (of devices) and misbehavior (of humans).9
An object that has a capability is an object whose interaction with the environment causally contributes10 to the realization of an activity, that is, it can participate in the successful execution of that activity. The core idea is that, given an activity and the object’s capabilities, the object can participate in an occurrence of that activity only if there is a role that fits its capabilities.
We have introduced capabilities as relational qualities relative to some functionality, i.e., an object that has a capability can contribute to realize some types of change. This determines that the object can play a role in an activity where that kind of transformation is needed. This, however, is not enough. A container has the capability to hold. Yet, in an activity occurrence the container has to contain a specific object for that particular activity to be realized. Similarly, a truck has to carry a specific type of object specifically required to be moved in order to successfully participate in a particular moving occurrence. In short, we need to move from being able to perform a function to being able to perform a function on certain objects and perhaps within specific constraints.
The notion of capacity is what we need here. Looking at how capacities are used in the literature (see Sect. 1), we propose to ontologically understand capacities as individual qualities that provide quantitative information. In this paper, we are interested in capacities related to capabilities as introduced above. The capacities of an object are its individual qualities that specify to which extent the object can realize a function, i.e., manifest a capability. Like capabilities, capacities are relational qualities that depend on the context in which the object is used. Examples of capacities are containment (volume available to perform a storage functionality depending on the type of entity, e.g. liquid, spheres, boxes and pallet) and throughput (e.g. output of parts relative to a production capability).
Without entering in details, we now show how this could be formally modeled. Recall that in our framework a capability is the quality of a physical endurant that can participate in an engineering function, and that a physical endurant that has a capacity has also at least a suitable capability: 9The problem may be in the plan itself because badly characterized or even physically unrealizable. 10The relation ‘causally contribute’ is here taken as primitive. It resembles the use in [24].
As in the formalization of functions in Sect 3, these axioms acquire full strength once a framework for the classification and interdependencies across capabilities and capacities is provided. Also, because resources only possibly participate in manufacturing occurrences, the use of modal logic would be more suited to represent modality. For instance, looking at (Ax3), it should be clear that only possibly participates in . Further work is therefore needed to coherently grasp these aspects in a robust formal way. Table 2 provides a summary overview for the terms discussed in the last two sections.
We proposed to separate the notions of capability and capacity, both seen as individual qualities
of objects, and to use them to align objects with the functions they can perform. Also, the
introduction of the distinction between ontological and engineering functions helps to reason in
terms of transformations and ways of achievements. In this view, if a resource bears a capability,
than it can participate in the execution of an activity with certain requirements. Our proposal is
presented within the PSL approach following our earlier work, e.g., [
Although the presented proposal has still a preliminary flavour, with respect to the state of the art, we explicitly spelled out how capabilities and functions can be conceived in a manner that is coherent with both applied ontology and industrial engineering. This is done by relying on the literature about engineering and ontological functions, which is seldom taken into account in existing works.
Further developments are needed to strengthen our proposal and bring it to the application level. A formal representation of the discussed notions is foremost required to explicitly capture their intended meaning. A deeper investigation of some ontological notions is also needed; e.g., we conceive capabilities and capacities as relational qualities. This view requires a precise treatment of what relational qualities are, as well as a representation of the corresponding quality spaces (i.e., abstract and commonly multi-dimensional spaces giving information about the values of qualities [13]). Finally. the approach needs an industrial benchmark to be tested against use cases. [11] R. Arp, B. Smith, A. D. Spear, Building ontologies with Basic Formal Ontology, Mit Press, 2015. [12] L. Solano, F. Romero, P. Rosado, An ontology for integrated machining and inspection process planning focusing on resource capabilities, International Journal of Computer Integrated Manufacturing 29 (2016) 1–15. [13] C. Masolo, S. Borgo, A. Gangemi, N. Guarino, A. Oltramari, L. Schneider, DOLCE: A descriptive ontology for linguistic and cognitive engineering, WonderWeb, D18 (2003). [14] L. Solano, P. Rosado, F. Romero, Knowledge representation for product and processes development planning in collaborative environments, International Journal of Computer Integrated Manufacturing 27 (2014) 787–801. [15] ISO, ISO 15531-31: Industrial automation systems and integration - Industrial manufacturing management data - Part 31: Resource information model, 2004. [16] M. S. Erden, H. Komoto, T. J. van Beek, V. D’Amelio, E. Echavarria, T. Tomiyama, A review of function modeling: Approaches and applications, Ai Edam 22 (2008) 147–169. [17] M. Grüninger, Using the PSL ontology, in: S. Staab, R. Studer (Eds.), Handbook on
Ontologies, Springer, 2009, pp. 423–443. [18] S. Borgo, A. Cesta, A. Orlandini, A. Umbrico, Knowledge-based adaptive agents for manufacturing domains, Eng. Comput. 35 (2019) 755–779. [19] R. Mizoguchi, Y. Kitamura, A functional ontology of artifacts, The Monist 92 (2009) 387–402. [20] D. Almeida, J. Ferreira, Analysis of the methods time measurement (mtm) methodology through its application in manufacturing companies, in: 19th International Conference on Flexible Automation and Intelligent Manufacturing (FAIM 2009), 2009. [21] G. Fantoni, S. Al-Zubaidi, E. Coli, D. Mazzei, Automating the process of method-timemeasurement, International Journal of Productivity and Performance Management 70 (2021) 958 – 982. [22] N. Guarino, G. Guizzardi, “we need to discuss the relationship”: Revisiting relationships as modeling constructs, in: International Conference on Advanced Information Systems Engineering, Springer, 2015, pp. 279–294. [23] S. Borgo, M. Franssen, P. Garbacz, Y. Kitamura, R. Mizoguchi, P. E. Vermaas, Technical artifacts: An integrated perspective, Applied Ontology Journal 9 (2014) 217–235. [24] S. Borgo, R. Mizoguchi, A first-order formalization of event, object, process and role in yamato, in: FOIS 2014, volume 267 of FAIA, IOS Press, 2014, pp. 79–92.