Automated PLC Code Generation for the Implementation of Mode-Based Control Algorithms in Buildings

Abstract

Faulty programming of control functions in Building Automation and Control Systems (BACS) might result in inefficient building operations. To reduce programming errors, an automated implementation process of control functions might be a promising solution. Recently, Building Information Modeling (BIM) contributes to digitizing building construction projects but is rarely used in the planning and implementation of control functions in BACS. The control description in BIM also remains unclear. Regarding these problems, a control documentation method for BIM and an automated control implementation approach can simplify control implementation in BACS and hence improve the building operation. In the previous work, we developed the MODI method for a structured planning process of mode-based control algorithms for building energy systems. This method showed the potential to support digitized control planning and implementation in BACS. Based on this, in this paper, we introduce a documentation method to report mode-based control algorithms in the industrial foundation class (IFC), enabling data sharing among BIM, and a software-assisted approach to automatically generate PLC codes for implementing these algorithms. The case study demonstrates the documentation of a desired mode-based control strategy for an energy supply network in IFC and the implementation of this strategy in a PLC program. In the simulation phase, we test the implemented control strategy to verify the functionalities of the PLC program. The results prove that mode-based control strategies can be fully automatically implemented in a PLC program based on IFC data.

1. Introduction

The building sector accounts for 30% of total global final energy consumption and 27% of total greenhouse gas emissions [1]. To reduce the large share of energy consumption in the building sector, improvement of building energy efficiency is becoming important. However, a performance gap in buildings has been frequently encountered within the building industry [2,3]. The gap represents a mismatch between the intended and the actual measured energy performance in the context of building energy consumption and also indicates the unused efficiency potential of the building stocks [3]. As the review in Ref. [2] demonstrates, this performance gap is addressed in multiple contexts throughout the building’s lifetime, such as climate conditions and control settings. Building Automation and Controller Systems (BACS) are also key contributors to increasing energy efficiency and hence reducing this performance gap [4,5].

Recently, the impact of BACS on building operations has been discussed in several investigations, which proved that effectively designed BACS can reduce energy consumption and CO2 emissions in the building sector [5,6,7,8]. Noteworthy examples include discussions in Refs. [5,6] on knowledge management strategies to enhance BACS design, in Ref. [7] emphasizing the integration of the Internet of Things (IoT) into BACS for improved building performance, and in Ref. [8] centering on control loop testing to substantiate the impactful role of BACS in achieving energy savings. According to the study in Ref. [9], efficiently configured BACS can even save up to 30% on heating in an office building. Unfortunately, the current design and commissioning of control logic in BACS are still strongly dependent on textual descriptions, spreadsheets as well as two-dimensional drawings for information exchange and control programmers for manual programming [5,10,11,12,13]. Such low-digital documentation of control logic is unstandardized as well as ambiguous, which needs to be further interpreted and left room for various implementations. In the implementation process, code programmers encode control functions manually as specified or directly use the codes from an existing and similar project [14]. This process is inefficient and might be prone to errors [15]. Moreover, the application of the low-digital documentation method can also result in unexpected information loss across different project stages.

To change this status quo, the digitalization of control design, code programming, and commissioning is a promising method [16]. In support of this effort, we have in previous work introduced a so-called MODI-method (MODI) enabling a systematic development process of mode-based control algorithms for building energy systems [17,18,19]. Mode-based control algorithms depend on operating modes and transitions of these modes to organize system operation. An operating mode specifies system behaviors by identifying the operation of all components within a system. Transitions activate translations from one operating mode to another and finally determine the currently used operating mode. The application of Signal-interpreted Petri nets (SIPN) as the formalized description method in this method ensures the description of the control algorithms without ambiguities and misunderstanding and hence avoids errors in the implementation process [18,19]. Based on this, we have developed a software-assisted framework to implement mode-based control algorithms in Programmable Logic Controllers (PLC) by automatically generating PLC code in the programming language Structured Text (ST) [20]. The developed software gathers configuration information about mode-based control algorithms through a Graphical User Interface (GUI) and then generates a corresponding PLC program. Nevertheless, the software developed in the previous work requires manual input of configuration information, which can be both cumbersome and error-prone. This challenge can be effectively addressed by enabling the software to directly interpret mode-based control algorithms from a digital data source, such as Industry Foundation Classes (IFC), rather than relying on a GUI. Therefore, in this study, we introduce a novel methodology for documenting mode-based control algorithms within IFC format and subsequently automating their implementation in PLCs through the generation of PLC code.

IFC is an open data schema and promotes data exporting and data sharing among the Building Information Modeling (BIM) tools [21]. BIM represents building physical and functional characteristics in a digital format and hence has been widely used in the Architecture, Engineering, Construction, and Operations sector (AECO) [22,23,24,25]. BIM supports data exchange and information interoperability across the whole life cycle of buildings [26]. Typical BIM planning tools, such as Revit [27] and ArchiCAD [28], apply individual proprietary data formats for their internal data storage [5]. IFC is standardized as ISO 16739 [29] and supports these BIM tools’ interoperability by sharing BIM data among these tools [21]. In IFC, a set of generic building objects is defined as corresponding IFC elements with associated properties and attributes, which can be instantiated and applied for specific use cases. Therefore, IFC-based BIM data are capable of providing a standardized digital data source and enable data exchange for building control functions across design, commission, and even operation phases [30]. However, descriptions of control functions in the current BIM software and IFC are limited [29]. Compared to other building systems, the design of BACS is not considered in the design-built BIM cycle but is normally merged into the later stage, i.e., facility management [23]. Thus, BIM tools and IFC are seldom used to exchange BACS information [23,31,32]. Moreover, methods enabling descriptions of control functions in IFC remain unclear [29]. A formalized description method of building control functions might be beneficial for the digitization of the control function design and implementation in BIM [29,33,34,35].

To tackle this issue, we investigate in this paper a new description method to describe mode-based control algorithms in IFC format and then interface IFC with the developed software to automatically generate PLC code for implementing mode-based control algorithms. In this way, a hierarchical structure is constructed based on the IFC schema for data representations. The IFC files containing control algorithms can be imported into the software to generate corresponding ST code and implement this code in a PLC program of BACS. The paper is structured as follows: Section 2 introduces the methodology to document the mode-based control algorithm in IFC and details the automated generation process of PLC code. Section 3 presents a use case and discusses the results. Section 4 concludes the primary outcomes and next steps.

State of the Art

BACS are responsible for monitoring and controlling the building environment and building security, such as fire, lightning, and air conditioning [36,37,38]. Two control levels are identified in BACS: one is process control, which is performed by continuous and linear controllers, such as PID controllers, and the other is building automation, which performs discrete control strategies by using textual or graphical programming tools. Depending on the complexity of the control functions, two main types of controllers applied in BACS are recognized as programmable logic controllers (PLC) and Direct Digital Controllers (DDC) [37,38,39]. Due to the robustness and easy set-up of PLCs, PLC-based automation systems are frequently preferred in BACS designs [40]. IEC 61131-3 [41] standardizes the basic software architecture and executable programming languages for PLCs. This standard has been extended by object-oriented components in recent years [42]. The programming language supported by IEC 61131-3 includes two textual programming languages, namely structured text and instruction list, and three graphical programming languages, i.e., ladder diagram, function block diagram, and sequential function chart.

In various industries, PLC programs have historically been relatively straightforward. However, in recent years, there has been a growing demand for intricate, sophisticated, and modular PLC programs. The motivation to reduce manual effort in PLC programming promotes several works presenting methods for automated PLC code generation, especially in the manufacturing and production domain [43,44,45,46,47,48,49,50,51]. In principle, code generation is an implementation of the source code in the concrete syntax of the target code, which matches the semantics of the source code [47,52]. As Daniel Darvas et al. demonstrate [51], code generation can be achieved based on formal methods. Thus, in their work, a formal specification language PLCspecif is introduced and a corresponding code generator is developed. The target code is ST. However, formal methods and code generation are not widely applied in practice [52,53,54]. One reason might be that the PLC practitioners usually have a technical background and limited software engineering knowledge, while the theoretical concepts of formal methods originate from computer science.

Thereby, some works choose to generate PLC code by reusing existing PLC programs and general-purpose modeling languages, such as UML and SysML. For example, Vogel-Heuser et al. [45] identify three generic approaches to PLC code generation: the template-based approach, the modular approach, and the parameter-based approach. Based on the template-based approach, function blocks of components can be translated to templates for reusability, which are stored in the code generator library and can be selected by a specified case [46,47]. A modular approach is also a typical approach to intensive reusability of PLC programs. This approach introduces a module consisting of some components, which represent a typical system in the industry, such as a plant or a complete station, and its control logic [44,50]. Fischer et al. [49] demonstrate a parameter-based concept for reusing existing PLC programs by analyzing the PLC program of storage systems as a use case, in which reusable codes and various parts are identified and the various parts allow being declared by a set of parameters. There are other works that focus on the integration of a formal method into a well-constructed engineering tool and the practice workflow. Many control vendors developed tools for automatic PLC code generation [55], such as Beckhoff TwinCAT automation interface [56], Schneider Unity Application Generator [57], and Mitsubishi Adroit Process Suite [58]. These tools provide the possibility to be integrated into a predefined workflow configured by the PLC programmers.

To the best of our knowledge, PLC code generation is not yet widely employed in the implementation of control logic within the BACS domain. This domain necessitates intricate PLC programs to manage and ensure a comfortable environment while optimizing the efficient operation of Building Energy Systems (BES). There is a clear demand for a well-defined digital workflow to enable the automatic implementation of control logic in PLCs for BACS.

In the BACS domain, to digitalize the design and implementation of control logic, various data formats besides IFC are developed for the information exchange between software tools and control logic designers.

ISO 16484-3 [29] introduced the requirements covering software and functions for BACS and provides a sample template for documentation of function blocks defined from the design, called the BACS function list. In the BACS function list, inputs as well as outputs of function blocks, parameters specifying function blocks, relevant sensor data, and their internal control logic are represented as a spreadsheet. However, the BACS function list cannot enable a formal description of control logic and a sufficient description of sophisticated and non-standard control functions.

The OpenBuildingControl project [14] developed the Controls Description Language (CDL) to exchange the specified control logic for Heating Ventilation and Air Conditioning (HVAC). The CDL is based on the modeling language Modelica dealing not with knowledge representation but with component-oriented modeling and simulation of complex systems [59]. The method developed in the OpenBuildingControl project is solely limited to being used in HVAC and failed to represent hierarchical control logic. The possibility of translating Control Description Language (CDL) to IEC 61131-3-supported programming languages is acknowledged but has not been attempted yet. Ontology-based modeling approaches for the descriptions of control logic in BACS are also frequently encountered in many works.

The investigations trying to apply IFC to describe control logic in BACS are limited. In the work of Chen et al. [60], Building Control Knowledge is defined as knowledge about the control logic as well as algorithms, control structure, and functionalities of technical equipment in buildings. A database schema M-BCK [61] is utilized to exchange the control knowledge. The authors of this work [60] mean that control logic and its representation in programming languages generally depend on the manufacturers and are often represented in various formats and programming languages. Thus, this work only provides a data schema to represent generic building control knowledge without considering the implementation of the control modules reported in the data schema. A potential to integrate the M-BCK into the IFC schema is mentioned in the work, however, the discussion is limited. Benndorf et al. [62] constitute an effort in extending the IFC schema to describe some typical control logic in HVAC, such as controlling by heating curves, time schedules, and PID controllers. Based on this method, the IFC schema can contain information on buildings, their technical systems, and the corresponding control functions. However, this documentation method cannot fully flexibly describe specified control functions but only predefined control logic in the IFC schema. These works [11,63,64] indicate the lack of formal semantics of IFC and emphasize the advantages of a logic-based language in control knowledge representation. Based on this, the conversion from the EXPRESS schema specification representing the IFC schema to an ontology language is discussed in several works [5,10,11,65,66,67].

While existing methods enhance building operation, a critical void exists in terms of a workflow to automatically implement the control functions described in these formats, hindering the efficient implementation of control functions.

2. Methodology

To support implementing control logic in BACS, this work leverages the IFC schema to represent mode-based control algorithms and introduces an automated implementation approach for mode-based control algorithms in PLCs. Figure 1 shows the workflow of the developed methodology. The first part of the methodology is to document mode-based control algorithms in the IFC schema by developing a hierarchical subset in the IFC schema so that the information of the control algorithms can be digitized and shared throughout various project stages. This part is implemented in Python and applies IfcOpenshell to process the IFC data [68]. The second part is about the implementation of the mode-based control algorithms in a PLC by translating the IFC data into JavaScript Object Notation (JSON) and then generating the corresponding PLC programs in the programming phase. This part is implemented in the .Net framework, in which JSON data can be processed more feasibly than IFC data. Section 2.1 focuses on translating SIPN-described mode-based control algorithms to the IFC schema. Section 2.2 introduces the method to automatically generate PLC code for implementing IFC-described control algorithms in the PLC program.

2.1. Documentation of Mode-Based Control Algorithms in the IFC Schema

To describe mode-based control algorithms in the IFC schema, we develop a prototype based on the IFC schema, which considers the following issues:

• Describe the hierarchical control structure of mode-based control algorithms in the IFC schema.
• Describe the SIPN-described control logic of mode-based control algorithms at each level in the IFC schema.
• Describe the connections between controllers and energy systems in the IFC schema.

Table 1. The used IFC entities of the IFC schema for describing mode-based control algorithms.

IFC Entities	Description
IfcController	A controller within a BACS.
IfcRealAggregates	The aggregation relationship applied to IfcObject.
IfcSimpleProperty	A generalization of a single property object, including IfcPropertySingleValue, IfcPropertyEnumeratedValue, IfcPropertyBoundedValue, IfcPropertyTableValue, IfcPropertyReferenceValue, IfcPropertyListValue.
IfcComplexProperty	Complex properties, which can be a collection of IfcProperty subtypes.
IfcRelDefinedByProperty	The relationship between objects and a property set.
IfcPropertySet	A container class holding properties within a property set.
IfcActor	An actor within a BACS.
IfcSensor	A sensor within a BACS.
IfcDistributionPort	A specialized interface for distribution elements.
IfcRelNests	The nesting relationship for the general composition or decomposition relationship.
IfcRelConnectPorts	The connection relationship between two ports.

summarizes the used IFC entities in the IFC schema for the documentation method [69].

2.1.1. Hierarchical Control Structure in the IFC Schema

As MODI [18] demonstrates, an energy system can be decomposed into a multi-level hierarchical structure at the beginning of the control design process. As Figure 2a illustrates, this hierarchical structure consists of the network level, subsystem level, component level, and actuator level. Operating modes, which describe specific system behaviors, will be identified at each level. Sequentially, a corresponding mode-based control strategy will be established by choosing the used operating modes and defining the corresponding mode-switching conditions. We apply the SIPN-based modeling approach [19] for modeling and performing control logic based on the mode-switching process in SIPNs (Figure 2b). Each operating mode is converted to a place of SIPNs, while mode-switching conditions are implemented in transitions of SIPNs. By satisfying a mode-switching condition, the corresponding transition of a SIPN will be fired and a token can be transferred from the upstream place to the downstream place of the SIPN. Containing a token, the downstream place will be activated to perform the corresponding operating mode, which is implemented as an output function of the place.

Based on the hierarchical structure of mode-based control algorithms, the prototype can encode such a hierarchical SIPN structure in the IFC schema. Figure 2c presents a map from the SIPNs at the network and the subsystem level to the IfcController entities in the IFC schema. Each SIPN is mapped as IfcController, and the representation of the hierarchical SIPNs is enabled through IfcRealAggregates to bridge these IfcController entities. IfcRelAggregates is specified with two attributes as “RelatingObjects” and “RelatedObjects”, in which the IfcController entities at a higher level are defined as RelatingObjects and the IfcController entities at a lower level as RelatedObjects in this relationship.

2.1.2. SIPN-Described Control Logic in the IFC Schema

Based on the hierarchical structure, we begin to convert SIPNs to IfcController objects. A SIPN can be implemented with a newly defined and objectified property set assigned to the IfcController through the relationship IfcRelDefinedByProperties. As Figure 3 shows, the property set contains two types of properties, i.e., IfcSimpleProperty and IfcComplexProperty. IfcSimpleProperty is a single property object, which contains various subtypes, such as IfcPropertySingleValue, IfcPropertyEnumeratedValue, and IfcPropertyListValue. In our case, we use IfcPropertySingleValue to report some auxiliary information, such as the minimal time between twice mode-switching of the SIPNs. Compared to IfPropertySingleValue, IfcComplexProperty allows a mixed collection of IfcProperty subtypes as well as being included as a single property entry in an IfcPropertySet. We use IfcComplexProperty to document the main information of SIPNs.

The basic elements of a SIPN are places, transitions, and output functions. To convert these elements in the IFC schema, we define four IfcPropertyEnumerationValue objects to enumerate all permissible operating modes, transition conditions, relevant state variables, and output functions in

Table 2. The one-to-one correspondence from signal-interpreted Petri net elements to IfcPropertyEnumerationValue objects in the IFC schema. SIPN: signal-interpreted Petri net.

SIPN	IfcPropertyEnumerationValue	Description
Places	Operating modes	Listing all permissible operating modes
Transition conditions	State variables	Listing all relevant state variables
	Transition conditions	Listing all possible mode-switching conditions
Output functions	Output	Listing system behaviors by activating operating modes

. These IfcPropertyEnumeration objects are regarded as containers, from which we can select enumeration values to achieve a place-transition-place pattern describing a transition from one place to another place. The IFC entity IfcPropertyListValue is utilized to implement such a pattern. An IfcPropertyListValue object has three assigned values that can be instantiated to list the first place, the transition condition, and the second place of a place-transition-place pattern. The output function of this pattern defines the system behavior by activating the second place, which is encoded by a series of “0” and “1” representing the operating modes “Off” and “On”, respectively. The IfcPropertyEnumeration instance “Output” is assigned to label these codes.

For example, as Figure 4 shows, to implement a place-transition-place pattern $P_1\to T_{12}\to P_2$, we instantiate the IfcPropertyListValue object by selecting two operating modes as $P_1$ and $P_2$ from the IfcPropertyEnumerationValue entity “Operating modes” and a transition condition $T_{12}$ from the IfcPropertyEnumerationValue entity “Transition conditions”, respectively. The output of this IfcPropertyListValue instance “Transition” is a group of “0” and “1” labeled by the IfcPropertyEnumeration entity “Output” to point out the system behavior of $P_2$. This prototype can also be used to report other information, for example, the hydraulic circuit types are enumerated in an IfcPropertyEnumeration instance, and an IfcPropertyListValue instance specifies the constructed hydraulic circuits of an energy system from the IfcPropertyEnumeration instance.

2.1.3. Bridging Controllers and Physical Systems in the IFC Schema

To perform a control process, the controller needs to gather information from the relevant sensors and run actuators to perform the control logic. All relevant sensors and actuators can also be documented in the IFC schema, as Figure 5 shows. An IfcController entity is associated with an IfcSensor entity and an IfcActuator entity through the IFC nesting relationship IfcRelNests and the IFC distribution port IfcDistributionPort. IfcRelNests is used to nest ordered collections of elements with the two attributes RelatingObject and RelatedObjects. The applicable targets can be non-physical subtypes, such as controller and process, or physical subtypes, namely elements having ports. IfcDistributionPort represents distribution ports that can be assigned with IFC elements by IfcRelNests. These distribution ports are regarded as interfaces to indicate the role of the elements in a particular system, such as a water inlet or a data output. The attribute FlowDirektion identifies the flow direction as a Sink (inlet) and a Source (outlet). In our case, the used IFC entities (IfcController, IfcSensor, and IfcActuator) contain distribution ports defined by IfcDistributionPort to indicate the sensor data flow from IfcSensor entities to IfcController entities and the command from IfcController entities to IfcActuator entities.

2.2. Automated Implementation of IFC-Based Mode-Based Control Algorithms in PLC

To automatically implement mode-based control algorithms in PLCs, we primarily develop a methodology to convert the IFC-described mode-based control algorithms into ST code segments and then implement this methodology in the .Net framework to achieve a software-assisted automated implementation process of mode-based control algorithms in PLCs.

2.2.1. Implementation of IFC-based mode-based control algorithms in ST

The main issues of the implementation of IFC-described mode-based control algorithms in ST are shown below:

• Mapping hierarchically structured mode-based control algorithms expressed by the IFC schema to corresponding hierarchical PLC programs
• One-to-one correspondence of the IFC properties to the ST code segments

Previous work [20] has demonstrated a hierarchical framework of program organization units (POUs) enabling the implementation of mode-based control algorithms in PLC. Based on this, we only need to map the IFC-described mode-based control algorithms to the PLC program (PRG) framework. In PLC programming, there are three types of POUs defined by the IEC 61131-3 standard [41,42], i.e., PRGs, function blocks (FBs), and functions. In this work, we implement mode-based control algorithms represented by the networked IfcController entities in a PRG, as Figure 6 illustrates. The hierarchical structure of these IfcController entities will be recognized through the relationship IfcRelAggregates and mapped to FBs in the POU framework. The inputs and outputs of each IfcController entity, which describe the data exchange among different levels, are converted to the global variables and the public properties in the PRG.

Furthermore, we develop object-oriented standard FBs to implement the control logic of mode-based control algorithms in their hierarchical structure. Their hierarchical structure consists of the network level, the subsystem level, the component level, and the actuator level. At the network level, the FB object for networks is illustrated in Figure 7. This FB contains three mainly used methods, Auto, Off, and Run, as well as several public properties. Run is the key method, which will ask for the activated method and then run it. Off is defined to directly stop the network, while Auto implements mode transitions and determines the used operating mode at the network level. The output function of the determined operating mode at the network level will decide the used method at the subsystem level. As an interface, the property Mode presents the currently used method of this FB. Other public properties of this FB can be flexibly parameterized by instantiating this object-oriented FB, in which all the transition-relevant state variables are defined as properties to enable external reading of these variables from sensors.

The structure of the FB object for subsystems is similar to the object FB at the network level. Based on this FB structure, we further use programming languages supported by IEC 61131-3 to implement control logic documented by the IfcController entities in PLC.

The implementation of the control logic of mode-based control algorithms in PLCs can be achieved by mapping the properties of IfcController entities into this program framework. As Figure 8 illustrates, the core properties to describe the control process are a set of the IfcPropertyListValue instances, the IfcPropertyEnumeration “Operating modes”, and “Output” assigned to each IfcController. The IfcPropertyListValue instances implement control rules to determine the used operating modes. The IfcPropertyEnumeration “Operating modes” contains all used operating modes, which can be decoded by the IfcPropertyEnumeration “Output”. Since the one-to-one correspondence is capable of reinterpreting generated code, we use this principle in the following to translate the properties of IfcController entities into the program framework.

$\mathbf{IfcPropertyEnumerationValue}\mathbf{object} “\mathbf{Operating}\mathbf{modes}”$ The instances of the IfcPropertyEnumerationValue object “Operating modes” are mapped to the enumeration variables in ST to present operating modes of all levels that can be used.

$\mathbf{IfcPropertyListValue}\mathbf{object} “\mathbf{Transition}”$ The instances of the IfcPropertyListValue object “Transition” are implemented in IF statements of ST to help determine the used operating mode. As Figure 4 depicts, the first place and the transition of a “Transition” instance are converted to the conjunctive conditions of the corresponding IF statement. The second place is regarded as the consequence to define the enumeration variable showing the used operating mode.

$\mathbf{IfcPropertyEnumerationValue}\mathbf{object} “\mathbf{Output}”$ The instances of the IfcPropertyEnumerationValue object “Output” and “Operating modes” provide the corresponding system behaviors, which are implemented in the consequences of IF statements to derive output functions while asking for operating modes in the conditions of the IF statements.

At the component level, two main types of FBs are defined, one comes from the library AixOCAT [70] to provide control for the four typical hydraulic circuits (mixing circuit, throttling circuit, diverting circuit, and injection circuit). The other uses the embedded control of components by calling the predefined data points in BACnet (Building Automation and Control Networks). Many components in markets integrate control modes into their control modules and provide several data points for users to activate these modes by interfacing with their communication modules. Different communication protocols are applied by these communication modules in practice, such as BACnet or Modbus. In our work, we develop an object-oriented FB, which enables communication with components in BACnet by setting components as BACnet clients and calling the predefined BACnet ID of integrated functionalities.

2.2.2. Software-Assisted Generation of ST to Implement IFC-Based Mode-Based Control Algorithms in PLC

In this section, we develop a software-assisted approach in the .Net framework to import IFC data as the data source, translate IFC data to JSON data, and then automatically generate ST codes as well as implement them in PLC programs. The Beckhoff-distributed software TwinCAT (Windows Control and Automation Technology) and the TwinCAT Automation Interface are used to generate and configure PLC programs [56]. TwinCAT allows the IEC 61131-3-defined object-oriented programming languages to program PLC projects. The TwinCAT Automation Interface bridges PLC projects in TwinCAT and external environments based on COM-capable programming languages, such as .NET or C++, for creating and handling the projects in external environments. In this way, we can program manuscripts to directly generate and configure PLC projects in TwinCAT instead of manual programming.

Figure 9 illustrates the software framework. As the front end, a GUI is programmed to import IFC files and gather some supplementary parameters for configuring PLC projects. The backend program is developed based on the .NET framework and is capable of interfacing with the TwinCAT Automation Interface. In the backend program, the IFC files will be converted primarily to JavaScript Object Notation (JSON) serialization. In our case, we use IfcOpenshell to read and process IFC data [20,68]. IfcOpenshell is an open-source library to work with the IFC data in multiple programming languages, such as Python and C++. However, IfcOpenshell cannot support the .NET framework. Therefore, we need to read the IFC data by using a Python script and transform the necessary configuration information into JSON files, which facilitates the information processing in the .NET framework. A POU list containing the configuration information about the POUs will be generated by reading the JSON files. We call a loop through the POU list to select the desired POU template and instantiate a corresponding POU object by integrating the configuration information at each iterable. These generated POU instances will be implemented in the desired PLC project.

As Figure 10 shows, the workflow of the backend program starts with converting an IFC file to a JSON file, importing as well as translating the JSON file to a POU list, processing the POU list to call POU templates in a database, iteratively showing them in a GUI, and finally configuring the POUs in a PLC project in TwinCAT.

JSON is an open file standard, which represents attribute–value pairs and arrays in texts as its syntax. Therefore, this standard is simple for computers to parse as well as generate and for humans to read. Afsari et al. have discussed the implementation of the IFC standard as a JSON schema, but the description of control algorithms in IFC is rarely considered [21]. Therefore, we need a new approach to translate mode-based control algorithms described in the IFC schema to the JSON schema. The approach is illustrated in Figure 11. The configuration information and the properties of an IfcController instance will be translated into the attribute–value pairs of JSON. For example, the attribute “Name” of the IfcController instance in Figure 11 will be mapped to the corresponding attribute–value pair [“Name”:Name] of JSON. The hierarchy of this IfcController instance in the IFC schema is enabled through the definition of the JSON attribute “Type”. Therefore, there are four predefined values of “Type”, namely “Network”, “Subsystem”, “Component”, and “Actuator” representing the controllers at the network level, subsystem level, component level, and actuator level, respectively.

The property set assigned to the IfcController instance is also converted to the attribute–value pairs. For example, the IfcPropertyListValue “Transition” of an IfcController instance is mapped into an attribute–value array named “Transition” in the JSON schema, as Figure 12 shows. The “Transition 1” is mapped into the first array in the JSON schema, while the “Transition n” is into the $n^{th}$ array.

Subsequently, the configuration information in the JSON schema needs to be translated into a POU list, which is an interface of the POU generation program. According to the JSON attribution “Type”, a corresponding template type is called and a parameter list for this template is declared. There are various template types, such as the template for network controllers, subsystem controllers, and hydraulic circuits. For each template type, a parameter list is developed and its list item is also defined in a predefined order, which supports grasping the necessary configuration information for the template. Figure 13 presents an example of mapping the configuration information of controllers in the JSON schema into a POU list. The JSON element “Network 1” in Figure 13 is mapped to the POU list as the list item “POU 1”, which is tagged as the template type “Network Controller”. The necessary configuration information for this template will be taken from the JSON schema to the “POU 1” sublists following a predefined order.

The work in Ref. [20] has proved that a template-based approach can generate ST code by calling templates of POU objects and then parameterizing these objects. The corresponding parameters were imported manually through a GUI. For this process, the library AixOCAT [70] provides several FBs of typical control functions for BACS, such as PID controllers and controllers for the typical hydraulic circuits. Based on this, the backend program is developed in this work to call POU templates in a template database iteratively through the POU list generated from a JSON schema. Instead of reading parameters from the GUI and hand triggering the generation program, the necessary parameters are obtained from the POU list. During the loop throughout the POU list, the desired POU at each iteration can be represented in the GUI with the imported parameters. The backend program allows checking POUs, completing missing information, and generation triggering for the next iteration through the GUI. After looping through the list, all generated POU instances in this list can be configured in the desired PLC project by using the TwinCAT Automation Interface.

3. Use Case

In this section, we use the developed methodology to document a mode-based control strategy for an energy system in IFC data and then automatically implement this strategy in a PLC program. Section 3.1 presents the development and documentation process of a mode-based control strategy for the desired energy system. The IFC data, which hold the control strategy, will be imported into the software to generate the corresponding PLC program in Section 3.2. We test the generated PLC program in a simulation to verify the planned control functionalities in Section 3.3 and discuss the results afterward in Section 3.4.

3.1. Documentation of a Mode-Based Control Strategy for the Desired Energy System

Figure 14 illustrates the system scheme and hierarchical structure of an energy supply system consisting of a heat pump, heat storage, a boiler, and an energy consumer. The heat storage and the boiler satisfy the heat demands, while the heat pump supplies warm water to the heat storage. An air-to-water heat exchanger is regarded as the energy consumer, in which the supplied warm water can heat the supplied air in the air duct. Based on this system scheme, we decompose this system into a hierarchical structure, as the MODI method demonstrates. This energy system is regarded as a heat supply network (HSN) at the network level, which can be further divided into two heat supply subsystems (HSS) at the subsystem level, namely HSS1 and HSS2. At the component level, one subsystem constitutes the heat storage and the boiler and the other only contains a heat pump. Within each component, the corresponding actuators are identified.

Based on this hierarchical structure, a hierarchical IFC schema of IfcController objects is also constructed, in which each decomposed object, such as each component, is assigned a corresponding IfcController object to record control functions within this object. The control functions of these IfcController objects are described by using the IFC properties. As Figure 15 shows, we perform a stepwise identification process of operating modes from bottom to top, i.e., from the component level to the network level, and report these operating modes as enumeration values contained in the corresponding IFC IfcPropertyEnumerationValue objects as properties of these IfcController objects.

To complete the control strategy, we need to define the mode-switching conditions of these operating modes. At the network level, the HSN consists of HSS1 and HSS2. Running HSN, HSS1 can satisfy heat demands, while HSS2 cannot directly supply heat to the consumer but charge the heat storage of HSS1. Thus, we choose Mode 0 and Mode 3 for this level and define the transition of these two operating modes depending on the demand. When the network is on (with demands), HSS1 and HSS2 will work. Otherwise, both subsystems will stop. At the subsystem level, the operation of HSS2 is determined by the output of the network level. If HSS2 runs, the storage temperature is further used to determine the operation of the heat pump within HSS2. With running HSS2, if the heat storage is empty, the heat pump will charge the heat storage. Otherwise, the heat pump will stop. In the HSS1, the heat storage prefers to supply heat if HSS1 runs and the storage is not empty. The boiler will support the heat supply only if the storage cannot discharge to cover the heat demands. At the component level, the operation of the components is determined by the used operating mode at the subsystem level.

This strategy can be encoded in the IFC schema by using the IFC-based documentation method. We use the control strategy at the network level to describe this process as an example. As Figure 16 illustrates, there are three defined IfcPropertyEnumerationValue instances “Operating modes”, “Transition conditions”, and “Output” for HSN, which contain operating modes, transition conditions, and subsystems of HSN, respectively. We chose the enumeration values of these IfcPropertyEnumerationValue instances to describe the mode-switching process and report them in IfcPropertyListValue instances. For example, Figure 16 represents a mode transition from Mode 0 to Mode 3 when the last used mode is Mode 0 and the transition condition in red is satisfied. Mode 3 with (1,1) is decoded by the IfcPropertyEnumerationValue instance “Output” to indicate that HSS1 and HSS2 will work by activating this mode. These properties are related to the IfcController of HSN by using the relationship IfcRelDefinedByProperties. Hence, the desired mode-switching conditions of the network level for this energy system are reported in the IFC schema based on the IfcController of HSN and its related properties.

In this planning process of control functions, the sensor data of the supply air temperature are used to determine if there is a demand. The temperature sensor, which provides the supply air temperature, is defined as an IfcSensor instance and associated with the state variable in the IfcPropertyEnumerationValue instances “State variables” of HSN. As Figure 17 illustrates, IfcController “HSN” is defined by IfcPropertyEnumerationValue instance “State variables” containing the state variable relevant to the transition conditions and presents a relationship with a sensor by IfcRelNets, IfcDistributionPort, and IfcRelConnectPorts. For a simplified visualization, we omit the relationship between IfcRelNests and IfcSensor in Figure 17.

Based on the documentation process, the designed mode-based control strategy is documented in an IFC file and will be processed in the next implementation process.

3.2. Implementation of a Mode-Based Control Strategy by Generating PLC Code for the Desired Energy System

The generated IFC file from Section 3.1 is imported into the developed software through the GUI. As Figure 18 illustrates, the hierarchical IFC schema of IfcController instances is mapped into the corresponding PLC program. For each IfcController, a corresponding function block is generated. The outputs of these function blocks can directly write the properties of other control functions or be associated with the corresponding global variables (GVLs), which can be called by the other function blocks. For example, the outputs of the function block FB_HSN are the currently activated operating mode of HSN, which is associated with the global variable “GVL.HSNModiMode”. The output function of this mode impacts the subsystem level by writing the public properties “Mode” of the FBs of HSS1 and HSS2 (see Figure 18).

For the generated FBs in Figure 18, the predefined object-oriented templates configure the structures of these FBs and the documented IFC property sets are translated into ST code segments implemented in these FBs. For example, at the network level, an FB for HSN is generated based on the network template, as Figure 19 illustrates. Auto implements the control logic to determine the currently used operating mode, while Off stops the whole network. The FB also implements the relevant state variable, Demand, as a property, provides an external bridge to read and write these variables. By running this FB, if Demand is true, Auto will be called to perform the desired control function at this level and written in the property Mode. Demand can be set from the external sensor and system module to determine which operating mode will be used at this level. For example, if Demand is true, M3 will be activated at the network level. Correspondingly, the output function converts this result to the FBs of HSS1 and HSS2 by writing their properties Mode (see Figure 19). At the subsystem level, the generated FBs are similar to those at the network level.

At the component level, an FB for controlling the throttling circuit is utilized by reading the circuit type in IFC for HD. This FB is parameterized through the GUI, in which the set supply temperature is 19 °C and a PID-controller is parameterized to control the valve opening to ensure the supply air temperature. For the pump of this circuit, we choose a Grundfos pump with the communication interface module CIM/CIU 300 supporting BACnet MS/TP [71] for this use case and define an FB of BACnet client to implement the pump control. In the datasheet, the communication interface module enables a multistate output (MO) object to set the control mode for the pump and analog output (AO) for the setpoint (see

Table 3. Multi-output object to set the control mode for the desired pump equipped with the communication interface module CIM/CIU 300 [71].

Object Type	ID	Name	Description
Multistate output (MO)	0	Set controlmode	1: Constant speed
			2: Constant pressure
			3: Proportional pressure
			…
Analog output (AO)	0	Set setpoint	Sets the pump setpoint.

). Several control modes of the pump are available by activating the MO with the corresponding signal. As Figure 20 depicts, according to the datasheet, we define an FB for the pump and then implement these two output objects of the pump through GUI. Furthermore, an enumeration variable is also defined in GUI to identify the control modes from MO. In this use case, we choose the control mode “Constant speed” with 60% rotation speed by running the pump.

3.3. Simulation-Assisted Evaluation of the Implemented Control Strategy

In this section, we model the energy system in the modeling language Modelica [59] (named system model in the following) and use the Functional Mock-up Interface (FMI) [72] to integrate the system model in Python. The generated PLC program can also be integrated into Python by using the Python package Pyads [73]. Then, a simulation-based evaluation of the PLC program will be performed to verify if the functionalities of the PLC program accord with the planned control functions.

We use the Modelica Standard Library, Aixlib [74], and Buildings [75] to model the system model. Aixlib contributes the storage model and the heat pump model, incorporating measured data to depict the heat pump’s performance. The boiler model from Buildings is utilized, offering parameterization options for fuel type, set temperature, and desired boiler power. The measured data of a commercial building in Lüneburg are imported as conditions [18,76]. As Figure 21 illustrates, these measured data are the environmental temperature and the heat demands of the building covering two weeks in January. The evaporator temperature and the condenser temperature are respectively designed with 14 °C and 45 °C for the heat pump. The desired temperature of the heat supply network is 40 °C and hence the heat storage is proposed to be fully charged with the storage temperature $\left(T_{HS}\right)>$ 45 °C and empty discharged with $T_{HS}<$ 40 °C, ensuring that the desired network temperature can be achieved. Based on these, SOC turns to FALSE with $T_{HS}>$ 45 °C and TRUE with $T_{HS}<$ 40 °C. Between 40 °C and 45 °C, SOC will not be changed. Similar to SOC, SOD turns to FALSE with $T_{HS}<$ 40 °C and TRUE with $T_{HS}>$43 °C.

The system model is translated into a Functional Mock-up Unit (FMU) and then imported into Python for the simulation. Figure 22 illustrates the simulation process. In each time step of the simulation, the system model will run and then provide the desired system state. The relevant state variables are mapped to the corresponding inputs of the PLC program, which can determine the used operating modes according to the desired control logic as well as the inputs. These determined modes can further operate the system model through the corresponding interfaces.

Figure 23 depicts the simulation results of the system model and the PLC program at the network and subsystem level. With demands, the operating mode M3 at the network level is always activated, which turns the methods of Subsystem 1 and Subsystem 2 to Auto. At the subsystem level, if the controllers of Subsystem 1 and Subsystem 2 turn to Auto, the storage temperature determines the operating modes of both subsystems. If $T_{HS}>$ 45 °C, M0 of Subsystem 2 will be activated, which stops charging the heat storage by the heat pump. With $T_{HS}<$ 40 °C, M3 of Subsystem 1 and M1 of Subsystem 2 will be used to support the heat supply and charge the heat storage, respectively. The operating mode of Subsystem 1 will be converted to M1 if $T_{HS}>$ 43 °C. These mode switchings accord with the planned control strategy.

To analyze the system behavior at the subsystem and component level, we use the operation of Subsystem 1 as an example. As Figure 24 illustrates, the operating mode of Subsystem 1 can determine the used methods of the heat storage and the boiler, in which M1 activates Auto for the heat storage as well as Off for the boiler and M3 activates Auto for both components. With Auto, the heat storage and the boiler indeed supply heat for demands shown in the third subplot of Figure 24. The control result is presented by the supply air temperature oscillating around the set temperature (19 °C).

Based on these analyses, the planned control strategy is indeed implemented in PLC. In the hierarchical PLC structure, the output of the controllers at the higher level can decide the used FB Method (Off or Auto) of the controllers at the lower level. Within these two Methods, the planned control logic is performed to determine the used operating modes. The output of the configured PLC, i.e., operating modes at the component level, can be imported into the system model in Modelica to decide the system behaviors through the Functional Mock-up Interface. Based on the control strategy, the supply air temperature keeps around the set temperature within 1 °C.

3.4. Discussion

The results in the use case demonstrate the methodology to document mode-based control algorithms in the IFC schema and automatically implement the algorithms in PLCs for BES. Based on a software-assisted approach, the IFC-documented control strategy is configured in PLC by automatically generating ST code and then tested in a simulation phase.

Based on MODI, mode-based control algorithms are designed in a predefined hierarchical structure and described in SIPN at the design stage of BACS. To these algorithms, we develop a documentation framework in the IFC schema consisting of hierarchically structured IfcController entities to enable one-to-one correspondence from the SIPN-described control algorithms to the IFC-described algorithms. In this process, the hierarchy of the algorithms and the corresponding control logic are mapped into hierarchically nested IfcController entities and their properties sets, respectively. This framework represents the control hierarchy as well as reports all designed mode switchings in a list format in the IFC schema. Therefore, there is no need for extra interpretation between the design and the documentation process. Designers can also directly check the listed place-transition-place patterns following the control hierarchy to ensure the exact documentation of the planned control logic. Furthermore, this documentation framework is fully based on the existing IFC schema. Hence, this framework can be directly integrated into the workflow of construction projects, in which BIM and IFC are used.

In the implementation process, the one-to-one correspondence is further utilized to convert the IFC data into the PLC program. To keep the hierarchical control structure, the PLC program in the use case consists of hierarchically constructed POUs to map hierarchically nested IfcController entities. Within an IfcController entity, each place-transition-place pattern reported in its property set is implemented in an IF statement to perform the corresponding mode-switching process. After mode switching, a series of IF statements are implemented to check the determined mode and then call its output function. This implementation method can avoid implementing complex IF condition logic for mode switching but only generate IF statements one-by-one for each place-transition-place pattern, which significantly reduces difficulties and errors in the automated code generation process and helps programmers to understand as well as check the generated code. Furthermore, the programmed software facilitates the application of the automated implementation approach. In the use case, we only need to run the Python script to convert the IFC data and then import the resulting JSON file through the GUI. All POUs, which need to be generated, will be represented with parameters in the GUI. The IFC-reported parameters can be checked in the GUI, and we still have a chance to complete the missing information in the IFC data, which might be first determined in the implementation process.

The simulation results prove the feasibility of the methodology to implement mode-based control algorithms in PLCs. The PLC enables the mode-switching process in a hierarchical control structure and consequently determines the used operating modes following the planned control strategy. The actual air temperature can satisfy the control request, which keeps around the set temperature within 1 °C.

The whole application process of the tool to generate the PLC program in the use case takes 15 min, including importing the IFC file, running the Python script to convert the IFC file to a JSON file, checking as well as completing parameters for all used FBs, and generating the PLC program. The information about the generated program is shown in

Table 4. Information about the generated PLC program in the use case.

Function Blocks	Methods	Global Variables	Local Variables
7	21	23	71

. As a referent test, we manually program a PLC program to implement the designed control logic by using the standard FB objects. This reference process costs 2 h when the programmer has solid knowledge of PLC programming and the implementation method of mode-based control algorithms. The cost time will be longer if the programmer manually implements all codes of the program without using these objects. Therefore, the time and programming costs can be reduced significantly by using this methodology.

4. Conclusions

Programming control functions in BACS is always a time-cost and cumbersome task in building construction projects. The digitalization of control logic documentation in BACS is still insufficiently developed. This work introduced a documentation method to report mode-based control algorithms in the IFC schema and a software-assisted method to automatically generate PLC code in Structured Text for implementing mode-based control algorithms in BACS. The hierarchical control structure of mode-based control algorithms was converted into hierarchically structured IfcController entities, while SIPN-described control logics of mode-based control algorithms were mapped into predefined IfcPropertySet entities associated with the corresponding IfcController entities. Based on this documentation structure in IFC data, one-to-one correspondence was applied to map IFC data into Structured Text code segments in a hierarchically structured PLC program. Each IfcController entity was implemented in a function block by translating its property set in Structured Text code. This code generation method was programmed in a tool, which provided a GUI for importing IFC data and visualizing as well as checking the generated FBs. We used this tool to implement a mode-based control algorithm for an energy supply network in a use case and tested the generated PLC program in a simulation phase. The results of the use case proved that the planned mode-based control algorithm was indeed reported in IFC data and read by the tool to generate a corresponding PLC program. In IFC data, the hierarchical IfcController entities and their properties represented the desired control structure and control logic described in signal-interpreted Petri nets. These IFC data were successfully implemented in a PLC program to perform the desired control logic and determine the used operating modes.

The IFC-based documentation method allows the integration of control logic design for BACS directly into the current building construction workflow by using IFC as the digital data source. This method is developed based on the existing IFC schema. No extra efforts are required to extend the IFC schema for documenting control algorithms. Furthermore, by using this tool, the programming cost and errors were reduced significantly. Instead of manually programming whole PLC programs or copy-and-paste and then reconfiguration from existing programs, programmers only need to import IFC data and then check as well as supplement each FB to achieve the implementation of control algorithms. In this process, programmers can only focus on parameterizing FBs at each level and not be required to construct the whole control algorithms in PLC as well as have an overview of complex control relations. The implemented control algorithms can also contain more flexible control logic than copy-and-paste from existing PLC programs. However, it is important to note that certain control functions, such as PID controllers, within the generated PLC programs necessitate tuning to align with specific system requirements. Additionally, users are required to verify and complete parameters for function blocks if there are any missing parameters in the IFC format.

In future work, a hardware-in-the-loop test is expected to further evaluate this methodology in the practical phase. The standard mode-based control algorithms for air handling units will be also integrated into this methodology as a specific use case to enrich the application of this methodology.