Maintenance is vital to ensure our manufacturing assets operate safely and eficiently. Maintenance work is triggered by a number of factors. One of these factors is a change in health state of an asset and the impact of this change on the ability of the asset to perform its functions. In addition, the act of performing maintenance changes the health state of the asset, restoring or retaining it to a state in which it can perform its required function. The ability to perform maintenance can also depend on the state, up state or down state, of the asset. The notion of state and the precursors and consequence of a change in state of an asset are central to developing formal maintenance ontologies and their related reasoning mechanisms to support maintenance management process automation. This paper explores this notion in a Basic Formal Ontology (BFO) context using an illustrative case study. In modelling a simple example, we have encountered many issues that are under active discussion within the industrial ontology community. We propose a formalization for maintenance state and discuss practical and ontological issues. Our main focus is on the role of maintenance state in the interplay between function realization and process participation, conditioned on a state. The paper is a call-to-arms to the ontology community to engage with defining a notion of state to support the use of ontologies and reasoning to assist in automation of industrial manufacturing processes.
The notion of an asset’s state is central to maintenance language. Maintenance is defined as
“combination of all technical, administrative and managerial actions during the life cycle of an
item intended to retain it in, or restore it to, a state in which it can perform the required function"
[
Maintenance actions may be triggered by the change in health state of an asset and the impact of this change on the ability of the asset to perform its primary and secondary functions. The ability to perform maintenance also depends on the operating state, up state or down state, of the asset. The act of performing maintenance is often, but not always, intended to change the health state of the asset, restoring or retaining it to a state in which it can perform its required function. An exception to this is an inspection task which does not change the state of the asset.
Historically information about the health of an asset has seldom been available in near real time to maintainers and operators. However, this situation is changing due to rapid developments in industrial internet and analytics associated with Industry 4.0 and prognostics health management initiatives. Both these initiatives hope to improve asset availability and reduce costs through maintaining assets proactively before failure, reducing unnecessary maintenance work on healthy assets, and optimising when asset maintenance actions occur to balance cost, risk and performance. The availability of digital asset health information and the ability to infer a health state from sensor data opens the way to automated reasoning about maintenance actions to be taken conditioned on certain health and operating states. For example, a failed state notification could be used to trigger a repair maintenance action. The challenge of linking the outputs of health assessment with maintenance task generation, leveraging automated reasoning, is of interest to the industrial ontology community. The authors are part of the Maintenance Working Group of the Industrial Ontology Foundry (IOF) and engaged in the development of open, shared ontologies aligned with the Basic Formal Ontology (BFO) top-level ontology. It is within this framework that we explore the notion of state in a maintenance context and describe our ontological challenges.
We start with identifying terms of interest and their natural language definitions. We draw the definitions from International Standards such as those developed by the International Standards Organisation (ISO), International Electrotechnical Commission (IEC), European Committee for Standardization (CEN) and the Society of Automotive Engineers (SAE). The shared vocabulary provided by formal standards is an important feature in how engineers communicate and these standards are widely used, and in many cases are mandatory, in engineering work. The terms in Table 1 and their definitions inform the development of classes in our proposed ontology but there is not a direct mapping.
Each asset has a primary function, this describes the main reason(s) for owning or using the asset. It may also have a set of secondary functions due to the need to fulfill regulatory requirements
Natural language definition from International Standards Standard
Item that has potential or actual value to an organization [
Cambridge Dictionary defines state as ‘a condition or way of being that exists at a particular
time’. In the domains of systems engineering and software development, state is used to describe
and understand the behavior of complex systems. In those domains, a state simply represents
a stage in the behavior pattern of an object. A transition is a progression from one state to
another and will be triggered by an internal or external event [
For ontological definitions of state, we first consider DOLCE which defines a class state
as a perdurant (approximately equivalent to BFO ‘process’), particularly a subclass of stative
alongside process. State is understood as actual occurrences of situations, which are temporally
located and unchanging [
This unchanging nature is also reflected in the Common Core Ontologies (CCO)[
In general, discussions on ‘state’ and ‘stasis’, particularly when discussing systems, share several common attributes, including: • states occur/hold for some time; and, • states describe some unchanging aspect of interest.
As such we consider a very general notion of state/stasis as ‘an occurrence that is of a particular entity (possibly an aggregation or assembly) and during which some aspect of interest (specified by the state kind) remains unchanged (completely or within some tolerance).’ This captures a variety of phenomena of interest, which we can narrow down with more specific notions necessary for our domain.
Coverage in the literature of the notion of the state of an asset and what functions can and
cannot be realised in a state is sparse in engineering-related domain and application ontologies.
We know that a motor in a powered of state cannot produce torque (its function), however we
have not found ontology patterns that represent this idea. Engineering ontologies that mention
states include the PROTEUS e-maintenance platform 2006 which identified four asset states:
Normal state, Degraded state, Failure state, Programmed stop state [
The notion of an Object in Fault State has been used in reasoning in a recent Failure Modes
and Efects (FMEA) ontology [
In this section, we propose an implementation of the notion of state in maintenance that aims to address specific goals and reasoning tasks encapsulated by the competency questions listed in the next section. The ontology is demonstrated on an illustrative use case of a washing machine. The competency questions for this ontology are shown in Section 4.
We describe an illustrative use case using a washing machine. Assume, for the purpose of this discussion, that our washing machine has four functions. These are: (1) to wash clothes (primary function), (2) to turn on (secondary function), (3) to turn of (secondary function), (4) to operate at 5-Star energy eficiency (secondary function). The state of the washing machine determines which of these functions can be realized. Assume that our washing machine has ifve possible states.
1. Operating State (the equipment is operating normally, i.e., broadly related to the ‘up state’ in the terminology of Table 1) 2. Degraded State (e.g., the washing machine’s filter is degraded i.e., the ‘degraded state’ in the terminology of
Table 1) 3. Failed State (the equipment cannot perform its primary function, i.e., the ‘down state’ in the terminology of
Table 1) 4. On State (the equipment has been switched on by an external agent) 5. Of State (the equipment has been switched of by an external agent)
The first three states ofer a familiar view of equipment state in reliability and maintenance work management. When making decisions about the timing of maintenance actions, reliability engineers will consider which of these three states the asset is currently in. States (4) and (5), rather, refer to the state of the washing machine after it has been acted upon by an external agent. This information is used in two ways by engineers. The first is for troubleshooting, knowing which health state (1-3) and which On/Of State (4-5) the asset was in at a particular time is necessary for fault identification. The second is for maintenance task planning: while most maintenance work can only be executed when an asset is in the Of State, there are certain tasks such as calibration that need the asset to be in the On State. We use this distinction as a basis for our conceptualisation of Maintenance State, described in the following section.
We introduce the notion of Maintenance State as a ‘stasis that holds during a temporal interval when the realizable functions and capabilities of the participating maintainable item, or the grade of realization of those functions and capabilities, remain unchanged and where the stasis may prevent specific functions and/or capabilities from being realized.’ This definition is based on the notions of function and capability from the BFO and IOF Core ontologies, which map approximately to the maintenance notion of primary and secondary functions, respectively, and which are both types of disposition. These functions and capabilities are associated with types of process that realize the disposition; together, the functions/capabilities and their correlated processes represent both aspects of “engineering function”, i.e., the (intended) ability to do something, and the actual performance of the function/capability. By making this ontological commitment, it helps identify these subtle distinctions which helps to further refine the conceptualisation.
This is applied to the use case described in Section 3.1, using a “two-tier filter" conceptualisation of which functions and capabilities may be realizable at any given time. The first tier iflter is primarily based around the maintenance concepts of operating, degraded, and failed states, which impacts which functions and capabilities are realizable: all are realizable in the operating state; (primary) functions are still realizable in the degraded state, while one or more capabilities are no longer realizable; and the (primary) function is no longer realizable in the failed state (i.e., there is a malfunction). The second tier filter is characterised by external factors impacting the functions and capabilities that can be realized, without implying anything about a malfunction. An example of this conceptualisation is shown in Figure 1.
The grey box labeled “dispositions 1” contains all of the washing machine’s dispositions (i.e., all of its primary and secondary functions described in Section 3.1). When there is no state information, we can assume that all of these dispositions are realizable. However, we can filter this set of dispositions depending on whether the washing machine is in an operating, degraded or failed state. We call this our “tier 1 filter”. So, in Figure 1, the washing machine is in an Operating State. Since an operating state does not afect which dispositions are realizable, the box “disposition 2” still contains all four of the washing machine’s dispositions. Now, we can “pass” our dispositions through a second filter. This filter is the set of states that are influenced by an external agent (i.e., On State and Of State). In Figure 1, the washing machine is in an Of State . When it is of, it cannot turn of, wash clothes or operate at 5-star eficiency. Therefore, after passing the set of possible dispositions through this filter, we are left with only one realizable function: to turn on. The fact the washing machine cannot wash clothes does not mean that the equipment is malfunctioning when it is turned of, rather it is in need of intervention from an external agent in order to realise this function. In summary, if a washing machine is in an operating state, but is switched of then it can only turn on (it cannot perform its other three dispositions).
Now consider the example shown in Figure 2. In this case, our washing machine is in a Degraded State. This is a state in which it fails to fulfil a secondary requirement. For the purpose of this example, this means that the washing machine has a degraded filter and fails to meet an eficiency requirement. Therefore, Figure 2 shows that after the “tier 1 filter”, the box labeled “dispositions 2” shows that only three functions remain for the washing machine. Finally, since the washing machine is in an On State, it cannot be turned on because it is already on. Therefore, after “passing” our dispositions through the “second-tier filter”, the washing machine has two realizable dispositions. In summary, if the washing machine is in a degraded state, but is switched on, then it can turn of and wash clothes; however, it cannot turn on or operate at 5-star energy eficiency.
The introduction of Maintenance State as a distinguished kind of State separates the axioms specific to the maintenance domain from the axiomatisation of the mid- and upper-ontology. This helps future proof the ontology as we expect that not all axioms that we define in future application ontologies for maintenance will hold for the general notion of State. It also helps to modularise the ontology and support mappings of the maintenance application ontologies into other upper ontologies in the future.
A BFO-aligned OWL implementation of the conceptualisation described in Section 3.2 can be found at https://github.com/uwasystemhealth/FOMI_maintenance_state. Figure 3 shows the four functions of a washing machine and their organisation under Function and Capability where the primary function is considered a Function and the secondary functions are considered Capabilities. The organisation of functions and capabilities in this implementation is discussed further in Section 5.1. The figure also shows that there exist individuals (as specifically dependent continuants) for each of these functions that inhere in an instance of Washing Machine. The washing machine itself being a Maintainable Item and, as such, will generally be in one or more Maintenance States.
The “two-tier filter” conceptualisation for Maintenance State described in Section 3.2 is
modeled in OWL using the Value Partition design pattern [
We introduce new object properties in the ontology implementation. To capture the idea that functions and/or capabilities may be made unrealizable in a particular state, we introduce the relation disables (domain: Maintenance State, range: Function or Capability): i.e., if a Maintenance State disables a Function or Capability, it ‘prevents the Function/Capability from being realized’. In terms of temporalized BFO, it is a sub-property of ‘has participant at all times’ indicating that the Function/Capability is disabled for the entire time that the state is in efect. The inverse relation, disabledBy is a sub-property of ‘participates in at some time’, as function/capability may only be disabled during some parts of its existence, We use this object property to model which instances of Maintenance State disabled which functions or capabilities of our washing machine. This idea is captured in Figure 4.
We also have the object property hasState (domain: Maintainable Item, range: Maintenance State), a sub-property of BFO:participates in at some time and its inverse stateOf, which is a sub-property of BFO:has participant at all times. We use this object property to capture the current state(s) of a Maintainable Item (i.e. the washing machine) and the idea that each state (individual) is of a specific Maintainable Item.
We capture which States disable which Functions using a series of SWRL rules. Two examples are as follows: (1) WashClothes(? ) ∧ MaintainableItem(?) ∧ bearerOf (?, ? ) ∧ hasState(?, ?) ∧
(FailedState(?) ∨ OffState(?)) → disabledBy(?, ?) (2) OperateAtFiveStarEfficiency (? ) ∧ MaintainableItem(?) ∧ bearerOf (?, ? ) ∧ hasState(?, ?) ∧ (FailedState(?) ∨ DegradedState(?) ∨ OffState(?)) → disabledBy(?, ?) These rules say that for a given function or capability (?f) and state (?s), if a maintainable item (?i) has that disposition and state and the state is of a relevant type, then the function or capability is disabledBy the state.
Now that there are dispositions that can be disabled by various states, we need to model the effect of this disabled property. We need to say that if a disposition is disabled then a maintainable item cannot participate in the process that realizes that disposition. For example, if the wash clothes function is disabled, the washing machine cannot participate in (as the “agent/instrument/efector”) a washing clothes process that would realize the wash clothes function, while the disablement is in efect. We represent this by inferring a relation unableToParticipateIn between the Maintainable Item and the realizing Process, for example1: (3) MaintainableItem(?) ∧ bearerOf (?, ? ) ∧ hasState(?, ?) ∧ participatesInAtSomeTime(?, ?) ∧ realizes(?, ? ) ∧ disabledBy(?, ?) → unableToParticipateIn(?, ?)
This relation is purely a support for reasoning and analysis and is extra-ontological. This
approach is along the lines of [
Validation was performed for this work by testing the ontology against competency questions that are of relevance to a maintenance engineer. In the following, we assume the execution of an OWL reasoner and that the queries are performed over the asserted and inferred information. For brevity we do not query for within a specific time-frame.
What are the conditions that need to be met so that an asset can perform its primary function? i.e., what state does the asset need to be in? We illustrate this by considering if there is a Maintenance State in which the asset cannot perform its required function. This requires the querying of specification information for which we introduced the relation typeDisabledBy. To use this we posit a Washing Machine individual and query for which states it must be in that would not disable the function (as indicated by typeDisabledBy).
PREFIX b f o : < h t t p : / / p u r l . o b o l i b r a r y . org / obo / > PREFIX s t a s i s : < h t t p : / / www. semanticweb . org / s t a s i s − ontology − f i l t e r #> SELECT ? m a i n t a i n a b l e _ i t e m ? s t a t e ? p r i m a r y _ f u n c t i o n WHERE {
VALUES ? m a i n t a i n a b l e _ i t e m { s t a s i s : washing_machine_001 } . ? m a i n t a i n a b l e _ i t e m b f o : BFO_0000196 ? p r i m a r y _ f u n c t i o n . # BFO_0000196 = " b e a r e r o f " ? p r i m a r y _ f u n c t i o n a s t a s i s : P r i m a r y F u n c t i o n . { ? s t a t e r d f s : s u b C l a s s O f s t a s i s : T i e r 1 S t a s i s V a l u e P a r t i t i o n } UNION { ? s t a t e r d f s : s u b C l a s s O f s t a s i s : T i e r 2 S t a s i s V a l u e P a r t i t i o n } .
FILTER NOT EXISTS { ? p r i m a r y _ f u n c t i o n s t a s i s : t y p e D i s a b l e d B y ? s t a t e } }
Can an asset perform its function if it is in an Operating State but is switched of (i.e., in its Of State)? Or more generally, is the Primary Function of a Maintainable Item disabled in its current Maintenance State? If it is not, then it can perform its function, otherwise it cannot. This can be captured by the query: PREFIX b f o : < h t t p : / / p u r l . o b o l i b r a r y . org / obo / > PREFIX c o r e : < h t t p : / / www. i n d u s t r i a l o n t o l o g i e s . org / c o r e / > PREFIX s t a s i s : < h t t p : / / www. semanticweb . org / s t a s i s − ontology − f i l t e r #> SELECT ? m a i n t a i n a b l e _ i t e m ? p r i m a r y _ f u n c t i o n WHERE {
VALUES ? m a i n t a i n a b l e _ i t e m { s t a s i s : washing_machine_001 s t a s i s : washing_machine_002 s t a s i s : washing_machine_003 } . ? m a i n t a i n a b l e _ i t e m b f o : BFO_0000196 ? p r i m a r y _ f u n c t i o n . # BFO_0000196 = " b e a r e r o f " ? p r i m a r y _ f u n c t i o n a s t a s i s : P r i m a r y F u n c t i o n .
FILTER NOT EXISTS { ? p r i m a r y _ f u n c t i o n s t a s i s : d i s a b l e d B y ? s t a t e } }
If the asset can perform its primary function, but it is not operating to full eficiency, what conditions have not been met? I.e., what Maintenance State(s) does that asset need to be in to be able to realize the capability. For this we ensure that the asset is participating in, and able to be participating in, the process of its primary function and identifying the relevant states. SELECT ? item ? f u n c t i o n i n g _ p r o c e s s ? c a p a b i l i t y ? s t a t e WHERE { VALUES ? item { s t a s i s : washing_machine_001 s t a s i s : washing_machine_002 s t a s i s : washing_machine_003 } ? f u n c t i o n i n g _ p r o c e s s a s t a s i s : F u n c t i o n i n g P r o c e s s . ? item b f o : BFO_0000056 ? f u n c t i o n i n g _ p r o c e s s # ’ p a r t i c i p a t e s i n a t some time ’ FILTER NOT EXISTS { ? item s t a s i s : u n a b l e T o P a r t i c i p a t e I n ? f u n c t i o n i n g _ p r o c e s s } . ? item b f o : BFO_0000196 ? c a p a b i l i t y . # b e a r e r o f ? c a p a b i l i t y a s t a s i s : O p e r a t e A t F i v e S t a r E f f i c i e n c y .
OPTIONAL { ? c a p a b i l i t y b f o : BFO_0000054 ? p r o c e s s } FILTER ( !BOUND( ? p r o c e s s ) ) . { ? s t a t e r d f s : s u b C l a s s O f s t a s i s : T i e r 1 S t a s i s V a l u e P a r t i t i o n } UNION { ? s t a t e r d f s : s u b C l a s s O f s t a s i s : T i e r 2 S t a s i s V a l u e P a r t i t i o n } MINUS { { ? c a p a b i l i t y s t a s i s : t y p e D i s a b l e d B y ? s t a t e } UNION { ? item s t a s i s : h a s S t a t e / a ? s t a t e } } }
In simple English, we define a function as something that the equipment is designed to do
(that is the purpose of its existence), whereas a capability is something that it can do. In the
ontology presented here, the classes function (from BFO) and capability (from IOF Core) are
both subclasses of disposition. A function is defined as a “disposition that exists in virtue of
the bearer’s physical make-up and this physical make-up is something the bearer possesses
because it came into being...through intentional design (in the case of artefacts), in order to
realize processes of a certain sort" [
The notion of ‘capability’ occurs frequently in the manufacturing domain. In ISO 15531 [
In maintenance, there is the notion of primary function and secondary function as described in Table 1. This distinction is essential in the maintenance domain and aligns with the notions of function and capability from BFO/IOF Core, respectively. In general, the maintenance of equipment is intended to ensure that it is able to fulfil its primary function upon request, while secondary functions may fulfil other requirements (e.g., regulatory, eficiency, protection, etc.) and may not intrinsically impact the ability to fulfil the primary function. For example, while the failure to fulfil a safety requirement (in a particular context) may prevent an equipment from being turned on, it does not change the nature of the equipment nor its ability to fulfil its primary function (if it were to be turned on).
In the case of a washing machine, to wash clothes is the machine’s primary function. To turn on, turn of and operate at five star energy eficiency are secondary functions—for simplicity of this presentation we do not consider protection, safety, regulatory, etc., secondary functions. According to the vocabulary used in industry, it is intuitive for both primary and secondary functions to be a subclass of function.
In the implementation described in Figure 3, however, we chose to make wash clothes a function and turn on, turn of and operate at 5 star eficiency all capabilities. We made the commitment align with the BFO elucidation of function. In our implementation, wash clothes is the only function because to wash clothes is the reason for the washing machine’s existence. In contrast, secondary functions (i.e. operate at five star eficiency ) are not the primary reason for the washing machine’s existence, thus secondary functions have been asserted as capabilities. Moreover, we believe this distinction will be beneficial in the analysis of equipment and system decompositions where the interplay between functions and capabilities at diferent levels will be highlighted. Even so, this terminology may be confusing for industrial users. We invite further discussion on this topic from the industrial ontology community.
In BFO compliant ontologies, continuants have functions that are realised in a process. The continuant is then a participant in that process. The implementation described in Section 3.3 expands this pattern. In the implementation, there is a fourth entity, the maintenance state, that has an impact on the maintainable item’s ability to perform a function. Therefore, we require some mechanism to model the situation where: a maintainable item has a function that is disabled, therefore the maintainable item cannot participate in any process that realises that function. The pattern used is demonstrated in Figure 4 and in competency questions 2 and 3.
In the maintenance domain, the function of an asset does not change throughout its lifetime. Within the BFO framework, it could be argued that when equipment is in a failed state, the equipment has changed so significantly that the function is non-existent. To align to the maintenance domain, we want continuity of the function individual. Therefore, we use the disables object property to model if functions or capabilities are realisable.
The IOF has been using the term stasis in line with the Common Core Ontologies (CCO). CCO
is a collection of ontologies in OWL that extend BFO. The IOF’s argument for this is that the
word ‘state’ is overloaded with other entities (such as location). The term ‘stasis’, as defined in
CCO, is something to maintain, a condition in which things are unchanging. In engineering the
term ‘state’ is often associated with a specific context such as ‘operating state’. In an operating
state, qualities such as the load on an asset or its speed can be changing. Our interest here is in
how to represent functions that can be realised, or not, conditioned on the state of the asset e.g.
if it is operating or not. If we use the term ‘stasis’ to describe ‘state’ in this context we have to
explain what stasis means and why we are using it to our engineering colleagues. One view is
that ontologies should be invisible to end users, in our case, engineers. This is enabled by the
use of patterns and pipelines that allowing ontology experts to build and manage a library of
templates and domain experts to provide content in the form of structurally simple template
instances [
One way forward might be to use ‘stasis’ at the reference ontology level, but subclass it with our more appropriate domain class, e.g. ‘Maintainable Item State’. Apart from clarifying the terminology, it means the assertions we are making about ‘stasis’ are not universal but specific to our domain, since not all ‘stasis’ necessarily control whether functions can be realised or not.
This paper explores the notion of state in a BFO context to model the transition between an asset being able to perform a function and not perform it. We propose the notion of maintenance state as a means of modelling the relationship between function realization and process participation conditioned on a state. We discuss the diference between a function and a capability of an engineered asset when there are primary and secondary functions, choosing to model the first as a function and the latter as capabilities. The current formulation and reasoning treats the ontology largely atemporally, as a snapshot. However, a more complete solution will require consideration of temporal aspects including temporal data properties and relations between states and processes. Although some consideration has been made towards temporalisation, e.g., unableToParticpateIn links to the temporal nature of a state, immediate future work will incorporate a more complete treatment to allow reasoning across time.
In this work we explored including the event that initiates the state change in our ontology. Lengthy discussions were had on the notion of triggering events and the role that a process or process boundary might play (e.g. a failure event). We decided this should be developed in a separate modular ontology. We propose the community put more focus on developing small modular ontologies aligned with a top level ontology and associated reference and domain ontologies, to address specific modelling needs. This approach would support a more rapid deployment of ontologies that are fit-for-purpose for use by the engineering community.
The authors wish to acknowledge members of the IOF community particularly in the Maintenance Working Group. Melinda Hodkiewicz would also like to acknowledge funding from the BHP Fellowship for Engineering for Remote Operations.