Towards a formal ontology of engineering functions, behaviours, and capabilities

4.1.Engineering behaviours

Engineers create an artifact to realize a certain interaction between the artifact itself and elements of the environment. The behaviour of an artifact is the way in which that artifact participates in that interaction (e.g. ‘[the car] rattled when it hit the curve’ [17]). In DOLCE one models the happening of the interaction as a perdurant. How to ontologically understand behaviour is more tricky. In the literature, the term behaviour is used with different meanings, e.g., as simplified part or description of processes like in these excerpts: ‘The causal rules that describe the values of the variables under various conditions’ [17], ‘the behaviour represents objective conceptualisation of its input-output relation as a black-box’ [43], ‘situation-independent conceptualisation of the change between input and output of the device’ [70]. In YAMATO [72] behaviours are modelled as processes with an ‘agent or an agent-like object as a doer’. Instead, in [4] Borgo et al. model them as relational qualities which characterize the specific way of participation of an object in individual events.

Here we discuss a few key ontological properties to distinguish possible definitions of behaviour. There are, in fact, at least four axes along which different meanings of behaviour can vary in the literature. First, there is what we call the occurrence-property dichotomy:

Then, there is the token-type distinction: behaviour can be a class or a concept, as for Mizoguchi in [70]. Alternatively, it can be an instance of something, or an entity relative to a specific event, as for Chandrasekaran and Josephson in [17], and for Borgo et al. in [4], respectively.

Additionally, there is the external-internal axis, that is, the behaviour of an artifact may refer only to characteristics of the artifact itself, or it may need to refer to external entities. For example, ‘the electric switch can alternate between open and closed states’ is an internal behavioural description, as it refers only to transitions between states of the artifact. In contrast, ‘the current passing through an open switch is zero, if the applied voltage stays within operating conditions’ is an external description, since, the current and the voltage are not intrinsic elements of the artifact. Some authors explicitly use behaviour with the internal meaning, e.g. Zhao et al. in [104], others with the external one, as Kitamura et al. in [47].

Finally, there is the modal axis, since behaviours can be either expected (i.e. as envisioned by engineers) or actual (i.e. what actually happens), as implied by Gero in [28] with respect to design activity (though one could use the same duality when talking of, e.g., malfunctioning). This axis includes, arguably, talks of causal laws or relations, since those could be conceptualized as changes of a system under some kind of modality, that is, changes that necessarily happen when some condition is met. We do not argue in favor of conceptualizing causal laws in this way, but, in any case, one must also take this use of behaviour into account, since it is encountered often.

In this paper, we take an engineering behaviour to be a DOLCE perdurant with a few assigned roles. The class of engineering behaviours, called just behaviours from now on, is the class of perdurants in which one can identify two ‘processual’2323 roles in the sense of [59]: an active one, called doer, and a passive one, called operand or flow [78]. This role-based notion of behaviour is motivated by (and restricted to) the domain of functional modeling where it highlights a common engineering viewpoint. This notion complements the broader ontological view of behaviour as a relational quality between an entity and its environment, which was introduced in [4]. While the role-based view introduces behaviour as a perdurant and fits naturally with the view of ontological function that we will investigate later, the ontological notion of behaviour can be resumed to distinguish the behaviour of the doer from that of the operand, if necessary. For instance, a cutting action entails that there is something that is the subject of the action, say a saw (or the system formed by a person or machine using the saw), and the object of the action, say a beam of wood. At the same time, the saw has its own specific way to interact with that environment (to which the wood belongs), i.e., its own ontological behaviour, and so does the wood with respect to its environment (to which the saw belongs). The same holds for pumping, joining, and other behaviours described by transitive verbs.

All devices’ engineering behaviours that can be described as operations on operands have engineering behaviours as described above. Such behaviours, whose class we characterize with predicate Behaviour(·), are external behaviours, since the flow is an entity external to the behaving artifact (the doer). We conceptualize the two processual roles through two specialisations of the participation relation: participatesAsDoer(·,·,·), to indicate participation in a process with the role of an agent or agent-like doer, and participatesAsFlow(·,·,·), for the role of flow:

From (a9) it follows that behaviours are perdurants. Additionally, we assume that behaviours can be combined to give causal explanations of complex perdurants (e.g. the beam was cut, therefore it fell to the floor), and formalize this with a binary relation called causal contribution,2424 which we assume holds more in general between perdurants:

We do not axiomatize the causal contribution relation further as it has a much broader scope than the focus of this paper but see [10] for an initial proposal.2525 Similarly, we do not axiomatize the roles of doer and flow, see [59] for a deeper discussion of these notions.

The role-based approach combined with the causal contribution relation allows us to model behaviour from the point of view of the participating device (a9). Admittedly, it also introduces some limitations. For instance, the case of an artificial agent changing its own setting exemplifies a function where doer and flow coincide, a case ruled out by (a9) (such a function is called ‘change over’ in [6]). A full analysis of the relationships between the two approaches to behaviour (relational quality vs. perdurants with roles) has not been carried out. We highlight once more that they are mutually compatible within DOLCE. When using behaviour from now on, we will mean engineering behaviour unless otherwise specified.

Having conceptualized behaviours as a role-based view of perdurants, we spend a few words about the notion of state of an engineering system. In DOLCE states are, as mentioned in Section 3, cumulative and homeomeric perdurants. The same properties should hold for engineering system states. Indeed, if we understand states, as many engineers do, as conditions determined by constraints over state variables, then such conditions are homeomeric (if a device satisfies a constraint over a time period, then it also satisfies it during a fragment of that period) and cumulative (if a device satisfies a constraint over some time periods, then it satisfies it during the union of those periods). Unfortunately, engineers commonly use the term ‘state’ also for oscillating phenomena and the like (e.g. the buzzing action of a clapper, which alternates between two different DOLCE-states while buzzing, namely open-circuit and closed-circuit). Hence, the right DOLCE category to conceptualize system states is the one of stative perdurants. To avoid a terminological clash, in the following we will use the term ‘state’ following the engineering terminology. Ontologically, it is to be understood as a ‘stative condition’ in DOLCE. For this reason, we will use the stative predicate STV(·) in formulas.

Finally, engineers typically know how to characterize a state a system should be in, therefore we assume that, given a technical artifact, some ‘types’ of states are selected as desired, and call them goals. Note that, typically, one selects the conditions that a state has to satisfy, that is, selects a concept and not a state-instance, since the latter would have a specific time extension. Hence, we have that

Thus, goals may correspond to expressions ‘the temperature at the port B of the heat exchanger is between 80 and 110 Celsius degrees’ and ‘the buzzer is clapping with a frequency of at least 10 kHz’, which are expressions for state classifiers.

4.2.Systemic functions and ontological functions

Systemic functions In this paragraph we exploit the concepts introduced in the previous sections and propose a preliminary formalisation of ontological functions as roles. Precisely, we start by defining systemic functions. In doing that, we are mainly inspired by the definition presented in [71] (cfr. also Cummings’ definition in [20]), from which we also take the concept name. Such a definition is based on the so-called systemic view of devices, that is, on the idea that devices are complex aggregates of components, whose interaction with the rest of the system contribute to generate the activity of the whole system. In this context, a function is seen as the contribution of an individual component’s activity to the activity of the system as a whole, and teleological aspects are introduced through goals imposed on the system. Note that our notion of behaviour (a perdurant with roles) is different than the one in [71] and presents a nice feature: with our approach it is very simple to decompose (and to recompose) the system’s behaviour into components’ behaviours as the latter are simply parts of the first (provided one correctly identifies the suitable roles).

Of course, there are many different function conceptualisations in the literature and each is relevant from one engineering perspective or another. We propose to start from Definition (d8) because, differently from the others, it is ontologically clear and helps to clarify the assumptions on which other meanings rely.

Note that, observing Definitions (d8) and (d9), it is natural to assume that systemic functions are definition-founded on systems, a fact that we introduce with the following axiom:

Ontological functions In engineering practice, one may speak about functions independently of any system, for instance in an early system design phase. For example, if one wants to address the problem of finding the set of devices that have the capability of realizing a needed transformation, the devices cannot be a priori associated with a certain system, since there is no system yet. Indeed, the system is a variable input of the problem. Therefore, to solve this problem, a more general concept of function is needed, see, e.g., [6]. We call such functions ontological functions as they are relative only to the upper ontology one is using. The idea is that these functions distinguish very general transformations without addressing how such a transformations may occur or to which entities they apply. The informal intuition of ontological functions is that they are classified primarily according to the ontological difference(s) they enforce between the input and the output states. In this sense, they are independent of systemic functions.

For instance, assume we want to model a walking activity as the realization of a moving function. Walking may be considered a simple action but is very complex to model since it is a highly coordinated, continuous and dynamic process. One might decide to simplify its modeling by “restricting” the walking model to some aspects, such as the variation of the distance of the feet from the floor, the trajectory of the body’s center of mass, the changing contact forces between the feet and the floor, those developing into the leg joints, and so on (cf. [33]). It turns out that there are many aspects that one may focus on. Which should one use?

Assuming that an upper ontology is fixed (DOLCE in this paper), one considers the state transitions that are made available by the ontology and that are relevant to the transition of interest. In the case of walking, the relevant feature(s) that characterize a walking in the upper level of DOLCE are the change of location of the entity. At this high level, among the entities relevant to walking, the ontology makes available only space and location qualities. Other classes, like foot or center of mass, and other qualities, like speed and force, are not characterized nor committed to. The perdurant could not be said to be a walking since DOLCE has no walking category nor the needed ontological commitments to introduce such a category. If walking at this level can be characterized only by the change of the location quality, then one cannot distinguish it from swimming or flying (this depends on the upper level ontology, different ontologies may be more or less rich). One may wonder whether this level of characterization is too weak to be used for functional modeling. It is not. Already at this level one can make substantial differences since one can distinguish cutting from walking. Cutting is characterized by the presence of one entity at the initial state and two or more at the final state, walking is not. (In DOLCE, like most (perhaps all) upper ontologies, entities can be distinguished in number, thus cutting and walking are different types of perdurant even at this level.) Since functions are realized by perdurants, we can use this ontology-driven categorisation of perdurants to introduce a categorisation of functions. Let us call ontological functions the functions that are carried out by transformations characterized by the ontological commitments (thus, distinctions) present in the upper ontology. As said, this provides only a high level (coarse) characterization of functions. Since the resulting taxonomy of functions strictly depends on the ontology adopted, we use the qualifier “ontological” and call them ontological functions (where more than one upper level ontology is used, one should be more precise indexing the ontological functions by the ontology they depend upon, e.g., ‘DOLCE-ontological functions’). Continuing the discussion with DOLCE as the upper ontology, the ontology makes available the categories region, quality, physical object, amount of matter, etc. (see Fig. 1), which give rise to several ontological function-types based on change in quality-value (for example, the controller increased the internal temperature of the oven), change of physical object (e.g., the employee assembled four legs and a table-top to form a table), change of amount of matter (e.g., the water was vaporized by the boiler), and so on.

Note that an ontological category can be involved in a transition in different ways. For example, an instance of said category could be eliminated, meaning that the instance was present in the state before the transition but not after, or an instance could be created, meaning that the instance was not present before a transition but exists after. Another possibility is that there is a change of a relation of the ontology, e.g., in the initial state there were two individuals that were, say, one part of the other, while in the final state they are not. More complex changes can be described, depending on the difference between the initial and final structure of the ontology. We have reported some of these cases in Fig. 2, which is not exhaustive, while in Fig. 3 these cases combine with the aforementioned ontological categories to produce different ontological functions. Note also that in most cases the same event may be classified by several ontological functions. For instance, an event of cutting by a device, say a knife, is also a squeezing event, i.e., a compression (a change of the shape quality of the initial object) and a moving event (a change of the device location relatively to the object’s location). Clearly, most of these distinctions are similar to those obtained via the ontological analysis of events [33]. Finally, the functional terminology used in this paragraph is inspired by engineering literature which, as we have seen earlier, is not homogeneous. For instance, the reclassification (i.e., a change such that an instance changes type) of energy or matter is in other places called ‘convert’ [37,87] or ‘change’ [78] or ‘transform’ [47], while the change of value of a spatial location quality is called ‘channel’ [37,78], and so on.

Functional terms that are linked to domain-level terms (e.g., ‘vaporize’, ‘moisten’, ‘heat’) are not captured at the lever of ontological functions and require a domain or middle-level ontology containing corresponding concepts (e.g., vapour, humidity, temperature) in order to expand the construction we have just described up to that level of ontological distinctions. The ontological nature of some concepts, like ‘energy’, is unclear [67] despite being a fundamental concept in engineering and physics. Nonetheless, given an ontology containing a conceptualisation of energy, it is possible to introduce a corresponding ontological function, which might be different in another ontology with a different conceptualisation of energy. For instance, one could conceptualize energy as a quality, as done in [5]. This is the case, arguably, when one speaks about the energy of something, e.g, of a battery. In this case, in our ontology there would be a, say, energy content quality-type, which gives rise to a corresponding convert energy ontological function. Another possibility is to conceptualize energy as an endurant, which can reside into entities, change its location, and change type (e.g., heat energy, kinetic energy, etc.). In that case, the convert energy ontological function would be a reclassification-type transformation.

Formalizing ontological functions, like formalizing events, might be difficult. One would benefit from the introduction in the ontology of a general relation ‘change of …in event …’. An ontological function, as understood in this paper, is essentially an event classifier which looks at what changes (or remains stable) in the event. This suggests defining specific functions by comparing, for instance, initial and final states. For example, a connect function could be introduced as follows:

In the previous formula we used the predicate startState(y,si,ti) to mean that si is a state with time extension ti, which is part of the perdurant y and such that there are no parts of the time extension of y which precede ti. Analogous meaning for endState(·,·,·). Notice that: (a) this notion captures the act of forming a single object out of two given ones, to formalize an assembly function one should add the condition that the final object is also a single piece (self-connected); (b) if one reverses the initial and final states in Formula (d10), then one obtains a definition for the divide function.

Another example, to define a convert function (here Φ and Ψ are types belonging to the set NR of all non-rigid types of the underlying ontology):

Notice that in the previous definition we have quantified over the set of all non-rigid classes of an ontology (NR). If such a set is finite, like in DOLCE, then the quantification corresponds to a finite disjunction of predicates, therefore Formula (d11) is a first-order formula. Moreover, upper-level ontologies typically contain only rigid categories (e.g., if an individual is a physical object, it is always a physical object), therefore, such a convert function becomes useful when modelling changes in entities that go through phases [35], when modelling entities that change their processual role (as described earlier) or in combination with non-rigid categories (as provided by middle or domain-level ontologies).

The type of all ontological functions that involve some change in quality values (cf. qualitative events in [33]) could be defined as follows:

One can further specialize this latter notion. If the quality in formula (d12) is spatial location, the ontological function will be of type channel. If the quality in (d12) takes values in an ordered space (e.g., temperature, humidity, etc.) then the ontological function is of type vary, possibly specialized into increase and decrease types, see [37,78]. Some functions, such as store and support, hint at the absence of change: for instance, a battery stores energy very well if it does not lose its charge over time, while a load-bearing wall supports the roof only if the roof does not fall. Therefore, functional concepts like store and support could be defined by modifying formula (d12) to impose that the initial and final values of the quality are the same (perhaps including some tolerance).

At this point we make three observations:

Up to this point we have defined some types of ontological functions, but not the concept of ontological function itself. A possibility is to find an exhaustive list of types of ontological functions and then define ontological function as the disjunction of all those types, for instance:

This can be done by providing an exhaustive list of ontological functions made available by an upper ontology. Another possibility is to look for an intrinsic definition of ontological functions that informally could be as follows: Since “a formula expressed in the language of an upper ontology” is not something that can be written in a natural way using first-order logic, we cannot give an intrinsic first-logical definition of ontological functions. (A similar argument could be applied to extend the notion of ontological functions to functions in the language of reference ontologies.)

Link between systemic functions and ontological functions Returning to the relation between systemic functions and ontological functions, we observe that the former correspond to system-dependent functional descriptions, while the latter corresponds to system-independent functional descriptions. Since ontological functions are more general than systemic functions, they can be used to classify them:

For example, take a tooling machine as a system, e.g., a lathe, and assume that it makes use of two electrical motors: one for rotating the spindle and the other for moving the spindle horizontally. Both electrical motors perform the same ontological function of ‘converting’ (electrical energy into mechanical energy), but they also perform two different systemic functions specializing the ontological function in the context of the lathe: ‘converting (electrical energy into mechanical energy) to rotate the spindle’, and ‘converting (electrical energy into mechanical energy) to translate the spindle’, respectively. The intuition is that we can group systemic functions together through common characteristics, along the lines of definitions (d10) to (d12), abstracting from specific systems or from their occurrences in different parts of the same system.

Finally, notice that the two types of functions introduced in this paragraph cover at least two different ideas of functions used by engineers. First, there are ‘general’ functions that engineers use when they need to, say, describe information about or collect information from different systems. For example, Collins [19], when collecting and analyzing failure experience data, speaks of ‘elemental mechanical functions’, which are application-independent characterisations of ‘basic’ functions. Analogously, Pahl et Beitz [78] speak of ‘generally valid functions’, and propose them as references for cataloguing design knowledge about function implementation. These types of functions can be approximated via ontological functions. In contrast, a second meaning used by engineers is system-dependent. In general, when engineers focus on a single system, they use different concepts to speak about the system components. The terminology is varied, but typical terms are ‘serial number’, that is the identifier of a component-instance, ‘component code’, i.e. the component or assembly-type identifier, and ‘functional location’ or ‘tag’, which are identifiers that consider also the position of a component within a system. For example, Fig. 4 schematises a hydraulic system containing four solenoid valves, whose tags are EPF1 to EPF4. These tags cannot refer to the valve-type, since the four valves could have the same type, nor they can refer to the valve-instances, since schema are generally used to represent different system-instances. In our terminology, we could say that tags identify roles that components play in a system. Necessarily, these roles are of functional nature, for each component in an engineering system has a role in the system function. Thus, tags or, at least, the teleological content they carry, could be formalized by systemic functions.

4.3.Functional decomposition

An important feature of functions in engineering is the possibility to decompose them into sub-functions. This also allows to refine the granularity of the system description. In this paragraph, we show how such decomposition relation can be used in order to formalize the difference between ontological functions and engineering functions that we described earlier.

First, observe that such decomposition cannot be reduced to a partial order relation between functions. That is, if we represent the functional decomposition of a function, say f, into sub-functions, say f1,f2,…,fn, as decomp(f;f1,f2,…,fn), then it does not seem possible to find a parthood relation such that decomp reduces the mereological sum. This is caused by, at least, the following reasons:

Additionally, Vermaas has proven that attempting to model a Functional Basis style of functional decomposition2828 entails contradictions [100],2929 so that there are also formal obstacles preventing the application of classical mereology to functional decompositions. We do not attempt a solution to these problems here, instead we assume that the relation decomp is given, and focus on engineering methods.

Inspired by the work of Kitamura et al. on ‘ways of functional achievement’ [43,45], we consider engineering methods as non-agentive social objects representing the knowledge that engineers share about ways of implementing functions through functional decomposition:

Formally, such non-agentive social objects can be understood as reifications of functional decomposition relations. Precisely, we introduce roles mainFunction(·) and subFunction(·), contextualized by a decomposition, such that: Additionally, we assume that methods are always contexts for a main-function and for a certain number of sub-functions (axiom (a16)^∗ is actually a meta-axiom, for this reason we mark it with a ∗-symbol). Note that, given a finite set of methods, the previous axiom can be substituted with a finite set of axioms in FOL. The following condition constrains the decomposition relationship and is expressed via an axiom schema (here n is an integer): Since the main-function and the n sub-functions roles of a given method are univocally determined, we can represent them with functional symbols. In particular, we will write mainm, sub1m, …, subnm to indicate the roles corresponding to the method m, as per Axiom (a17) (we omit the functional dependence of n on m, for ease of notation). Finally, the link between methods and decompositions is given in the following definition schema:

The advantage of this approach is manyfold: it makes possible to organize the method-types within sumbsumption taxonomies, for example, ‘spot welding’ is a specialisation of the method ‘welding’, which itself is an implementation method of the function ‘to join’; and to describe the properties of the methods, for instance the working principle, say Kirchhoff’s law for a ‘voltage divider’ method. Additionally, it makes possible to introduce properties of functional decomposition. For example, if one wishes to express that all functions are decomposable, she can state:

Instead, if one wishes to state that a function, say f, is not decomposable: Moreover, this approach allows us to give a formal definition of engineering function and, thereby, to discuss the ontological difference between capacities and capabilities. In fact, we define engineering functions to be main functions so that engineering functions are roles that systemic functions, which are defined in (d9), can play in the context of a functional decomposition. For instance, in the lathe example discussed above, it could be that the systemic functions of the two motors are both implemented through the method of, say, ‘three-phase electric motor’, and, therefore, play the role of engineering functions. In this case, the functional decomposition entailed by the method includes sub-functions roles for, say, ‘supply electrical energy’ (one per each phase), ‘drive the motor’, and ‘output mechanical energy’.

5.1.Capabilities vs. capacities

Whenever a capability is based on some other quality of a technical artifact, that is, when each realisation of the capability depends on some other quality, we say that it is founded on that quality (or qualities). As before, we formalize this through the relation founded(·,·) defined in (d4). For example, in the case of the pump we could say that the capability of the pump to move water is founded on its flow rate capacity. Coming back to Gero and Qian’s example of the water tap mentioned in Section 3, which is similar to the one of the pump, we could say that the faucet has the capability of delivering water when requested, which is founded on its flow rate capacity, which is itself founded on its diameter quality (Gero and Qian say that the flow rate is ‘controlled’ by the diameter [80]). Now, in this example, there is a difference between the flow rate and the diameter: the latter is an intrinsic quality and the former is a relational quality, as we argued in Section 3. These examples suggest that capacities are those relational qualities on which a capability is founded, analogously to the approach in [11]. The point is that capacities are relational qualities that provide information about how the corresponding capability can be realized in practice. Going back to the pumping example, we conclude that the flow rate capacity parametrizes, perhaps only partially, the pumping capability.

Another example: electronic components such as resistors, transistors, etc., are accompanied by a datasheet that reports technical properties of the devices. Typical properties are, for example, the failure rate and the maximum temperature, current, or voltage that the component can reliably operate with in standard conditions. In our terminology, all the aforementioned properties are capacities: these properties are manifested only when the component is inserted into a working electrical circuit;3131 and they parametrize some capability of the component like, say in the case of a resistor, to create a voltage drop.

Capacities themselves are founded on some intrinsic physical qualities of the bearing object. For example, the maximum operating current will depend on the geometric and electrical properties of the conductor metal, such as its diameter and its resistivity. Similarly, the flow rate of the water tap depends on its diameter. Given these observations, we characterize capacities as follows:

In (a18), the bearer(·) is the (unique) bearer of a quality, i.e.: Axioms (a18) and (a19) do not fully define what a capacity is. They only give some constraints. Modelling the relation between capacities and capabilities remains complicated and requires further investigations. Yet, a promising way to tackle the problem is to define a capacity as a ‘parameter’ of the capabilities it founds, that is, as a quality such that its values are always related to the conceptual space of the corresponding capability: Briefly put, the formula above views capacities as the parameters of capabilities allowing to ontologically support practical approaches like, e.g., that of ISO 15531-31 [39].

5.2.Capabilities vs. functions

From another perspective, capabilities are inextricably intertwined to functional aspects. To be able to do something is, arguably, a modal concept calling for possible events in which that something is actually done. Possible events are already part of the DOLCE ontology so we can write the following (where e is a possible, perhaps not actual, event):

Since the introduced capabilities are specifically dependent on their bearers, and each capability of a certain kind is unique to its bearer, we treat them as individual qualities.3232 Finally, note that Example (ex4) also seems to suggest that capabilities depend on types of functions (not just processes or behaviours, for the pumping process in (ex4) will always play a function), which are used in their definition. This suggests to adopt the definition-founding relation already introduced in Section 3:

Additionally, we assume that each capability is parameterized by at least a capacity (cf. (a19)): From this axiom, we have that capabilities are specifically dependent on capacities, which specify how the artifact (the bearer) can function. The intuition, as anticipated at the beginning of this section, is that capabilities are relational qualities that associate their bearers with ontological functions, so that they must refer to those functions: in our terminology, they are definition-founded on ontological functions. Note that they are not instantiation-founded, see (d5), since an artifact could have the capability to function without actually functioning. Additionally, the function must be ontological and not systemic because, otherwise, the bearing object would be associated a priori with some given system.

The characterization of capacities and capabilities via (a18), (a20), and (d18) has the advantage of explaining:

The quantitative-qualitative difference between capacities and capabilities anticipated at the end of Section 2 is only partially clarified by this approach. For instance, while a flow-rate capability takes as values positive real numbers with, say, m³/s as unit of measure, the value space of the corresponding pumping capability is quite more complex and difficult to describe.

One reason for the difficulty in defining capacities and capabilities is the relational and potential nature (in our interpretation) of these concepts: they are relational, and we have attempted to capture it with relational qualities, since they need the relation between their bearer and its environment to make sense; and they are potential, in the sense that they are strictly related to events that may occur, but need not to actually happen. Functions are, arguably, similar to capabilities in this aspect, and this may partially explain the terminological and conceptual complexity that these concepts bring. Of course, these concepts are not the only ones to be both puzzling and commonly used in engineering: affordances are another well-known example. As mentioned at the end of the literature review, engineering affordances are often defined as “interaction between artifact and user in which properties of the artifact offer a potential use to the user” [62], but this is not an universally shared definition, and conceptual confusion persists in the disciplines (not only engineering) that make use of this concept. We do not attempt to carry out an ontological analysis of affordances, but we do make two brief observations:

From this point of view, our analysis of capabilities would carry at least some insight into affordances.

Finally, in Fig. 5 we give a schema that shows the main relations and concepts used in our theory of engineering functions.

We conclude this section with another example to show how the concepts we have introduced above concur to provide an integrated description of a functional scenario. Suppose that a company handling swimming pools must empty some of its pools for maintenance. This imposes a goal, say ‘the pools are empty’, that must be carried out through some device able to realize a ‘to move’ (ontological) function, specialized to a systemic function in the context of the swimming pool system. Such a function can be realized by artifacts that have a corresponding capability. In this case, the function would probably be implemented through some fluid-emptying-method, that is, through the knowledge of the way that a recipient can be emptied, and its fluid content disposed of, by pressurizing the fluid and guiding it through a path. Now, the ‘pressurize’ sub-function (which refers to the goal of ‘having a big enough pressure gradient’) could be implemented through a pumping-method, that is, referring to engineering knowledge about pumps. Then, a pump (more generally an artifact with pumping capability) could be selected for being the ‘doer’ of the necessary ‘transform electrical energy into pressure’ sub-sub-function. In this context, we could say that the pump has been selected because of its pumping-capability and that the pumping-method describes, at least, a flow rate capacity, which founds the pumping-capability, and its interaction to the other properties and entities involved in the pumping process.

6.1.Reduction to OWL ontology

To facilitate the deployment of our theory in applications, we present an OWL version of the first-order logic formalization. This is standard practice, for at least the following reasons: first, OWL is decidable, while first-order logic is not, so that reasoning tasks will terminate in finite time.3333 Second, OWL is a standard endorsed by the World Wide Web Consortium (W3C) and is part of the Semantic Web technology stack [102], and is the language of choice for many ontologies in various domains [75].

Unfortunately, the computational properties of OWL come with a tradeoff with respect to its expressibility, therefore, one has to simplify the first-order theory. The original theory remains essential as it constrains the intended meanings of the OWL concepts and provides the ‘official reading’ of the theory, it also helps to conceptually understand how the overall model is supposed to work.

The first-order theory developed in the previous sections can be converted to OWL language as is, except for the expressions where ternary relations are used, as well as those that necessarily need at least three arguments to be formulated. For example, the definition of systemic-function-of (d8), the instantiation-founding definition (d5), and the engineering method schema (d15) cannot be expressed in OWL. In these cases we have to weaken the axioms. For instance, in OWL we replace the definition of systemic functions with

where classifies is the inverse relation of CF(·,·,·). In this way the fact that systemic functions are founded on systems is preserved.

Additionally, all the ternary temporalized relations used in the first-order version, such as CF(·,·,·) and participateAsDoer(·,·,·), occur in the OWL version with the temporal argument removed, i.e., as binary relations. The link between the temporalized and non-temporalized relations can be interpreted in different ways [95]. For example, one could state that the non-temporalized relation holds if and only if the temporalized relation holds whenever one of the relation arguments exists, what argument precisely depends on the relation. This is our choice for parthood (d7), classification, temporal quale, and participation-like relations as shown by these meta-rules aimed to show the intended interpretations:

One could also state that the non-temporalized relation holds if and only if the temporalized relation holds true at some time adopting the following meta-rule: There are other possibilities. The choice of one over the others must be planned carefully depending on the application concerns, since this kind of changes affects the intended models of the OWL ontology. For example, (d21) excludes participation-as-doer in, say, a chemical process only for its first part, while (ex6) allows it, but in OWL this difference is lost. Additionally, the removal of the temporal argument reduces the flexibility of the ensuing ontology. For example, one cannot track (at least not directly) dynamic aspects of roles, e.g. a component that carries out a function at a time and then it changes its function. Nor one can express that, say, there is a chemical process which is driven by two different catalysts during its first and second parts.

Finally, as a further simplifying assumption, we define two binary relations that we will use as shortcuts to implement and simplify the definition schema (d15) and to redefine (d16):

Note that in (d24) the individuals must necessarily be systemic functions due to (d22).

Even though the DOLCE ontology is primarily a first-order logic theory, OWL versions exist as well, e.g. DOLCE-lite and DOLCE-Ultralite.3434 Any of these could be used to align the ontology developed in this paper with DOLCE. In our case, we used the OWL version of DOLCE that has been recently submitted as part the ISO 21838 standard. The resulting ontology, which can be found on GitHub,3535 was tested using the Hermit reasoner. (For the sake of example, the ontology is populated with only a few individuals).

6.2.Evaluation

The ontology developed in this paper is a hand-crafted prototype that discusses middle and high-level concepts. Therefore, some common approaches to evaluation cannot be employed, as, for example, there is no “gold standard” [90], or set of formal ontologies that one could use to compare common ontology metrics (such as those extracted by OntoMetrics3636), nor there is a precise application against which to carry out the evaluation. Instead, we will evaluate our ontology using the OntoClean methodology [35] and the Ontology Pitfall Scanner [79]. Moreover, we will discuss how our ontology answers the research questions (RQ1)–(RQ3), as well as some competency questions that will serve to demonstrate the expressive potential of the ontology. Finally, we will also discuss some possible application scenarios, though we highlight that the ontology main goals are the research questions (RQ1)–(RQ3). The development of derived application-level ontologies is a goal for further work.

OntoClean OntoClean does not identify any issue in our taxonomy, that is, none of the meta-level rules that OntoClean methodology enforces are violated. In fact, this is almost trivial to check: since we are extending DOLCE categories, the only source of OntoClean violations would be an extension of role-concepts (that is, the set of all entities that, at a given time, are classified by the role-concept) which is not anti-rigid. This condition is not violated since (systemic) functions, as we define them, are contextual (e.g., a heat exchanger, with its behaviour, may be used either to heat a substance or to cool it, depending on the context). The other rules checked in the OntoClean methodology are trivially true. The correspondence with OntoClean principles is mainly due to the alignment of our theory with a well-established upper-level ontology.

Ontology Pitfall Scanner The OWL ontology was evaluated with the Ontology Pitfall Scanner (OOPS!) [79], which searches for common design errors from a list of 41 items. Among the pitfalls not related to imported ontologies, the scanner found some minor stylistic issues3737 and warned about a few important pitfalls: P11 (“Missing domain or range in properties”), P24 (“Using recursive definitions”), and P30 (“Equivalent classes not explicitly declared”). Of these three, P11 means that not every object property has domain and range axioms, but this is a conscious design choice to reduce the ontological commitment of the ontology. P24 occurs because OOPS! thinks that (a13) is a recursive definition (since the class of ontological functions appears both on the left and on the right of the material implication), but this is not the case. Similarly, P30 occurs because OOPS! is, incorrectly, assuming that the class of resistors (capabilities) and the class of resistances (capacities) should be equivalent.

Research questions and competency questions Our ontology answers the research questions listed in the introduction. In particular:

Additionally, since the formal ontology answers these research questions, it is also able to answer related competency questions, which can be of interest in applications, such as the following:

The OWL ontology, after being populated, can be used to answer the competency questions (CQ1)–(CQ6) by means of SPARQL queries. For example, these are implementations of (CQ1):

  PREFIX : <https://github.com/kataph/function-method-ontology#>
  SELECT  ?component
  WHERE {
    ?capability :definition-founded-on :<the given function> .
    ?capability :quality-of ?component}

of (CQ4):

  PREFIX : <https://github.com/kataph/function-method-ontology#>
  SELECT  ?component ?functionOntological ?capacity
  WHERE {
          ?functionSystemic :function-of ?component .
          ?functionSystemic :founded-on :<the given system> .
          ?functionSystemic :specializes ?functionOntological .
          ?capability :definition-founded-on ?functionOntological .
          ?capability :quality-of ?component .
          ?capability :founded-on ?capacity .
          ?capacity :quality-of ?component}

and of (CQ5), provided that the functional decomposition of a system is interpreted as the list of all systemic functions of the given system involved in a method, with their role (main-function or sub-function) and underlying component:

  PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
  PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  PREFIX : <https://github.com/kataph/function-method-ontology#>
  SELECT  ?component ?functionSystemic ?role ?method
  WHERE {
      ?functionSystemic ?role ?method .
      ?method rdf:type/rdfs:subClassOf* :EngineeringMethod .
      ?functionSystemic :function-of ?component  .
      ?component :constant-part-of :<the given system>}

The remaining competency questions can be implemented in a similar way (see also Fig. 6 for (CQ3), which is taken from the Protegé ontology editor – Fig. 7 shows another view of how the ontology appears in Protegé).

The fact that our ontology can answer all these questions shows its expressivity and coverage. In the following paragraphs we explain how these characteristics could be used in application scenarios.

6.3.Motivating scenarios

Innovative design (and other things) A good portion of the literature on functional modelling argues that functional modelling can be used to improve engineering design. For instance, the basic argument of the approach of Pahl and [78] is as follows: designers should start from the customer’s requirements, translate them into high-level functions, then decompose those functions into less abstract ones, until arriving at a point where finding a solution that realizes the functions is easy. This methodology, is argued, facilitates engineers to quickly develop high-quality designs and enhances their creativity by decoupling the goals of the design from the ways they are achieved.

This argument is not wrong, but, in actual practice, one rarely starts from a blank slate. Designers are typically constrained by the need to reuse pre-existing solutions, for a company may have developed a legacy that is difficult to depart from, possibly because the company would not be able to (profitably) reroute its know-how and resources towards innovative lines of products, or other reasons. Therefore, designers usually have to devise marginal improvements or corrections in pre-existing solutions, and these activities seem at odds with the aforementioned methodology. Additionally, the described methodology is design-oriented and does not seem relevant to other activities, such as troubleshooting or reverse engineering, despite functional reasoning being clearly relevant in all of them.

One important reason for carrying out ontological analysis is to bridge all such activities and cases, by producing an explicit representation (the ontology) of the shared conceptualisation of the relevant stakeholders, which can be used by all of them. We argue that our ontology is useful for the blank-slate innovation scenario (for, e.g., competency questions (CQ1) and (CQ3) showcase the possibility of linking capabilities to functions, which is important since it allows engineers to find whether they already have available components that can satisfy a given functional requirement), as well as many other scenarios, some of which we describe briefly in the following.

Incremental innovation In a company, innovation may happen mainly through incremental changes in pre-existing products. Therefore, product types will have a version history. Using our ontology, one could describe the relevant improvements, allowing their digitalisation in a semantically meaningful way. For instance, a new version may introduce new capabilities, or it may have the same capabilities as the former version, but it could realize them better due to different capacities. Storing such information could be more helpful to engineers than just storing structural information (like the bill of material) of the different versions in the enterprise management system.

Knowledge transfer An engineer or technician could have recently been employed by a manufacturing company. In that case, he or she is (hopefully) trained to learn about the company’s products and their functioning. Still, a good part of the knowledge the company possesses, especially functional knowledge, is implicit. Therefore, the trainee will learn about it only through experience or through his/her background knowledge of the domain. This may be a slow process, and some knowledge could be lost. Building a knowledge base modelling functional knowledge (necessarily together with other types of information, e.g. geometrical from CAD models, etc.) could facilitate training since it would relieve the trainee from having to infer the functionality of components from their structure, as well as the (functional) role of components within their systems.

Troubleshooting When a technician troubleshoots a product he often makes use of functional reasoning (e.g., “the volume of the speakers is constantly louder than it should be. It may be that there is something wrong with the amplifier circuit, since it is that component that has the function of controlling the volume”). Sometimes, a technician may lack sufficient knowledge about the functional structure of a product to carry out such reasoning fruitfully (say, it is an external contractor with limited knowledge of the company which manufactures the product). In those cases, a clear representation of the product functional structure, if accessible to the technician, may solve the issue. For example, a query answering (CQ4) may be useful in this case.

Formal requirements Requirements are an essential part of engineering design, which engineers have to write, share, maintain, and implement. The ensuing work and documentation can be daunting, especially in large progects. Therefore, attempts have been made to standardize [1], trace [74], and automatize [38] requirement pipelines using ontologies. Some approaches discuss how requirements should be written, so that their quality, shareability, and even automatic verification against a design model can be assured (e.g., [18,58]). In the latter case, requirements are usually interpreted as assertions (constraints) about an engineering artifact that can be expressed (at least some of them can) in a formal language. The fact that the requirement refers to something that should be, and not to something that is, means that requirements are modal concepts, though this can be left implicit in formal representations. For example, a requirement translated directly from a client’s request, could be that the product, say a table, “must weight as little as possible”, then engineers could precise this in different ways, e.g., by stating

Therefore, if one also designs products using the same formal language, the products can be checked against the set of constraints, to verify that those are satisfied by the products.

One difficulty of this approach is that some requirements are more difficult to express than others. Requirements such as (ex7) are easy to express, as they refer to physical properties of the products (they are sometimes called “physical requirements” [58]). On the other hand, requirements linked to product performance or functions are more difficult to express. For example, in [58], the requirements “The artifact [desk spot lamp] should be able to illuminate more than half a square meter of room”, “The base [of the desk spot lamp] should provide support to the artifact”, and “the short arm must have a hole […]” are formalized as follows:

Therefore, predicates “illuminating_feature”, “provide_support_feature”, and “hole_feature” are introduced to classify the capability to illuminate, the function to support, and the hole of the short arm as “feature_of” the corresponding artefacts. So that capabilities and functions are features in the same sense that a hole is, and we consider this an ontological error.3838

The point is that being able to express requirements that mention capabilities or functions is difficult, and an ontology describing such concepts would make things easier. For example, using our theory we would write requirements (ex9) and (ex10) as, respectively (in the following we have introduced a subclass of capabilities, illuminating_capability, a subclass of capacities illumination_area, and a subclass of (ontological) functions, provide_support):

Notice that (ex11) and (ex12) can be readily rewritten in OWL, so that they can be part of an OWL knowledge base containing all the requirements that can be expressed in a similar way. Then, if engineers build during design a model of the product, using the same language, they just need to import the model into the knowledge base with the requirements: the product model satisfies the requirements if and only if the ensuing ontology is consistent (similarly one can find if the requirements are inconsistent or if there are duplicates). In an actual application the user may never write complex formulas such as (ex11) and (ex12), unless user-friendly templates are made available as done in [18].

An analogous procedure is the one that the READI project [51,77] aims to implement. In their case, the requirement are expressed in SCD (Scope Condition Demand) form. This means that they are assertions of the form

where S, C, and D are OWL classes, for example (the example is taken from [77]), “Equipment with a transport dry weight above 1000 kg shall be weighed by the manufacturer and a weight certificate shall be issued” is written in such a form, if S, C, and D are interpreted as the classes ‘Equipment’, ‘things with transport dry weight above 1000 kg’, ‘things that have a weight certificate’, respectively. Again, it is difficult to express functions- and performance-related requirements in the format of (ex13) if one lacks an appropriate reference ontology.