INFO6030 - Systems Analysis and Design
Introduction
The University of Newcastle is replacing its old fire management system for all their buildings. The fire management system is responsible not only for fire detection, but also for managing parts of the early suppression, compartmentation, and evacuation processes of the University’s fire emergency response procedures. This also includes providing crucial information and control to fire-fighting services on-site. The fire management system (FMS) operates as a hub-and-spoke model, with a central hub managed by the University’s Infrastructure and Facilities Services (IFS). The hub maintains a registry of all buildings operated by the University and connects to the local fire indicator panel (FIP, sometimes also referred to as a Fire Brigade Panel) in each registered building. The hub receives information and alerts from each FIP and can remotely issue commands and configuration updates as required. This is done via the main FIP on campus or via direct access using the IP address of registered equipment on the FMS.
Each building operated by the University has at least one FIP, usually located near the main entrance to the building. Larger buildings may have multiple FIPs located near the main entrances as well in a fire riser, if the building is equipped with one. The FIP takes input from all sensors and alarms located in the building and controls any alert and suppression equipment. Equipment differs depending on how the building is used; for example, rooms containing sensitive electrical equipment are not likely to use a sprinkler suppression system, as this is not ideal for fighting electrical fires. As a further example, food preparation areas such as staff kitchens may not be equipped with smoke detectors, opting instead for a different type of detector such as aheat detector.
Early detection of fires is crucial to an effective response. To that end, each building, and specifically, each detection zone (generally a single room or set of corridors) is equipped with detection equipment, both automated and manually triggered. This includes but is not limited to smoke detectors, heat detectors, carbon monoxide detectors, manual pull alarms, and manual break glass alarms. In some cases, a single zone may contain multiple detectors, particularly where a high rate of false alarms is likely to occur. As an example, a zone where smoke is frequently detected may still use a smoke detector, but the FIP maybe programmed with a rule that will, when the detector is triggered, query a different detector in the same zone, such as a heat detector, and only enter an alarm state if the heat detector detects a temperature above a certain level.
When a fire is detected, the FIP will follow rules set by IFS, that, depending on the severity of the fire detected, may involve triggering suppression systems, evacuation, automatically contacting firefighters, and compartmentation systems. Suppression systems can vary depending on how the zone is used, but may include sprinklers, gas suppression, foam suppression, and dry chemical suppression. A small fire detected in a small room with equipped sprinklers does not for example, necessarily require the entire building to be evacuated immediately. The FIP might be configured with a rule to first activate the sprinklers in the room, only triggering an evacuation if the detectors in the zone show the fire becoming worse after a set amount of time. The FIP can also shutoff building power, which maybe necessary in some cases to remove a source of ignition for additional fires.
If, however an evacuation is necessary, triggered either by an automated rule, manually from the FIP or remotely from the hub,then the FIP may trigger warning systems in the building, such as sirens and strobe lights, such as from an occupant warning system and/or emergency warning and intercommunication system. The FIP may also detect conditions such as a power outage, or a high level of smoke in corridors and activate additional emergency lighting, or control dynamic emergency exit signs to activate their alarm modes with inbuilt speakers to guide people towards them, or in case an escape route is compromised, switch these signs into warning mode to alert people to seek an alternative exit. Note, not all emergency exit signs have these dynamic features included, some, including older models, may indeed not even be powered at all. As a fire grows worse, it maybe necessary to attempt compartmentation of the fire. The FIP can be used to perform. this task either automatically or manually, by closing fire doors, fire windows, and fire shutters within the building to delay the spread of a fire, allowing people additional time to escape. Fire doors are located at points within a building where fire resistant materials have been used in the construction of the building, and sub-divide the building into smaller sections that are typically easier for firefighters to manage.
The FIP, in addition to its automated functions, also includes an adjacent master emergency control panel in the same cabinet with indicator lights and buttons that allow authorised personnel and firefighters to quickly see the state of all connected sensors and systems, and to manually trigger or override them. It can also be used to send an all-clear signal to the system once the building is safe tore-enter, which will silence any alarms, reset detectors, and shut-off any active suppression systems. All alerts are sent to the hub, which stores a record of any alarms, detectors triggered, suppression systems turned on, fire doors closed, firefighters contacted etc.
Authorised IFS managers can generate reports of these records, which can be customized according to several parameters, for example,
● a list of the most frequent detectors triggered regardless of whether an alarm condition was entered (this is often used for identifying common culprits for false alarms).
● Another example would be a list of all recently activated suppression systems, and the amount of
time they were activated for (this can be used to calculate how much water/chemical agent/foam/etc has been used and needs to be ordered to restock the relevant suppression systems).
Each building has at least one member of staff assigned to the role of evacuation warden for the building.
The hub must alert these person/persons if an evacuation is triggered. Evacuation wardens can also manually trigger a building evacuation at anytime. The current state of building alarms and equipment across campus are visible from the main FIP on the FMS network. To ensure that everyone can be accounted for, each building entrance is to be fitted with dual gait and facial recognition linked to the University database. If someone cannot be recognised, they should be listed as an unidentified occupant. The current building occupancy list will be stored in the hub and made available to the evacuation wardens of the building, as well as authorised IFS staff.
The hub can also send commands and configuration updates to the local FIP of each building. There are many possible ways that this could be used, for example,
● to trigger an evacuation of every building for a fire drill,
● to update the automated rules for a single building,
● to update the automated rules in every building for a certain type of equipment,
● to manually trigger compartmentation in a building if the local FIP cannot be accessed in a fire,
● to initiate system tests during an inspection, etc.
For auditing purposes, any such use of the hub must be recorded and stored. Managers can generate reports of these records. Where commands are in conflict, the mostrecent command must take precedence; for example, the hub might send a remote command to close a fire door, but a person trapped in the building can still use the local FIP to temporarily open the door so that they can escape.
Both local building FIPs as well as the hub can be used to override building security systems. Areas that are usually locked by key or that require a University swipe-card to enter can be remotely unlocked in an emergency either in a single building from the local FIP or anywhere in the University from the hub. Use of this function must also be recorded for auditing purposes. It maybe assumed that firefighters have their own unique code pre-programmed into every FIP that can be used to access all functionality. Additional codes to access some or all functions of an FIP, or multiple FIPs across a set of buildings maybe added by IFS, either from the hub, or from the local FIP. Where added locally, the FIP will send this information back to the hub to prevent data conflict. The hub can communicate with the separate University security system for this purpose. The security system has a general override code associated with the fire management system as a whole that is used whenever the fire management system needs to override the security system. It is for this reason that the fire management system has the responsibility of associating use of this code with a specific user, or external firefighters (nominally this would be Fire and Rescue NSW) for auditing purposes.
The hub maintains all records, such as a list of buildings, equipment, configuration settings, users and their permission levels, alarms, overrides, etc. These records need to be easily searchable by IFS managers and auditors. Additional requirements for the FMS and other interconnected systems are available at https://www.newcastle.edu.au/_data/assets/pdf_file/0010/937639/UON-Fire-Services-Guiding-Principles-V1.3.pdf (outside the actual scope, but will be very useful for Business Rules and ideas for the next team project).
Note that the scope of this project is restricted to the master control (hub) of the FMS, as other equipment comes from external suppliers according to defined standards.
Objective of the system
The main objective is to develop an online management system for IFS that will control the hub of the fire management system. The local building FIPs are produced by other companies, but the hub needs to be able to communicate with them using their published addressable interface (IP address on the fibre FMS).
1. The manager needs all information at their fingertips to make decisions.
2. Safety is a critical aspect of this system, as failure could result in loss of life where a fire occurs.
3. The manager requires multiple types of reports, periodic each month, on-demand, and after-action reports (automatically generated after a major alarm state has been resolved).
4. Records must be kept secure, only accessed by authorised staff.
5. The system must be able to receive and report on equipment and sensor data as it comes in, that is, it must be ‘live’ 24/7, with reliability and uptime a priority.
The system should be online, so that, for example, IFS staff can issue commands from a mobile app outside a building in an emergency, instead of having to run to an accessible computer and login, although this should also be possible.
Tasks
The system definition above will be used for the two assignments for this course. For this assignment, you will elicit and document the requirements for the online system. You should identify system processes and user requirements. In this assignment you will gather and document system requirements, business rules and perform. an initial analysis of the domain in UML. Specifically, you will develop use case diagrams, activity diagrams and map out a class diagram for the problem domain.
There are no limits to how far the requirements specification and analysis might go. However, complexity, coverage and correctness of the elements will be considered in the assessment of the submitted work.
The main deliverable of this assignment is a report and MS Gantt Chart to be submitted via Canvas.
Note, your academic may also ask for a hard copy of the report and to show your MS Gantt file in class.