Requirements Document for Home Heating System (HHS)
Version 2

Summary

This document is the definitive requirements description for the well-documented home heating system (see [Booch91] and [Hatley88]). Our approach differs from others in a number of ways and the resulting structure ensures that a number of the limitations and shortcomings of object-oriented methods (such as OMT and UML) can be avoided. This requirements document can be used as input to UML and OMT.
The system ‘HHS’ is an instance of a process control system.

 

1. Goals and Scope of Problem

A system needs to be developed which ensures that the temperature in the rooms of a house does not fall below a certain level. The system to be developed transforms raw materials (for example, oil or gas) into heat. This is achieved by burning the raw materials whereby the released energy is transferred to a water storage which in turn is circulated to the rooms in the house via a network of pipes which connect up to radiators in the rooms. It is through these radiators that heat is convected to the rooms which in turns raises the temperature.

The system to be developed is intelligent in the sense that it knows when the owner is at home or not and furthermore, it can adapt to the living pattern of the owner.

We view HHS as a black box which interacts with its environment. In particular, we need to determine the external agents with which it communicates. In this application they are represented by the owner of the house, the environment (which produces changes in room temperature) and the source of the oil supply. In other words, these abstractions fall outside the system and will not be modelled. The control context diagram for HHS is shown in Figure 1. It shows the main external agents including the control flow between them and the system. The ‘Owner’ terminator is responsible for starting and stopping the system, adjusting the reference or desired temperature. The system senses when the owner has arrived home or is no longer at home. The ‘Oil Supply’ terminator is the source of those raw materials which will be transformed by the system into other products. Finally, the ‘Environment’ terminator produces changes in ambient temperature and these changes are made known to HHS.

Figure 1: Control Context Diagram

Figure 1: Control Context Diagram

 

The major responsibility of HHS is to ensure that the temperature in the home is within reasonable bounds at all time. In this sense we see HHS as a soft real-time system and in this sense timing requirements do not play a major role. We consider the systems goals to be achieved if the desired temperature in the home is achieved at some reasonable interval after the system has been started or when a temperature drop takes place. Furthermore, a feasibility study has already taken place and this study has determined that the installed hardware has sufficient capacity to heat the home to the desired temperature. Finally, the current system does not model the following important subproblems:

 

2. Finding Functional Domains (ANSI/SPARC Model)

Based on the manufacturing metaphor we partition HHS into three functional domains which we call Delivery (internal layer), Regulator (conceptual layer), Control (external layer). The Delivery domain is responsible for processing the raw materials, heating water which will be pumped to the radiators in the home. The Regulator domain is responsible for ensuring that the home temperature remains within the desired range while the Control domain contains the strategic controls for starting, stopping and displaying status information about the system.
The above three domains are constructed according to the Information Hiding Principle; communication between the different domains is allowed at the very highest level but it is not possible for one domain to access the lower-level domains or objects of another domain.

 

3. Elaboration of Functional Domains

As mentioned in section 1, a feasibility study has been carried out to determine what the optimal combination of hardware which together forms the system to be built.

The Delivery domain uses a furnace whose job it is to burn oil, warm water and eventually pump this water to the radiators in the home. The furnace consists of a number of components, namely:

 

Each of these components serves some purpose. The oil valve controls the flow of oil to the furnace from the oil supply. The motor control consists of a motor (which in its turn consists of two windings) and two sensors, one of which determines when the motor has fully started while the other sensor checks whether the motor has become overheated during startup or while in operation. The function of the ignitor is ensure that ignition is started or stopped. Finally, the sensor unit consists of three sensors which monitor the following possible events:

 

The structure of the Delivery domain is given in Figure 2 in the form of a class diagram (in practice we need to iterate a number of concept maps before arriving at this stage but these intermediate phases are not included).

Figure 2: Delivery Domain

Figure 2: Delivery Domain

 

The main responsibility of the Regulator domain is to monitor and control the temperature in the home (we are modelling one room in this version of the requirements). A number of physical devices is situated in the room; first, a water valve which guards the flow of warm water to the room’s radiators, two sensors which determine if the owner has entered or left the room and which determines what the current temperature is in the room, respectively. In order to be able to change the desired reference temperature, the room contains a thermostat.

Finally, associated with the room is a so-called living pattern which knows when the owner is due home each day of the week. The living pattern is updated when deviations from the established arrival pattern occurs two weeks in a row.

The structure of the Regulator domain is given in Figure 3.

Figure 3: Regulator Domain

Figure 3: Regulator Domain

 

The Control domain consists of an output display and an input panel. At this stage the panel consists of one master switch (This may change in later versions).

The structure of the Control domain is given in Figure 4.

Figure 4: Control Domain

Figure 4: Control Domain

 

4. Events and Scenarios

There are three agents, namely the owner, the environment and the oil supply. As can be seen from Figure 1 the system reacts to external events originating from these agents.

These events are:

// From the owner
E1: Press ON on master switch
E2: Press OFF on master switch
E3: Change reference temperature using the thermostat
E4: Owner arrives home
E5: Owner leaves home
E6: Owner is expected home

// From the environment
E7: Room temperature drops below accepted limit

// From the oil supply
E8: Fuel flow problems

 

These major external events lead to the following scenarios:

S1: Startup HHS
S2: Shutdown HHS
S3: New thermostat reading
S4: Heat room for owner presence
S5: Stop heating room due to owner departure
S6: Prepare room for owner
S7: Heat room because of temperature drop
S8: Emergency shutdown due to fuel flow problems

 

5. Scenario Elaboration

We now document each of the scenarios in section 4 according to the standard layout techniques described earlier.

Name of scenario: Startup HHS (Scenario S1)

Summary: This scenario describes how the HHS system is started with the eventual objective of warming the home.

Preconditions: The system is not in the restart period (typically 5 minutes). This means that there is a cool-off period in which the system is disabled. The owner must wait until this period has expired until the system can be started again.
The system will not start if is already in an abnormal condition.

Domain: HHS

Description: The scenario is started when Control receives a signal from its panel. The Regulator is enabled and we must determine if the room needs heat. When this is the case the Delivery is activated and after a given interval the Delivery notifies the Regulator that warm water is available. Then the room may be warmed.

Exceptions and Special Cases: The main possible error situations are:

The exception in the first case may be caused by any number of lower level exceptions but these are not visible at this level.

Postconditions: Room is being warmed

Sequence diagram

 

In this event trace we discover a new scenario ‘needs heat?’ which determines if the room needs heat or not. This is room-based and it can be documented as before. However, we restrict ourselves to an event trace as follows:

Sequence diagram

 

Name of scenario: Shutdown HHS (Scenario S2)

Summary: This scenario describes the sequence of steps which occur when HHS is shutdown.

Preconditions: HHS not in abnormal condition.

Domain: HHS

Description: When Control receives the OFF event it signals the Regulator to top monitoring the room. This means that heat is no longer need and thus the Delivery is deactivated. When this occurs the Regulator informs the room and the room can take action based on this information.

Exceptions and Special Cases: Delivery may fail to deactivate

Postconditions: System is inactive.

Sequence diagram

 

Remark: The Delivery-based scenarios which correspond to the events ‘activate’ and ‘deactivate’ are not discussed here because they are part of the Datasim OOA/OOD course notes.

 

Name of scenario: New thermostat reading (Scenario S3)

Summary: This scenario describes what happens when the owner chooses a new desired reference temperature and the current room temperature is too low. Thus, action is needed.

Preconditions: None

Domain: Room

Description: The owner changes the value in the thermostat. The room is informed of this change. The difference between the current and desired temperatures is calculated. Too large a difference means that heat is needed and a signal is sent to the Regulator to this effect.

Exceptions and Special Cases: New reading but no action needed

Postconditions: Room waiting to be heated.

Sequence diagram

 

Name of scenario: Heat room because of owner arrival (Scenario S4)

Summary: This scenario describes what happens when the owner arrives home and the temperature is not to his liking.

Preconditions: None

Domain: Room

Description: The occupancy sensor signal movement and informs the room of this. The temperature difference is measured top see if action is needed (which is the case). Then, the Regulator is signalled that heat is needed.
The living pattern is informed of the fact that the owner has come home and it will register the time of homecoming for future reference.

Exceptions and Special Cases:

 

Postconditions: Room waiting to be heated

Sequence diagram

 

Name of scenario: Stop heating room because of owner departure (Scenario S5)

Summary: This scenario describes what should be done when the owner has been out of the room for some time.

Preconditions: None

Domain: Room

Description: The occupancy sensor has failed to detect occupancy for longer than a given period. In this sense we conclude that the owner is not home and thus it is no longer to heat the room. The Regulator is informed of this fact.
The living pattern is informed of the time at which we suspect that the owner left the room.

Exceptions and Special Cases:

Postconditions: Room not waiting to be heated.

Sequence diagram

 

Name of scenario: Heat room because of impending owner arrival (Scenario S6)

Summary: This scenario describes what happens when the owner is expected home. In this case the living pattern knows when this event is supposed to happen and the room can be gradually be warmed up.

Preconditions: None

Domain: Room

Description: The living pattern informs the room of the impending arrival. The temperature difference is measured and the Regulator is informed of the fact that warm water is needed.

Exceptions and Special Cases: No heat needed as room is warm enough

Postconditions: Room is waiting to be heated.

Sequence diagram

 

Name of Scenario: Heat room because if temperature drop (Scenario S7)

Summary: The current temperature in the room drops to such a level that the Regulator needs to be informed of the situation.

Preconditions: None

Domain: Room

Description: The current temperature sensor notices a change in room temperature and inform the room of this. The current temperature difference is calculated and the Regulator is signalled if this value is too large.

Exceptions and Special Cases: Temperature drop but no action is needed

Postconditions: Room waiting to be heated

Sequence diagram

 

Name of Scenario: Emergency shutdown because of fuel flow problems (Scenario S8)

Summary: The fuel flow sensor (indicator) signals that there is no more fuel. The system should be deactivated. This is in fact an abnormal scenario.

Preconditions: None

Domain: HHS

Description: A state change in the fuel flow sensor signal via a chain of events that the system must be shut down (for more details, see the accompanying event trace).

Exceptions and Special Cases:

Postconditions: Systems is in tilt mode.

The following event trace shows the sequence of steps which take place as the fault makes its way up the object hierarchy.

Sequence diagram

 

Finally, we show the event trace which validates that scenario for ‘Water ready for pumping in Delivery domain.

Sequence diagram

 

Appendix: Event Flow Diagrams and Harel Statecharts for HHS Problem

In this appendix we include a number of diagrams which in fact belong to OOA but are included here for completeness. The diagrams are:

Event flow diagram

 

State diagram

 

State diagram

 

State diagram

 

State diagram

 

State diagram

 

State diagram

 

State diagram

 

State diagram

 

State diagram

 

References

  1. [Booch91] G. Booch ‘Object-Oriented Design with Applications’, Benjamin Cummings Redwood City CA 1991.
  2. [Duffy95] Daniel J. Duffy ‘From Chaos to Classes, Software Development in C++’, McGraw-Hill London UK 1995.
  3. [Hatley88] D. J. Hatley, I. A. Pirbhai ‘Strategies for Real-Time System Specification’, Dorset House New York 1988.

 

Click here for a Home Heating System prototype in Java

[ Homepage | Articles ]