Asset Information in Design and Maintenance (NEN 2767)

The water sector faces the ongoing challenge of deciding when to replace, dismantle, maintain, or renovate its many assets. Making such choices requires insight into the performance and condition of the systems, as well as understanding why a component must not fail. For instance, some components contribute to safety, while others contribute to sustainability. The information providing this insight is a combination of data from measurements, maintenance systems, and designs describing how a system is intended to operate.

In practice, design and maintenance information are often used interchangeably, and standards are not suitable for both processes. This blog aims to give you a better understanding of how these different types of information are interconnected.

Click here to read this blog in Dutch.

Part 1: Focusing on Asset Performance and Conditions

Whether a system, such as a lock, or a component, such as the operation of a lock, needs to be maintained or replaced is determined by the likelihood that the component will no longer function as intended. This also depends on the impact this has on other parts of the lock.

To assess this, the properties of the components are inspected. Examples include the degree of rust or corrosion, the number of movements a pump has made, or the number of hours a control panel has been in use (see Figure 1: a component and requirements regarding conditions and inspection).

There are various methods for measuring conditions in a standard. A widely used example is the Dutch standard NEN 2767 (1 and 2) for condition measurements. Such standards differ by industry and country, but the essence is the same: under what conditions must a component be replaced, merely maintained, or even taken out of service?

To do this, we must be able to deduce the minimum conditions a component requires to function properly. What a component must do is defined as what the operation (function) must lead to (the performance). Whether a component can perform depends on the condition in which it is found (the intrinsic characteristics of the component). Why a component does what it is supposed to do is the desired situation, or goal (Figure 2: Derivation of requirements for a lock). 

This is established by the lock’s design and is generally unnecessary for regular maintenance. After all, the systems in place are a given, tested, and proven, and the point is that they do not fail (do not lose their function). Information from condition assessments is therefore sufficient to determine whether a component needs maintenance or replacement. However, condition assessments provide insufficient substantiation for choices regarding new construction or demolition. Those choices require insight into the interrelationship between functioning components and the ‘why’, such as the contribution to aspects like ‘safety’ or ‘sustainability’.

Part 2: Designing a System According to Systems Engineering

Ideally, a lock is specified (in requirements) and designed (in solutions), from goal to function to solution (see Figure 3: A system is defined from goal to function, to fulfiller and solution). This method, deriving choices from coarse to fine, is central to Systems Engineering (SE). The reason for doing this in such a step-by-step manner is to ensure that a lock is conceived and built that actually ‘works’ and continues to perform as intended.

The order of choices in SE is structured from coarse to fine:

• What must the thing do? (function) And why? (purpose)
• How must the thing do that? (performance) And why in this way? (purpose)
• What characteristics must the thing possess? (conditions) And why those? (purpose)

In SE, we start by specifying a lock by first naming the conceivable types. Think of it as the choice of principle. For example, we want ‘a’ lock. Next, we specify where the (identifiable) lock will be located. That is a first step in the design (the geography) of ‘this’ lock. We do this for all parts of a lock (see Figure 4: An individual, identifiable lock has a number of unique requirements depending on the context of the lock).

If the Systems Engineer knows which functions correspond to which solution types, it is easier to make choices during the design process. A lock is therefore defined more and more specifically. As we know more (requirements) about the way a function is fulfilled, we choose an increasingly better defined solution (see Figure 5: Choosing an increasingly specific ‘a’ signal as the requirements for a system become more concrete.).

By applying SE, the system administrator knows the consequences if a component fails. If the administrator also knows the probability of the component failing by measuring its condition, the risk (probability times consequence) becomes clear. Based on the risk, it can then be determined whether the component needs to be maintained or replaced, and therefore also why. For example, for reasons of safety or sustainability.

Part 3: Design and Maintenance of Assets Based on Standards

It is not necessary to create a functional decomposition for every individual lock. Furthermore, not all performance requirements for every lock are the same. Therefore, we distinguish between what ‘a’ lock must do and what that identifiable lock (and the identifiable components) does in a specific situation. By knowing in advance what things can do, we are better able to:

1. Choose appropriate solutions,
2. Which requirements apply as failure prevention measures,
3. How is it verified whether the system complies (also during maintenance)?
   
   

In a library, often referred to as an Object Type Library (OTL) for asset types in the Dutch water sector, which is intended to assist in Systems Engineering and performance or condition measurements, we establish two important hierarchies:

1. Specialization of types of things (taxonomy).
2. Composition of types of things based on their functions (decomposition).

A specialization hierarchy is based on the greatest common denominator between types. Something has ‘specializations’ if the concept occurs in different forms. The difference is called the discriminator and is chosen depending on the intended use of the specialization. The selection of discriminators and the order in which they are applied is derived from the intended use of the library. The rules for discriminators must always be the basis for creating a library (i.e., an ontology). For Systems Engineering, for example, discrimination is based on purpose, function, technical principle, component, and intrinsic characteristic, such as material or dimensions. When we know which solutions follow which functions, we can also deduce which components a thing consists of. According to some sources, floodgate, outflow lock, and sluice are synonyms, and there is no difference. However, the most important discriminator for use in Systems Engineering is the function.

For maintenance only, one must be able to define the conditions, requiring information about the characteristics of a component, such as material or operating hours. As shown in Figure 8: Example of deriving requirements from objective to SMART characteristic, requirements, like their subjects, are methodically derived from coarse to fine and from large to small. This is done to the point where they are Specific, Measurable, Acceptable, Realistic, and Time-bound (SMART). This can be done in a library at the level of a decomposition of asset types and kinds. These requirements are then applicable to any lock project, whether new construction, renovation, or maintenance. Only specific location-based requirements need to be added.

By establishing in advance for all types of assets which functions are performed and how the components contribute to this, management organizations are able to determine general rules for maintenance, replacement, or demolition.

The hierarchy of assets in NEN 2767 is not based on the principles of specialization, discriminators, or functional composition. It is a specific way to aggregate scores and provide a shared ordering to navigate information about assets. For the time being, this works fine for maintenance based solely on condition measurements. Still, for Systems Engineering, it is necessary to know how the characteristics are derived from the required performance (see Part 1: Focusing on the performance and conditions of assets), so that one knows why the component must do what it is supposed to do. Similarly, for policy-driven choices regarding demolition or replacement, it is necessary to know the ‘why’ to determine what takes priority (see Part 2: Designing a system according to Systems Engineering (SE)).

This document argues against adapting NEN 2767 for Systems Engineering (SE). The key is that the characteristics from NEN 2767 can be linked to a functional decomposition that is suitable for SE. A library/standard should not be used for different applications. Every standard must be tailored to the purpose for which it is used. If NEN 2767 must also be suitable for engineering, conflicting requirements regarding the information may arise.