Framework for Implementation of Building Automation Control Programs for Industrial Heating and Cooling Systems

Abstract

This article proposes a novel framework for the rapid implementation of automation programs in industrial heating and cooling systems. The global push for sustainability necessitates significant infrastructural transformations within these systems, which currently rely heavily on fossil fuels and are responsible for 75% of industrial final energy consumption. Our research highlights the critical role of design patterns and object-oriented programming principles to address the complex integration of additional energy converters and storage into automation programs. By leveraging design patterns, our framework encapsulates the intricacies of various components, such as actuators, sensors, and storage, within a comprehensive object-oriented model that also allows the integration of different control strategies. Qualitatively, this approach enhances the reusability, scalability, and adaptability of automation programs. Therefore, quantitatively, our framework enables a more resilient and efficient energy system. The framework is validated through its application to a complex, cross-linked industrial heating and cooling system at the ETA Research Factory of the Technical University of Darmstadt. Using the developed framework reduces implementation effort significantly due to its consistent and modular structure resulting from the reusable design patterns.

1. Introduction

The global green transformation poses major strategic challenges for energy-intensive companies. Here, thermal energy systems, which account for 75% of industrial final energy demand, largely covered by fossil fuels (72%), are of particular importance [1,2]. Resulting from strategic transformation requirements, companies must achieve ecological goals while maintaining global competitiveness. This situation is intensified by the long-term rise in energy prices as well as increased requirements on the resilience of industrial energy supply systems. This results in the integration of additional energy converters and storage to create redundancies as well as increase energy efficiency and flexibility [3]. This leads to extensive infrastructural changes in industrial heating and cooling networks, which usually extend across the entire site and neighboring districts, that already possess complex structures [4]. As the integration of additional energy converters, storage, and couplings between multiple thermal supply systems means a rising number of possible operating states, the effort to develop, implement, and maintain an energy-optimized and resilient operating strategy will also increase [5,6,7]. Comparable to the evolution of industrial manufacturing systems in the early 2000s, enabling improved agility, robustness [8] (p. 4328), scalability [9] (p. 67), and modularity [10] (p. 32) are now also the major requirements for the automation control programs of energy systems. Furthermore, as industrial companies already had to quickly respond to change in time-to-market-driven environments by adaption of their manufacturing systems [11] (p. 1918), they now must be able to adapt their energy system in a comparably flexible way. This results in the need for a simple and cost-effective (re-) design of the associated automation system [12] (p. 1076). Common implementation approaches following standards like IEC 61131-3 or IEC 61499-1 for programmable logic controllers (PLCs) result in individualized and unreusable designs, so new design approaches for automation programs are needed [13,14,15]. Currently, object-oriented design principles are used for the implementation of automation programs to address the above-mentioned problems, as they represent the physical structure of energy systems, consisting of different components and subsystems [16,17,18] As a specialty of energy systems, besides implementing local control functions (e.g., temperature control), future building automation programs must enable the implementation of supervisory control functions (e.g., converter sequencing control, energy storage control) and take them into greater account [19]. For the implementation of local control functions, a uniform class structure is suitable, as we have previously presented and successfully validated in simulation and in reality for various production and energy systems [16,20,21]. However, the implementation into a holistic automation framework, covering also supervisory control functions for multiple energy converters and storage in cross-linked heating and cooling systems has not yet been considered. To enable this in an object-oriented environment, developing and using structural as well as behavioral design patterns in a framework as reusable objects or classes that are customized to solve a general design problem in a particular context may be suitable [22]. Therefore, herein, we address the following research question:

Which design patterns are suitable for the development of a holistic automation framework that enables the rapid implementation of building control programs, considering local and supervisory control functions of industrial thermal supply systems?

To answer this question, the state of technology and research is summarized in a systematic literature review in Section 2. Based on the description of our applied methods in Section 3, we present the developed automation framework focusing on the supervisory control design patterns for converter sequencing control, control approaches for cross-linked thermal systems, state-dependent control of thermal energy storage, and the dynamic adjustment of control logic and parameters during system operation in Section 4. Next, the automation framework is validated for a real-world use case of an industrial cross-linked heating and cooling system. Finally, the feasibility of implementing the developed design patterns using a programmable logic controller as proof of the functional capability of the resulting operating strategy is demonstrated in Section 5.

2. State of Technology and Research

This section presents the state of technology and research related to frameworks and design patterns dedicated to the implementation of automation control programs. Following [22], a design pattern is a reusable solution framework used to solve a commonly occurring problem in software design. It comprises four essential elements: the pattern name, which succinctly describes the problem and facilitates communication; the problem definition, which outlines the context and conditions for applying the pattern; the solution, which provides a general template of relationships and responsibilities among components without specifying a concrete implementation; and the consequences, which detail the trade-offs, such as space, time, and flexibility, involved in applying the pattern, helping to evaluate its impact on the overall system. We regard standards and well established approaches as the state of technology and scientific publications related to the topic as the state of research. Therefore, we provide in Section 2.1 a detailed explanation of already established and partly standardized approaches. Based on a methodological literature search procedure, which is described in Section 2.2, we present related, current scientific approaches in Section 2.3. In Section 2.4, we conclude the discussion of the state of technology and research, and present our preliminary work in Section 2.5.

2.1. State of Technology

The international Electrotechnical Commission (IEC) provides with the IEC standard 61131 [14] a comprehensive rule set for the implementation of PLCs. The standard comprises general PLC system information (part 1), generic requirements and check lists (part 2), information on common programming languages (part 3), definitions of communication interfaces (part 5), functional security information (part 6), fuzzy control programming information (part 7), physical device communication information (part 9), and general guidelines for users (part 4) and programmers (part 8) [23] (pp. 15–16). The aim of IEC 61131 is to foster open, non-proprietary automation architecture approaches and provide non-binding guidelines for automation software and hardware developers and users [23] (p. 12). With increasingly complex mechatronical systems and the necessity of realizing sophisticated algorithms within the automation environment, the standard IEC 61449 [15], an object-oriented further development of IEC 61131 [14] for distributed controls, was developed [24] (p. 14). It provides a function block framework for distributed automation systems [25] (p. 670). It is based on IEC 61131 part 3, where an automation architecture for PLCs is described [8] (p. 4328). The defined function blocks represent the basic elements for code, architecture, and design pattern reuse [11] (p. 1918). As pointed out in Section 2.3, many scientific approaches use IEC 61499 as the basis for further developments on reusability and design pattern development. In addition, current automation environments increasingly enable the use of object-oriented designs [26].

2.2. Literature Search Approach

Based on [27] (p. 99), we conducted the literature search approach depicted in Figure 1. The first step is to define search field dimensions. In our case, these are control function, to focus on literature dedicated to control tasks, application, to restrict findings on specified use cases, and development, to reflect the development focus of this paper on the literature search. The second step is the keyword definition. For each search field dimension, keywords are defined. For the control function dimension, control and automation are defined as keywords. The application is restricted to the industry and building domain, resulting in the respective keywords. As we want to differentiate our approach from existing design patterns, the development is restricted to design pattern approaches, which in turn define the keyword. With the defined keywords, we searched the Web of Science Database in all literature entry fields. Therefore, we formulated a search phrase that links the keywords with exclusive AND and inclusive OR operators and generated 124 literature entries for the following search phrase.

(“control” OR “automation”) AND (“industr*” OR “building”) AND “design pattern”

Using the method according to [28] (p. 174) and [29] (pp. 238–240), we analyzed the found literature in three steps. First, the titles were checked for relevance. This resulted in 20 remaining literature entries for which, in a subsequent step, an abstract analysis took place. After the abstract analysis, 16 full paper reviews were conducted, 11 of which were classified as highly relevant.

2.3. State of Research

Following the research question, presented in Section 1, this subsection presents the current state of research based on the described literature search method. Therefore, the most relevant related research is shortly summarized.

Gotzhein et al. [30] focus on the specification and description language (SDL) for the development of communication systems. They provide a detailed explanation of the SDL pattern and portray its usability in a case study. The authors present how the application of the SDL pattern results in increased development efficiency, traceability, and transparency of requirements for the overall software development. Eventually they conclude that pattern-based software development increases the reusability potential for the development of distributed systems.

Xia et al. [31] address the topic of design patterns in automation engineering at an early stage of the development of IEC 61499. They combine the model–view–controller (MVC) framework (IEC 61499) with the holon design pattern. Holons are described as autonomous and cooperative building blocks within a manufacturing system. The combination with function blocks from the MVC framework enables an encapsulated abstraction for both complex algorithms and interface definitions for one or more devices. The authors also provide a formal description and a step-wise implementation guide, which is validated for an assembly station.

Subsequent to their already presented work ([31]), Xia et al. [11] interpreted the development of control systems as a design pattern. In this later work, they deviate from their original interpretation and described a design pattern not in the pattern schema of [22]. The authors describe five steps, which portray activities necessary to implement a control system. Based on the IEC 61499 function blocks, an exemplary implementation to a water tank level control is illustrated. The authors state that design patterns, organized in frameworks enable the reusability of architectures and components.

He et al. [32] propose a design pattern for distributed control systems (DCSs). They describe requirements for the implementation of DCSs and potential approaches for the reusability of the developed solutions. Based on the design pattern schema of [22] (p. 6), a design pattern for the event processing, named the diner–waiter pattern, is described. The naming reflects the analogy of the developed communication pattern. A client (diner) communicates with the best-suited concrete handler (waiter). By describing generic interfaces in a unified Modeling Language (UML) sequence and class diagram, the authors provide a reusable design approach.

Machado et al. [33] present a multi-level design pattern for embedded systems with a focus on real-time systems. The proposed pattern is based on the MVC framework and links different levels of management and communication in the industrial production area, such as management information systems, industrial information systems, and enterprise resource planning systems. The structure is presented in UML deployment diagrams and network topology schema. The authors provide information on the necessary soft- and hardware components, therefore enabling a broad reusability of the design pattern.

Satoshi et al. [9] state that distributed control systems (DCSs) lead to higher network traffic due to increased communication effort. This is a potential error source. To handle this, they present five design patterns to model, simulate, and implement DCSs. To model the static DCS’s structure, they present two design patterns, the device–constructor and the composite-device pattern. Devices of the DCSs can be modeled as concrete subclasses. Therefore, the complete system structure with actuators, sensors, and interfaces is apparent. Dynamic behavior of each device is represented by the statechart pattern. The definition of different methods allows the modeling of state machines with sub-states and in- and output actions. This representation allows the direct implementation of the modeled devices—the authors present an automated implementation approach (java-based). To handle events during simulation of modeled devices, the event-chain pattern is developed. This, alongside the statechart–compiler pattern, provides the basic functionalities to execute DCS simulations.

Soundararajan et al. [34] focus on benchmarking implementations for DCSs. Therefore, they provide a hybrid design pattern to implement an environment for the coupling of simulation models and the physical environment. This is based on the proxy pattern that is described by Gamma et al. and initially presented in [22] (pp. 208–210). The authors describe the development of function blocks enabling the communication between a simulation environment and their physical counterpart.

Lüder et al. [35] give a general overview of existing design patterns for distributed field control systems. They present design patterns dedicated to distributed control applications, reusability of control building blocks, and device implementation. The design patterns are applied within a specified control architecture. A step-wise implementation procedure is introduced. First, a resource-independent control application is designed. Second, the predesigned blocks are enhanced with access to communication systems and physical I/Os. The authors argue that systems can be implemented more efficiently and are more easily maintained when implemented in the described two-step procedure.

Dai et al. [8] aim to establish service oriented architecture (SOA) on PLC systems. They present a component-based design pattern that includes a high-level control layer, a service layer, a low-level control layer, and an interface layer. The application to an airport baggage handling system demonstrates the abstraction level of the described layers, e.g., “bag tracking” is located in the service layer and “redundancy” in the high-level control layer. The authors claim that an automation program implemented with their design pattern is reusable because interfaces between the different layers can be applied to a different use case. They demonstrate this by the explanation of a function block implementation according to IEC 61499.

Mei et al. [36] provide a framework for the development of automatic test systems (ATSs). As the development process of the framework is their focus, a design pattern for the implementation of components for the ATS framework is developed. This includes a pattern description following the pattern schema of [22] (p. 6) and particular class libraries to enable specific reuse of code. The presented approach is validated by the application to a multi-channel Controller Area Network (CAN) test system development procedure. The authors state that the development efficiency is increased.

Lyu et al. [37] present a self-manageable architecture modeling framework that is aligned to the IEC 61499 function block definition. The framework is based on an agent-embedded design pattern that allows the separation of control application tasks and self-manageable services. The approach is motivated by industrial cyber-physical systems (iCPSs) where a remaining problem is the integration of high-level intelligent software agents with low-level real-time control units. For this problem, the authors present a design pattern that provides classes for the representation of agents that is compatible to the IEC 61499 function block approach. The classes include methods for self-configuration, self-optimization, self-healing, and self-protection and can be reused due to the use of standardized interfaces.

2.4. Literature Search Conclusion

This subsection is dedicated to what conclusions can be drawn the literature search. First, we ascertained that the focus throughout the literature is on automation programs for manufacturing systems; we have not found any research on design patterns applied to heating and/or cooling systems, despite our own research (see Section 2.4). In addition, the description of the use cases follows a minimalist description approach, which makes the applicability and transferability of the presented design patterns difficult. Second, most of the approaches are generalized with reference to distributed systems ([8,10,11,12,31,35,36]). The mentioned requirements for distributed automation programs and their development approaches are agility [8] (p. 4328), robustness [8] (p. 4328), scalability [9] (p. 67), modularity [10] (p. 32), adaptability [12] (p. 1076), and development efficiency [36] (p. 141). These requirements can be applied to automation programs for modern industrial heating and cooling systems, confirming the relevance of the literature to this article. Third, with the exception of [37], we found no recent scientific work on our research topic. With respect to Dai et al. [8] (p. 4328), who claim that automation programs developed according to IEC 61131 and 61499 are still platform dependent, we consider our research to be highly relevant. To conclude, the presented literature affirms that design patterns, organized within a framework, are a suitable approach to addressing the requirements of automation programs for heating and cooling systems, therefore, justifying our methodological approach, which is presented in Section 3. Currently no comparable approaches exist, especially not in the domain of heating and cooling systems, affirming the necessity for our research. With a detailed elaboration on the application of our design patterns, our work adds fundamental value to the research community.

2.5. Own Preliminary Work

In addition to the results of the literature review, our own preliminary work on the development of design patterns should be mentioned here. In [38], we focused on developing an object-based design pattern tailored for industrial building automation systems. This approach centers on encapsulating system components, such as sensors, actuators, and control algorithms, into modular objects that can be flexibly integrated and reused across various applications. By organizing these objects hierarchically, we achieved a scalable structure that simplifies system management and enhances adaptability. Our design pattern also emphasizes secure, standardized communication with external systems through protocols like OPC UA, ensuring seamless interaction with optimization algorithms while maintaining safety and reliability. In [16], we presented object-oriented design patterns to develop a modular and extensible data model for energy-flexible cyber-physical production systems. We utilized encapsulation to create cohesive classes such as Actor2Point and SystemContinuous, which manage their own state and behavior, and inheritance to build complex systems from simpler base components, fostering code reuse and adaptability. Our model incorporates the Composite Pattern to manage complex systems through a hierarchical structure of machines, actors, and sensors. Additionally, the strict naming conventions and structured data models align with the Facade Pattern, offering a simplified interface for complex subsystems and ensuring a unified approach to data exchange across various components. The State Pattern is used in the model to manage different operational modes of the system, such as Standby, Ramp-up, and Working. It encapsulates the behavior for each state, allowing smooth transitions and ensuring that the system’s actions align with its current state. These design patterns collectively contribute to a robust framework that supports seamless integration and flexible management of industrial energy systems. Our paper [39] shows the usage of several design patterns to structure and enhance the automation architecture for demand response in aqueous part-cleaning machines. By applying the Encapsulation and Abstraction pattern, we organized complex machine behavior into distinct data points such as rated power and power consumption, which simplifies management and control. The Modular Design Pattern was employed to break down the system into manageable components, ensuring clear interfaces and modularity in the automation program. We also leveraged the Observer Pattern to dynamically update and react to changes in machine state and process values, facilitating real-time adjustments. The Mediator Pattern was used to streamline communication between the IT and OT layers, reducing direct dependencies and simplifying integration. Additionally, the Factory Pattern enabled the flexible creation and management of machine modules, while the Decorator Pattern allowed us to extend process control functionalities with energy control capabilities. Lastly, the Strategy Pattern guided the implementation of various demand response (DR) approaches, enabling the system to adapt and apply different optimization strategies based on the operational context. These design patterns collectively support a robust, scalable, and flexible automation architecture for energy-flexible operations. In [20], we explore the application of design pattern principles to enhance the modeling and simulation of industrial energy systems. Our approach incorporates architectural and component-based design patterns by establishing a modular library structure with standardized base classes and hierarchical packages. This design mirrors the flexibility and maintainability inherent in design patterns, facilitating the consistent integration and management of control strategies. Our library’s use of well-defined interfaces and reusable components reflects these principles, aiming to improve the scalability and robustness of modeling complex energy systems. Our work [21] presents design patterns to enhance the modularity, scalability, and maintainability of an automation architecture for implementing demand response on aqueous part-cleaning machines. By employing object-oriented design patterns, we model sensors, actuators, and systems as distinct objects, facilitating clear and efficient communication between the machine control level and the IT level. For instance, we use the Factory Pattern to create various actuator objects dynamically, and the Observer Pattern to ensure real-time updates between the system state and control algorithms. These design patterns streamline the development process and ensure that the architecture can be easily adapted to different machines and operational scales. Please note that although we have already developed design patterns for automation systems in production machinery and building automation in the preliminary work presented above, this research work has previously had a stronger application focus. Therefore, we did not use the term ’design pattern’ in that context. This paper, therefore, presents the method for creating design patterns for building automation control programs in detail, extending our previous work, and demonstrates our comprehensive approach through a practical example.

3. Methodology

In [40] (pp. 23–24), the programming paradigm of object orientation is described as an effective method to model complex, technical systems. Therefore, we use it as the methodological basis for developing our framework. It builds the counterpart to procedural programming and is characterized by class definition and instantiation [41] (pp. 381–433). When classes are instantiated, they are called objects. Classes are constituted of methods and attributes. Attributes are local variables of classes and only accessible via class specific functions, called methods. Attributes are generally only accessible via methods. This restriction is called data encapsulation. To avoid code redundancy, the concepts of inheritance and polymorphism are applied. Inheritance allows the definition of a class and object hierarchy, where methods are inherited by lower hierarchical classes (specialization) or methods are generalized in top classes (generalization). Polymorphism enables methods to be implemented differently for different objects. The elaborations on object orientation are based on Silberbauer et al. [42] (pp. 41–64). As we aim with our work at higher abstraction levels, we further apply the concepts of frameworks and design patterns. Following [22] (pp. 26–28), frameworks typically contain several design patterns and are representable in code. The integrated design patterns are smaller architectural elements, less specialized than frameworks. Gamma et al. describe a catalog of design patterns. These are categorized in terms of purpose and scope as follows:

Purpose:

• Creational: “…concern the process of object creation.” [22] (p. 10)
• Structural: “…deal with composition of classes or objects.” [22] (p. 10)
• Behavioral: “…characterize ways in which classes or objects interact and distribute responsibility.” [22] (p. 10)

Scope:

• Class: “…class patterns deal with relationships between classes and their subclasses.” [22] (p. 10)
• Object: “…object patterns deal with object relationships, which can be changed at run-time and are more dynamic.” [22] (p. 10)

In addition to these categories, description parameters are formulated. The description parameters are as follows [22] (pp. 6–7):

1.

Pattern name and classification;

2.

Intent;

3.

Also known as;

4.

Motivation;

5.

Applicability;

6.

Structure;

7.

Participants;

8.

Collaboration;

9.

Consequences;

10.

Implementation;

11.

Sample code;

12.

Known uses;

13.

Related patterns.

Categories and description parameters are our most important tool for describing our scientific approach, as they provide a consistent form of describing design patterns. This form is called pattern schema [35] (p. 157) and overcomes the fundamental critics of Lauder et al. [43] (p. 116) who state that it is a common problem of design patterns that no standard notation exists, which makes their interpretation ambiguous. Therefore, we follow precisely the described pattern schema (categories and description parameters), as shown in the list above, supported by UML 2.0 class [44] (p. 682) and sequence diagrams [44] (p. 595) as well as pseudo code. We deviate partly form a full pattern description as some description parameters cannot be defined; for example, if no similar approaches exist and, therefore, no “also known as” description is possible. Frameworks that consist of design patterns, allow the combined reuse of design and code [36] (p. 141). Therefore, design patterns refer to the software itself and the software development procedure [31] (p. 234). For the implementation of our framework, presented in Section 5, we apply a pattern-based design process. This starts with an abstract description, in our case with the application of IEC 61331 and IEC 61499, that is developed further based on the selection of patterns from a pattern pool [30] (p. 1).

4. Results: Framework for Rapid Implementation of Building Automation Control Programs

This section presents a framework for the rapid implementation of the building of automation control programs for industrial heating and cooling systems. Following Section 3, we first give a general overview of our developed framework in Section 4.1. Then, we present each design pattern in Section 4.2–Section 4.6.

4.1. Framework Overview

Unlike the pattern schema for design patterns from [22] (p. 6), no standard documentation for frameworks exists. Therefore, we derive our framework structure from a theoretical industrial heating and cooling system, presented in Figure 2. It comprises of a water–water heat pump that operates between a hot and a cold network. Each network includes a thermal storage, a pump, and valve system for the supply and consumption side. Temperature sensors provide the necessary information for the supervisory and local control strategy to control the system. The components can be generalized as actuators (pumps, control valves, heat pump, storage), sensors, which are combined to systems (e.g., combination of heat pump, control valve, pump, and temperature sensor), thermal networks (e.g., hot and cold network), and strategies (e.g., supervisory control and local control), which we declare as essential elements of every industrial heating and cooling system. In this example, the activation of whole heat pump system, consisting of heat pump, centrifugal pumps, and mixing valves, is determined by the supervisory control depending on the storage temperatures of the hot and cold network. This also defines the flow temperature, which should be maintained within the hot water network by the heat pump. This information is passed to the local control, which implements the sequence control for the components of the whole system. For this example, this means starting all ancillary units, e.g., valves and centrifugal pumps as well as controlling the flow temperature by the heat pump itself. The relation between the components is presented in Figure 3, which describes the framework in a UML package diagram as “[…] a set of cooperating classes that make up a reusable design for a specific class of software” [22] (p. 26). Concluding that, we develop design patterns for the identified components, which are presented in the following subsections. The subsection structure follows the pattern schema of [22] (p. 6), as described in Section 3.

4.2. Design Pattern ’Actuators’

The design pattern actuators derives from the AutomationBaseClasses, as we outlined in [16,20]. This pattern falls under the behavioral category, focusing on interactions among objects, see Section 3. Hence, its application is specifically related to objects. Technical components that manipulate process inputs are commonly called actuators. They normally need electrical, hydraulic, or pneumatic support energy [45] (p. 441). Following our work in [16] (p. 218), actuators can either adjust processes discretely (2 point) or continually. The design pattern actuators can be applied to all discrete and continuous actuators. In Figure 2, it is shown that a state-of-the-art heating and cooling system has several actuators. These actuators have to be the implemented to be accessed by the automation program. The abstract heating and cooling system already includes four pumps and four control valves. While different specifications may apply to each actuator, ultimately, every pump and control valve must be implemented similarly. In Figure 4, the structure of the design pattern is depicted in a UML package diagram. It consists of the classes ActuatorContinuous, which is derived from the Actuator2Point class, the ActuatorContinuous LocalControlMode class, and the SystemContinuous class, both derived from the ActuatorContinuous class, and the SystemContinuous LocalControlMode class, which is derived from the SystemContinuous class.

Following the description according to the pattern schema, the implementation follows the approach presented in Figure 5. First, whether a continuous or a discrete actuator needs to be implemented must be clarified. Next, the classes can be extended accordingly. Finally, specific methods, relevant to the actuator, can be implemented.

As our framework is implemented within the Beckhoff TwinCAT3 automation environment (see Section 5), the sample code Listing 1 is taken from the structured text implementation. The presented sample code represents the function block of a Grundfos MAGNA3 pump. The implementation follows the described structure in Figure 4. In line 1, the extension from the base class function block ActuatorContinuous takes place. The following lines instantiate the described attributes with input variables from lines 2 to 6 and output variables from lines 7 to 11. Actuator specific parameter definitions are set in lines 13 and 14. In addition to the application to the ETA Research Factory supply system presented in Section 5, the design pattern actuators is used for the energy-flexible automation of a chamber cleaning machine [21,46]. As described in Section 4.4, the design pattern actuators is related to the design pattern systems.

Listing 1. Sample code from the structured text implementation of the function block of a Grundfos MAGNA3 pump.

4.3. Design Pattern ’Sensors’

Sensors are the first element in the measurement chain and, therefore, the linking element between a process and its signal processing unit [45] (p. 413). In the context of this work, only sensors that transfer the physical measurement procedure into electrical signals are relevant. The design pattern sensors is a behavioral pattern with a scope on objects Section 3. It is a further development of the AutomationBaseClasses from [47]. To control processes, information about the current state of the process is required. Processes that are in need of a control input typically have different physical characteristics that need to be monitored. Therefore, different measurement principles have to be applied. In the context of industrial heating and cooling systems, mechanical, thermal and electrical measurands are relevant. In Figure 6, the different sensor types (electricity meter, gas meter, pressure sensor, flow sensor, heat counter, temperature sensor) are presented within a UML package diagram, presenting the structure of the design pattern sensors.

The sensor types extend from the abstract class Sensor. Depending on the measurand and its related measurement principle, different methods for the conversion, according to [45] (pp. 418–434), are defined (e.g., temperature measurement within the TemperatureSensor class requires the transformation of an electrical resistance measurement (e.g., PT100 element) into a temperature value [45] (p. 427)). The implementation procedure for sensors, following the design pattern, is depicted in Figure 7 as a UML sequence diagram.

The first step is to determine the desired measurand. The conversion calculation for obtaining the measured variable is then analyzed and checked to see whether an existing method is suitable or not. Once the method has been defined, the sensor is instantiated. Depending on the communication protocol and manufacturer of the sensor, different decoding methods must be used for the transmitted telegrams. If the decoding works, the sensor has been successfully instantiated. Considering the conversion calculations as methods allows a simplified instantiation of specific sensors with specified communication protocols. The following sample code Listing 2 presents the instantiation within the Beckhoff TwinCAT3 automation environment for a temperature sensor. In line 1, the extension from the abstract class function block Sensor takes place. Different to the actuator instantiation in Section 4.2, no input variables are defined in lines 2 and 3. In lines 4 to 6, the output variable, the desired measurand, is defined. From lines 7 to 9, decoding-relevant I/O links are defined. The instantiation of sensors according to the design pattern sensors is currently applied in the building automation of the ETA Research Factory, see Section 5. The design pattern sensors is related to the design pattern systems.

Listing 2. Sample code from the structured text implementation of the function block of a temperature sensor.

4.4. Design Pattern ’Systems’

As presented in the package diagram for the overall framework in Figure 3, the design pattern systems is directly related to the actuator and sensors design patterns and enables the transition from components to thermal networks. It comprises different specific component definitions and extends from the base class SystemContinuous, which originates from the AutomationBaseClasses from [20] (p. 3). Following the interface and structure definition, the design pattern can be characterized between structural (actuator interface to thermal network) and behavioral (method definition for system components). In Figure 8, the design pattern is represented as a UML package diagram.

The intention of the design pattern is to join related actuators and sensors in systems to enable a rapid implementation of automation sequences. Derived from the abstract heating and cooling system (Figure 2), four classes are defined. The differentiation between HeatingSystems and CoolingSystems is characteristic for industrial supply systems, and leads to the later-introduced thermal networks (see Section 4.5). It allows the implementation of systems that operate at different temperature levels. To enable the connection of networks, LinkageSystems are defined. These allow the integration of systems like heat pumps and heat exchangers or the implementation of storage systems. To integrate consumers consistent to the framework, a ConsumerSystems class is defined.

Following the energy conditions of machines, standard sequences are integrated in the SystemContinuous base class as methods, as we introduced in [16,20], according to [48] (p. 4). With operational, ram-up, working and ramp-down system-specific definitions for the control of actuators are available. For the implementation of storage systems, additional methods like SelectLocalControlMode, necessary to adapt control modes of directly integrated actuators (e.g., pumps), and SwitchMode, to allow active charging and discharging are defined. To understand the implementation procedure, Figure 9 provides a UML sequence diagram.

Given the example of the abstract heating and cooling system in Figure 2, the design pattern systems can be applied to implement the heat pump in the following way: First, the system boundaries are defined. As a linkage system, the heat pump operates in two thermal networks. Therefore, the condenser side and the evaporator side are included with their related pumps and control valves. Second, the necessary operating set points as temperature limits are defined. Third, the methods are initialized. Here, the temperature limits for the condenser and evaporator sides are declared within temperature bands. The methods define control sequences for the pumps, control valves, and the heat pump, e.g., for ramp up, first the control valve, then the pumps, and then the heat pump is run. The following sample code Listing 3 presents the implementation of a heat pump within the Beckhoff TwinCAT3 automation environment. First, the function block HeatPumpSystem extends from the function block SystemContinuous in accordance with Figure 8. In lines 2 to 5, no variable inputs or outputs are defined. In line 7, the HeatPump actuator is instantiated with the function block HeatPump. In lines 8 to 11, the discrete valves on the evaporator (SV146) and condenser (SV246) sides are instantiated. In lines 12 to 14, relevant methods for the control of the actuators, see Section 4.2, are implemented. For this specific implementation example, heat counters in lines 15 and 16 (WMZ146 and WMZ246) are instantiated, as well as a timer method in lines 17 and 18. Unlike the abstract example, no pumps are instantiated, because they are included in the heat pump actuator (line 7). Furthermore, instead of control valves, discrete valves exist. The design pattern systems is applied in the building automation of the ETA Research Factory (see Section 5) and it is related to the design pattern thermal networks.

Listing 3. Sample code from the structured text implementation of the function block of a heat pump.

4.5. Design Pattern ’Thermal Networks’

The design pattern thermal networks represents the central implementation idea of the building automation framework, first presented in [38]. As such, it is in the center of the UML package diagram, presented in Figure 3, and, therefore, connected to every design pattern defined in the framework. It aims at integrating every component of an industrial heating and cooling system in a structured, comprehensible and rapidly implementable way. Therefore, it is characterized as structural and focused on classes. The UML package diagram in Figure 10 presents the design pattern structure.

Three networks are predefined within the design pattern thermal networks. Together with the ambiance class, they extend from the abstract base class network. The related attributes are a set of localState variables and a controlAutomatic variable, which enables the switching of manual and automatic control. In Figure 11, a sequence diagram for the implementation of the design pattern is depicted.

The first step is to define and instantiate the ambient conditions of the thermal system (e.g., room temperature, outside temperature). Then, the thermal networks are defined. Here, an iteration through the complete system is necessary, unless every thermal network is defined. The instantiation of each network comprises the definition of included and predefined systems, see Section 4.4. If there is a network without a system, the definition must be adapted. Eventually, the linkage networks are defined and instantiated with their related systems. Here, no system existence check is necessary because the linkage is characterized by the system itself. The following sample code Listing 4 presents the implementation of a thermal network within the Beckhoff TwinCAT3 automation environment for the ETA Research Factory. The initial step is to extend from the function block HeatingNetworkHighTemperature from the function block Network. In lines 2 to 5, the standard attributes (controlAutomatic and ambientState) are instantiated. In lines 6 to 8, the output variable (localState) is defined. In lines 9 to 26, every system that is connected to the HeatingNetworkHighTemperature is instantiated. Here, producer systems, for example, combined heat and power units (CHP1System and CHP2System), consumer systems, for example, the central machine heating (CentralMachineHeatingSystem), and storage systems, for example, the vacuum super insulated (VSI) storage system (VSIStorageSystem) are defined. The design pattern thermal networks is used in the building automation of the ETA Research Factory (see Section 5).

Listing 4. Sample code from the structured text implementation of the function block of thermal networks.

4.6. Design Pattern Strategy

The design patterns introduced so far do not provide any possibility of actually implementing control strategies. For this purpose, the design pattern strategy is intended, implementing and extending our concept presented in [38]. It defines local and supervisory control strategies for the components within the already-declared thermal networks. Following [22] (p. 10), it is characterized as behavioral. In Figure 12a, the design pattern is represented as a class definition for a strategy controller. The attributes of the design pattern include every object that is necessary to implement supervisory and local control strategies for industrial heating and cooling systems. The ambientState provides information about the ambience of the system. Similarly, the networkState represents information about the networks. The network control attribute is the object representation of the control algorithms, implemented for each network that needs to be controlled. On a local control level, the attributes localSetParameters, localState, and localDefaultParameters are necessary and defined for each component in the network-related systems (see Section 4.4 and Section 4.5). The public attributes are definitions for control-relevant temperature values or trigger elements. As presented in Figure 12a, standard methods are already implemented in the StrategyController class. The base methods include clock usage (for time-dependent control strategies), ambience control, temperature level definition and network control functions. Based on these general attributes and methods, concrete control approaches for supervisory and local control are defined. On the supervisory control level, Figure 13a provides a method for the prioritization of converters, based on multiple temperature hystereses.

As described in Section 4.5 and depicted in the abstract heating and cooling system, presented in Figure 2, industrial heating and cooling systems include several thermal networks that operate at different temperature levels and need different controllers. Therefore, Figure 13b presents a method to logically link network controllers to enable the control of cross-linked systems.

To control active storage system, Figure 14a presents a state-dependent charging and discharging approach. By the combination of the two boolean variables bCharging and bSetStatusOn, the method allows separation of the activation status and the charging or discharging of the storage. In Figure 14b, the adjustment of the control strategy based on attributes presented in Figure 12a is presented. Here, the outside temperature sets the target temperature. In this example, an outside temperature of under 10 °C leads to a target temperature increase from 65 °C to 80 °C, representing the typical heat curve increase during season change. With the provided control methods, the supervisory and local control of an industrial heating and cooling system can be realized. The following sample code Listing 5 presents the instantiation of a strategy controller within the Beckhoff TwinCAT3 automation environment for the ETA Research Factory. It follows the implementation procedure described in Figure 12b. In lines 2 to 7, the input variables are defined. The defined states include definitions about the networks, that need to be controlled. The network control is enabled via the controls defined in lines 8 to 15. For each network and linkage system, a control attribute is defined. From line 16 on, different methods, which are described in Section 4.5, are defined.

Listing 5. Sample code from the structured text implementation of the function block of a strategy controller.

5. Application

This section applies our framework, presented in Section 4, to the ETA Research Factory at the Technical University of Darmstadt. The representativeness as a validation use case is given by the complex, cross-linked industrial thermal energy supply system of the ETA Research Factory. The automation implementation environment is a Beckhoff PLC (C6030-0070) with the programming environment TwinCAT3. In Section 5.1, the supply system is described with detailed reference to the heating and cooling networks and their converters and storage systems, as well as auxiliary equipment. The implementation of the described methods and attributes is presented in Section 5.2. In Section 5.3, we align our application use case with common validation practices for control strategies. Additionally, we provide in Appendix A a detailed schematic illustration of the controlled components with temperature hysteresis and design pattern elements.

5.1. System Description

The heating and cooling demands of the ETA Research Factory are met by three thermal supply systems operating at different temperature levels. Hot water is supplied via the Heating Network High Temperature (HNHT), whose flow temperature is 60–80 °C depending on the machines in operation. Warm water supply is carried out by the Heating Network Low Temperature (HNLT) operating at 35–45 °C flow temperature. And cooling water is supplied via the Cooling Network (CN) at approximately 15 °C. For hydraulic and temporal decoupling, all networks consist of a passive buffer storage (BS) as well as active storage (ST).

The hot water supply is ensured by two combined heat and power (CHP) plants and a condensing boiler (CB). These supply the central machine heating (CMH), the basement heating (BH), and the heat exchanger (HEX1) for heat transfer to the HNLT. Furthermore, excess waste heat from the HNLT can be transferred to a higher temperature level in the HNHT using the heat pump (HP1).

The HNLT also integrates the outer capillary tube mats of the building for energy-efficient recooling (OCTM) and a water-cooled compressor (COMP). In the winter months, the heat demand of the building is covered by the HNLT via the underfloor heating for the offices (UFH) and via the inner capillary tube mats for the shop floor (ICTM).

During the summer months, these consumers are connected to the CN so that the building is cooled. The cooling water is provided by a cooling unit (CU) and a heat pump connected to the HNLT (HP2). Central machine cooling (CMC) is also located in the CN. Figure 15 shows the described topology of the thermal energy system. In

Table 1. Supply systems and their characteristics (capacity, temperature range, and purpose) at ETA Research Factory.

System	Capacity	Temperature	Purpose	Reference
HNHT
BS	1000 L	80–60 °C	hydraulic and time decoupling	[49]
HNLT-ST	7000 L	80–60 °C	heat storage	[50]
CHP1	12 kW	85 °C	heating unit	[51]
CHP2	15 kW	85 °C	heating unit	[52]
CB	24 kW	80 °C	heating unit	[53]
BH	6 kW	75 °C	basement heating	[54]
CMH	25 kW	75 °C	central machine heating	[54]
HNHT–HNLT Linkage
HP1	13 kW	65 °C	waste heat usage (summer)	[55]
HEX1	46 kW	45 °C	low-temperature heat supply (winter)	[56]
HNLT
BS	1000 L	45–35 °C	hydraulic and time decoupling	[49]
HNLT-ST	25,000 L	45–35 °C	waste heat storage	[57]
OCTM	29 kW	38 °C	recooling unit	[54]
COMP	22 kW	60 °C	waste heat source	[58]
HNLT–CN Linkage
HP2	7 kW	45 °C	waste heat usage (summer)	[59]
UFH	20 kW	40 °C/15 °C	office heating and cooling	[54]
ICTM	40 kW	40 °C/15 °C	shop-floor heating and cooling	[54]
CN
BS	1000 L	5–20 °C	hydraulic and time decoupling	[49]
CN-ST	25,000 L	5–20 °C	cold storage	[60]
CU	40 kW	15–20 °C	cooling unit	[61]
CMC	10 kW	15 °C	central machine cooling	[54]

the related supply systems and their characteristics are presented.

5.2. Experimental Investigations

To validate the framework, the automation program of the thermal energy supply systems of the ETA Research Factory was implemented by the application of the presented design patterns. At this time, the implementation has been in operation for one year and we present the detailed system behavior for an exemplary production day in the following paragraphs. To that end, Figure 16 visualizes heat flow rates of all systems as well as storage temperatures from 9 a.m. to 4 p.m. on 9 April 2024.

Due to the moderate ambient temperatures in April 2024, only a low building heat demand occurs (see UFH/ICTM). The main heat demand results from the cleaning machine supplied by the CMH within the HNHT. In addition, there is approximately 6 kW waste heat from the compressor within the HNLT and a cooling load is simulated by mixing the HNLT and CN buffer storage. Because of the moderate ambient temperatures, the supervisory control logic prioritizes CHP1 over CHP2, since CHP1 has a lower nominal power and it may run with higher efficiency than CHP2 in times of lower heat demands. However, as the heat generation is not sufficient for supplying the cleaning machine, CHP2 and the condensing boiler are also switched on. After heating up the cleaning machine, only steady-state heat demand must be covered, so the temperature within the HNHT buffer storage rises and one CHP is switched off. To reduce load cycles and run systems at their best point, the additional storage within the HNHT is loaded by CHP2 and the condensing boiler. Mixing HNLT and CN buffer storage to simulate a simultaneous heating and cooling demand, leads to prioritization of HP2 over the cooling unit (CU). However, as the cooling demands in the CN cannot be covered by the HP2 alone, the CU is also switched on. Analyzing the system behavior and the storage temperatures shows that the developed design patterns not only enable a rapid and structured implementation process but also ensure that the allowed temperature limits are permanently adhered to. Furthermore, the energy-optimized system operation is achieved by prioritizing heat pumps and running combined heat and power units within their best point. The complete implementation of the automation program as well as the underlying base classes can be found in our GitHub repositories [47,62].

5.3. Validation Remarks

The goal of the experimental investigation is to show the effectiveness and applicability of the presented framework in the implementation of automation programs including control strategies for complex industrial heating and cooling systems. The implemented control strategy is developed based on expert knowledge and application experience. As the automation program has been in operation for one year, software and operational robustness as well as prioritization-related efficiency improvements can be claimed. Although the control strategy has yet to be benchmarked against any optimal control strategy, the described use case provides valuable insights into the real-world applicability of the developed framework and its design patterns.

6. Conclusions

In this article, we present and validate a framework for the rapid implementation of building automation programs for industrial heating and cooling systems. The key element of the proposed framework is the use of object-oriented programming principles and design patterns for the main components of industrial supply systems. This approach enhances reusability, scalability, and adaptability of automation programs, and accelerates the development process by reducing the individualized programming effort to prioritization tasks and use case-specific logic adaptions.

The effectiveness of this framework is demonstrated through its application to a complex, cross-linked, industrial heating and cooling system at the ETA Research Factory of the Technical University of Darmstadt. Due to the lack of existing approaches, frameworks or use case-specific guidelines, our framework provides unique functionalities for the implementation of complex automation programs. The experimental investigation details how the design pattern methods work and demonstrate the rapid deployment as well as reduction in implementation effort, while still ensuring robust system performance and energy efficient operation. Our framework does not inherently generate optimal control strategies, so the implemented automation program for the ETA Research Factory is not optimal and needs further development. However, the implementation effectiveness has been proved and a reusable automation framework is validly made available. Given that, this research contributes to the field of industrial heating and cooling system automation by demonstrating how object-oriented programming and design patterns can be used to accelerate the implementation process.

Future work should consider enhancing the framework with features for cross-industrial integration of automation programs. This would enable the combined automation of production processes with their related energy systems.