Articolo_FOMI2022_v0.1.tex

%% The first command in your LaTeX source must be the \documentclass command.
%%
%% Options:
%% twocolumn : Two column layout.
%% hf: enable header and footer.
\documentclass[
% twocolumn,
% hf,
]{ceurart}

%%
%% One can fix some overfulls
\sloppy

%%
%% Minted listings support 
%% Need pygment <http://pygments.org/> <http://pypi.python.org/pypi/Pygments>
\usepackage{listings}
%% auto break lines
\lstset{breaklines=true}


%%%%%%%%%%%%  additional packages  %%%%%
%\usepackage{LOA-template}
\usepackage[hidden-comments]{LOA-template} %FC: use this to hide TODOs
% \usepackage[labelsep=space]{caption}
\usepackage[labelsep=space]{subcaption}
\usepackage{graphicx}
% \captionsetup[figure]{labelsep=space}
%%%%%%%%%%%%  -------------------  %%%%%

%%
%% end of the preamble, start of the body of the document source.
\begin{document}

%%
%% Rights management information.
%% CC-BY is default license.
\copyrightyear{2022}
\copyrightclause{Copyright for this paper by its authors.
  Use permitted under Creative Commons License Attribution 4.0
  International (CC BY 4.0).}

%%
%% This command is for the conference information
\conference{FOMI 2022: 12th International Workshop on Formal Ontologies meet Industry, September 12-15, 2022, Tarbes, France.
% held at JOWO 2021: Episode VII The Bolzano Summer of Knowledge, September 11–18 , 2021, Bolzano, Italy
}

\title{Functional Modelling in Engineering: A First Comparison of Approaches on Two Problems}


%%
%% The "author" command and its associated commands are used to define
%% the authors and their affiliations.
\author[1,2]{Compagno Francesco}[%
email=francesco.compagno@loa.istc.cnr.it,
]
\cormark[1]
\address[1]{ISTC-CNR Laboratory for Applied Ontology, via alla cascata 56/C, 38123, Povo, Italy}
\address[2]{Adige S.P.A, via per Barco, 11, Levico Terme, 38056, Italy}

\author[1]{Borgo Stefano}[%
email=stefano.borgo@cnr.it,
url=https://www.istc.cnr.it/people/stefano-borgo,
]


%% Footnotes
\cortext[1]{Corresponding author.}

\begin{abstract}
  Functional modelling is a well-studied topic in engineering and applies more broadly to areas like biology, management and organization studies. 
  While it is an essential part of building and describing engineering systems, to apply functional modelling consistently in practice remains difficult.
  This obstacle is especially painful since digitalisation is becoming an increasingly important aspect of modern engineering enterprises.
  To study the causes of such a difficulty, we analyze two typical problems that are encountered when modelling engineering systems and that are intertwined with functional aspects: identity of system components across time, and granularity management of the system models.
  The problems are introduced and used to compare a few ontological and engineering approaches that can deal with them. We illustrate our findings with a brief example.
\end{abstract}

%%
%% Keywords. The author(s) should pick words that accurately describe
%% the work being presented. Separate the keywords with commas.
\begin{keywords}
  Functional modelling \sep
  Functional decomposition \sep
  Replacement problem \sep
  Granularity
\end{keywords}

%%
%% This command processes the author and affiliation and title
%% information and builds the first part of the formatted document.
\maketitle

%% TODO "theory" --> "ontology"?

\section{Introduction}
    
Engineering is about the design and construction of machines, systems and infrastructures, their management and maintenance, including their dismantling at the end of life. The things that engineers create interact with our physical world to obtain desired changes and to prevent undesired happenings. Either way, these things have a reason to exist or, as engineers say, have a function. 

Functionality is an essential concept in engineering, and functional modelling has received widespread attention in the literature. 
Unfortunately, though several theories of functionality have been proposed and studied for more than twenty years, no unique treatment has emerged, and some problems persist. In particular, consistent application of functional modelling is known to be difficult in practice \cite{eckertThatWhichNot2013}.
In this paper, we describe some of the problems that current theories face, and show, using a brief use case, possible ways to tackle them through applied ontology principles.

%% introduction & very brief review
\section{A Brief Look at the Literature}\label{sec:literature}

Functionality is a well-studied topic in engineering and the literature is large, %\cite{chandrasekaranFunctionalRepresentationDesign1993, umedaFunctionBehaviourStructure1990, hirtz_functional_2002} and ontology \cite{sasajimaFBRLFunctionBehavior1995, TowardAUnifiedDefinition2012}, at least from more than 50 years \cite{collinsFailureExperienceMatrixUseful1976,pahl_engineering_2007} 
see for instance \cite{pahl_engineering_2007,erdenReviewFunctionModeling2008}. %for an in-depth review of some aspects of the function-related literature).
We briefly recall the main characteristics of some theories and methodologies that have been developed: %in engineering until today:

\begin{itemize}
    \item \textbf{Functional Basis (FB)} \cite{hirtz_functional_2002}%
    %,stone_development_2000}\TODO{FC: se necessario rimuovere item biblio "stone\_development\_2000"}
    . Inspired by the German school \cite{pahl_engineering_2007}, this methodology considers functions as black-boxes that operate transformations on inputs, producing outputs. FB consists in a vocabulary for functions (e.g., `convert', `distribute') and a classification of inputs/outputs (called flows, e.g., `pressure', `electric energy'). The vocabulary is organized in three levels of increasing specialisation. A functional model is a graph whose nodes are boxes labeled with function terms, and whose edges are arrows labeled with %functions and 
    flow terms. %which describes the transformations that the flows entering an engineering system undertake.
    \item \textbf{Functional Representation (FR)} \cite{chandrasekaranFunctionalRepresentationDesign1993, chandrasekaranFunctionDeviceRepresentation2000}. This methodology builds a structural model of the system at the desired level of granularity. The system is modelled as a set of devices, each one with a set of relevant parameters and input/output ports, and relations between devices, such as the connection between two ports or the containment of one device into another. State variables are attributed to the system and used to determine different system states. Lastly, the system behaviour is represented as a set of state transitions, each one justified either by a `causal process description' (CPD), a `domain law', or a component `function'. CPDs and functions can then be justified by other CPDs or functions, forming an in-depth explanation of the system behaviour. Therefore, FR functions are justifications for state transitions. Moreover, FR functions have been defined as intended constraints about the behaviour of a device when isolated (`device-centred functions') or when deployed in a given environment (`environmental-centred functions'). In the latter case, functions are also considered roles in the context of the device environment. %Indeed, they can be enriched by stating the starting state, the terminating state, and possibly conditions necessary to start the transition.
    \TODO{S: in FR le funzioni sono vincoli desiderati tra behaviours, c'è un motivo per non dirlo chiaramente? [FC: cambiato un po']} 
    \item \textbf{Function and Behaviour Representation Language (FBRL)} \cite{sasajimaFBRLFunctionBehavior1995, kitamuraOntologicalModelDevice2006}. This framework starts from a structural model of the system (analogous to the structural models of FR) obtained via a separate module called `device ontology'. %Then, a particular class of devices behaviours is selected (\quotes{behaviour based on states of the flowing operands at ports of a device}, `operands' being similar to Functional Basis flows). 
    In FBRL a function is a role that a device behaviour plays in the context of the system, to contribute to the achievement of predetermined goals. The separation between behaviours and functions explains how a device can have different functions despite its behaviour remaining the same (e.g., a heat exchanger can either cool or warm a liquid depending on the system configuration). Moreover, the vocabulary of functional terms (such as `to join') is distinguished from the vocabulary of `way-of-achievements' (such as `welding', a possible way to realize the `to join' function). 
    %This vastly reduces the number of functional terms and allows engineers to build domain-specific databases of `way-of-achievements', while the functions are domain-independent. 
    In this approach, functions are domain-independent, and way-of-achievements can be collected in domain-specific databases.
    Finally, to give a teleological explanation of a system, a set of `meta-functions' is introduced (e.g., the give-heat function of the boiler \textit{drives} the rotate-shaft function of the turbine). 
\end{itemize}

Several other theories and methodologies exist, the interested reader can see, for example, \cite{umedaFunctionBehaviourStructure1990,qianFunctionBehaviorStructure1996}, or the behavioural diagrams of UML or SysML, %some of which are arguably similar to the methodologies in this section, 
though the latter do not differentiate clearly between behaviours, functions, and related concepts. %, zhaoStateBehaviorFunction2019}.
There are also theories of functionality developed by the philosophical community, e.g., Cummins \cite{cumminsFunctionalAnalysis1975} and further works in upper ontologies (where FBRL originates) such as \BFO, \GFO, \YAMATO and \DOLCE (see e.g. \cite{spearFunctionsBasicFormal2016, herreGeneralFormalOntology2006, sasajimaFBRLFunctionBehavior1995, borgoFormalOntologicalPerspective2009}, respectively)
These theories preicate different ontological categorisations of functions. 
Here we collect those that we will use later:
\begin{itemize}
  \item \textbf{Functions as dispositions} \cite{arpFunctionRoleDisposition2008, barryBasicFormalOntology2015}. According to this view, a function is a disposition that an object manifests provided it has the appropriate physical make-up and the situation satisfies suitable conditions. In this sense, functions inhere in objects, like properties. 
  \item \textbf{Functions as transformative events} \cite{borgoFormalizationFunctionsOperations2011, garbaczTwoOntologydrivenFormalisations2011, garbaczStandardTaxonomyArtifact2005}.
  %\TODO{FC: è possibile rimuovere "garbaczStandardTaxonomyArtifact2005"}.
  Some authors describe classes of functions as particular classes of occurrents. For example, the Functional Basis function `to convert' is interpreted as the class of all events in which a flow is converted (e.g., whenever a combustion engine consumes some fuel to move a vehicle, that conversion of chemical energy to kinetic energy is a function of `to convert' type).%% As anticipated before, the engineering functions listed in fb are here interpreted as types whose instances are perdurants of certain kinds. EngFun(p) −→ PD(p). (26) -- quote from two formalisations...
  %% to distribute is a class of perdurants in which a certain flow is broken up. EngFuncðxÞ!PDðxÞ -- quote from borgoFormalizationFunctionsOperations2011
  \item \textbf{Functions as role-concepts} \cite{sasajimaFBRLFunctionBehavior1995,burekToplevelOntologyFunctions2006}. In this view, functions are (or are related to) particular roles contributing to the achievement of some goal. More precisely, in the view of Sasasjima et al. \cite{sasajimaFBRLFunctionBehavior1995} functions are roles of devices behaviours, contributing to some system goal. Instead, for Burek et al. \cite{burekToplevelOntologyFunctions2006} functions are quadruples composed of identifiers, requirements, functional items, and goals. Requirements and goals are state descriptions, respectively preceding and following the realization of a function, while functional items are the roles played by the entities realizing the function. 
\end{itemize}



%Theories of functionality attempts to solve practical and theoretical problems. In doing so, many difficulties are encountered. In this paper, we focus only on three of them: diachronic identity, granularity, and malfunction. <--FC:non chiaro perché functioni c'entrano.
The modelling of engineering systems encounters many difficulties, in both practical and theoretical aspects. 
Theories of functionality, as an important part of systems modelling, intersect some of these problems and can help to solve them. In this paper, we focus on two of them, namely, diachronic identity and granularity.
% Classical lists of general desiderata are \cite{vermaasAscribingFunctionsTechnical2003,artigaReorganizingOrganizationalAccounts2011}, among others. In order to adapt them to this work we take only a subset of items and we modify them slightly:
% \begin{itemize}
%     \item \textbf{Distinction between different types of function.} In philosophy, the classical example is proper versus accidental (e.g., using a hammer to nail something versus using the same hammer as a door stopper), but technical distinction used in engineering could be main function versus secondary function versus safety function (e.g., a system of gears has the main function of transferring rotational movement and/or varying the angular velocity. In order to maintain this function a designer will have to implement some cleaning/lubrication system with the secondary function of maintaining the correct motion between the gears and preventing wear. Finally, if, say, the gears are such that there is the danger for the workers to get impinged within them, then a system with some safety function should be present, as physical barriers between the workers and the gears or automated stoppage systems). Not all authors use such distinctions, but they are neverthelless quite widespread.
%     \item \textbf{Accounting for malfunctions.} It should be possible to describe the case that an artifact has a function even if it does not work (at least not currently). Notice that this desideratum is essential, especially in the maintenance domain, which revolves around the possibility for an object to malfunction.
%     \item \textbf{Describing the link between function of an object and its physical properties.} That is, every function in an object shoul be realized by virtue of necessary and/or sufficient set of physical properties (e.g., we would not be able to use the hammer as a door stopper if it were very light).
%     \item Accounting for innovation. The theory should be able to represent functions of newly invented artifacts and the innovation in the functionality of existing artifacts.
%     \item \textbf{Teleology.} The theory of function should help the process of explaining the working of a system. 
% \end{itemize}
% The previous list is made of general principles, while, coming to theory of functions devised to help engineers with their tasks, such as design, diagnosis, or troubleshooting, we find another classical desiderata: `no function in structure' principle \cite{kleer_qualitative_1984}. The original formulation of De Kleer is \quotes{the laws of the parts of the device may not presume the functioning of the whole} \cite{kleer_qualitative_1984}. This principle has the goal of making description of devices independent of any particular application, to facilitate modularity. Subsequent critics were moved to the applicability of such principle \cite{keunekeExploringNoFunctionInStructurePrinciple1989}. We want to focus on a derivative aspect of the `no function in structure' priciple: 
% \begin{itemize}
%     \item \textbf{No function in structure?} What is the relation between functionality of an object and the system(s) in which that object can operate? For example, does a battery have a function independently of the particular system(s) in which it could be inserted, or it has a function only when part of a system? %what is the relation between . Information about functionality and information about structure of an engineering system should refer to indipendent background knowledge (they should refer to different `modules', using language mutuated from knowledge engineering). This priciple has the goal of allo
%     \item 
% \end{itemize}
% Anoter recurring problem is the one of functional decomposition.
% The last point raise the issue of the correct representation of engineering artifact from an ontological 
% To these desiderata we add some classical
% To those points, we concern

% \begin{itemize}
%     \item Functional decomposition
% \end{itemize}





\section{Two Problems in Functional Modelling}

\subsection{Diachronic Identity}\label{subsec:identity}
Engineering systems and their components are difficult to characterise ontologically. %Take, for example, any schematic of a given system. The actual system may or may not, at any given time, follow such a schematic. For instance, a component may be missing for some period of time. This can be explained by saying that the schematic represents a system the way it should be, not the way it actually is. Unfortunately, in this way we must reason in terms of modality (how it is vs. how could be). Additionally, this view does not explain how one can recognize the actual system and the schematic as linked to each other %the same type of objects{[S: mi aspettavo "linked to each other", cos'\`e il "same type of objects" di cui parli?][FC: modificato come hai detto te]} 
In this section, we argue how an appropriate theory of functions can lessen this difficulty. %these problems. %<--FC:lungo;argomentabilmente sbagliato o fuori contesto;rimuovere} 
In particular, we focus on the so-called replacement problem \cite{guarinoArtefactualSystemsMissing2014},  \cite[Chapter 14]{westDevelopingHighQuality2011}:
\bflist
\item[(\mypb{replacement})] \textbf{The replacement problem.} In maintenance, the replacement of a malfunctioning component
with another is a common occurrence. Thus, it happens frequently that a (sub)system has many or even all of its parts changed over time, but for domain experts that one remains the same (sub)system at all times. 
\eflist
In our opinion, this problem is deeply intertwined with the following, which we call `the malfunctioning problem':
\bflist
\item[(\mypb{malfunctioning})] \textbf{The malfunctioning problem.} In engineering, the functionality of components/systems is an essential property (indeed, it is the very reason components are employed in a system). Despite this, components/systems do malfunction and when they do, their identity is not lost.\footnote{We state the problems in their generality, the reader should bear in mind their practical relevance: a knowledge base that fails to address them, may give wrong answers to queries such as \qquotes{how many times was the engine replaced?}.} 
\eflist 
A solution to this problem is arguably the second desiderata of Varmaas and Houkes in \cite{vermaasAscribingFunctionsTechnical2003}, which asks for the `ascription of proper functions to malfunctioning artefacts'.
An obvious idea to solve Problem \refpb{replacement} is to introduce in the domain of discourse `stable' \cite{compagnoComparingOntologicalAlternatives2021}, `conventional' \cite{guarinoArtefactualSystemsMissing2014}, or simply `system' \cite{westDevelopingHighQuality2011} components as entities that, by definition, survive replacement.   
This is the way ISO 15926-14 \cite{kluwerISO159261420202020} solves the problem: it introduces a category of objects, called `functional objects' (sometimes `functional locations'), which is distinct from the category of physical objects. A physical object is a mere constituent of a functional object in the sense that the first can be `installed-in' the latter. When a component is replaced, the functional object remains the same, only its constituent changes. Furthermore, this approach may solve Problem \refpb{malfunctioning} as well, since the function would be ascribed to the functional object (the `stable' component) as its essential property, while only temporally ascribed to the physical component. 

Unfortunately, to implement this strategy, one should characterise these `stable' entities from the ontological viewpoint, and this turns out to be difficult.
ISO 15926-14 proposes a functional characterisation. Other ways to characterise `stable' components are via physical features and structural relations \cite{compagnoComparingOntologicalAlternatives2021}, or introducing a four-dimensional point of view \cite{westDevelopingHighQuality2011}. Additionally, ISO 81346 \cite{ISOIEC8134612009} speaks about `functional', `product', and `location aspects' of a system component in a way that suggests that each of these aspects (or any combination of these) could be used instead of, or in combination with, the functional one.

In this paper we investigate the functional characterisation of system components, for three reasons: first, we aim to show that such a choice is not possible and effective. Second, this choice elegantly solves both problems \refpb{replacement} and \refpb{malfunctioning}, essentially by looking at malfunction as non-conformity to a nominal function (cfr \cite{mizoguchiUnifyingDefinitionArtifact2016}, which describes a similar strategy). Third, such an approach relies on already existing engineering methodologies and is, arguably, preferred in some engineering domains (cfr., e.g., the functional objects of ISO 15926).

In the following, we argue that not all ontological theories of functions are equally adapted to be used for such a modelling strategy. To show this, we discuss the distinctions introduced in Section \ref{sec:literature}: 
\begin{itemize}
  \item \textbf{`Stable' entities when functions are dispositions}. This view does not fit well with the previously described strategy, since it does not separate the functions from the physical objects that function. Additionally, engineering functions are, arguably, externally grounded (e.g., depending on the context a heat exchanger can realize a heat or a cool function), while dispositions are not. The view that functions are dispositions is analyzed and criticized also in more general settings, see, e.g., \cite{rohlWhyFunctionsAre2014}. %Additionally, notice that ISO 15926-14 adopts (from BFO) the idea of functions as dispositions, therefore, we consider the previous critiques applicable to such standard. NO--> loro mettono i functional objects
  \item \textbf{`Stable' entities when functions are transformative events}. % Some authors describe classes of functions as particular classes of occurrents. %% As anticipated before, the engineering functions listed in fb are here interpreted as types whose instances are perdurants of certain kinds. EngFun(p) −→ PD(p). (26) -- quote from two formalisations...
  %% to distribute is a class of perdurants in which a certain flow is broken up. EngFuncðxÞ!PDðxÞ -- quote from borgoFormalizationFunctionsOperations2011
   This view is not appropriate  % because engineers clesarly treat functions and \qquotes{functionings} (that is, occurrences of functions) differently: functions, at the very least, keep existing after any individual functioning.<-- FC: nonsenso: se in FR le funzioni sono transizioni tra stati, allora i loro tipi sono tipi di eventi.  
   for our strategy, since we would have at our disposal only individual functions, equated to single `functionings', that is, individual events during which functions are carried out, and the classes of such events. Neither the classes nor the single individual occurrences could be used as `stable' entities, because the individual occurrences have limited time extension and one can not predicate on classes in first order logic.
   One could insist by, e.g., reifying event classes and using these new individuals as stable entities, but there seems to be no natural way to ontologically categorize such reifications. 
  \item \textbf{`Stable' entities when functions are role-concepts}. This view seems quite flexible since it relies on an ontological entity, the role, which by construction survives the replacement of its player. This suggests that the approach may satisfy the requirements of the strategy. In the following we investigate it further.
\end{itemize}

Using functions as role-concepts, to solve problems \refpb{replacement} and \refpb{malfunctioning} one should identify the entities that survive replacement with functions (i.e., role-concepts), and the entities that don't survive with the physical objects that execute the functions\footnote{More precisely, the physical objects whose behaviour executes the function. For simplicity, we omit such details.}. 
An objection to this could be raised, stating that `conventional components', `functional objects', and the like are entities of a different type than functions. This is the case in, say, \cite{westDevelopingHighQuality2011,guarinoArtefactualSystemsMissing2014,kluwerISO159261420202020}. For example, in ISO 15926-14, the entities surviving replacement are `functional objects', which form a different category than functions and have their own mereology. West \cite{westDevelopingHighQuality2011} explicitly observes that system components are not simply functional objects or roles. 
The modelling choice of using additional entity kinds, as done in ISO 15926-14, can surely work and solve problems \refpb{replacement} and \refpb{malfunctioning}, but complicates both the ontology and the knowledge information system, and seems to be needed only because of the limitations of the function theory adopted in that system. 
In fact, one fundamental issue of functional modelling in engineering is functional decomposition, which could be defined as the determination of the teleological (functional) aspects of a system, at increasingly finer levels of granularity. The result depends on the precise methodology used, but is essentially a tree whose nodes are functions and whose edges are interpreted as some kind of part-whole relation.\footnote{It cannot be a standard part-whole relation as shown in \cite{vermaasFormalImpossibilityAnalysing2013}.}
The functional decomposition of a system becomes redundant when one introduces the decomposition of the system into functional objects, for instance through the ISO 15926-`hasFunctionalPart' relation, or any analogous relation\footnote{See also \cite{mizoguchiPreliminaryStudyFunctional2017} for another approach on functional parts.}. Indeed, if ISO 15926-14-functional objects are not physical objects, what properties distinguish them from functions?
%it is not clear what properties separate ISO 15926-14-functional objects from functions, if they are not physical objects. West's system components are physical, but in this context, the presence of physical properties is not consequential. %\TODO{FC. mancanoo gli altri casi--> espandere!!!}.
Since the relevance of functional decomposition is broadly recognized in engineering and has a rich history in the literature, the use of functions suggests itself as the most direct and natural option.
The introduction of additional entities in the domain of discourse
%, as suggested e.g. in \cite{westDevelopingHighQuality2011,guarinoArtefactualSystemsMissing2014}, 
may be unnecessary if the goal is just to solve problems \refpb{replacement} and \refpb{malfunctioning}. We do not rule out the possibility that additional entities could be necessary to solve other types of problems when modelling engineering systems. This remains to be investigated.%\TODO{S: questo paragrafo non è chiarissimo. dovrebbe almeno chiudersi con un riassunto della strategia proposta. [FC: cambiato ultimo paragrafo in quella direzione]}

In Section \ref{sec:use-case} we will showcase how one can implement the proposed strategy of introducing functions and functional decompositions to explain the survival of engineering systems to component replacement.  

\subsection{Granularity of the Functional Model}
We now turn to the granularity problem:
\bflist
  \item[(\mypb{granularity-problem})] \textbf{The granularity problem}. How can we ensure effective management of granularity in engineering system modelling?
\eflist
We are especially interested in Problem \refpb{granularity-problem} when specialized to functional modelling.

Since granularity is an important factor to motivate the choices discussed in this paper, we clarify how it should be here understood in its generality:
\bflist
\item[\mydf{granularity}]
    Given any binary relation $R$ in some domain of discourse, whose transitive closure is a (possibly strict) partial order, we say that an element $x$ of the domain is at a finer granularity level than the element $y$, with respect to the relation $R$, if and only if there exist elements $x_1$, $x_2$, \dots, $x_n$ such that $R(x,x_1)$, $R(x_1,x_2)$, \dots, $R(x_n,y)$.\footnote{The constraint on the transitive closure prevents unwanted scenarios, such as domain elements which are, at the same time, both at coarser and finer granularity level than a second element.} 
    We say that $x$ is at a coarser granularity level than $y$ to mean that $y$ is at a finer granularity level than $x$.
    %Finally, moving to a finer (coarser) level of granularity are expressions meaning that, given some domain element, we consider a set of elements that are a finer (coarser) granularity level than the starting element.\TODO{S: quest'ultima frase non mi sembra necessaria.}
    
\eflist
Since granularity, as defined above, is relative to a partial-order relation and there is no restriction on the number of such relations, a few consequences follow. Given an element, this fixes a granularity level. Given a granularity level, to move to a different (finer or coarser) granularity level, one has to fix the relation of reference. For example, consider a model of a combustion engine. Let us take the engine to be (structurally) composed of three parts: the carburetor (that mixes the fuel with air), the intake manifold (that distributes the air/fuel mix to the cylinders), and the cylinder group. Then, from the point of view of the mereological part-of relation, we have a tree structure, where the root is the engine (as a whole), which has three leaves attached (the carburetor, the manifold, and the cylinder group); and we can move to a finer (coarser) granularity level expanding (collapsing) nodes of this tree structure. Additionally, if a taxonomy\footnote{That is, a directed acyclic graph (usually a tree, but sometimes one accounts for multiple inheritance) between classes of entities whose edges represent the subsumption (is-a) relation.} of artifact types is used, one could refer to the is-a relation to change granularity level in the taxonomy. Therefore, granularity must be stated relatively to a structure, see Figure \ref{fig:granularity-table-structural} for an exemplification. 

In the same way, if we have a taxonomy of function-types, together with a relation of aggregation/decomposition of some kind between functions, we can vary the granularity of any functional model along these two different relations. See Figure \ref{fig:2-ways-granularity-table-function}, which uses the Functional Basis methodology for representing functions, for an exemplification. In this case, moving to a finer granularity level over the aggregation relation means decomposing the current function, while moving to a finer granularity level on the is-a relation is achieved by using more specialized flow and function terms (e.g, from `connect' to `mix').

\begin{figure}
    \centering
    \begin{subfigure}{0.49\textwidth}
    \includegraphics[width=\textwidth]{granularity-table-structural.png}
    %\caption{A simplified structural model of a combustion engine. Starting from the engine as a whole one can go towards a finer mereological-granularity and find out that the engine is made of three components; going towards a finer subsumption-granularity one can find out that the engine is not just an instance of any combustion engine, but has additional properties (in this case the number, location, and volume of the cylinders), and the same holds fro the engine parts.}
    \caption{}
    \label{fig:granularity-table-structural}
    \end{subfigure}
    \hfill
    \begin{subfigure}{0.49\textwidth}
%    \centering
    \includegraphics[width=\textwidth]{granularity-table-functional.png}
    %\caption{\label{fig:2-ways-granularity-table-function}A simplified functional model of a combustion engine using the Functional Basis methodology. For simplicity, we refer to the structure in Figure \ref{fig:granularity-table-structural} and assume that each part of a system has a function. Using the Functional Basis vocabulary, the function of the engine could converting fuel into mechanical energy, while the function of carburetor is to mix fuel and air, and so on for the other components. In this case, moving to a finer granularity level over the aggregation relation means decomposing the current function, while moving to a finer granularity level on the is-a relation is achieved by moving to a finer level of the functions vocabulary (e.g, from `connect' to `mix'), as well as using more precise terms for the flows.}
    \caption{}
    \label{fig:2-ways-granularity-table-function}
    \end{subfigure}
\caption{\subref{fig:granularity-table-structural}: A simplified structural model of a combustion engine. Starting from the engine as a whole one can go towards a finer mereological-granularity and find out that the engine is made of three components; going towards a finer subsumption-granularity one can find out additional properties of the engine and its parts. \\ %that the engine is not just an instance of any combustion engine, but has additional properties (in this case the number, location, and volume of the cylinders), and the same holds for the engine parts. \\
\subref
{fig:2-ways-granularity-table-function}: A simplified functional model of a combustion engine using the FB methodology. For simplicity, we refer to the structure in Figure \subref{fig:granularity-table-structural} and assume that each part of a system has a function. Using the FB vocabulary, the function of the engine is converting fuel into mechanical energy, while the function of the carburetor is to connect (more precisely, to mix) fuel and air, and so on. %In this case, moving to a finer granularity level over the aggregation relation means decomposing the current function, while moving to a finer granularity level on the is-a relation is achieved by moving to a finer level of the function vocabulary (e.g, from `connect' to `mix'), as well as using more precise terms for the flows.
}
\label{fig:due-figure}
\end{figure}

%We are especially interested in the case that it is the relation is the one 


% Functional decomposition is essential, because of multiple reasons. We lists some of those in the following (some points refers to the structural hierarchy and not to the functional one, but, if we assume that some relation exists between the physical components of a system and its functions, they translate to the functional hierarchy as well):

Granularity is important when modelling engineering systems for, at least, these reasons:
\begin{itemize}
    \item \textbf{Accounting for different viewpoints.} Different operations carried out on a product during the various steps of its lifecycle require different points of view about the product. Those viewpoints may differ also due to the level of granularity they focus on, for example, during the assembly of a machine, a car say, it may be important for the workers to know where each screw goes and what kind of washer is required. On the other hand, during maintenance, it may happen that, if a part of the car is malfunctioning, it is simply replaced as a whole.%, and no diagnostic is carried out to determine what was wrong within that part, because it would be too costly in terms of time and money, even if that part was assembled by the same company that is carrying out maintenance. 
    \item \textbf{Simplifying the management of complex systems.} Engineering systems can be extremely complex, and when that happens it would be very difficult to manage them using a fixed level of granularity. %This is because that level would necessarily be the finest one, otherwise some information would be lost. But this would be akin to always treat a complex system, say a car, as a list of screws, bolts, pipes, metal plates and pieces of various shapes, etc., which would be untenable.
    \item \textbf{Reasoning about engineering systems.} Human reasoning about engineering systems often requires jumping between different levels of granularities. For example, the German school of systematic design \cite{pahl_engineering_2007} explicitly describes the design process as the development of a functional hierarchy (`funktionsstruktur') starting from the coarsest level of granularity (the main function the product to be designed should satisfy) and going down to finer-granularity-level functions until one reaches a point that can be readily translated to an assembly of physical items (`embodiment' of the functions). Analogously, a common way for technicians to troubleshoot a malfunctioning system is to produce a chain of parts, each one possibly `containing' the cause of malfunction and strict subpart of the proceeding part.%\TODO{S: ho cambiato un po' verso la fine, controlla [FC: hai aggiunto "cause of" e "possibly", è perfetto]} %The method used to isolate the next part of the sequence vary, but it could very well be based on function of the part (e.g., if a laptop is not playing music correctly the problem will be -- among other possibilities -- in its speakers; if, more precisely, the music is played always too softly, the problem will be in the amplifying circuit within the speakers, etc.)
    \item \textbf{Allowing scalability of applications.} 
    %Suppose that one were to build a simplified model of some system as a proof-of-concept, and some application is developed to interact with such a model. Later, if this system is implemented, the actual model may become orders of magnitude bigger than the preliminary one. If the behaviour of the application concerning granularity was not well thought out, it may happen that the application does not work well with the full model.    
    Suppose that one were to develop an application or a pipeline and test it on a simplified model of, or with a limited dataset from, some system. Later, if the application/pipeline is implemented, the actual model or data inputs may become orders of magnitude bigger than during the testing period. If the behaviour of the application/pipeline concerning granularity was not well thought out, it may not work well.% with the full model.    
\end{itemize}

We are especially interested in the granularity of aggregation-like relations\footnote{Recall that, generally speaking, one cannot assume that the relation is a part-whole relation \cite{vermaasFormalImpossibilityAnalysing2013}.} between functions (that is, a functional decomposition), to facilitate the previous points, going towards a solution to Problem \refpb{granularity-problem}. Moreover, functional modelling is difficult to use in actual engineering practice, despite its emphasis in the literature; we believe that effective management of granularity is instrumental in facilitating a broader functional modelling adoption in engineering.

Also in this case we argue in favour of a particular style of decomposition, among the few possibilities described in Section \ref{sec:literature} (the following considerations can be applied, with some changes, to other functional theories):

\begin{itemize}
  \item \textbf{Functional Basis style of decomposition.} This style of decomposition was briefly described in Section \ref{sec:literature}, see also Figure \ref{fig:2-ways-granularity-table-function}. We argue that it has some weak points:
  \begin{itemize}
    \item It is not (intrinsically) modular: decomposition happens by substituting a box with some input and output flows with a set of boxes with additional flows between them (the original in/out flows are preserved). It may be possible to, say, label some typical decompositions and reuse them, but this is not often discussed in the literature on the Functional Basis, even though some works of the German School of systematic design (e.g. \cite{rothKonstruierenMitKonstruktionskatalogen2000}), which the Functional Basis is based on, seem to suggest this.
    %go, essentially, in that direction. 
    \item At a finest level of granularity, the decomposition of a system, say an electrical or hydraulic system, can become redundant with the electric/hydraulic schematics already commonly used by engineers. This is intended, since this methodology aims to produce, at the end of the design process, a decomposition that is readily translatable in such schematics. Since we want to cover (at least) maintenance activities, we assume that such schematics already exist, therefore, the decomposition at the finer functional level would be redundant. Moreover, it is generally considered useful to keep the functional and structural representations independent from each other (see e.g. \cite{ISOIEC8134612009}).
    \item The taxonomy of the FB vocabulary is organized on three levels only \cite{hirtz_functional_2002}. This, presumably, helps with systematicity, but it imposes only three subsumption-granularity levels (e.g., we cannot distinguish between cooling and heating without expanding the original taxonomy).
  \end{itemize}
  \item \textbf{Functional Representation style of decomposition.} This style is modular by design: we just need to label some CDPs and reuse them. On the other hand, the functions are not organized in a taxonomy, except for the four types determined by Keuneke \cite{keuneke_device_1991}. Moreover, the view of functions as labels for state transitions/behavioural constraints means that, at finer granularity levels, the decomposition becomes a sort of behavioural diagram, which could even be used to simulate the system as a finite state machine. This may fit some applications, but, arguably, does not supply a language to properly represent a system on the teleological level only. % and, instead , possibly limiting the  
  %This may fit some applications, but, again, it does not limit itself to only teleological aspects.
  \TODO{S: quest'ultima frase non mi è chiara. [FC: cambiata un po']}
  \item \textbf{FBRL style of decomposition.} This style is also modular by design: in this case the `way-of-achievements' can be reused. Additionally, function-classes are organized in a rich taxonomy; even the `way-of-achievements' are organized in rich taxonomies which implement domain-specific knowledge \cite{kitamuraOntologybasedDescriptionFunctional2003}. Finally, this methodology introduces also teleological relations between functions (`meta-functions') which, arguably, allow the decomposition to stay on a purely teleological level. 
\end{itemize}
In Section \ref{sec:use-case}, we will showcase a simplified application of our interpretation of FBRL-style functional decomposition.

%\subsection{Malfunction}{S: lascerei questo argomento per un articolo successivo [FC: my thoughts, exactly]}
%We touch this topic only briefly, since a full discussion is outside the scope of this paper.
%{<spiegare principali classificazioni relative a guasti e argomentare che la divisione in funzioni ontolo./sist./ing.-metodi riflette un'analoga suddivisione a livelli di guasti, che è originale e interessante> delete? This is waaay out of space.}

\section{How to Put a Possible Approach to Work}\label{sec:use-case}

%The exploitation of this approach requires further work both at the theoretical and practical levels. Yet, the material introduced in this paper suffices to roughly outline how to apply it in a conceptual model.
The exploitation of the approach we argued for in the previous sections (that is, conceptualizing functions as roles and using a FBRL-style of decomposition) requires further work both at the theoretical and practical levels. Yet, the material introduced in this paper suffices to roughly outline how to apply it in a conceptual model.

First, we need a taxonomy accommodating both physical objects and functions. Figure \ref{fig:class-taxonomy} shows a DOLCE-based \cite{Borgo-FGG22Dolce} putative taxonomy of such a kind, which subsumes functions and `way-of-achievements' (from now on `engineering methods') into a concept-category\footnote{In \cite{Borgo-FGG22Dolce} roles are subsumed into concepts. Here we also subsume functions into concepts, but do not discuss if functions are roles or not.}. 
The categories of functions and methods can then be further specialized into different kinds. 
Let us assume that these classes are sufficiently characterised ontologically, possibly by adopting a foundational ontology. 
The classes could be stored, together with relevant info, in an appropriate database (see e.g. \cite{kitamuraOntologybasedDescriptionFunctional2003} for a suitable implementation for engineering methods).

In this approach, a functional decomposition of an engineering system is achieved by alternating the decomposition between engineering methods and functions. This is because, in this approach, a function can be implemented by a method, and a method can raise the problem of implementing some functions of finer granularity. 
Consider a laser cutting machine that cuts metal tubes using a laser beam emitted from a mobile cutting head. The tubes are held in place and moved by a spindle that rotates and translates. To obtain an acceptable quality of the cut, the workpiece must be kept in the right position very precisely. To do this, a specific subsystem, called \textit{steady rest}, is used. The steady rest secures the tube head by using special jaws moved by pneumatic cylinders. 
Steady rests are a standard engineering solution in tooling machines (including laser cutting machines), thus they can be considered parts of a well known engineering methodology. In the particular case we are considering, the steady rest is automated (it rotates and performs other things, such as sensing the tube position through a photocell couple), therefore some method must be selected to allow it to perform the needed functions, e.g., \textit{to rotate}. Figure \ref{fig:functional-decomposition} gives an example of how the goal of performing a high quality laser cut is ensured by decomposing the function of a steady rest of the laser cutting machine.
The decomposition shows the chosen method based on an \textit{electrical motor} (together with typical auxiliary parts such as a gearbox and a pinion-crown gear coupling). This method can be further divided into a \textit{convert electrical energy into mechanical energy} function, realized by the motor proper, and a \textit{transmit mechanical energy} function, realized by the gears and shafts linked to the motor. The decomposition can go on until the desired granularity level is reached. 
Note that this functional decomposition manages granularity quite well, in the sense that it is easy to build trees of different depths; and is also modular, as, for example, the motor-gearbox-pinion and the photocell couple methods can be reused many times in the tree.

Finally, as explained in Section \ref{subsec:identity}, the replacement of parts can be modelled, by making use of the functional roles as constant `anchors' for the replaced physical objects. It suffices to link physical objects with functions, and to, for example, attribute to the physical objects the temporal information about their use (e.g., adding timestamps of installation and removal from the system, or introducing an `installed-after' relation between components). Figure \ref{fig:replacement} shows such an example: two motors are installed in the same system, at different times, at the same `functional location' (here interpreted simply as some fixed function).

\begin{figure}
  \centering
  \includegraphics[width=0.55\textwidth]{class-taxonomy-small.png}
  \caption{\label{fig:class-taxonomy} Example of class taxonomy including functions and engineering methods.
  %\label{fig:class-taxonomy}
  }
\end{figure}
\begin{figure}
  \centering
  \includegraphics[width=0.80\textwidth]{functional-decomposition-small-2.png}
  % \caption{\label{fig:functional-decomposition}}
  \caption{\label{fig:functional-decomposition} Example of functional decomposition. Notice the alternating between functions and methods, which is explained in the text. Additionally, methods should not be confused with the objects required to implement them.}
\end{figure}
\begin{figure}
  \centering
  \includegraphics[width=0.50\textwidth]{functional-decomposition-with-replacement-small.png}
  % \caption{\label{fig:replacement}}
  \caption{\label{fig:replacement} Example of component replacement.}
\end{figure}

\section{Conclusion}
The paper described two recurring problems in functional modelling, and used ontological arguments to characterise some of the most common methodologies used in functional modelling with respect to these problems and to show their limitations. 
The paper suggested that certain characteristics of these methodologies, in particular of the FBRL approach, can be used to successfully manage the two problems. %a different way to face these problems and argues that it seems to be a successful approach to effectively manage these problems. 
This claim has been supported via an (admittedly brief) example of how the approach could be implemented in conceptual modelling.

Further work is needed to analyze these topics more accurately and to cover additional aspects necessary for the full understanding the proposed methodology including, for example, the modelling of malfunctioning.

\acknowledgments

Francesco Compagno is funded by the company Adige Spa. This work is partially funded by the European project OntoCommons (GA 958371, www.ontocommons.eu).



\bibliography{biblio-funzioni}

\end{document}

%% MEMO CITAZIONI 

% What is a functional location?
% `[In the context of] Plant Maintenance, 
% An organizational unit in Logistics that structures the maintenance objects of a company according to functional, process-oriented, or spatial criteria. A functional location represents the place at which a maintenance task is performed.' Notice that, despite the name, the spatial criteria is only one possible criteria for identifying the functional location.
% \url{https://help.sap.com/glossary/?locale=en-US&term=functional%2520location} accessed May 2022.


% `ISO 15926-14 includes terms for defining restrictions identified in the design phase and terms for the transition from design to procurement. This includes in particular class terms for physical objects, systems, functions and functional objects. 

% Using these terms one can capture the evolution of functional objects from an early design phase to the functional locations of tag numbers and capture the distinction between a tag number and a physical object installed at the tag. This feature is exploited in the modelling patterns for lifecycle information.' --page 11

% `The starting point is a system s, with functional parts a and b represented by the object property functionalPartOf. Both the system s and its functional parts a and b are classified as FunctionalObject. A functional object could be a tag, or an object identified in the design process at a point before tags are introduced.' --page 60

% `An important point is that the breakdown structure of the physical objects may be very different from the system breakdown structure captured by the object property functionalPartOf. The physical breakdown structure is not illustrated, but could be captured by part/whole properties, e.g., arrangedPartOf.' --page 61

% `The story begins with the creation of a functional object that fulfills the need for pumping. The object is then associated with Function Requirements (FR) specifying such details as rated power, etc. Next, the location for the object is specified as well as the Component Type (CT) and a Product Specification (PS) is given. Once the specifications are in place, an actual motor, i.e. a physical object, is installed and, later, replaced by another motor as part of a maintenance policy.' -- page 65

% `Class: lis:System Annotations: rdfs:comment "A system is a complex of functional parts working together. Each part contributes to the realisation of the system's function (though not necessarily every part in every performance of the system).", rdfs:label "System", skos:note "A functional location that does not itself have functional parts is not a system.",' --annex F

% functional locations are implicitly equiparated to functional objects, see Figure G.5.3.

% `Class: lis:FunctionalObject Annotations: rdfs:comment "A functional object is part of a system, and has a function whose realisation contributes to the performance of the system as a whole.", rdfs:label "FunctionalObject", skos:example "An item on a Process Flow Diagram (PFD) or Process and Instrumentation Diagram (P\&ID) should be classified as a FunctionalObject.", skos:note "A class of artefacts such as Pump is not a subclass of FunctionalObject: a pump that is not in service is not part of a system. However, an individual functional location should in general be given some high-level artefact classification in addition to its description as part of a system.", skos:prefLabel "FunctionalObject" SubClassOf: lis:Object, lis:functionalPartOf some lis:System, lis:hasFunction some lis:Function Every object in an industrial plant is there for a purpose, and the objects are arranged into systems of “functional objects”. Plant design assigns one or more functions to each functional object'--page 20[10]