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.
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
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:
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.
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
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 rooms 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
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
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
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.
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
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:
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
Finally, we show the event trace which validates that scenario for Water ready for pumping in Delivery domain.
In this appendix we include a number of diagrams which in fact belong to OOA but are included here for completeness. The diagrams are:
Click here for a Home Heating System prototype in Java
[ Homepage | Articles ]