A Petri net oriented approach for advanced building energy management systems

2.1.Review of the scientific literature

BEMS received significant attention from the scientific community. Authors in [1] made in 2021 a systematic review of the scientific literature on BEMS; this paper detects some functions that are attributed to BEMS: the functions and the relative frequencies are in Table 1.11

From these papers, the authors extract several lessons learned and future research challenges. Among the others, they are worth mentioning: simulation models are useful to monitor and predict energy demand, IoT can be successfully used to collect energy usage, there is a need to enhance the estimation and prediction related BEMS since they have achieved the least energy saving rates with about 10%; control or optimize related ones perform better.

Another interesting perspective on the research on BEMS is reported in [26]. This document is one of the results of the SmartBuilt4EU project22 that surveys several EU-level public funded projects researching on the next-generation BEMS. In addition, SmartBuilt4EU is strongly related to the last developments of the Smart Readiness Indicator (SRI), i.e., a common EU scheme introduced in 2018 in the European Energy Performance of Buildings Directive (EPBD) for rating the smart readiness of buildings [28]. The SRI usually refers to seven “impact criteria” (e.g., Energy Efficiency; Health, Well-Being and Accessibility; Energy Flexibility and Storage) and seven “domains” (e.g., heating, lighting, electricity, electric vehicle charging). According to this document, the projects mainly related to the theme of this paper are:

As the present paper is centred on the usage of modelling approaches for the evaluation, monitoring and prediction in BEMS, other papers are reviewed, according to their relevance regarding the presented one. Fanti et al. propose a PN model for BEMS control [6]; the model is then improved by proposing a First Order Hybrid Petri Net (FOHPN) model in [7]. In [24], a State Machine (SM) model is proposed for control. PNs are also used to find failures in smart grids [5]. In [21], a simulation conceptual framework is defined to support different above-mentioned phases, from evaluation to analysis. An optimization approach based on soft computing techniques is proposed in [23]. Other papers – considering evolutionary computing techniques in the optimization of energy management in the home and smart grid domains – are [8,33].

Many simulation tools, which analyze energy consumption, have been developed. In [16] the authors describe a framework for the interaction of common home devices and appliances to control and monitor energy consumption. The tool shows the estimated consumption to the customer with the related costs allowing him/her to adopt a better strategy for energy and cost reductions. Choosing an optimal energy consumption policy can also be pursued by transferring this responsibility to a device within a Smart Home. GridLab-D33 and EnergyPlus [31] are two existing tools, which examine the energy consumption with the focus on heat generation and thermal load of a building, considered as the main energy-consuming activity. The Smart Home Simulator introduces the capability to model a smart home configuration, to set the energy workloads and to allow monitoring such home appliances [2].

Other approaches tackled with model-based methods to evaluate energy consumption properties in other hybrid systems: in [22], the authors use PNs in combination with fuzzy logic to model and evaluate the energy profiles of hybrid electric vehicles; the authors in [27] approach to the modelling and the evaluation of prosumer-based microgrids be means of PNs. In both the papers, there is no usage of a PN dialect enabling and easy modelling of hybrid systems while the focus is set on the control.

This review of the scientifically relevant papers confirms the originality of the contributions of the present paper:

2.2.The FSPN formalism

FSPNs are a type of mathematical formalism used to represent and analyse systems that involve concurrent processes and the flow of fluid resources. It is an extension of the traditional PNs, mainly used for discrete event systems. In a PN, the basic elements are places, which represent resources or states, and transitions, which represent processes or events that consume or produce resources. The flow of resources between places is represented by arcs, which connect the places to transitions. In addition to these elements, the FSPN formalism also includes fluid places, used to model continuous variables, and fluid arcs, used to change such quantities continuously in time.

FSPNs can be used to understand how a system behaves under different conditions and to identify bottlenecks or other issues that may impact the performance of the system also in the presence of random or probabilistic behaviour. Transitions in FSPNs are associated with probability distributions, which describe the likelihood of a transition occurring at a given time. This allows for the modelling of systems with uncertain or unpredictable behaviour, such as those involving queues or delays. The presence of fluid places and arcs allows FSPNs to model hybrid systems with both discrete and continuous variables in a more natural way with respect to simpler formalisms as PNs and Markov Chains (MCs).

3.1.A BEMS reference architecture

This subsection wants to summarize the main contributions present in the literature through a BEMS reference software architecture. This architecture is a synthesis, made in this paper, on the base of the Building Energy Management Open Source Software (BEMOSS) initiative, described in [18]. The architecture is depicted in Fig. 1.

Fig. 1.

A BEMS reference architecture.

The architecture considers four layers: User Interface, Application & Data Management, Operating System & Framework, and Connectivity layer communication with each other directly and through shared databases. Some functions provided by these layers are: Alarm Notification, Load Management, Price-based Management, Authentication, Resource Management, etc. About shared data, there are: (1) a Database, containing user-level information as User profile, Device UI Device Information, etc.; (2) a Time Series Repository (SMAP) containing time series of monitored variables, e.g., temperature, real-time pricing, etc; (3) cloud-related sources of data, e.g., weather forecasting, energy prices, etc. All the layers and the provided functions work in different domains, e.g., heating, lighting, electricity, and electric vehicle charging.

For simplicity, this paper focuses on Price-based Management: this notwithstanding, BEMS-related function may be not the only one involved in the process. As a consequence of this hypothesis, Price-based Management leads the System Designer to the workflow, as it is described in Section 3.2. Other scenarios are possible, according to the specific index chosen to match/optimize: a further discussion is reported in Section 6.

On the base of this reference architecture, Fig. 2 depicts the proposed approach considering actors and high-level artefacts.

Fig. 2.

A model-driven BEMS architecture.

The actors are: the Price-based Management function of the BEMS; the Device, which continuously senses the variables to monitor, both physical (e.g., energy consumption, temperature), and immaterial (e.g., energy price); the User, who lives/works in the building; and the System Designer, who has the objective of building a BEMS respecting the required features. For what concerns the high-level artefacts, they are: the Control Strategy, which is the business rule determining how the involved function (Price-based Management, in this case) reacts to the changes in both the usage of the building and in the market conditions; the Device Software, controlling the logic of sensing and communication from the device to the upper layers of the BEMS; the BIM model, describing not only the physical structure of the rooms of the buildings, but also the locations of the sensing devices and the actuators (e.g., Heating, Ventilation and Air Conditioning (HVAC) pumps); the SMAP repository, containing both the data concerning the user (i.e., the User Profile) and the variable evolution series, captured by the sensing devices. Furthermore, the approach introduced in this paper, adds some original elements.

3.2.The software life-cycle

In the framework of the above proposed approach, a design and development methodology is also suggested, giving to the software engineer a practical tool for running the proposed methods. The reader should consider that these activities are not strictly conducted during the design phase, drawing a separating line between a system’s design and operation phase. This approach should be seen as a tool operating inside a broader evolutionary software approach where software could be subject to modifications and improvements during the system operations. More in the detail, such workflows can be described from three different perspectives:

4.1.User model

Before discussing the generation of the User Model from the data contained in the SMAP, let us make some consideration on the data. According to our proposed architecture, as well as to the reference architecture of BEMOSS reported in Section 3.1, both sensing devices and user activities populate the database. The first set of actors dumps in the dataset the events related to the activation of the electrical appliances in the building (HVAC equipment in this case). The second set of actors (i.e., the users) injects in the SMAP the events related to the presence of people in the physical facilities. An excerpt of such event logs is reported in Listing 1. Valuable fields of the log are: the timestamp, the kind of the event, the itemId that identifies the involved item (e.g., room, lightbulb, HVAC device), the measure of the involved variable, and the id of the actor producing the log entry (the caseId).

Listing 1.

Example of the SMAP event log.

Fig. 3.

User model (from alpha miner).

Fig. 4.

User model (refined).

The generation of the User Model from the logs contained in the SMAP is made by exploiting the well-known technique of the Process Mining (PM) [32]. PM has demonstrated in more than a decade to be a versatile, mathematically well-founded, and industry-mature body of knowledge, techniques, and tools for the extraction of a business process from event data. Among the PM algorithms proposed in the literature, the Prime Miner algorithm has been chosen in this paper [3]. This algorithm is an evolution of the well-known Alpha Miner, overcoming some limitations and generating a more compact model. The Prime Miner generates a PN model where the events are transformed into transitions; Fig. 3 represents a generic situation present in the extracted model.

By analysing the event log, the Alpha Miner algorithm detects, as an example, the presence of two threads, one switching on an electrical appliance (i.e., Pi, Pi+1 and switch_on), the other switching it off (i.e., Pj, Pj+1 and switch_off). The extracted model is then woven with specific ad-hoc PN model fragments to produce the PN model as depicted in Fig. 4. More specifically, the switch_on place is substituted by a more complex subnet with the objective of flushing out the token from the off place, while the switch_off one with a subnet with the aim of putting just one token in the off place. To this aim, PN patterns can be used as described in [20].44

A brief discussion about the capture and the generation of the SMAP dataset is due: in PM approaches, the presence of a caseId is needed to group together events that refer to a single system usage. In the considered architecture, it is easy to suppose that devices are easy to be identified; as regards the users, it is reasonable to suppose that many interactions may be done intermediated by some sort of smart devices (e.g., a simple application running on a smartphone), allowing the users in interacting with the building in a simplified and secure way. On the other hand, the authors are aware that the application of PM in Cyber-Physical Systems (CPSs) can be affected by unavailability or by the partial availability of interaction session identifiers [34]. In this case, one of the most widespread techniques is the application of methods able to label with a proper value of caseId those events where such information is not present [9].

4.2.Building model

The Building Model is generated by the Bim2Model tool on the basis of the information and the data contained in the BIM Model. The aim of the building model is to make explicit the relationships between the significant monitored variables according to the physical environment. An example, related to the HVAC domain, is constituted by the changes in the temperature of a room according to the natural ventilation, the shape of the room, the temperature of the adjacent rooms, and all the other impacting causes. The details of the transformation are not formalized in this paper, while Fig. 5 summarizes the mapping between BIM constructs and the FSPN elements.

Fig. 5.

The BIM model to building model mapping.

On the left of the figure, an example tree of a BIM Model, represented by a high-level view of a eXtensible Markup Language (XML) tree: the model represents a flat, having a room connected to the outside by a window. In Room there are an HVAC equipment and a lamp. The FSPN model on the right represents the energy/temperature balance of the considered building. In particular, for each room, a “temperature” fluid place is generated (respectively TR and TOUT). On the other hand, only one energy place is generated (Energy) representing the energy spent by users. Three elements of the XML tree are translated into FSPN subnets.

Even if the presented mapping is very simple, it summarizes the main possible cases. Of course, other physical variables could be added according to the national regulations and user preferences. It seems possible that the same reasoning could be applied to variables as humidity, air pollution, presence of specific substances as CO2, radon, etc.

4.3.Device model

Regarding the Device Model, let us start from the general sensing-computation-communication pattern that characterizes IoT devices [36]. To this aim, we can imagine a library of possible behaviours that could be adapted to the different specific sensor architectures. Figure 6 and Fig. 7 reports two of these behaviours.

Fig. 6.

Device model (basic).

Fig. 7.

Device model (advanced).

More in the details, the PN model in Fig. 6 reports the very basic schema of a device in Idle that periodically samples the monitored physical variable (by the firing of the period transition); at this point, if the sampled data match the guard of the sending transitions, this last transition fires and data are sent to the BEMS. Otherwise, the wait transition fires and another idle period starts. Figure 7 reports a more complex scenario in which the sensor is capable to be put in the sleep mode (represented by the sleeping place) or, on the other hand, being set into the sensitive state where a lower sampling period is possible. This is represented by the presence of two different timed transitions: period0 and period1; the rate of the second transition is higher than the rate of the first one.

For clarity, the models here reported are expressed in the FSPN formalism. To be more precise, the approach considers IOPTPNs and their supporting tools, which explicitly address input-output mechanisms and code generation procedures. The schemes present in the library also consider the transformation of such models into IOPTPN models and the, the generation of source code. Details on the formalisms, the generation techniques and toolsets are in [13].

4.4.BEMS model

The process of generating a FSPN model from the Control Logic starts from describing the adopted formalism to express such a program. In this paper, as in [10], we adopt a pseudo language – named Smart Meter Programming Language (SMPL) – originally used to describe control logic of Smart Meter (SMt). In the cited paper, the generation of a FSPN model from a SMPL program is automated by the smpl2fspn M2M.

In this paper, we extend SMPL to adapt it to the different scenario here considered. In [10], SMPL just considered classical control applications, structured as infinite loops; in this paper, as sensors/device models are structured according to such a paradigm (see Section 4.3), we consider an APPLICATION, composed of different procedures, explicitly invoked from the external, i.e., data sent from the Device Layer. This notwithstanding, both the control paradigms can be used together: future research work will explore this trend, also focusing on a formal definition of the language and fully describing the model transformation here just sketched. Listing 2 reports the description of the logic related to a BEMS putting in the sleeping mode a temperature sensing device that measures the same temperature for three consecutive times.66

Listing 2.

Example of SMPL program

Fig. 8.

Generated FSPN model [10].

A control logic expressed in SMPL is structured in this way:

Some possible instructions that can be used in both the RECEIVED and the INIT sections are: COPY, that copy the value of a physical (fluid) variable into another; INCREASE/DECREASE, modifying upward/downward the value of an integer variable of a specified quantity; and the SEND command, raising a signal to sensor/actuators. Let us underline that, to avoid ambiguity in interfacing as example with more than a sensor, elements that refer to other modules (i.e., temp_received) are preceded by the name of the module: the name of the module and of the variable are separated by a dot (e.g., device.temp_received).

The translations in FSPN snippets of some constructs used in this example are already considered in [10]. However, Fig. 8 reports the FSPN model generated by the example just described.

CONST sections are translated by defining constant parameters of the model, VARIABLE sections by defining proper discrete/fluid places and the INIT sections by setting the proper initial marking of such places. For what concerns the other elements, the dotted boxes enclose the FSPN subnets translating such SMPL constructs; more in the details, Table 2 reports for each of the blocks present in the FSPN model the corresponding lines of code of Listing 2.

4.5.Model structuring and evaluation

Figure 9 reports further details on the four PN models, in particular their interactions among each other.

The PN structuring problem has been exhaustively studied in the literature: in this paper, we use the results of many of such studies, which are summarized and classified in [12]. There are two used PN structuring mechanisms: place/transition superposition, where two or more places (or transitions) are shared among different submodels [4], and message-passing invocation, obtained by adding arcs from transitions in a submodel to places into another submodel. More specifically, the following interactions are present.

For what concerns the evaluation of the composed FSPN model, the complexity of the model itself – in particular, the presence of more than one fluid place – does not allow the application of analytical exact solution algorithms, as they are reported in [14]. The only way to solve the model is by using simulation-based algorithms, as described in [15].

Fig. 9.

The formal model overall structure.