Fire-alarm systems

Defining the system context. A fire-alarm system is a relatively autonomous sys-

tem, but it does provide a number of interfaces to its context. The first issue to decide whether the mechanical and hardware parts of the detectors and alarm devices are part of the system or not. Since we are concerned with the architecture of the software system, we consider those parts to be external and consequently interfaces exist between the software system and the physical detectors and alarm devices.

As second issue that we need to decide upon is whether the communication system is part of the system at hand, because the fire-alarm system is highly distributed in nature. In this case, we decide that communication is included as a part since it forms an integral part of the fire-alarm system functionality.

A second interface of the system is towards the operator of the system. In the case of an alarm, but also for activating and deactivating parts of the system and moni- toring its behavior. This amount of variability of the functionality of the interface is very large, but one can identify a number of core issues that need to be retrievable via the operator interface, such as the location of an alarm or fault warning in the building. Part of this interface is the interaction with external contacts that need to be notified when the system enters certain states, e.g. alarm, such as the local fire station.

A third interface, although related to the previous, is concerned with the interaction to other building automation systems. Other systems may be interested in certain events that take place in the fire-alarm system and may request to be notified. Sim- ilarly, the fire-alarm system may want to affect the state and behavior of other sys- tems, e.g. in case of a fire in a part of the building, the passage-control system may

Illustrating Functionality-Based Design

be ordered to unlock all doors in that part allowing people to leave the building without having to use their cards and codes at every door.

FIGURE 7.Interfaces of the fire-alarm system

In figure 7, the interfaces provided by the fire-alarm system are presented graphi- cally. As discussed earlier, in a real design, one would assign functional and quality requirements to the identified interfaces and define the interaction at these inter- faces in more detail. However, we leave this step here to avoid exposing unneces- sary details of the system.

Identifying the archetypes. When searching for entities that grasp the behavior of

several entities and are still abstract, one can detect a number of candidates. Among these, we will use the following as archetypes:

•

fire-alarm domain functionality. It is the abstraction of the two subsequent archetypes.

•

equipment, including smoke and temperature sensors.

•

traditional alarms, such as bells, extinguishing systems, operator interfaces and alarm notification to, e.g., fire stations.

Functionality-based Architectural Design

•

groups of points are located at control units that interact with the detectors and outputs in the group. Control units are connected to a network and can commu- nicate. The latter is of crucial importance since the detector alarms in one con- trol unit should often lead to the activation of outputs in other control units. In figure 8, the relations between the archetypes are shown. As discussed earlier, detector and output are specializations of point and points are contained in control units. Control units communicate with other control units to exchange data about detectors and to activate outputs.

FIGURE 8.Relations between the fire alarm system archetypes

Describing system instantiations. The first activity in this step is to identify sub-

systems. The actual system design is decomposed in six main subsystems. How- ever, since we scaled down the actual system for illustrative purposes, we identify only those subsystems directly related to the identified archetypes for the example fire-alarm system.

FIGURE 9.Subsystems of the fire-alarm system

To understand the instantiation of the fire-alarm system, we present two system instantiation that are at the two extreme ends of the complexity scale. The first sys-

Point

(from java.awt)

Detector Output

ControlUnit

Illustrating Functionality-Based Design

tem, shown in figure 10, represents a small system that might be found, for exam- ple, in a single family house. It consists of a small set of detectors, five smoke detectors in the example, one control unit and two outputs, i.e. a sound alarm and a simple LED-based user interface. The functionality available to the user is to acti- vate or deactivate the system and the feedback from the system is an indication for alarm and one for faults, i.e. internal system errors.

FIGURE 10.Example small fire-alarm system instantiation

A considerably larger example of an instantiated fire-alarm system is shown in fig- ure 11. The fire-alarm system covers a site consisting of two buildings and each building is divided into 4 sections. Each section is supervised by a control unit. One of the control units has an operator interface as a point connected to it. Since the

Functionality-based Architectural Design

control units are able to communicate with each other, the operator can monitor the complete system from the control unit that the interface is connected to.

FIGURE 11.Example two-building fire-alarm system