A Simple HVAC System Simulation Part I Focusing

A Simple HVAC System Simulation Part I (Focusing on UML modelling and not physics) Jan Pettersen Nytun HVAC stands for Heating, Ventilation, and Air Conditioning. We ignore ventilation and focus on heating and cooling (air conditioning).

Outline • UML Diagrams – Class, Use case, activity, object, communication, sequence • Transform to Java • Design Patterns – Abstract factory – “Abstract” factory with use of interfaces • Running the simulation 2

Overview Room Outside Cooler Temperature Sensor Heater Temperature Setpoint Thermostat HVAC System From Wikipedia: A thermostat is a device for regulating the temperature of a system so that the system's temperature is maintained near a desired setpoint temperature. The thermostat does this by controlling the flow of heat energy into or out of the system. That is, thermostat switches heating or cooling devices on or off as needed to maintain the correct temperature. 3

UML Class Diagram From Wikipedia In the Unified Modelling Language (UML), a class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. 4

UML Diagrams Shown With The Help Of A UML Class Diagram Italic indicates abstract class Diagram Generalization Structure Diagram Class Diagram Component Diagram Composite Structure Diagram Behaviour Diagram Object Diagram Deployment Diagram Activity Diagram Package Diagram State Machine Diagram Interaction Diagram Sequence Diagram None-italic indicates concrete class Use Case Diagram Interaction Overview Diagram Communication Diagram Timing Diagram 5

Behaviour Modelling Use Case Diagram Structure Diagram Class Diagram Component Diagram Composite Structure Diagram Behaviour Diagram Object Diagram Deployment Diagram Activity Diagram Package Diagram Use Case Diagram State Machine Diagram Interaction Diagram Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram 6

UML Use Case Diagram From Wikipedia A use case diagram is a type of behavioural diagram defined by the Unified Modelling Language (UML). Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals—represented as use cases—and any dependencies between those use cases. 7

Simulation Seen From The User Point Of View From Wikipedia: Wooden mechanical horse simulator during WWI. UML Use Case Diagram The simulation is meant* as a tool for deciding dimensions of HVAC systems! * Actually it is meant as a pedagogical tool when teaching UML/Java. 8

Behaviour Modelling Activity Diagram Structure Diagram Class Diagram Component Diagram Composite Structure Diagram Behaviour Diagram Object Diagram Deployment Diagram Use Case Diagram Activity Diagram Package Diagram State Machine Diagram Interaction Diagram Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram 9

Activity Diagram From Ambysoft Inc. , Scott W. Ambler: http: //www. agilemodeling. com/artifacts/activity. Diagram. htm UML 2 activity diagrams are typically used for business process modelling, for modelling the logic captured by a single use case or usage scenario, or for modelling the detailed logic of a business rule. Although UML activity diagrams could potentially model the internal logic of a complex operation it would be far better to simply rewrite the operation so that it is simple enough that you don’t require an activity diagram. In many ways UML activity diagrams are the objectoriented equivalent of flow charts and data flow diagrams (DFDs) from structured development. 10

Overall Functioning Of Simulation Application Activity Diagram 11

Background Information/ Decisions/Assumptions • The Kelvin scale is an absolute temp. scale where the coldest possible temp. is 0 Kelvin. Relation between Celsius degrees and Kelvin degrees is given by: °C = K − 273. 15 • The temperature in the room is influenced by the outside and the HVAC system. • Outside has a given temp. , stated in Kelvin; the same have heaters and coolers of the HVAC. 12

Structure Modelling Class Diagram Structure Diagram Class Diagram Component Diagram Composite Structure Diagram Behaviour Diagram Object Diagram Deployment Diagram Activity Diagram Package Diagram Use Case Diagram State Machine Diagram Interaction Diagram Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram 13

Analysis Model (Platform Independent Model (PIM)) 14

Background Information/ Decisions/Assumptions • We introduce the concept temperature exchanger. Outside, heaters and coolers are temperature exchangers. • A temperature exchanger is characterized by its temperature and also by its ability to transfer heat (chill) to the room. • The heat transfer of a working temperature exchanger is dependent on it’s environment; in our case this is the conditions of the room; we hardcode this. The heat transfer is also dependent on it’s physics, e. g. the heat transfer of a radiator with large surface is greater than for one with a small surface. • The heat transfer of a cooler or heater that is turned of is assumed to be 0. 15

Calculating Room Temp. • It is assumed that room temperature is established momentarily. • Room temp. in Kelvin is given by: n Σ (TE. temp* TE. transfer) i Room temp. = i i=1 n Σ (TE. transfer) i i=1 where TEi. temp is the temperature of temperature exchanger i and TEi. transfer is the heat transfer of temperature exchanger i. 16

Regulating Temperature Exchangers • Some temperature exchangers can not be turned off, e. g. outside. • Some temperature exchangers can be turned off and on, e. g. heaters. • Some temperature exchangers can operate in steps, e. g. a heater that can be off, “on state 1”, “on state 2”, … We model this by assigning a “current step” (as an index) to the temperature exchanger and having an array of temperature values corresponding to the different steps. If current step equals 0 then heat transfer is 0, the other steps correspond to different temperatures! 17

Design Model (PIM) 18

Structure Modelling Object Diagram Structure Diagram Class Diagram Component Diagram Composite Structure Diagram Behaviour Diagram Object Diagram Deployment Diagram Activity Diagram Package Diagram Use Case Diagram State Machine Diagram Interaction Diagram Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram 19

UML Object Diagram From Wikipedia In the Unified Modelling Language (UML), an object diagram is a diagram that shows a complete or partial view of the structure of a modelled system at a specific time. This snapshot focuses on some particular set of object instances and attributes, and the links between the instances. . . Object diagrams are more concrete than class diagrams, and are often used to provide examples, or act as test cases for the class diagrams. 20

Room Outside Cooler Temperature Sensor Heater Temperature Setpoint Thermostat UML Object Diagram 21

A Class Diagram Typically Defines an Infinite Set Of Possible Object Diagrams Object Diagram Class Diagram Object Diagram 22

Behaviour Modelling Communication Diagram Structure Diagram Class Diagram Component Diagram Composite Structure Diagram Behaviour Diagram Object Diagram Deployment Diagram Activity Diagram Package Diagram Use Case Diagram State Machine Diagram Interaction Diagram Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram 23

Communication Diagram From Wikipedia A Communication diagram models the interactions between objects or parts in terms of sequenced messages… …, communication diagrams use the free-form arrangement of objects and links as used in Object diagrams. In order to maintain the ordering of messages in such a free-form diagram, messages are labelled with a chronological number and placed near the link the message is sent over. Reading a communication diagram involves starting at message 1. 0, and following the messages from object to object. 24

A Communication Diagram Without Messages Correspond To An Object diagram 25

Introduction Of Operations • In our case a message is a call of an operation done by one object on another object. • In our case the calls will be synchronized like you have it in Java, i. e. the caller is blocked during the call (waiting for the return). 26

Setting Up The Simulation Communication Diagram Simulation. Monitor is a new class 27

Behaviour Modelling Sequence Diagram Structure Diagram Class Diagram Component Diagram Composite Structure Diagram Behaviour Diagram Object Diagram Deployment Diagram Activity Diagram Package Diagram Use Case Diagram State Machine Diagram Interaction Diagram Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram 28

Sequence Diagram From Wikipedia The well-known Message Sequence Chart technique has been incorporated into the Unified Modelling Language (UML) diagram under the name of Sequence Diagram. A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner. 29

Sequence Diagram 30

Model For Mapping To Java Navigations have been introduced 31

Create A Transformation 32

Source And Target For Transformation 33

Running The Transformation This generated many errors since some getters and setters already where included! 34

Some Generated Code package airtemp; import java. util. Set; public class Simulation. Monitor { private Set<Temp. Exchanger> tempexchanger; private Room room; public void set. Up() { } public void run. Simulation() { } package airtemp; import java. util. Set; } public class Room { private double temp; private Set<Temp. Exchanger> temp. Exchanger; public void get. Temp() { } public void set. Temp(double tem) { } } 35

More Generated Code public class Temp. Exchanger { private double temp; private double current. Heat. Transfer; public void set. Current. Heat. Transfer(double current. Heat. Transfer) { } public void set. Temp(double temp) { } public double get. Temp() { return 0; } public double get. Current. Heat. Transfer() { return 0; } } public class Step. Temp. Exchanger extends Temp. Exchanger { private double[] steps = null; private Integer current. Step; private Integer number. Of. Steps; public void set. Steps(double[] steps) { } public void turn. On() { } public void turn. Off() { } public Integer get. Current. Step() { return null; } public void set. Current. Step(Integer step) { } } 36

Dependency in UML From Wikipedia • • • A dependency exists between two defined elements if a change to the definition of one would result in a change to the other. This is indicated by a dashed arrow pointing from the dependent to the independent element. A dependency can be between instances, classes, or both. Dependency is a model-level relationship and not a run-time relationship - describing the need to investigate the model definition of the client element for possible changes if the model definition of the supplier element is changed. UML-defined dependencies include: – «use» UML 2: The client element somehow "uses" the supplier «use» – «call» UML 2: The client (an operation) may call the supplier (an operation) – «create» UML 2: The client (a classifier) may create instances of the supplier (a classifier) – «derive» UML 2: The client (e. g. , attribute value, link) may be computed from the supplier(s) – «instantiate» UML 2: Operations of the client (a classifier) may create instances of the supplier (a classifier) – «refine» UML 2: The client element(s) are at a "later" semantic level than the supplier(s) – «trace» UML 2: The client elements "trace" to the suppliers. Typically used for levels of requirements 37

Our Tool Got A Special Type of Class Diagram Tailored for Java (Java Profile) • If we “drag” the classes generated onto such a diagram they appear stereotyped as Java Class. • Associations with multiplicity many appear as dependencies and they also appear as attributes inside the class. • “Of some reason” associations with multiplicity zero or one appear only as attributes. transform from transform to 38

All Generated Classes 39

Design Patterns From Wikipedia • In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. • A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. • Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. • Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems. • Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software design. Other kinds of patterns, such as architectural patterns, describe problems and solutions that have alternative scopes. 40

Abstract Factory [1] Will Be Used In The Design Provides an interface for creating families of related or dependent objects without specifying their concrete classes. Example: An application supporting multiple look-and-feel standards like Windows and Motif. Most of the code should be without knowledge of which look-and-feel that is used. 41

The Abstract Factory Pattern Will Be Used From Wikipedia • In software development, a Factory is the location in the code at which objects are constructed. The intent in employing the pattern is to insulate the creation of objects from their usage. This allows for new derived types to be introduced with no change to the code that uses the base class. • Use of this pattern makes it possible to interchange concrete classes without changing the code that uses them. . . 42

Abstract Factory: Example [1] Client Widget. Factory create. Scroll. Bar() create. Window() Widget. Factory is abstract, so either Motif. Factory or Windows. Factory is instantiated Scroll. Bar «instantiate» Windows. Scroll. Bar Motif. Factory create. Scroll. Bar() create. Window() Windows. Factory Motif. Scroll. Bar Window create. Scroll. Bar() create. Window() «instantiate» Windows. Window Motif. Window 43

Abstract Factory: Object Diagram … Widget. Factory factory = new Motif. Factory(); . . . Scroll. Bar sb = factory. create. Scroll. Bar(); … Window win = factory. create. Window() … Motif look-and-feel is selected; Create. Scroll. Bar and Create. Window are called. factory: Motif. Factory : Client sb: Motif. Scroll. Bar win: Motif. Window 44

Abstract Factory: a General Class Diagram Abstract. Factory Client Abstract. Product. A create. Product. A() create. Product. B() «instantiate» Concrete. Factory 1 create. Product. A() create. Product. B() Concrete. Factory 2 Product. A 1 Abstract. Product. B create. Product. A() create. Product. B() «instantiate» Product. B 2 Product. B 1 «instantiate» 45

We Will Use Interfaces Instead Of Inheritance To Implement The Pattern package airtemp; import java. util. Array. List; public interface Room { public abstract void set. Temp. Exchanger(Array. List<Temp. Exchanger> temp. Exchanger); public abstract double get. Temp(); } package airtemp. impl; … public class Room. Impl implements Room { private Array. List<Temp. Exchanger> temp. Exchanger; public double get. Temp() { … 46

The Factory package airtemp. impl; import airtemp. Air. Temp. Factory; import airtemp. Cooler; … public class Air. Temp. Factory. Impl implements Air. Temp. Factory{ public Cooler create. Cooler(){ return new Cooler. Impl(); } … } The potential benefit of using a factory in this example is not so big since the creation of objects is done in one place and not spread to many different parts of the code! 47

Overview #1 After Some Massage package airtemp; public class Simulation. Monitor. App extends Simulation. Monitor { public static void main(String[] args) { Simulation. Monitor. App simulation. Monitor. App = new Simulation. Monitor. App(); simulation. Monitor. App. assemble. Objects(); simulation. Monitor. App. get. User. Input(); simulation. Monitor. App. run. Simulation(); } } 48

… public class Simulation. Monitor { private Air. Temp. Factory. Impl air. Temp. Factory. Impl = new Air. Temp. Factory. Impl(); private Room room = air. Temp. Factory. Impl. create. Room(); … public void assemble. Objects() { System. out. println("Assembling the objects. "); heater. turn. On(); cooler. turn. On(); Array. List<Temp. Exchanger> temp. Exchanger = new Array. List<Temp. Exchanger>(); temp. Exchanger. add(outside); temp. Exchanger. add(heater); temp. Exchanger. add(cooler); room. set. Temp. Exchanger(temp. Exchanger); Array. List<Cooler> coolers = new Array. List<Cooler>(); coolers. add(cooler); thermostat. set. Cooler(coolers); Array. List<Heater> heaters = new Array. List<Heater>(); heaters. add(heater); thermostat. set. Heater(heaters); thermostat. set. Temp. Sensor(temp. Sensor); temp. Sensor. set. Room(room); } public void get. User. Input() { … } public void run. Simulation() { System. out. println("n--- Simulation starts ---n"); for (int outside. Temp = -20; outside. Temp<=40; outside. Temp++){ double outside. Temp. Kelvin = outside. Temp + 273. 15; outside. set. Temp(outside. Temp. Kelvin); thermostat. regulate(); System. out. printf("n. Heater on: %b Cooler on. : %b n", heater. is. On(), cooler. is. On()); double inside. Temp = room. get. Temp() - 273. 15; System. out. printf("Outside temp. : %d Inside temp. : %. 2 f n", outside. Temp, inside. Temp); } } } 49

Overview #2 The Temp. Exchanger hierarchy 50

Overview #3 51

Overview #4 (A Bit Chaotic) 52

… public class Thermostat. Impl implements Thermostat { private double desired. Temp; private Temp. Sensor temp. Sensor; private Array. List<Heater> heater; private Array. List<Cooler> cooler; public void regulate(){ final double temp. Delta = 0. 5; double current. Temp = temp. Sensor. get. Temp(); if (current. Temp <= (desired. Temp + temp. Delta) && current. Temp >= (desired. Temp - temp. Delta)) return; if (current. Temp < desired. Temp){ for(Cooler cool : cooler){ cool. turn. Off(); } for(Heater heat : heater){ heat. turn. On(); } } else { for(Cooler cool : cooler){ cool. turn. On(); } for(Heater heat : heater){ heat. turn. Off(); } } } … 53

Running Simulation Assembling the objects. Get parameters governing the simulation. Give desired temp. (C): 20 Give heat transfer for outside: 10 Give heat transfer for heater: 2 Give heater max. temp (C): 200 Give heat transfer for cooler: 2 Give cooler min. temp (C): -50 Heater on: true Cooler on. : false Outside temp. : 32 Inside temp. : 60. 00 Heater on: false Cooler on. : true Outside temp. : 33 Inside temp. : 19. 17 --- Simulation starts --- Heater on: false Cooler on. : true Outside temp. : 34 Inside temp. : 20. 00 Heater on: true Cooler on. : false Outside temp. : -20 Inside temp. : 16. 67 Heater on: true Cooler on. : false Outside temp. : -19 Inside temp. : 17. 50 Heater on: true Cooler on. : false Outside temp. : -18 Inside temp. : 18. 33 Heater on: true Cooler on. : false Outside temp. : -17 Inside temp. : 19. 17 Heater on: true Cooler on. : false Outside temp. : -16 Inside temp. : 20. 00 Heater on: false Cooler on. : true Outside temp. : -15 Inside temp. : -20. 83 Heater on: true Cooler on. : false Outside temp. : -14 Inside temp. : 21. 67 … Heater on: false Cooler on. : true Outside temp. : 31 Inside temp. : 17. 50 Heater on: false Cooler on. : true Outside temp. : 35 Inside temp. : 20. 83 heater to weak cooler to weak Heater on: false Cooler on. : true Outside temp. : 36 Inside temp. : 21. 67 Heater on: false Cooler on. : true Outside temp. : 37 Inside temp. : 22. 50 Heater on: false Cooler on. : true Outside temp. : 38 Inside temp. : 23. 33 Heater on: false Cooler on. : true Outside temp. : 39 Inside temp. : 24. 17 Heater on: false Cooler on. : true Outside temp. : 40 Inside temp. : 25. 00 54

Some Comments • It seems that the simulation can be used to detect if dimensions of heaters and coolers are to low! • The approach of the application seems to be: set parameters and then calculate room temp. • The approach is a very “static” and quite different from real life, e. g. a real thermostat might sample the temp. sensor regularly and the room would dynamically change temp. We can achieve a more dynamic system by using program threads! 55

References [1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns Elements of Reusable Object-oriented Software Addison-Wesley, 1995 [2] Christopher Alexander et al. : A Pattern Language Oxford University Press, New York, 1977 56