## Serviços Personalizados

## Journal

## Artigo

## Indicadores

- Citado por SciELO
- Acessos

## Links relacionados

## Compartilhar

## Sba: Controle & Automação Sociedade Brasileira de Automatica

##
*versão impressa* ISSN 0103-1759

### Sba Controle & Automação v.15 n.2 Campinas abr./jun. 2004

#### https://doi.org/10.1590/S0103-17592004000200003

**SISTEMAS INTELIGENTES**

**A hybrid Petri net modeling approach for HVAC systems in intelligent buildings**

**Emilia Villani; Paulo Eigi Miyagi**

Dept. Eng. Mecatrônica e de Sistemas Mecânicos, Escola Politécnica, USP, Av. Prof. Mello Moraes, 2201, São Paulo Brasil. evillani@usp.br; pemiyagi@usp.br

**ABSTRACT**

In this work, a novel hybrid modeling approach for HVAC control system design in Intelligent Buildings is introduced. In order to achieve building system integration, a characterization of HVAC system as hybrid is required. The proposed approach is a top-down modeling method based on Petri net. Starting from abstract models designed using the Production Flow Schema, Petri net based models are built by successive refinements. The discrete part of the system is modeled using Place-Transition Petri nets and the continuous part is modeled using differential equation systems. The interface between these two parts is provided by Differential Predicate Transition Petri nets.

**Keywords:** Hybrid systems, Petri nets, intelligent buildings, HVAC systems.

**RESUMO**

Este trabalho propõem uma nova metodologia para modelagem de sistemas de ar condicionado em Edifícios Inteligentes. Para possibilitar a integração com outros sistemas do edifício, o sistema de ar condicionado é caracterizado como híbrido. A metodologia proposta consistem em uma abordagem do tipo *top-down* baseada em redes de Petri. A partir de um modelo abstrato construído usando *Production Flow Schema*, modelos baseados em redes de Petri são obtidos através de detalhamentos sucessivos. A parte discreta é modelada usando redes de Petri Lugar-Transição e a parte contínua é modelada usando sistemas de equações diferenciais. A interface entre as duas partes é realizada pelas redes de Petri Predicado Transição Diferenciais.

**Palavras-chave:** Sistemas híbridos, redes de Petri, edifícios inteligentes, sistemas de ar condicionado.

**1 INTRODUÇÃO **

The "intelligence" of a building is mainly achieved based on the incorporation of new technologies together with the use of the system integration concept (Arkin & Paciuk, 1995), (Becker, 1995). In order to fulfill this integration, a *Building Management System *is responsible, among other tasks, for information interchange between building systems, such as the lighting System, the HVAC (Heating Ventilation and Air Conditioning) system, the fire system, etc. The main purposes of the system integration in *Intelligent Buildings *are to maximize the productivity of the building occupants, allow an efficient management of resources and minimize costs.

In order to reach these purposes, the design of a building control system must evaluate how events monitored by other building systems affects the performance of the system under design. Once that the information of the occurrence of these events can be transmitted to the system under design via the Building Management System, it should be considered how it can be modified in order to improve the overall building performance.

A crucial point in the design of the building control systems is the modeling activity. Among other important points, the model choice directly influences the possibilities of analysis and implementation. When modeling from a management perspective, the dynamic behavior of an Intelligent Building might be characterized by discrete events and states. Examples of discrete events are turning elevators on, activating alarms, etc. Examples of discrete states are elevators on, alarms activated, etc. Consequently, some building systems might be characterized as *Discrete Event Dynamic Systems *(Ho, 1989). On the other hand, when considering the interaction of the building systems with the environment, it is also necessary to take into account some behavior that might be characterized as *Continuous Variable Dynamic Systems*, such as the water or energy consumption of the building.

In this context, this work introduces a novel modeling approach for supporting HVAC control system design based on the building system integration. The main innovative point is that HVAC is modeled as a hybrid system, while the conventional modeling approaches usually consider the system as either continuous or discrete. A general definition of hybrid systems might be systems where it is necessary to consider interactions between discrete and continuous parts (Alla & David, 1998), (Antsaklis & Nerod, 1998).

When analyzing HVAC systems, the plant, i.e., the conditioned environment has a mixture of continuous interactions that are influenced by discrete events. An example of continuous interactions is the room temperature changing according to the HVAC air temperature. Examples of discrete events are door opening and people entering in the room. The HVAC control system is also essentially hybrid. It consists of continuous local controllers, such as proportional-integral (PI) controllers, supervised by a discrete management system, which is composed by a number of control strategies and might turn on/off equipment or switch configurations.

In conventional buildings, the HVAC control system design is based on the interaction of the continuous controller with the continuous part of the conditioned environment (Figure 1) and therefore it is considered a problem restricted to the domain of Continuous Variables Dynamic Systems. On the other hand the HVAC Management System design is based only on the interaction with users and on the monitoring of discrete states of HVAC equipment where the continuous characteristics of local controllers and plant are not considered. The HVAC Management System design is therefore considered a problem restricted to the domain of Discrete Event Dynamic Systems.

In Intelligent Building, system integration turns possible to consider the influence of discrete events that acts on the conditioned environment and, indirectly, influence the local controller performance. These events are detected by other building systems and are transmitted to the HVAC Management System by the Building Management System (Figure 2). The HVAC Management System is then expected to act on the local control system.

In order to take into account the influence of these discrete events, the design of the HVAC Management System and of local control system should not be considered completely independent. For this purpose a hybrid approach is necessary, where the influence of both discrete events, treated by other building systems, and the continuous variable, measured from the plant, could be modeled. The necessity of a hybrid approach is therefore a result of the building system integration.

The proposed modeling approach is a top-down method based on Petri net (David & Alla, 1994). Starting from models designed using the Production Flow Schema (Miyagi et al, 1997). Petri net based models are built by successive refinements. The discrete part is modeled using Place-Transition Petri nets (David & Alla, 1994) and the continuous part is modeled using differential equation systems. The interface between these two parts is provided by Differential Predicate Transition Petri nets (Champagnat et al, 1998).

This paper is organized as follows. Section 2 explains the choice of the modeling formalisms, presenting the Place-Transition Petri nets and the Differential Predicate Transition Petri nets. Then, Section 3 gives a detailed overview of the proposed approach, using as example an ambulatory building. Finally, in Section 4 some conclusions are given.

**2 THE CHOICE OF MODELING FORMALISMS **

**2.1 Discrete Event Dynamic System modeling **

As presented before, the HVAC Management System can be a Discrete Event Dynamic System. Among the formalisms for modeling this kind of system, the Place-Transition Petri nets (P/T Petri nets) is chosen due to its well-known proprieties, such as ability to represent process synchronization, concurrence, causality, resource sharing, conflicts, etc.

Briefly, a P/T Petri net consists of *places*, *transitions*, and *arcs* that connect them (Figure 3a). . *Input arcs* connect *places* with *transitions*, while *output arcs* start at a *transition *and end at a *place*. *Places* can contain *tokens*. The current state of the modeled system (the *marking*) is given by the number of *tokens* in each *place*. *Transitions *are active components. They model activities that can occur (the *transition fires*), thus changing the state of the system (the *marking *of the Petri net). *Transitions* are only allowed to fire if they are *enabled*, which means that all the preconditions for the activity must be fulfilled (there are enough *tokens* available in the input *places*). When the *transition* fires, it removes *tokens* from its input *places* and adds some at all of its output *places*. An example is presented in Figure 3: Figure 3a a presents a Petri net *before *the firing of its *transition* and Figure 3b the Petri net *after *the *transition* firing. More details and a formal definition of Petri nets can be found in (David & Alla, 1994).

**2.2 Hybrid System modeling **

A number of formalisms have been proposed for hybrid system modeling. Champagnat et al (1998) and Guéguen & Lefebvre (2000) present detailed revisions of hybrid modeling formalisms. Some approaches are extensions of continuous models based on differential equation systems where discrete variables are added in order to provide discontinuous behavior. Other approaches are extensions of modeling techniques defined for Discrete Event Dynamic Systems, such as the Hybrid Petri Net (Alla & David, 1998). Finally, there are also some approaches that mix continuous models, described by differential equation system, and discrete ones, described by automata or Petri Nets. In these approaches, an interface is introduced to perform the communication between these two kinds of models.

For the purpose of HVAC system modeling, this work considers the last group. The main reason is that, as a general rule, extensions of discrete formalism result in a restricted modeling capability of the continuous part. The equivalent could be also said for the extension of continuous formalism. On the other hand, approaches that specify a solution based on the mix of two formalisms usually results in more flexibility and more modeling power.

Particularly, among the tools of this group it is considered those where the discrete formalism is based on Petri Nets because of the reason presented in 2.1 . One of the formalisms that meet all these requirements is the Differential Predicate-Transition net (DPT Petri net) (Champagnat et al, 1998).

Briefly, the main characteristics of the DPT Petri nets are:

A set of variables (x

_{i}) is associated with eachtoken. A differential equation system (F

_{i}) is associated with eachplace(P_{i}); it defines the dynamic of the x_{i}associated with thetokensin P_{i}, according to the time. An enabling function (e

_{i}) is associated with eachtransition(t_{i}); it triggers the firing of the enabledtransitionsaccording to the value of the x_{i}associated with thetokensof the inputplaces. A junction function (j

_{i}) is associated with eachtransition(t_{i}); it defines the value x_{i}associated with thetokensof the outputplacesafter thetransitionfiring.

However, the DPT Petri net does not include any kind of support for model decomposition or progressive modeling approaches, such as hierarchical modeling where models could be refined and showed with different levels of detail. The modeling activity should be performed in a flat way, which difficulties the study of the complex system, where it is not possible to understand the system as whole with appropriate depth.

Looking for a solution for this problem, this work introduces a new top-down modeling approach, focus on the problem of HVAC modeling, where P/T Petri nets, DPT Petri nets and the Production Flow Schema are merged.

**3 THE PROPOSED APPROACH **

**3.1 The modeling activity in the HVAC control system development process **

Once that in Intelligent Building the HVAC management system and the HVAC local controllers cannot be developed completely independent from each other, the development of HVAC control system can be viewed as an interdisciplinary problem involving concepts and methods from three areas: software engineering, discrete event dynamic systems and continuous variables dynamic systems. On one hand, the HVAC Management System is itself a software, including procedures and databases. At the same time it is also a discrete event dynamic control system (it discretely changes the state of HVAC plant and local control system). On the other hand, the design of local controllers (such as PID) is a typical matter of the continuous variables dynamic systems.

Based on approaches for software development (waterfall lifecycle (Whitten, 1995)), for development of discrete event dynamic control system (Miyagi, 1996), and for continuous control system development (Ogata, 1990), the HVAC control system development is divided into four main steps (Figure 4):

The Step 1 consists of the identification of the control system purposes, i.e., what the system should do, what are possible interactions with users and what are possible interactions with a high level control system. Local control systems should also be specified by defining the input/output variables of each local controller.

In the Step 2, it should be determined how the control system will perform the activities defined in Step 1. During this phase, the modeling activity has an important role, since it is responsible for guiding designers throughout the design process.

In the Step 3, the models built in Step 2 should be analyzed in order to validate the overall system behavior according to the requirements defined in Step 1.

Finally in Step 4, models should be codified in any programming language and implemented. It is also part of this step the selection of hardware equipment.

The focus of this paper is on the Step 2. The design phase should embody the modeling of the HVAC control system, the HVAC equipment, the water/air flow, and the environment. For this purpose, a further division of Step 2 is proposed in this paper (Figure 5).

Basically, during the Step 2.1, control strategies should be defined considering the systems requirements of Step 1. It should also consider how the HVAC Management System could improve the local controller performance based on events treated by the Building Management System or based on the thresholds informed by the local processors. The models of the HVAC Management System, equipment, air/water flow and conditioned environment should then be built. According to these models local controllers should be designed by defining the controller configurations and its constants. Finally, in Step 2.6 all the models should be integrated into a global model of the HVAC system (including control system and controlled object).

Each step is presented with more detail in the following, using as example the models developed for the HVAC system of an ambulatory building.

**3.2 The Example **

The proposed approach is applied to the HVAC system of the Ambulatory Building of the Medical School Hospital of University of São Paulo. Giving an idea of its complexity, the ambulatory is a building of about 100,000 m^{2}, which includes clinics, surgery center and industrial pharmacy, among other installations. The Intelligent Building concept cannot be fully implemented at the ambulatory building, but its HVAC system can be used as a reference model. The ambulatory HVAC system includes heating and cooling. The chilled water is centrally produced by 8 chillers and 8 cooling towers. The hot water is produced by 2 boilers. The water is then distributed to various coils. Each coil conditions a zone. A zone is a conditioned environment under the control of a single temperature sensor. The Ambulatory Building is divided into 370 zones. In this paper a simplified version of the modeling of one of its zone is presented as an example. The complete models of the HVAC system, including the hot and cool water production, can be found in [Villani, 2000].

A scheme of the HVAC zone system adopted as an example is presented in Figure 6. Basically, the zone temperature is controlled by changing the amount of water that passes through the cooling coil. A three-way valve controls the water flow in the heating/cooling coil. The airflow is maintained by two fan. In the zone the mixing-box performs the partial or complete air renovation. In the following section, each step of the proposed approach is detailed for this zone system.

**3.3 Step 2.1: Strategy specification **

Strategies of the HVAC Management Systems are composed by discrete event sequences that are executed under certain conditions. These events are commands sent to local controllers and equipment in order to change their configurations. The strategy specification is an intermediate step after the requirement analysis and before the system modeling. It consists of a textual description and uses no formalism. The description must contain the event sequence of each strategy and the conditions under which the strategy is performed.

For the ambulatory zone example the following strategies are considered:

** Fire Strategy:** it is activated and maintained when fire is detected in the zone. The event sequence is:

the mixing box is set to take 100% of outside air;

simultaneously to the mixing box setting, PI valve controllers are turned off in order to avoid an eventual unbalance of the system due to the great demand of cold water;

the return fan speed is increased to prevent smoke diffusion and the supply fan is turned on.

** Unoccupied Zone Strategy:** it is activated and maintained when there is nobody in the zone and fire is not detected, or when there is an order by the BMS or the user and fire is not detected. The event sequence is:

PI valve controllers are turned off;

fans are turned off;

simultaneously to the fans setting, the mixing box is set to take 0% of outside air

** Occupied Zone Strategy:** it is activated and maintained when there is someone in the zone and fire is not detected or when there is an order by the BMS or the user and fire is not detected. The event sequence is:

the mixing box is set to take 60% of outside air;

simultaneously to the mixing box setting, fans are turned on;

PI valve controllers are turned on;

PI valve controller switches configuration according to the occurrence of discrete events that change the thermal load in the zone.

The PI valve controller switching activity of the ** Occupied Zone Strategy **is introduced to reduce the HVAC time lag between the occurrence of a disturbance (discrete thermal load variation) and its compensation by the HVAC control system. Briefly, the reason for the time lag in the HVAC response is the large thermal inertia of the whole system (Honeywell, 1995). However, this time lag could be reduced if a modification in the thermal load instantly causes a modification in the HVAC control system. By switching PI configurations according to the occurrence of discrete events that cause thermal load variation detected by other building systems, the duration and amplitude of these disturbances can be reduced while improving users thermal comfort.

**3.4 Step 2.2: Management System Modeling **

Starting from the textual description of the management strategies, a top-down method based on Petri net and Production Flow Schema is applied to build system models. Firstly, a conceptual model is obtained by using the Production Flow Schema modeling technique (Miyagi et al, 1997). Then, the Production Flow Schema is refined into a functional model using P/T Petri nets.

The Production Flow Schema is derived from interpreted graphs (channel/agency net) (Reisig, 1985) and, essentially, describes the activities performed in a flow of discrete items in a high level of abstraction. Production Flow Schemas have no dynamic. Its components are *activities*, which represent modifications on the flow of items, *inter-activities*, which are passive elements, and *arcs *(Figure 7).

Each *activity* of a Production Flow Schema is detailed into a new Production Flow Schema (Figure 8a), a Petri Net model (Figure 8c), or a mixed Production Flow Schema/Petri Net model (Figure 8b). During the refinement process, *activities *should be replaced by models beginning and ending with either an *activity *or a Petri net *transition*, in order to guarantee the coherence of the resulting Petri Nets.

Based on the Production Flow Schema/Petri net refinement procedure, the HVAC Management modeling is decomposed into the following steps:

Step 2.2.1-A high level Production Flow Schema is built showing the relation between the strategies, i.e., if they are concurrent, complementary, can be executed at the same time, etc. In this Production Flow Schema each strategy is modeled as an activity.

Step 2.2.2-Each strategy of the previous Production Flow Schema is detailed according to its sequence of events.

Step 2.2.3-The communication with the Building Management System and the User Interface (which enable or disable strategies) is performed byenablingandinhibitor arcs(Silva & Miyagi, 1996). In this case the control signal carried by thearcsis a logical combination of the information from the Building Management System. According to their value thearcsinhibit or enable the beginning or end of anactivity.

Step 2.2.4-Eachactivityof the strategy is detailed into a P/T Petri net model. At this level, theactivityis modeled as a command that is sent to the correspondent equipment or local control system. Before passing to the nextactivity, the supervisory system must receive an acknowledge of the command execution.

Step 2.2.5-The communication between the Petri net strategy model and the equipment or local control system models is also performed by addingenabling arcs.

In the following, these steps are applied to the ambulatory zone example. Figure 9 presents the Production Flow Schema of Step 2.1.1. According to the textual description of the strategies, they are all concurrent.

By Step 2.1.2, this model is detailed into the Production Flow Schema of Figure 10. Then the *enabling *and *inhibitor arcs *integrate the HVAC Management System with Building Management System and User Interface (Step 2.1.3), according to the textual description of the strategies.

The control signals are calculated according to the following expressions:

Control signal 1: *NOT*(F) *AND* (B *OR* U *OR* P)

Control signal 2: (NP_old - NP_new)*CP + (NL_old - NL_new)*CL + (NE_old - NE_new)*CE > Q_{min}

Control signal 3: (NP_new - NP_old)*CP+ (NL_new - NL_old)*CL + (NE_new - NE_old)*CE > Q_{min}

where :

F is the signal from the Building Management System indicating fire in the zone (this information is given by fire system);

B is the signal from the Building Management System imposing this strategy;

U is the signal from the User Interface imposing this strategy;

>P is the signal from the Building Management System indicating that there are people in the zone (this information is given by the access control system);

NP_old is the information from the Building Management System about the number of people in the zone a certain time ago (this information is given by the access control system);

NP_new is the is the information from the Building Management System about the number of people in the zone now (this information is given by the access control system);

CP is a constant associated with the thermal load of one person;

NE_old, NE_new, CE, NL_old, NL_new, CL - idem of NP_old, NP_new, CP for equipment and lights.

Q

_{min}is a constant associated with the minimal thermal load variation for switch controller configuration.

Subsequently, the model of Figure 10 is refined into a Petri net model (Figure 11), according to Step 2.1.4 and 2.1.5.

**3.5 Step 2.3: Equipment and water/air flow modeling **

At this step, a hybrid approach is necessary to model both equipment discrete states and water/air continuous variables. The Production Flow Schema has been initially defined for discrete systems, and here an extension of it is introduced for hybrid system modeling. In this case, the refinement of each *activity* uses the DPT Petri net [Champagnat, 1998] and differential equation systems. In the DPT Petri net model the link between the *activities *is made by the continuous variables, instead of *token *flows as in Step 2.2.

The procedure for building the Production Flow Schema for hybrid systems is divided in the following steps:

Step 2.3.1-The relevant fluid properties should be chosen. Basically, these properties are those that are necessary for evaluating the system performance, that are the inputs and outputs of the local control system, and all the others that are necessary to calculate the previous ones.

Step 2.3.2-The Production Flow Schema is built by determining the sequences ofactivitiesperformed on the fluid. Anactivityis any modification on the relevant properties along the process.

Step 2.3.3-For eachactivity, a vector of variables is defined for the beginning and the end of theactivity, representing fluid properties at that point of the process

Figure 12 illustrates the Production Flow Schema built for the ambulatory zone example. In this case, there are two fluids: water and air. The relevant properties are flow (f) and temperature (T).

The refinement procedure of the Production Flow Schema for hybrid systems is divided in the following steps:

Step 2.3.4-Eachactivityof the Production Flow Schema can be detailed into a new Production Flow Schema, a DPT Petri net and/or an equation system. The equation system is used to determine the relation between the properties at the beginning and at the end of anactivity. The DPT Petri net is used in the case that the equipment performing theactivitycan assume different discrete. Each state of the equipment is represented by aplace, which is associated to an equation system.

Step 2.3.5-Enabling and inhibitorarcsare added to the DPT Petri nets in order that a local control system or the HVAC Management System can set the equipment state.

Step 2.3.6-Inter-activitiesrepresent system parts where no modification is performed on fluid properties. However, properties in the end of an activity are not the same of the beginning of next activity because the air that is leaving anactivity"spends some time" to arrive in the beginning of the nextactivity. In order to represent this time delay, equation systems are associated with inter-activities.

As an example, Figure 13 shows the *activity* [Flow division on valve] detailed into an equation system, and the *activity* [Air in the mixing box] detailed into a DPT Petri net.

In Figure 13 the following notation is used in the equation systems:

P is the position of the three-way valve;

b,L are valve constants;

P1, P2, P3 represent the mixing box position of 0%, 60% and 100% of airflow renovation.

As an example, the equation system for the first inter-activity is presented Figure 14.

**3.6 Step 2.4: Conditioned environment modeling **

The model of the conditioned environment is also composed by differential equations and DPT Petri nets. The following steps are defined for the conditioned environment modeling:

Step 2.4.1-An equation system determines the evolution of the relevant properties of the zone according to the properties of the airflow entering in the zone and external variables.

Step 2.4.2-Discrete events that may influence the dynamic of the zone properties are modeled by DPT Petri nets.

For the example of the ambulatory zone, the equation of Step 2.4.1 must determine the air temperature within the zone according to the incoming flow of the HVAC system, thermal loads introduced across walls and by equipment, people and lights. In this case, the thermal load can be modified by discrete events (light is turned on, someone enters in the zone) and is modeled using DPT nets. The zone equation system and the DPT Petri net associated to the people thermal load are presented in Figure 15.

In Figure 15 the following notation is used in the equation systems:

Q

, Q_{people}, Q_{light}_{HVAC}are thermal loads introduced into the room by people, lights and the HVAC system; K is the thermal load of a person, which is considered constant.

T

_{zone}, vol_{air}are the temperature and the volume of air in the zone; r,c

are the air density and the specific heat at constant pressure;_{p}

**3.7 Step 2.5: Local Control System Design **

Possible configurations of local controllers must be specified considering the interactions with the supervisory system defined previously. The fixed parameters for each controller configuration must be designed together with a switching configuration policy. Each local control system is then modeled by a DPT Petri net.

In the ambulatory zone example, two configurations are considered for the PI controller of valve position. They are switched according to the signal from the management system. The DPT Petri net is presented in Figure 16. This model is connected to the management system model of Figure 11 by the enabling *arcs*, and to the equation system model of Figure 13 by the continuous variable P.

In Figure 16 the following notation is used in the equation systems:

P is the position of the three-way valve;

e(t) is the difference between zone temperature (continuous variable of zone model of Stage 3) and its setpoint;

b, L are valve constants;

K

_{1_A}, K_{2_A}, K_{3_A}, K_{1_B}, K_{2_B}, K_{3_B}are controller constants at each configuration.

**3.8 Step 2.6: Model integration **

Once all *activities *and *inter-activities *are modeled, the DPT Petri nets of the equipment are connected to the local control systems and to the P/T Petri net models of the HVAC Management System by inhibitor and enabling *arcs*. Once connected, the HVAC management system authorize/inhibit DPT net *transition *firing, which results on changing equipment states according to the evolution of the management system and to the occurrence of discrete events on other building systems. Applying this method, a global model is built. This model is formed by P/T Petri nets, PDT Petri nets and equation systems. It is important to observe that Production Flow Schema models are not part of the resulting model. They act only as auxiliary intermediate models that are replaced by Petri net based models. Figure 17 illustrates the structure of the resulting model.

**4 CONSIDERATIONS ABOUT THE SYSTEM VALIDATION **

Once that the model of the HVAC control system is built, the next step, according to Figure 4, is Step 3 - System Validation. This step can include model simulation and the verification of formal properties of the model.

The model simulation can be used to analyze the system behavior under certain conditions. An example would be verifying if the PI controllers meet theirs requirements in extreme situations, such as with the most abrupt thermal load variation. Another example can be to calculate the average energy consumption. In this case, some transition could be turned into stochastic timed transition (as in Stochastic Petri nets). As an example, the entering of people in the zone (*transition* T1 of Figure 15) could be associated to distributions representing day/night occupation of the building. To each situation, it is possible to determine the number of chillers and fans that are on at each time, and therefore, average energy consumption.

For model simulation, two kinds of simulators should be accomplished: one of Petri nets and one of differential equations. Simulators must be synchronized by events. Figure 18 illustrates the steps for a hybrid system simulation.

Firstly, the initial state is defined (the initial *marking *and initial values of continuous variables). Then, it is verified if any *transition *is active and could be fired. Both P/T net transitions and DPT net *transitions *should be tested. If possible, active *transitions *are fired. When no more *transition *could be fired, a numeric simulation using the current system of equations is performed. Between every increment of simulation time a test must be performed to verify if any *transition *could be fired. The simulation data is then used in performance analysis methods such as the PMV (people average vote) and PPD (percentage of people unsatisfied) [Fanger, 1970].

In order to analyze the ambulatory HVAC system, a simulator has been developed using MATLAB/SIMULINK?. Basically, the differential equation systems of the DPT Petri net are simulated by block diagrams in Simulink. The P/T Petri net model and the discrete part of the DPT Petri net model are simulated by MatLab subroutines and incorporated in the Simulink model by the the *MatLab-Fuction* block. The interface between the two parts (the enabling and junction functions and the choice of the equation system) are also established by Simulink blocks. The synchronization between the two parts is guarantee by the Simulink clock. More details about the developed tool can be found in [Villani et al, 2002 (a)]

For the ambulatory zone model, two example of simulation are illustrated in Figure 19, comparing the results obtained when considering or not the integration of the HVAC system with the other building systems. In the first example, (Figure 19 a) the ambulatory zone is subject to the "Occupied Zone Strategy" and considers local controller configuration switching according to thermal load variations. During the simulation two discrete event happen: after 0.5 hour a thermal load is introduced in the zone and after 1.5 hours it is removed. From the zone temperature data, the improvement in thermal comfort can be estimated. The second example compares the cold water consumption with or without the use of the "Unoccupied Zone Strategy". It is supposed that the zone is not used during between 10:00 and 12:00 in the morning and between 14:00 and 16:00 in the afternoon. Figure 19 b) presents the percentage of economy of cold water during the day.

The other way of validating the system is by verifying formal properties of the model. In this case, the property may concern only the discrete part of the model or both the continuous and discrete part.

In the first case, all approaches developed for verifying the Petri net properties could then be used for the system behavior analysis, such as invariants, reachability, liveness, boundedness, etc. As an example, it is possible to guarantee that not more than one strategy is on at a time by verifying if it is 1-boundedness. It is also possible to guarantee that one, and only one strategy is on by verifying if the management system Petri net is a place invariant. By building the reachability tree it is possible to guarantee that a situation not allowed will never happen, such as the PI controller is 'ON' and the fans are 'OFF'.

When verifying properties that involve the continuous and discrete aspects of the hybrid model, a major problem arises: the non-decidability. This means that there is no guarantee that the property can be proved with a finite number of steps. As it has been proven by (Alur et al, 1995), if continuous variables with different growing rates (different derivatives) are included in the model, then the reachability may become undecidable.

Generally, this is the case of the HVAC system models. Even with no guarantee of a solution, many methods are being studied for proving properties of hybrid systems. In [Silva et al, 2001] a comparative study of the state of art in algorithmic approaches for the verification of hybrid system is presented. According to it the complexity of the computation restricts the application of the approaches for fairly small systems (systems with around 5 continuous variables and non-linear dynamic can require some hours of computation and enormous memory consumption). This problem is mainly due to the fact that these approaches are based on model checking, i.e., they must cover all the possible state-space in order to verify a property.

In order to reduce this problem, there are proposals of techniques for decomposing the analysis problem. Once the DPT Petri net model is intrinsically modular, the approach consists in analyzing each module (or a small set of modules) at a time. When analyzing a module, hypotheses are made about the interaction of the module with other modules. In a second step, these hypotheses must be proven and may eventually generate another set of hypotheses. By this way, a complex hybrid system analysis problem is broken down in a set of simpler problems, which are more likely to be computational tractable. Another point to be considered is the incorporation in the analysis procedure of the designer knowledge about system (for example in the definition of the set of hypotheses). These activities are then made "manually" by the designer (the analysis procedure cannot be fully automated), resulting in a balanced approach where man and computer aid can be incorporated in a synergetic way in order to solve complex problems. First results concerning these studies have been published in [Villani et al, 2002 (b)].

**5 CONCLUSIONS **

In this paper, a novel hybrid modeling approach for HVAC control system design in Intelligent Buildings has been introduced. The hybrid approach is necessary in order to achieve system integration. This top-down approach starts from Production Flow Schema models, and by successive refinements Petri net models are built considering system integration with other building systems. The discrete part is modeled using P/T Petri nets and the continuous part is modeled using differential equation systems. The interface between these two parts is provided by DPT nets. Although other tools might be used, Petri net is chosen due to its graphical capacity of representing concurrency, parallelism and sequencing of events, which are more suitable with the level of abstraction of the HVAC Management System.

The problem of HVAC control system behavior analysis is also approached. For the discrete part, the formal analysis techniques of Petri nets could be used. For the overall hybrid system simulation, a simulator has been developed using MATLAB/SIMULINK®. Methods for the formal verification of model properties are also under development.

Once the models have been analyzed, it should be translated into a programming language code in order to be implemented. Future directions of this work must also contemplate a method for translation that guarantee that the behavior modeled and analyzed using Petri nets will be preserved.

**ACKNOWLEDGEMENTS**

Authors acknowledge the collaboration and financial support of the Medical School Hospital of the University of São Paulo (HC-FMUSP), and the Brazilian governmental agencies FAPESP, CNPq, CAPES, RECOPE/FINEP. They also thank Prof. Emilio C. N. Silva for the English language revision.

**REFERENCES**

Alla, H. & David, R. (1998). Continuous and Hybrid Petri Nets, *Journal of Circuits, Systems and Computers*, Vol.8, n.1, pp. 159-188. [ Links ]

Antsaklis, P. J. & Nerode, A. (1998). Hybrid Control Systems: An Introductory Discussion to the Special Issue. *IEEE Transactions on Automatic Control*, Vol.43, pp. 457-460. [ Links ]

Arkin, H. & Paciuk, M. (1995) Service Systems Integration in Intelligent Buildings. *Proc. of IB/IC Intelligent Buildings Congress*, Telaviv. [ Links ]

Becker, R. (1995). What is an Intelligent Building. *Proc of IB/IC Intelligent Buildings Congress*, Telaviv. [ Links ]

Champagnat, R. et al (1998). Modelling and Simulation of a Hybrid System through Pr/Tr PN-DAE Model. *Proc.of the 3*^{th}* International Conference on Automation of Mixed Processes (ADPM' 98), *Reims. [ Links ]

David, R & Alla, H. (1994). Petri Nets for Modeling of Dynamic Systems - A Survey. *Automática*, Vol.30, n.2, pp.175-201. [ Links ]

Fanger, P.O. (1970). *Thermal Comfort*, McGraw-Hill, New York. [ Links ]

Guéguen, H. & Lefebvre, M. A. (2000). A comparison of mixed specification formalisms. *Proc.of the 4*^{th}* International Conference on Automation of Mixed Processes (ADPM 2000)*, Dortmund. [ Links ]

Ho, Y.C. (1989). Scanning the issue - Dynamics of discrete event systems. *Proceedings of IEEE*, Vol.77, pp. 3-6. [ Links ]

Honeywell (1995). *Engineering Manual of Automatic Control - HVAC.* Honeywell, New York. [ Links ]

Miyagi, P. E. (1996). *Controle Programável - Fundamentos do Controle de Sistemas a Eventos Discretos*, Edgar Blücher, São Paulo. [ Links ]

Miyagi, P.E. et al. (1997). Application of PFS Model Based Analysis of Manufacturing Systems for Performance Assessment. *Journal of the Brazilian Society of Mechanical Sciences*, Vol.19, n.1, pp.58-71. [ Links ]

Ogata, K. (1990) *Modern Control Engineering*, Englewood Cliffs, New Jersey. [ Links ]

Reisig, W. (1985). *Petri Nets - An Introduction. *Spring Verlag, New York. [ Links ]

Silva, J.R. & Miyagi, P.E. (1996). A Formal Approach to PFS/MFG: A Petri Net Representation of Discrete Manufacturing Systems, *Studies in Informatics and Control*, Vol.5, n.2. [ Links ]

Silva, B. I. et al (2001). An Assessment of the Current Status of Algorithmic Approaches to the Verification of Hybrid Systems. *40th IEEE Conference on Decision and Control*, Orlando. [ Links ]

Villani, E. (2000). *Abordagem Híbrida para Modelagem de Sistemas de Ar Condicionado em Edifícios Inteligente*. Dissertação de mestrado, Escola Politécnica da USP, São Paulo. [ Links ]

Villani, E. et al (2002a) Simulação de Sistemas Híbridos usando MatLab/Simulink. *Anais do II Congresso Nacional de Engenharia Mecânica (CONEM 2002)*, João Pessoa. [ Links ]

Villani, E. et al (2000b). Petri nets and Object-Oriented Approach for the Analysis of Hybrid Systems. *Anais do XIV Congresso Brasileiro de Automatica (CBA 2002)*, Natal. [ Links ]

Whitten, N. (1995). *Managing software development process: formulae for success *Willey, New York. [ Links ]

Artigo submetido em 26/06/02

1a. Revisão em 26/09/02; 2a. Revisão em 10/04/03

Aceito sob recomendação do Ed. Assoc. Prof. Takashi Yoneyama