WARNING LIGHTS AND EMERGENCY SIRENS

The era of “smart buildings” is here, bringing new opportunities for significant gains in efficiency, safety and environmental protection. In an interview, Rodger Reiswig, director of industry relations at Johnson Controls Global Fire Protection Products, offers his insights into the impact of smart buildings on fire detection and what it means for organisations planning new facilities. Q: How do you define smart buildings? The term “smart buildings” means different things to different people. For some, it’s all about the Green Initiative. Is the building able to sustain itself or reduce its carbon footprint? Can they reuse some of their water or generate electricity from onsite solar cells or wind turbines? Another definition of “smart buildings” is based on sensors. Is the building smart enough to know that, if I’m the first person there in the morning and I swipe my card, it should switch the HVAC system into occupied mode? Can it start to turn the lights on? Can it adjust the window shades to allow the sun to come in? Can it call the elevator down for me because it knows that I’m in the lobby and I’m going to the tenth floor? It’s all about how the systems integrate with one another, not just providing information to each other, but also interacting with one another, causing things to happen from one system to another. Q: How close are we to the vision of an integrated intelligent building where all the systems work together? We’ve already been doing some integration for a few years now with things like HVAC and lighting. Now we’re seeing tighter integration where, for example, we can use the position of the sun to get the best impact of sunlight to start to heat the building in the winter. One of the biggest challenges that we see in the smart building environment is protocols or topologies for how one system talks to another. The fire alarm system uses a certain protocol or language. The HVAC system uses another protocol or language, and so on. Creating an environment where systems can talk to one another and not just send, but also receive information – that’s the difficult part. Everybody can send information out. It’s easy for me to tell you what is happening in a system. But for you to tell me what’s happening in your system and then expect me to do something with that information, that’s when it gets a little bit harder. Q: What makes system-to-system communication challenging? Because of the critical role they play in protecting lives and property, life safety systems require a level of reliability and resilience far beyond that of other building systems or networks. Therefore, we have to be extremely careful about how we allow information from other systems to come into the life safety system, in case that information should affect the performance of the system. In addition, the design and specification of life safety systems is guided via three different means: building codes, standards and listings. Each of those means is controlled by different organisations. Any proposed changes to life safety networks have to pass muster with those entities, and that takes time, effort and consensus-building. When we’re talking specifically about system-to-system communication, the listing entities, organisations like UL and FM Global, regulate how much information can come into any life safety system. The listing documents require that there be some type of a barrier or gateway to prevent unauthorised or corrupted information from coming into a fire alarm system, causing harm or causing it to lock up. Life safety systems require a level of reliability and resilience far beyond that of other building systems or networks We will see all building technologies become more integrated over time as we work through the different entities and people begin to realise the benefits of improved safety, lower environmental impact, and reduced costs. Q: How will fire detection systems benefit from other sensor information available in a building? One of the things being explored is occupancy sensors that tell where people are located in a building. Some type of telemetry could be used to understand where people are concentrated in a facility and, based on that, make the fire alarm system more or less sensitive to smoke. If a lot of people are congregating in one area, there might be more activity and more dust being stirred up. You could use that information to set different alarm parameters compared to, for example, an empty building with no significant air movement. We see that type of operation happening. Knowing how many people are in a building and where they are located is also a critically valuable piece of information for first responders. Here’s another example: let’s say we have a big parking garage next to a mall. Cars come in, and perhaps some people leave their cars running, or the cars aren’t operating as efficiently as they should be. You could have carbon monoxide detectors and occupancy sensors in the garage, and when the garage becomes crowded and carbon monoxide levels start to rise a bit, you could tell the fire alarm system not to go into alarm, but instead to turn fans on to get some fresh air moving throughout the building. It’s performing a life safety function, but at a non-emergency level. Q: Are you involved in any cross-industry standard-setting organisations to enable better communication among building systems? On an industry level, Johnson Controls is very active in the development of codes and standards. We have people who sit on committees for things like healthcare occupancy standards. We have engineers that contribute to product listing documents. We have people who participate in committees that determine how products should be installed and maintained. We’re even involved with groups, like the National Disabilities Rights Network, that advocate for laws that promote equal access and notification of life safety events. The list goes on. Fire alarm systems couldbe used to detect and solve non-emergenciesbefore they become threats Just to give you an example, there’s a standard called BACnet, Building Automation Control Network, which was developed by the American Society of Heating, Refrigerating and Air-Conditioning Engineers. It’s a common protocol that allows all types of systems to get on the same communication platform and be able to send and possibly receive information, depending on the product and the type of system it is. BACnet is based on entities, so within their system, they need to define what each entity is. What is a thermostat? What is a variable air box? What is a lighting controller? What is a fire alarm smoke detector? We work closely with this organisation to create entities that can reside on their infrastructure so that, for example, the lightning system recognises what a smoke detector is when they send that entity out to the network. It’s one of the most important methods we are using to communicate among dissimilar systems. Integrated systems mean elevators could be used to evacuate people in an emergency We’re working on two fronts: internally and industry-wide. We’re developing third-party interfaces that enable an outside entity to sign a non-disclosure form and get the keys to the kingdom, if you will, on our protocols for how our systems operate – the data stream that we can send out and receive back – allowing that third-party developer to create some of these interfaces themselves. That has been one of our challenges, because we have always said that this is a fire alarm system, and if you want that type of an interface, we need to write it and get it listed. We had to step back and say, what if we developed a barrier gateway and allowed somebody else to develop the protocol and, done properly, became able to receive and send information to the fire alarm system? It’s like what Apple does with apps. We are going down that road with this third-party interface gateway. Q: Have these developments changed how you’re planning for the future development of fire detection systems? Yes, they have. We are looking at how we can use these systems strategically to make life safety systems better. And life safety is becoming more nuanced, proactive and comprehensive. Can I communicate and use this information to unlock the door so people have a clear egress? Can I start to use the elevators to evacuate people during an emergency? We’ve been told traditionally to use the stairwell and not the elevator in the event of a fire. But it takes a person about a minute a floor to get out. That’s a problem if you’re in an 80-story building. You have elevators sitting there. Is there something we could do to allow these elevators to be used to evacuate people? The American Society of Mechanical Engineers has been working hard on developing the language and requirements to do that. It’s just one example of how having systems integrated and talking to each other allows us to create smarter solutions that can help make facilities safer. Q: What advice would you give to building owners, architects, designers or contractors to help them start planning today for the future of smart buildings? The most important thing is to build awareness. The average building owner doesn’t know that a lot of this technology even exists. We need to inform them that there are options they can ask about. One of my recommendations would be to ask your design engineer. As you discuss the kind of windows you want, the kind of flooring and lighting and so on, ask how these systems could integrate together and what the benefits of integration would be. The bigger your facility, the greater the benefits of integrating these systems. Another resource that people don’t use often enough is the AHJs, the authorities having jurisdiction. That’s the local fire marshal, the fire chief, the local first responders. Don’t be afraid to sit down with a fire marshal, tell them what kind of building you’re putting in, and ask them what would help them respond in the event of an emergency in that building. They’ll be glad you asked, because these people see a lot of different buildings and respond to emergencies every day.

If anyone tells you that the use of Mass Notification Systems (MNS) is a new trend, it is likely that they do not fully understand it. You have been impacted by mass notification your whole life. Surprised? Every time there is a fire drill at an elementary school, or a bell chimes noon or a blinking light announces a snow-related parking ban, an MNS is being deployed. Ultimately, mass notification is just mass communications. What has changed is the distribution methodology, the granularity and specificity of the message, and the ability to customise it to individual recipients or groups Growing Need For Mass Communications Our capacity to communicate vastly improved through the 80s and 90s; 1G analog in 1983 was followed by 2G digital in 1990, paving the way for text messaging and IBM’s Simon, the first smart phone in 1993. Digital cable connected to nearly seventy million people by the end of the 20th century. By 1995, wide-scale commercialisation of the internet had begun, with social media and instant online chats prevailing through the early 2000s. So when did the genesis of modern mass notification occur? The problem garnered little national attention until the 1995 Murrah Federal Building bombing and the 1999 Columbine High School shooting, which saw issues with the immediate and post-crisis victim response. The tipping point was 9/11. Advances in communications integration and interoperability can be traced to the communications failures experienced by responders to the attack on the World Trade Center. These failures went beyond those traditionally involved in a crisis. The 9/11 Commission report states: “the ‘first’ first responders on 9/11, as in most catastrophes, were private sector civilians. Because 85 percent of our nation’s critical infrastructure is controlled not by government, but by the private sector, private-sector civilians are likely to be the first responders in any future catastrophe. For that reason, we have assessed the state of private sector and civilian preparedness in order to formulate recommendations to address this critical need.” Managing The Disaster Life Cycle Communications failures were tied inexorably to governmental and civilian command and control failures with frustration spreading all the way to the White House. President George Bush issued Homeland Security Presidential Directive 5 (HSPD-5): “to prevent, prepare for, respond to, and recover from terrorist attacks, major disasters, and other emergencies, the United States Government shall establish a single, comprehensive approach to domestic incident management.” The result was the National Incident Management System (NIMS). NIMS is intended to help manage the disaster life cycle and meet the challenges of timely emergency communication. The NIMS provides a comprehensive approach to incident management to meet the challenges of timely emergency communication to civilians and emergency services Most of the fire detection industry views Mass Notification through the "standards" looking glass, with NFPA 72 Chapter 24, UL2572 and the Defence Department UFC 4-021-01 as the primary players. The UFC standard best exemplifies the most commonly recognized MNS definition in its introduction: "Mass notification provides real-time information and instructions to people in a building, area, site, or installation using intelligible voice communications along with visible signals, text, and graphics, and possibly including tactile or other communication methods. "The purpose of mass notification is to protect life by indicating the existence of an emergency situation and instructing people of the necessary and appropriate response and action.” While there is nothing wrong with that definition, it is often misinterpreted. This stigma unintentionally creates operational silos. Mass notification isn’t just for your building, your campus, or your people. In fact, the greatest value of a well-architected mass notification system is that it can deliver communications to large diverse groups of people sharing a commonality. Holistic Mass Notification System While many people associate MNS with fire alarms and text message alerts, today’s systems incorporate numerous other modes of communication from an email notification to strobe lights or automated phone calls, similar to a reverse 911 call. For larger open campuses, an MNS could include a loud speaker, which can sound a siren notification or even an automated message. Through distributed messaging systems, MNS can also broadcast alert notifications and evacuation route directions to targeted areas in the event of an emergency. For example, in an active shooter situation, leaving a building may actually put more people in harm’s way in some cases. Depending on the situation, it may be safer for occupants to move to a different floor or area in the building. The same could be said about a weather-related issue, where a display board or email notification would share an alert to take shelter in a basement due to a tornado. The 21st century mass notification system will be holistic, highly configurable, intuitive and interactive enabling two-way multi modal communication. It will be inherently network-driven and adaptable to diverse individual and group perceptions, behaviours and needs. Article published courtest SourceSecurity.com®, a division of Notting Hill Media Limited. View the original article here

Are new VA standards cause for alarm? Dr Steve Harrison, Product Engineering Manager at ASL Safety & Security, considers certification requirements in the voice alarm (VA) sector and how pending new standards will differ from predecessors. What's new, what should we be interested in, when are the implementation deadlines and what is the best route towards compliance?  With major new voice alarm standards set to come into operation in Britain in 2011 (British Standard EN 54-16:2008 and British Standard 5839 part 8: 2008), engineering managers worldwide are bound to be considering how their products will fare in the UK under new demands and how changes to products can be handled. There are two important things to consider about British Standard 5839 Part 8: 2008. Firstly, given the advances made throughout the industry over the past 10 years, it is sobering to think that this is a standard whose principal content dates from 1998. Secondly, voice alarm manufacturers should be aware that while it is often quoted as a requirement in system specification documents, British Standard 5839 Part 8: 2008 is in fact a code of practice for the design, installation, commissioning and maintenance of voice alarm systems. While the previous version did describe the requirements of products, the latest version lives up to its title and refers out to EN54-16:2008 for specific product function. Similarly, it is not possible to comply on a product level with the current standard governing sound systems for emergency purposes, British Standard EN 60849: 1998. The clue ought to be obvious from the title; this is a "system level" specification and any attempt to declare a product compliant to it is likely to be spurious, though this has not stopped several major players in the field alleging third-party accreditation when there is in fact no defined test regime.While ten years is relatively recent in terms of certification when compared with other sectors, there is still much old-school thinking in the two voice alarm standards we are considering. They were written in an era when audio was mostly analogue, amplifiers were big, hot, unreliable beasts and software control systems were largely frowned upon. British Standard EN 54-16:2008 may level the playing field in the voice alarm sector  The new standard will apply directly to any Voice Alarm equipment The new standard that is causing interest throughout the British industry is BS EN 54-16:2008 which will apply directly to anything that a manufacturer refers to as Voice Alarm equipment or, more specifically, 'control and indicating equipment.' The distinction is that this is a product specification with a defined regime for testing and it will apply to everything from amplifiers to audio routers, in fact any component that is part of the core functionality of voice alarm.British Standard EN 54-16:2008 is a standard that has been designed as a means of obtaining third-party accreditation. In the same way that all fire alarm systems have to be accredited by an approved testing house before they can be sold, VA systems are now going to be subjected to similar scrutiny. This is a sea change in the voice alarm sector and will have the welcome effect of levelling the playing field. However,  there are enough nursery and fairy tales cautioning us to be careful what we wish for to sound a note of warning. Even so, in contrast with British Standard 5839 part 8: 2008 which gives voice alarm manufacturers no specific guidance on what should be inside their units, British Standard EN 54-16:2008 really does relate to equipment and what products need to do.The new British Standard 5838 Pt 8:2008 standard requires that voice alarm systems should be classified according to a graduated scale relating to the evacuation plan for a building. The categories are V1 to V5, V1 being the simplest such as the basic situation of a fire alarm panel connected to a voice alarm panel. In the event of the fire alarm going off, the VA simply gives an 'evacuate' announcement. The next two categories have different kinds of emergency microphones as well as elements of manual interaction and manual voice announcement. The highest category, V5, covers a complex alarm system at large installations such as a stadium, transport hub or shopping centre where there is a need for a sophisticated 3-D supervisory GUI such as ASL's iVENCS which can show what is happening at a location and help manage the location in the event of an emergency. To give an idea of scale, a standard London Underground station would be a V2 or V3 while a major national transportation hub like St Pancras International Station in London would be a V5.Fire alarm guidelines based on voice alarm proximity in British Standard 5839 Part 8For the first time in the UK, the standard has included recommendations for networked and radio-linked systems and there are configuration requirements for labelling elements. A significant statutory requirement is that connection to a fire alarm interface must be duplicated if the fire alarm is more than 10 metres away from the VA system. The various parties involved in design, installation, commissioning acceptance and verification can look at example certificates for each of those phases. This is a welcome development since certification allows each player to specify exactly what element of the design they have been responsible for.But while there is clarity with these elements, elsewhere there is ambiguity, notably in the fact that BS 5839:2008 makes reference to British Standard EN 54-16:2008, which does not come into effect until 2011. The present situation is one of flux that should be clarified in a year's time.Distinct functional conditions in British Standard EN 54-16 A notable aspect of the new standard is that a VA system is required to operate in at least three distinct functional conditions. These are the quiescent condition where it is inactive or simply playing music, an active voice alarm condition where it is evacuating people either through automatic message or manual microphone and a fault warning condition. The main implication of these conditions for voice alarm manufacturers is how they are indicated and an immediate task may well be to modify the functioning of LEDs in order to be fully compliant. In the case of manual control – a panel with buttons to evacuate certain parts of a building – British Standard EN54-16 requires voice alarm and fault LED indication per zone. There is also a requirement to have only one emergency mic active at any one time while currently we can have different mics active across various zones.Acknowledging commercial off-the-shelf software The new standard requires VA systems to operate in at least three distinct functional conditions A significant aspect of British Standard EN54-16 is that the existence of commercial off-the-shelf (COTS) software is acknowledged for the first time. Previously, the convention was that voice alarm systems were designed from the ground up with every element being created in-house to the requirements of previous standards. By contrast, British Standard EN54-16 acknowledges the use of generic operating systems, distributed systems and Ethernet usage. The current conflicting standards will be withdrawn in April 2011 and compliance with British Standard EN54-16 in the EC will become a legal requirement under the European Committee for Standardisation and the Construction Products Directive.Achieving compliance with British Standard EN54-16Even a cursory glance at the standard will reveal that there is no scope for cutting corners. Manufacturers will need to co-operate with an accredited test house, ensure all testing is witnessed and will be unable to reuse test results even if they have demonstrably met the required criteria previously. This applies to both electromagnetic compatibility (EMC) testing and environmental testing.The standard requires functional testing as well as EMC immunity assessment, and while these must be seen to be separate activities it is likely they will be performed together. ASL is currently analysing the requirements of the new standard and has created a separate validating team comprising EMC engineers, technical authors and software testers with the specific role of taking its public address and voice alarm product range through EN54-16 accreditation.   Dr Steve Harrison has worked in the professional audio industry for 20 years and has been jointly responsible for developing voice alarm products at ASL. His track record includes designing the first commercially-available 100V Class D amplifier for the VA market and the initial research he conducted after joining the company remains at the core of the adaptive Class D technology used throughout ASL’s product range. Steve is currently responsible for product design and the management of ASL's team of hardware and embedded software engineers.