Introduction

Water Supply Systems (WSS) are part of the critical infrastructure systems of a city or region aimed at satisfying the population’s demand for water. They are Systems of Systems (Joannou et al., 2019), geographically distributed in networks. The use of technology is essential to manage kinds of net systems (Nam and Pardo, 2011). Those networks are autonomous nodes, having control procedures according to the function of the node. However, each node must cooperate with other nodes in order to accomplish a global objective. Those systems are considered as a System of Systems (Colombo et al., 2019). The WSS is a set of continuous processes with jumps that are necessary to respond to changes in water supply and consumption, restrictions on pumps and valves, and also for failures in pipes and equipment.

This paper proposes an Holonic Manufacturing Systems (HMS) that integrates the physical level with the enterprise level allowing the execution of processes associated with operation management. The HMS can make configuration, reconfiguration of physical processes as results of the scheduling activities, and the supervision tasks to ensure the established WSS goals. The HMS aim to decentralize the manufacturing tasks into individual decisional entities (i.e., holons) for featuring autonomous, cooperative, and responsiveness behavior within manufacturing operations (Pujo et al., 2009). Therefore, the development of the holon concept and the holarchy organization has become a central issue responding to the efficiency and the reactive manufacturing challenges. Besides some HMS contributions (Chokshi and McFarlane, 2008b; Indriago et al., 2014; Bloch et al., 2017), have tended to focus on intermittent and discrete processes, rather than continuous production processes e.g., chemical processes, WSS or oil refining processes (Chokshi and McFarlane, 2008a).

The implementation of the proposed architecture is called Holonic Production Unit (HPU), as given in (Cruz S. et al. 2019). An HPU is divided into three levels: Plant level, where physical processes (mechanical, chemical, biological) take place; operations management level, aimed at optimizing the production process; and the business level. The plant level has a traditional architecture based on PLC (Programmable Logic Controller) and its SCADA (Supervisory Control and Data Acquisition). Therefore, this level contains a regulatory control tasks, and a local supervisor works together for monitoring the system sensors (i.e., water storage, tank level, water treatment rate, among others). The Image level, similar to the Digital Twin concept, contains the HPU’s information that allows supervising negotiating, retrieving/storing data, and interacting with other HPUs. These contribute to maintaining the state and evolution of the physical process. The enterprise level, as a non-real time regulator, it is oriented to evaluate the execution, transfers information to the enterprise systems, and accepts/rejects the assigned objectives and to establish cooperation with customers and suppliers.

After a brief introduction highlighting the complexity of WSS management and its automation, this document is organized as follows: “Water supply systems: a brief description” section describes the structure, functions and general behaviour of a WSS, the aspects of process integration, and the Information Technology (IT) and Operation Technology (OT) in this architecture. “Literature review: intelligent automation systems addressing I4.0 requirements” section describes a literature review addressing the I4.0 needs in manufacturing, and the trends that allow the integrated automation of the different processes by Intelligent Manufacturing Systems. A description of the HPU and its formal basis is given in “Automation approaches meeting I4.0 requirements” section. “Mission Holon (MH)” section describes the technological architecture of the HPU. In “The human in the loop” section the methodology for the application of HPU in WSS is shown. “Deploying the Holon over the IT/OT technology” section analyzes the fulfillment of the I4.0 requirements exposed to the HPU, and final conclusions are given in “The bottom layers of the HPU and the OT” section.

Water supply systems: a brief description

The urban water has a cycle that covers from the water catching process until the devolution to the environment, and by evaporation returns as surface water or groundwater to the rivers and aquifers (Marsalek et al., 2006), as is shown in Fig. 1.

Fig. 1
figure 1

Urban water cycle, from Marsalek et al. (2006)

Full size image

A WSS make part of the urban water cycle and connects units for collecting, storing, transporting, purifying, distributing drinking water to the population of a geographical area, particularly cities. WSS has an organization that allows to accomplish the objectives in supply water to the population, maintaining economic viability and sustainability with the environment. A WSS may have several sources (superficial and groundwater), several purification units, a main network that take the water to the distribution tanks and the secondary distribution networks.

The WSS enterprise organization

Figure 2 shows a functional breakdown of the technical processes associated with the supply of drinking water from collection, distribution and recovery to return to the environment. Specialized units carry out: (a) the collection of water from different sources, (b) the management of purification and distribution operations and, (c) the management of users that characterizes them, establishes their physical link to the network and analyzes their needs and ensures the interaction between customers and operations to detect supply anomalies. In addition, the maintenance unit guarantees the correct functioning of the resources.

Planning in a WSS covers two aspects: (1) the study of future demand and the construction or improvements of the infrastructure, and (2) the management of demand and production balances for the coming months ensuring the satisfaction of the population and the ecological consumption, generating projections of demand and raw water contributions to the system. A typical pattern for water demand and rains is shown in Fig. 3, and the variations of water consumption and their amounts for a city and a neighborhood are given in Fig. 4 (Candelieri and Archetti, 2014). Tanks, by design, are expected to store 33% of the daily consumption, and Fig. 5 shows the behavior of a distribution tank.

Fig. 2
figure 2

Description for a hydrological enterprise (UML Eriksson—Penker diagram)

Full size image
Fig. 3
figure 3

Historical behavior of rains (green) collected water (blue) and monthly consumption (red)

Full size image
Fig. 4
figure 4

Mean dairy consumption of a residential neighborhood and average consumption for a city (data from Candelieri and Archetti (2014))

Full size image
Fig. 5
figure 5

Behavior of a tank for a neighborhood

Full size image

IT integration for WSS: migration from the classic approach

For the effectiveness of the decision-making schemes, the following considerations must be taken: (1) In the management of the operation, at least the network models, generated mainly by the design department, the models of the infrastructure generated by their condition and resource behavior models that allow valid configurations to be established, (2) In the case of serious failures, the system must establish configurations to apply for contingency plans, prioritizing critical entities in the system, e.g., hospitals.

SCADA systems for managing operations in WSS are common in cities with more than 100,000 inhabitants. There are several providers of this technology such as Schneider, Siemens, etc. In principle, these systems are disconnected from administrative and longterm planning systems. Operations management and fault handling are basically done manually according to the experience of the operations personnel and in some cases guided by simulators. In the planning environment, the systems used are based on GIS and hydraulic models based on the gradient method (Todini and Pilati, 1988), which is used in applications such as Watergems (Bentley) or Epanet (EPA), these applications have georeferenced information handy for operation and hardly seen a timid IT integration with SCADA (Li et al., 2020). The billing systems have the information necessary for the planning of operations, they are not connected with the planning systems, as well as the systems of operation scheduling and their information about the users is necessary for the establishment of network configurations. Such is the case, of a breakdown (failure), it is necessary to know which users are connected to which network, which is the priority to establish a path that ensures the supply of drinking water, possibly through a secondary network.

Hydrological Companies, with a high degree of development, have Information Technology (IT) infrastructure that support the planning of operations connected with administrative systems, and an Operations Technology (OT) infrastructure, based on the classic CIM approach as shown in Fig. 6, to manage production operations. New analysis based on the performance of analytical functions are incorporated to improve leak detection. Also, functions to support the management of interactions between maintenance and operation personnel to establish configurations when maintenance work is carried out, as well as to establish operation sequences when new network configurations are needed, but there is still no full integration (vertical, horizontal). Integration of all systems, with built-in insulation, is very difficult and in most cases not possible. That is why the holistic view of I4.0 reveals the required integration in WSS and the need to do so defines its feasibility.

Fig. 6
figure 6

Classical IT/OT architecture for WSS

Full size image

Literature review: intelligent automation systems addressing I4.0 requirements

Origins of manufacturing systems until the modern I4.0 paradigm have correspondences with cognitive features of human behavior to get smart control (Galán et al., 2000). For example, contemporary automation systems are addressed by distributed artificial intelligence from various perspectives, such us: Multi-agent Systems (MAS) (Leitão et al., 2016; Salvador Palau et al., 2019; Seitz et al., 2021), Services Oriented Architecture or SoA for manufacturing (Garc´ıa V. et al., 2013; Gamboa Q. et al., 2013), HMS (Leitão and Restivo, 2008; Hsieh, 2009; Borangiu et al., 2014; Valckenaers, 2020), HMS for continuous processes (Chokshi and McFarlane, 2008a; Chacón et al., 2009; Indriago et al., 2014), Cyber-Physiscal Systems (CPS) (Lee et al., 2020; Monostori et al., 2016). All of them are different approaches but they follow common requirements to archive the I4.0 paradigm, as introduced in the next sub-section.

3.1 WSS requirements established by Intelligent Manufacturing Systems for I4.0

HMS architectures contribute to the future challenges of I4.0 (Derigent et al., 2020). However for HMS to be aligned to I4.0 (Derigent et al., 2020; Ribeiro and Hochwallner, 2018; Vogel-Heuser et al., 2014), should fulfill five essential requirements (Req1-Req5). These are fundamental properties aligned with the I4.0 paradigm based on the Cyber-Physical Production Systems (CPPS) concept (Cardin, 2019). There is a list for CPPS Minimal Conditions identified and they are grouped into four main categories (Cruz S. and Vogel-Heuser, 2017): CPPS minimal conditions (Req1), Smart characteristics attributes (Req2), Formalized Modelling Terms (Req3), and Systems and Human integration needs (Req4). This contribution adds another requirement regarding the Reference Architectural Model Industrie 4.0 “RAMI4.0” (Plattform Industrie 4 0 2018). Table 1 summarises and adapts these requirements to address WSS, based on Cruz S. and Vogel-Heuser (2017).

Table 1 Minimal requirements for Industry 4.0, addressing WSS. Adapted from (Cruz S. and Vogel-Heuser 2017)
Full size table

Automation approaches meeting I4.0 requirements

The automation of continuous production systems evolve from the Mesarovic et al., (1970) hierarchical approach, the first approach manages the complexity of these systems. Difficulties in achieving models that represent reality make this approach shift towards decentralized systems (Brdy´s and Roberts, 1986) and later using hybrid systems to model such systems (Morari et al., 2003). Both approaches use continuous local controllers and coordination that can be based on discrete abstractions of piecewise continuous systems. This allows the decentralized management of production nodes in a networked system.

Since manufacturing systems challenge changes daily (Leitão et al., 2016), to meet complex needs, various architectures have been proposed (Borangiu et al., 2019). In general, these architectures range from hierarchical (e.g. CIM), with centralized decision-making schemes with a cognitive model at the higher levels of the hierarchy. Moving on to the heterarchical and semi-heterarchical (Trentesaux, 2009), with decentralized schemes where the cognitive model is now distributed (Jiménez et al., 2017). The last ones depend on the behavior, structure, and dynamics dispersed that are expected during smart manufacturing processes, i.e., by CPS, HMS, MAS, among others. Until the current evolution con-ceiving architectures with holonic philosophy self-organized in holarchies and whose main implementation is given by agents (Colombo et al., 2006), whose cognitive model is given in the holarchy, where each entity (holon) is autonomous - intelligent (Blanc et al., 2008; Barbosa, 2015; Dias-Ferreira et al., 2018). In the manufacturing processes this paradigm is known as HMS and they have two representative architectures: ADACOR (Barbosa et al., 2015) and PROSA (now ARTIS) (Valckenaers, 2020). Selected HMS that fulfil I4.0 requirements are compared in Table 2.

Table 2 Comparison of selected HMS meeting I4.0 requirements (see “WSS requirements established by Intelligent Manufacturing Systems for I4.0” section)
Full size table

Holonic production unit architecture

Process industry, oil & gas production, energy generation/distribution systems, and WSS, among others, are systems that must guarantee a continuous flow of material to satisfy production demand. Those systems are constituted by a set of connected units (facilities, utilities, process units) forming a production network. Each Production Unit (PU) has its own behavior and the global behavior comes from the composition of local behaviors. Pipes give the connection between units where the material flow is continuous. Product flows in pipes is bulk and the material streams are transformed at the process units, adding value to the material until reaching the desired product. We will call PU to each process unit and also the transportation units area considered as PU. See Fig. 7.

Fig. 7
figure 7

Physical components (equipment) and the possible physical interconnections and the comunications network

Full size image

Each PU has internal resources that must be managed to perform production processes. Processes at the PU have behaviors that must be controlled by means of controllers and supervisors. The necessary knowledge to ensure the right behavior of a process is stored internally at the PU. PU performs “viable processes ” to achieve a goal, where goals are negotiated accordingly the internal capabilities. Then PU has the necessary knowledge to negotiate goals (missions). A complex goal can be obtained by a sequence of processes that can be internal to the PU or performed by a set of PU’s. Then a PU that have all these capabilities is considered a HPU.

Implementing a concept for geographically distributed continuous process systems requires a geographic distribution of control equipment at the edge with the ability to execute control algorithms and the handling of equipment failures. In this case, a WSS requires high-speed connections to handle the interactions between physical processes and changing modes of operation. As a result, recent alternative projects for distributed and decentralized systems are given by the I4.0 paradigm. For instance, Colombo et al. (2019); Leitão et al. (2016), introduce SOCRADES and IMC-AESOP projects for SCADA and DCS, as mechanisms to develop CPS.

Modeling the behavior of the global system

Hybrid Dynamical Systems HDS (Lygeros et al., 2012) appear as a tool that facilitates the modeling and control of physical production processes through the sequencing of modes of operation. Here is the proposed HMS’s relevance since the HPU has a considerable advantage over other approaches because they can be engineered as a holistic approach to suit different applications. The novelty focuses on continuous processes, where each mode of operation is represented as a discrete state. The global dynamics are represented as a sequence of operation mode jumps. The behavior of a production unit is described as a HDS, which has its own monitoring mechanism. Each discrete state of the production unit has its own control law that allows it to stay in that state or reach a target state. In behavioral modeling, a discrete state has a set of constraints on inflows, a set of constraints on outflows, and a control law to achieve or maintain the goal. Each discrete state is an abstraction of the continuous behavior of the controlled system, and it is necessary to have the event detection mechanisms that guarantee that the continuous dynamics is correctly mapped. Tazaki and Imura (2008) states that in the case of interconnected systems, the compound dynamics can be followed through abstractions if the requirements set out above are met. For a mode of operation of a subsystem the output flow must comply with a set of constraints that the receiving system of the flow knows in advance. Failure to comply with the restrictions implies that the HPU changes modes of operation and the receiver must change modes of operation. The discretization of each subsystem is associated with its outputs. Each subsystem is discretized separately.

An HDS is defined in several ways: as a Phase Transition Systems, as a Hybrid Automata (Lygeros et al., 2012), by means of Petri Nets (Lennartson et al., 2016) by Differential Logics (Platzer, 2010). We will use the definition given in (Lygeros et al., 2012) for a controlled general hybrid dynamical system.

A Hybrid Automaton H is a collection

figure a

See (Lygeros et al. 2012) for the description of concepts such as Hybrid trajectory, execution, reachable state, composability that allows the construction of control & supervision mechanisms for the HDS. In our case, several process units that interoperate, the synchronization (cooperation between units) proceeds physically by the outflows exchange among units. In a similar way, for each discrete state, a regulatory control function is associated, and the transitions generate symbols that allow the tracking of the system by a supervisor.

The system’s global behavior is achieved through the composition of the abstractions of the behavior of each subsystem. The hybrid model of each subsystem to meet the bisimilarity (Tazaki and Imura, 2008) requirements in order to be used in the construction of possible configurations.

The architecture presented assumes the existence of an intelligent resource. It is capable of negotiating a goal, in operation it executes control mechanisms to ensure compliance with the goal. Resources are honest, when a resource detect that the objective is not out of reach, it manifests it to the rest of the resources. In your operation, if you must cooperate with other resources, follow the agreed steps to synchronously achieve the objectives. Physically, the resources have a set of connections for the transfer of matter and energy that may or may not be enabled for a configuration. For a connection between two resources, in a configuration, the flows of matter and energy between them are previously agreed.

To arrive a configuration a negotiation must be performed to arrive to a schedule by using the bisimilarity concept; the negotiation determines the way to perform the coordination among the HPU and establishes the local supervisors. Each HPU presents the layers shows in Fig. 8.

Fig. 8
figure 8

Adapted from Chokshi and McFarlane (2008a)

Cooperative holons.

Full size image

Components of the Holonic Production Unit.

The PU has internal resources that must be managed to perform production processes. Processes at the PU have behaviors that must be controlled by means of controllers an supervisors. The necessary knowledge to ensure the right behavior of a process is stored internally at the PU. PU’s perform “viable processes ” to achieve a goal, where goals are negotiated accordingly the internal capabilities. Then a PU has the necessary knowledge to negotiate goals (missions). A complex goal can be obtained by a sequence of processes that can be internal to the PU or performed by a set of PU’s. If a PU those components is a HPU.

As in the ADACOR proposal (Leitão and Restivo, 2008), there are four main holons: (a) Mission Holon (MH) similar to the Order holon. (b) the Resource Holon (RH), in our case the central holon that performs both the physical tasks -equivalent to the Operational Holon in ADACOR- and the management tasks using the other two holons. The Engineering Holon (EH) that has the knowledge base of the product model and the behavioral models for each service provided by the resource, similar to the Product holon of ADACOR. The Supervisor Holon (SH), named the same as in ADACOR (Leitão and Restivo 2008; Barbosa et al., 2015), but derived from the concept of supervisory control of hybrid systems, which work on abstractions of continuous dynamics on the plant floor. These abstractions are built through Petri nets, and the interactions between the levels are given by messages associated with events. Therefore, even from different domains, our proposed HPU architecture differs from ADACOR mainly in the SH due to its decision hierarchy and the RH concept as the central element, not as the operational element (Leitão and Restivo, 2008).

The components of the HPU are given in Fig. 9.

Fig. 9
figure 9

UML class diagram of the HPU components

Full size image

The Engineering Holon (EH)

EH manages the production knowledge. The knowledge is grouped into three elements: (1) The Product Model, which describes the set of services provided by intelligent resources to obtain a product and its order of execution including the formula. (2) The Process Model, which is the procedure used by an HPU to provide a service. (3) The control mechanisms that ensures the right behavior of the system for each process model and it will be employed by supervisors to assure the accomplishment of goals.

Resource Holon (RH)

The physical system, as is shown in Fig. 7, is composed by several units, where each unit performs the necessary tasks in order to accomplish a service. The concept of service (Karnouskos et al., 2012; Gamboa Q. et al. 2015) is used to facilitate the description of the Product Model. A RH is autonomous, that is, it is able to establish its own goals, supervise and control its evolution. Each RH establishes its goals by a negotiation process among the others RH in order to achieve the global one.

RH is the central element in the architecture used. RH manages its internal resources, and executes the physical processes necessary to meet the production objective. RH negotiates with other RH missions, establishes production commitments, calculates the local supervisor to be used to monitor, and control the mission. An HPU can be a resource for another HPU more generic as is shown in Fig. 9. To manage the internal processes the HPU is partitioned in several resource layers as is shown in Fig. 10. The upper resource layers perform the negotiation with other HPU. It evaluates the possibilities to accomplish its part of the global goal and send an expected behavior to evaluate the whole behavior. If the composition of the system is considered viable, an agreement is achieved. Topological Models is the layout of the plant that describes the equipment (PU) and its hierarchy and the interconnections among the PU’s; an information exchange model describes the flow of data from the plant floor to the decision layers, and a plant information model (PIM), as introduced by Pérez et al. (2015).

Mission Holon (MH)

Similar to the Order Holon in PROSA (now ARTI by Valckenaers, (2020)), and the Task Holon in ADACOR (Leitão and Restivo, 2008), the MH has the objective to be reached or maintained by a PU during a period, it also has the information about the fulfillment of the mission. Goals and State of the Mission are part of the MH. A mission results from evaluating the feasibility of meeting a production objective. If the objective is achievable by the PU and a configuration is established, that means an acceptation of the mission. For an accepted mission, the PU creates a supervision mechanism to ensure the achievement of the objective. MH and SH are strongly coupled, since for each accepted mission a supervisor is established. When the process is continuous or batch, the evolution is described as a Hybrid System.

A mission has three stages:

  • In Evaluation. At this stage the HPU receives a proposal to performs a service. The algorithm for evaluation of a mission is given in Algorithm 1.

  • In Execution. It corresponds to the control system to ensure that each stage is performed as planned. The interaction between local supervisors and the global supervisor ensures the achievement of the mission. For continuous systems, the regulation is performed for each pass. At the execution the information of physical process and resources is collected to determine control signals and events that determine the evolution of the process.

  • Completed Mission. At the end of the mission, resources are liberated and a evaluation of the performance for the mission is made, also an evaluation of the resources is made to determine the needs of maintenance.

Algorithm 1: Negotiation of the mission.

figure b

Supervisor Holon (SH)

Harjunkoski, (2009) analyze the characteristics of production programming and process control and the need to integrate both tasks. The time scales at the two levels are different, and the programming decisions are discrete, while the control decisions are continuous. Discrete decisions determine the evolution of the dynamics on the plant floor, at the same time, that discrete decisions are conditional on the feasibility of continuous dynamics. In an HPU, the tasks of basic control, monitoring - supervision - coordination and planning occur simultaneously. Supervision can alter the dynamics of the floor by changing the operating mode, and in the floor, operating conditions can generate events that trigger the monitoring mechanisms. If supervision cannot find a suitable mode of operation, a reconfiguration mechanism is triggered. Coordination has two functions local internal coordination among the set of HPU that works in a configuration, and the cooperation mechanisms with other HPU. The local supervisors send events that allows to have updated the abstraction of the process. If the abstraction arrives to a non-desired state the reconfiguration process is triggered to arrives to a new viable configuration. The integration of the decision levels is shown in Fig. 10.

Fig. 10
figure 10

Supervisory control levels in a Production Unit

Full size image

In the continuous production process, each unit with autonomy can be seen as CPPS (Bloch et al. 2017). In execution, the HPU supervisor executes in Algorithm 2 to evaluate and ensure that the process behaves correctly.

The technological architecture: HPU’s IT/OT

This section shows how the functions of the HPU must be projected on the platform of technologies of operation IT/OT available in the plant. For a classic infrastructure, like the one shown in Fig. 6, the regulation functions go directly in the PLC (often OT component), the supervision and coordination functions in the equipment in the non-strict real-time level, and the programming and planning functions in the IT level, which store knowledge and images (digital copies) of plant processes and equipment. These images of the process are the basis for determining the state of the system and generating the scheduling of plant floor activities and determine local supervisors and coordination mechanisms among the units.

Algorithm 2: Monitoring the process

figure c

SCADA systems are a well-established technology in industrial process control and are part of the proposed architecture solution. SCADA systems have an interface layer with the field, associated with instrumentation, a layer associated with the controllers, and a supervision and data acquisition layer that allow to maintain control of the processes on the plant floor. Additional sensors may be necessary to implement the holonic vision that allows to have the information of the resource, and of the execution of the order. In relation to the RAMI4.0 reference model, it can be indicated that the SCADA covers its levels L1, L2, L3 (Zezulka et al., 2016). For the case study, the sensors of the treatment plant allow to follow the evolution of the processes (execution of the order), and the start, stop events for the filters and settlers are received from the SCADA. In the extended real-time servers associated with SCADA, the evolution of the process and the status of the resources are monitored. These functions correspond to the bottom layers of Fig. 8.

IT for the upper layer of HPU

Each physical resource or group of physical resources that perform a stage or sub-stage of a production process considered as a resource holon, and it is composed of two elements (a) its image (b) the description (knowledge) in the holon server as shown in Fig. 12 and corresponds to the smart part of the Holon. SCADA information updates the image, and process experts create its knowledge. These components are stored in the extended real-time part of the SCADA system. Each unit has knowledge associated with the product model, capabilities and abilities from its process models, and physical connections between the different resources and PIM (which correspond to the EH).

The upper layer in Fig. 8 correspond to the planning, scheduling, and re-scheduling activities of the HPU. These functions are performed on-line according to the inputs and requirements flows for the plant, increasing availability into the systems. The SCADA transmits to the extended real-time servers the events captured on the plant floor or the SCADA’s commands, updating the holon image. Process events update the status of the order and events associated with the resource that allows inferring the resource’s status. In Fig. 11 the mapping of the hierarchy levels of the HPU on the IT/OT architecture is given.

Fig. 11
figure 11

Holons into the IT/OT architecture for WSS

Full size image

To implement supervisors, it is necessary to have engines that receive a supervision model and execute the supervision tasks defined for that model. In our case, the motor used is based on a meta-model described using Petri nets. At the lower level, OT events at the plant floor are detected directly by sensors and/or by detection mechanisms regarding the operation regions. Other plant events come from the equipment monitoring. Other plant events come from the equipment monitoring. Supervisor receives these events to determine the following operation mode. External conditions are managed similarly. The occurrence of the events updates the abstractions (process and equipment images). All the events defined to describe the behavior of the physical system must have an associated sensor or a detection mechanism based on the measurements of the system. This allows to reconstruct the discrete dynamics, and to have an updated image that can be used to reprogram the system. According to the aim of this paper and is suggested by Liu and Xie (2020) into the technology available are soft-sensors, which are usually used in the chemical and petrochemical industry, power generating industry, because they require a high precision level, is essential to consider this kind of sensors to monitor the process. Kernel-based soft sensors are a suitable option to recognize and indicate abnormal events or a faults. A general way is to compare actual values, typical situations of WSS.

The functions of optimization and production programming are deployed using infrastructure IT. Servers oriented to maintain the HPU information, maintain the updated image of the process through update mechanisms by events. Plant floor events of the OT, travel to the management level of the HPU and a motor updates the status. If the state does not correspond to the expected state, the reprogramming mechanisms are triggered.

The Product Models and Process Models are maintained on specialized servers, which can be updated by the engineering and development staff. The relationships between the resource holons, and the product holons are similar to those proposed by McFarlane and Bussmann (2003).

The head of the holon has the whole description of the resource and its process image. The image of the tasks that a resource is executing are compared with the prediction obtained from the behavior model corresponding to the task. The behavior model is used both for planning and to determine if the evolution is as expected. The functionality is similar to that described in Monostori et al. (2016). Details of the software components at the holon server are given in Fig. 12.

Fig. 12
figure 12

UML deployment diagram of the HPU software components

Full size image

Linking process events and product events

The evolution of the discrete part of the dynamics of the process is driven by the appearance of events. A subset of these events are sent to the product evolution supervisor in order to change the system configuration if necessary. The appearance of events on the plant floor, captured by the controllers, allows the evolution of the process to be monitored. The list of all events, and the association with the events of the Product Model, allows the supervision of the stage. This event association map is part of the description of vertical integration.

For instance, events can be generated by external resources such as users using phone calls to inform about the water network conditions or external applications that make “data analytics” determine leaks or changes in the network. Those events travel on the computer network until the extended real-time servers and the evaluation cycle is started to process those events like the events detected internally.

Generation of production objectives for the HPU

In Large Scale Processes (LSP) such as WSS, the integration between the regulatory control functions and the planing functions is a need. These two functions are split into a hierarchy (Risbeck et al., 2019). Scheduling and re-scheduling process determine what are the “optimal” configuration to accomplish the production objectives. The daily optimization of the system balances the volume of water at the entrance of the treatment plants, the capacity of the main network (pumps, pipe diameters, network topology), storage capacity in distribution tanks and hourly demand. of the secondary networks (see Figs. 4 and 5). With this, the filling sequence of the different tanks and pressure reference for the secondary networks are determined using the algorithm shown in Algorithm 2.

The human in the loop

The human performs different roles in a LSP, (a) physical tasks that cannot be replaced by machines such as infrastructure maintenance, (b) supervision tasks in decision-making processes where expertise is essential due to the incompleteness of the models and c) providing knowledge to the system. In the decision-making process, the human must have the possibility of interacting in fully automated environments, to systems with manual decision-making (Cardin, 2019). Despite the human intervention in the operational level has been restricted to reduce variability in operations, the worker operator is indispensable in some situations as systems’ repair and maintenance Lee et al., (2020).

The main roles of the human in the system are:

  1. 1.

    Supervision of the physical operation in the different HPUs. The system must allow the visualization of the processes and generate enough information for the operator to validate the decisions suggested by the system. The system shows the different flows, the current balance and the values that the system will have in the next few hours. The state of the resources. Therefore, human as a supervisor is in charge of evaluating the performance of the system, as proposed in (Emmanouilidis et al., 2019).

  2. 2.

    Interaction with the users of LSPs In many cases, failures in the system such as pressure drops or absence of service, leaks in the circuits, are detected by users who communicate with the service centers, and these failures must be introduced into the system for reconfiguration or for carrying out of a maintenance. The first attention is made by a human being who reports to the system and acts similarly to the “magical human” concept, making decisions and interacting with the physical and cyber to solve problems (Trentesaux and Millot, 2016).

  3. 3.

    Management of events and contingencies The automated system must have the ability to detect most equipment failures, line leaks, and verification of goal compliance. Such an event will generate a new configuration that must be proposed by the system and validated by an operator. If there is no valid output it is up to the operator to build one. The system must allow the operator to establish procedures to achieve a new configuration.

  4. 4.

    Validation of optimizations The configurations found automatically, must be validated by the operator before being sent to the execution level in real time.

  5. 5.

    Loading of system knowledge Technical personnel are the creators of the models on which the system works. This knowledge is introduced, validated by the process engineers, by the maintenance personnel, they define the HPUs and their models of behavior. There is a strong dependence on the cyber part of human expertise. Similarly, the fit of the models found by data analytics must be validated by the expert, determining the parameters of the control system optimization processes (Fantini et al., 2016).

  6. 6.

    Manual operations Many operations must be carried out manually, especially in the case of corrective maintenance of LSPs. The operator interacts with the HPU to indicate the progress of the operation. In the control room, operators must have feedback on the progress of maintenance operations. Human acts as a local entity of the control system at the operational level and develops a cooperative relationship with the system because of the high level of complexity, as introduced by Pacaux-Lemoine et al., (2018).

The information platform must allow easy human interaction with the system at all levels. The most complicated interaction mechanisms are associated with activities of maintenance, since the platform must ensure interaction between the operator and maintenance personnel, ensure the visibility of the equipment, show plans, equipment connections, etc. The Digital Twin is corresponding to equipment and processes and must be viewed by all personnel involved in the maintenance activity.

The Digital Twin allows representing the human as a is decisional human entity considering a water supply system the human role may be different depending on its location into the system as is shown in Fig. 13. As a supervisor it takes some decision as scheduled the maintenance, start or stop the system, decisions which are supported by structured information about the system. By the hand the human as an operator or a crew could have a reactive role, executing manual operations or maintenance activities. In this case, the human receives an instruction, and it intervenes in the system. Human participation in maintenance is required especially when the automatic system repair is enabled to solve failures.

Fig. 13
figure 13

Human in the loop

Full size image

Methodology to implement the HPU: application to a WSS

The proposed methodological approach shown here, it is structured based on HPU requirements and the preliminary requirements for I4.0 (See “WSS requirements established by Intelligent Manufacturing Systems for I4.0” section). It takes into account Product & Process Models that includes control and supervision laws, PUs hierarchies and interconnections among them (topology of the production network) and the IT/OT that support models, information exchange and decision systems.

Those steps are: (a) Supply the necessary knowledge to the system, (b) Decides the Hierarchy levels and Layers for the whole system (See “Literature review: intelligent automation systems addressing I4.0 requirements” section), taking into account the possible holarchies and the existing information systems, (c) make the mapping of the functional layers on the IT/OT infrastructure.

Knowledge acquisition

The source of knowledge is given by experts in the area who define the general models for water management in cities. These experts use different software applications to study water sources and their capabilities; characterize the demand associated with population growth. Using this knowledge, they design and build the infrastructure of the WSS.

The first step achieve an implementation is to obtain the Product Model and Process Models and the connectivity of the whole system. In the case of a WSS, the Product Model takes into account the principal stages that it can be found on the city water cycle given in 2. Those stages are shown in Fig. 2.

From the city water cycle of Fig. 2, it will be considered only the WSS. The model from sources until water consumption considers water input from the sources including rain and neighborhood water requirements fore-casting, and operation to estimate the optimal levels of reservoirs and the final pressure at the neighborhoods to assure the permanent water supply as was given by Fig. 3 that shows the historical behavior of rains and water consumption.

Sources Determination of the characteristics and behavior of the sources. Surface and underground. Reservoirs. Rain forecasting.

Water intake System to intake the underground or surface water and make it available to transport to the purification plants. Reservoirs. Determination of the raw water quality.

Transport of raw water Description of the transport sys-tem from reservoirs to purification plants.

Purification system This stage transform raw water in drinking water.

Distribution The pipeline network that transports drinking water from purification plants to distribution tanks.

Final distribution The secondary network that transports water for distribution tanks to final users. Behavior of neighborhoods.

Information on minimum acceptable water quality to users (Color, flavor, amount of bacteria, cleanliness, pressure, etc.), to pass from one stage to another.

Purification stage is in charge of taking raw water (from sources or reservoirs) and converting it into drinking water suitable for human consumption. This process is divided into several sub-stages as is shown Fig. 14, the firsts sub-stages (Coagulation, flocculation, sedimentation, filtration and disinfection) eliminates the turbidity of the raw water coming from the source, produced by very small diameter particles and low sedimentation (colloidal), which is achieved by adding a coagulant in the sedimentation-filtration process, and in the last one, microorganisms, that can be harmful to humans are eliminated, which is achieved by disinfection (chemical means: addition of chlorine). The last step also stores the product to buffer changes in demand and in the steps in the sedimentation and filtering sub-stages.

Fig. 14
figure 14

Product Model for the purification process

Full size image

A purification plant is given in Fig. 15 and it corresponds to the case studied in (La Cruz, 2019), and it allows us demonstrate the methodology.

Fig. 15
figure 15

Product Model for the purification process

Full size image

Product & process models

The construction of the models is focused on the resource. The product model reflects the chaining of resources, while the process model represents the resource’s behavior when it performs an activity. Each resource has an internal behavior and an external behavior that results from the supervisor -system components used to coordinate and schedule production.

Product and Process Models are described formally Using Petri nets. The product model is associated to the stage (sub-stage) sequences for the product and the process model is associated to the steps inside the equipment that performs a stage or a sub-stage.

Taking as example the sedimentation sub-stage, a description of the process follows. In sedimentation, here the flocs that are in suspension are deposited; the rate of fall will depend on the concentration of the particles, the speed gradient of the system and the size distribution. The mass of water should remain between two and four hours to decantation. At the top of the sedimentation tank there are collecting channels throughout the tank, linked by rows of perforated ducts that collect water in the clarified area. At the bottom of the sedimentation tank there is an inclination to a drain point, for easy removal of the flocs, opening a gate or valve. The settlers can be vertical, horizontal, laminar flow, their structure and configuration depend on the flow and quality of water. See Fig. 16.

Fig. 16
figure 16

Plan of a settler resource for the sedimentation substage

Full size image

For the plant, there are two settler for each flocculator, and the filters are common to the settlers. The Petri net for sedimentation process is given in Fig. 17, and in Fig. 18 the behavior of the settler.

Fig. 17
figure 17

Petri net of the behavior of the settler resource

Full size image
Fig. 18
figure 18

Behavior of the flow in Mixer, Flocculator 1, settler for the turbidity level of the input water

Full size image

Deploying the Holon over the IT/OT technology.

The bottom layers of the HPU and the OT

The set of possible configurations results from the combination of the Product Model with the collection of resources that provide the services specified in the Product Model.

Conf = PM × Res available


where Resavailable ⊆ Res

The information about Resi is obtained in PIM and the Digital Twin of Resi. In this case possible configurations are:

$$ \left( {C - Fl_{1} - S_{1} - Fi_{1} - D} \right), $$
$$ \left( {C - Fl_{1} - S_{2} - Fi_{1} - D} \right), $$
$$ (C - Fl_{1} - \{ S_{1} ||S_{2} \} - Fi_{1} - D), $$
$$ (C - \{ Fl_{1} - \{ S_{1} ||S_{2} \} ||Fl_{2} - \{ S_{3} ||S_{4} \} \} - \{ Fi_{1} \left| {\left| {Fi_{2} } \right|} \right| Fi_{3} ||Fi_{4} \} - D) $$

The operation supervisor for the purification process coordinate the supervisors of sedimentation and filtering sub-stages, estimates the amount of drinking water output taking into account the quality of the raw water at the input (turbidity level), and the state of settlers and filters. The behavior of the HPU evolves according the quality of the raw water. The quantity of the raw water is determined by the water available at the reservoirs.

The global behavior of the Purification plant process is given in Fig. 19. The purification plant is a resource of the WSS system. Purification Plant has it own SCADA system, and is a smart resource for de WSS. Events that change the state of the purification plant are sent to the WSS SCADA where the same procedures are used to monitoring the global system.

Fig. 19
figure 19

Global behavior of a Purification plant process

Full size image

Evaluation and discussion of the HPU architecture

This section briefly evaluates and discusses how the characteristics of the currently installed automation and integration of the proposed HPU architecture meet the I4.0 requirements expressed in “WSS requirements established by Intelligent Manufacturing Systems for I4.0” section.

The IT-intensive WSS platforms have been named Smart Water Management (Li et al., 2020). They dif- fer from traditional water management technologies by including regulation, scheduling using real information from the WSS similar to the CPPS requirements. Establishing a criterion to measure HPU regarding the compliance of an intelligent WSS is difficult since there are no standardized CPPS metrics (Nikolakis et al., 2020). Therefore, for completeness reasons, a set of criteria has been adopted using the requirements of I4.0 (see “WSS requirements established by Intelligent Manufacturing Systems for I4.0” section), and Table 3 discusses its achievement of the classical architecture versus holonic WSS.

Table 3 Comparison of classical vs. holonic WSS architectures addressing by the I4.0 requirements (see “WSS requirements established by Intelligent Manufacturing Systems for I4.0” section)
Full size table

Advanced and intelligent WSS includes IT integration (Li et al., 2020), that is, intelligent water networks, like any data ecosystem, are hierarchical. It goes from sensors (L0), remote control and communication (L1), continues to data acquisition, supervision and visualization systems (L2), operations management, data analytics (L3) to the business management level (L4). An intelligent WSS architecture can be characterized by five layers: physical layer, detection and control layer, communication layer, data management layer, and data fusion layer. The WSS is a network of connected resources that works in different configurations to guarantee service to the population and must be resilient to changes in demand, failures, etc. (Rahmani et al., 2018).

Discussion: main activities from the HPU

An HPU, to maintain its autonomy, must possess the necessary knowledge to make decisions. This knowledge is given by the model of the physical behavior of the plant. The other elements necessary for decision making are: the state of the system, and the objective to be achieved, see Fig. 20. The knowledge of the HPU is provided at the beginning by the specialists, and it is adjusted based on the information collected from the different executions of the operation. The algorithms for calculating the outputs are part of the knowledge provided initially.

Fig. 20
figure 20

RAMI4.0 Layers’ main activities from the HPU

Full size image

The inputs to the decision-making system are:

  1. 1.

    Measurements generated in the physical systems, which may be stored or have already been processed. The current condition of the system results from process measurements that are transformed into the state of the HPU.

  2. 2.

    Production targets, which can be supplied by humans, or results from another HPU. This information will be used to determine the internal objectives to be met by the unit, the definition of procedures, the parameterization of controllers, etc.

  3. 3.

    The rules of cooperation, which can be considered as knowledge, that specify the forms of interaction between different HPUs, and the possible connections between them.

The outputs are of two types: first, the Internal objectives that are parameters to its resources, procedures. Second, the Information about the status of the HPU, events that alter its behavior and that must be handled by other HPUs. To obtain the condition of the units, it is necessary, at least to have, with the operating condition of the inflow (obtained from the inflow model), the operating condition of the unit (it is obtained from the operative condition of the resources (equipment and infrastructure given from maintenance), the operational condition of the supplies (given by reservoirs) and the operational knowledge of the human resource.

Benefits and limitations of the HPU architecture about the existent WSS

Compared to the WSS currently in operation, the expected changes are summarized as follows:

Benefits. (1) The evaluation of the possible configurations of the systems will be carried out automatically. (2) the SH will generate the sequences of operations for the configuration changes. (3) Improvements in predictions of WSS behavior for different operating conditions.

Limitations (1) Difficulties in the construction and validation of behavior models for each functional unit that are compatible with each other. (2) Complexity in the integration with the hydraulic model for WSS’s global monitoring of operations.

Conclusion

Following the preliminary design in (Cruz S. et al., 2019), an HMS architecture is expanded for continuous processes into WSS. The HMS is based on the concept of HPU that contains three fundamental holons: RH, MH, and EH. An additional holon, called SH, similar to the ADACOR’s evolution proposed by Barbosa et al., (2015), allows the supervision and control tasks for each HPU. Under this premise, HPUs can react to an unexpected disturbance. The mechanisms of high-level cooperation, as well as the establishment of global objectives, are achieved by elements that model the physical behavior of the processes and allow maintaining a coherent operation between units. This idea is similar to that of a Digital Twin concept. HPU involves the Human in the loop concept to get specific roles -e.g., decision-making features, probably defined by humans (or supervised by humans).

In summary, a cooperation between units is achieved by establishing viable global configurations and selecting the optimal one. The formation of individual behavior models allows us to determine global behaviors through simulation. Each HPU is modeled separately, and the composition of models establishes configurations modes. These configurations ensure a stable and continuous operational state, even if the outcome is not perfectly accomplished. The article shows how the HPU architecture can meet the requirements of I4.0, limited by the Hierarchy Levels and the Layers (two RAMI4.0 axes).