Emergency Management Digital Signage
What capabilities are required for Advanced Emergency Management in a Digital Signage platform?
Increasingly, digital signs are an integral part of any building’s interior landscape. In the previous blog we made the case to have digital signs, video walls and meeting room signage become part of the building code, which would provide greater safety to the building’s occupants.
Making the building’s digital displays part of the building’s(s) emergency management system requires a technology platform which:
- Can provide advanced emergency management capabilities emergency management digital signage
- Is able to support the many use cases for public digital displays for everyday content display. This also implies that the CMS (content management system) for the platform can support virtually any type of content.
- Will work with the widest variety of screen and player types
This blog will focus on item A, but B is critical as well, and C is a huge bonus to have. emergency management digital signage
Creating content for any particular type of emergency is something that any of the hundreds of digital signage CMSs (content management systems) can do, in some form or another. But how that content is activated on the targeted digital signs or displays is critical. We need to ask some important questions. emergency management digital signage
How quickly can emergency notification content be put up on displays?
We are talking about switching the currently playing content to the correct emergency messaging content. Some solutions store the emergency content on the player connected to the screen and it only takes 2-10 mins to switch the content. They can even store 2 different sets of emergency content. But there are at least between 6 to 12 different types of emergency content – fire, shelter in place, weather warnings (hurricane, tornado), a bomb threat, shooter on-premise, etc. How many different content shows can a player store? This approach is clearly not practical and, more importantly, the content doesn’t switch instantly.
The time it takes to switch the content is important. Does it take 2 minutes? 5 minutes? 10 minutes? Or longer? It really isn’t an emergency management capability if it can’t switch content instantly. Customers who thought they had emergency content found it to be useless in an emergency because it wasn’t timely. In a recent tornado disaster in Alabama, they claimed they only had 5 mins to warn people before disaster hit.
The system must allow the content to change instantly. Emergency management digital signage is great.
A few keywords start to surface, which define requirements for emergency messaging on a network of digital displays. Switching content streams. Switching can also be thought of as overriding the current content stream with a new content stream. Automated switching can only be enabled with an Advanced Emergency Management module as you will read below. There is another alternative which we refer to as, On-top messaging. On top means that emergency messaging is being played on top of the existing content as, or when an emergency occurs. This does not require a separate Advanced Emergency Management module. On-top messaging can be incorporated into an advanced CMS. We will cover On-top messaging in the third blog in this series.
Instant switching implies that we can have as many different types of emergency content categories as we like. And we can switch between our regular content and any of the emergency content streams without having to worry about storing them on the player. We also don’t have to worry about player storage capacity.
Automated, triggered switching means that the emergency content will change without anyone having to do anything. For example, a fire alarm is pulled and all the digital signs in the building immediately switch the content being displayed to the fire emergency content messaging.
A platform which supports triggered content switching also means that the platform should be able to generate a unique trigger. A unique trigger could be a URL, for each emergency show. The unique trigger is given to or inputted into, other systems or devices which can then trigger the content to play. The fire alarm example above demonstrates this perfectly. The URL is triggered when the fire alarm is activated. It happens instantly, and without any intervention needed. Two methods of HTTP requests can be used which are commonly supported on hardware systems such as door locks and cameras, etc. They are the GET and PUT methods of HTTP, where a unique URL with arguments, can be passed to the emergency system. Other devices or systems which could also trigger content: webcams, motion sensors, factory equipment or almost any IoT subsystem.
Ad Hoc switching means that the content can be manually switched by someone with the authority to do so, when necessary or needed. The security office for a building or campus, for example, might need to switch the content on the displays, depending on the emergency situation. This capability is critical especially during an ongoing crisis like an intruder or shooter on campus. The building or campus security team will have the ability to switch to any existing emergency content show; on any players; in any emergency zone, building, or building sub-zone; instantly.
Can the players be grouped differently for emergency messaging, then normal player groupings?
Let’s assume that any digital display platform we are evaluating will allow us to put players in our network of screens/players into different groups. Not all CMS packages allow this, but it is pretty standard for most true platforms with back-end management capability. This means we can run different content by player groupings, instead of having to manage the content on each display screen.
In contrast, for emergency content messaging, we want the ability to put a player into a different grouping than it has when it is playing day-to-day content. Why? Because being able to define different player groupings for emergencies, allows us to manage, or switch, emergency messaging quicker and more precisely by geolocation. So, players may be showing content that is not geographically relevant, whereas an emergency is normally specifically targeted for a geographic location. Let’s look at some examples.
Five Department Groups
First, let’s consider a building which has multiple floors with different departments on the floors. Each department has their own digital signage content. Some content may be common to all departments, but it may also contain content specific for anyone who is part of a department. All the digital signs are part of a single platform, but each department is managing its own content and has players on its floor(s) all part of its department grouping.
In this picture, we have two buildings with 5 different departments, called red, green, white, yellow and orange. Each of the departments has their own content playing on screens, and the players throughout the buildings are grouped according to the department color. For emergencies, we would want to also group the players by the building they are in and maybe even the floor they are on. emergency management digital signage
Can we put different emergency messages on different screens in an emergency?
Fire in the small building: If someone pulls the fire alarm in the small building then we want all the displays in the small building to immediately begin playing the content for a fire. The content might include instructions on what to do and where to proceed. There are 3 departments in the small building – red, green and white. All the players in the small building should have the same emergency building grouping. When the fire alarm is pulled, all the players that are assigned to the small building’s emergency grouping will change to the fire emergency content.
However, the green, red and white department players in the large building will continue to play their departmental content. No fire alarm has been triggered. This scenario is shown in the top-left part of the image below, where the purple color represents emergency content. But the security office may want to send a message to the occupants in the large building, letting them know there is a fire in the smaller building and they should stay away. One way to do that is to send instructions to all the players/screens in the large building. Then all 5 departments will have their departmental content overridden in both buildings – see the bottom-left part of the image below where there are two different emergency messages, purple and gray.
Severe Weather Warning: If there was a tornado, hurricane or other imminent severe weather then the security department could push a message to both buildings. The message would replace the departmental content immediately, communicating with both buildings. This is shown in the top-right part of the image above, with the purple emergency content going to both buildings.
Emergency Messaging by Floor: In a large office tower like the larger building above, the security office should be able to target the messaging on the displays by floor. Either different emergency messages, like the image in the bottom-right picture above, or simply sending the purple or gray message to the target floors and letting the regular content play on the other floors.
The examples above must easily scale to a larger campus. Higher education campuses with over 100 buildings, large corporate, government or real estate company campuses and even geographically diverse locations. With more buildings or locations, we would want the ability to group the buildings by Zone. We could then switch content by zone instead of by one building at a time, or switch the content in all zones instantly.
Shooter on Campus: Unfortunately, this type of emergency occurs regularly at our educational institutes. In this type of emergency, allowing the security office to control the emergency messaging on the screens as needed is critical. This type of ad-hoc switching was described above.
On a large campus different messaging is required for the building with the shooter (shelter in place), versus all the other buildings on campus where the messaging would be to stay away from the building with the shooter. As in any emergency, time is critical. Getting the messages up on screens in seconds versus minutes can save lives.
If the digital display platform has been integrated with the security camera system, it is possible for the security team in the control center to assist the onsite response team by putting camera feeds on display screens in the locations where onsite responders are stationed. This may or may not assist the onsite responders, but the possibility is important because it could be used in other scenarios.
Can mass notification systems be integrated into the digital display platform? Which ones? How are they integrated and used?
There are a number of mass notification services, e.g. Omnilert, CAPP, or FEMA. They are especially popular when the email and or mobile number of the regular or frequent occupants of a campus or facility, e.g. students, faculty, employees are available. If one of these services is used, integrating the service with the digital displays on site makes sense. It is particularly practical for a number of reasons pointed out in this blog.
A good digital display platform should allow for either switched content integration or on-top content integration. This blog talks about switched content capabilities. For a description of on-top content, and how it can be used for CMS emergency messaging, please see this other blog.
Integration with a Mass notification system like Omnilert can work with either switched or on-top messaging. For switched emergency messaging, this means, that when an alert is received from Omnilert, the content on the displays is switched instantly to the Omnilert message system-wide. The same integrations to CAPP or FEMA can be programmed to play on demand when an alert is sent. Omnilert provides an RSS based API that feeds an alert to the CMS platform. The Omnilert feed can then trigger the automatic switching to emergency messaging on the digital displays.
What else can be done to make the emergency messaging more robust on a digital display platform?
There are always new ideas which can enhance the capabilities of an emergency messaging system. And, there are things that can be done to make your emergency management messaging system more robust from an IT point-of-view. Here are some quick ideas for both.
More Robust IT Environment: emergency management digital signage
- Install the digital display server platform locally to take away the dependency on an internet connection for the messaging to work.
- Have a mobile internet back-up for your internet connection, e.g. Carriers are offering an LTE back-up, business service for $99/mth.
New Capabilities: emergency management digital signage
- Put up QR codes on Emergency messaging which would allow an occupant to scan the code to indicate where they are in the building. This allows the occupant to be tracked; have directions sent to their mobile; enable a live connection; or automatically trigger video instructions.
- Display a number to call or text if you are trapped in a building. Allow security to maintain a dialogue with you via txt
- Combine switched emergency messaging with on-top emergency messaging
- Allow different groups to have responsibility for messaging on different portions of the screen
- Incorporate audio files into the emergency messaging to play on the speakers which are part of the display. This may also require the capability to centrally turn the sound on for all screens in a display network. Emergency management digital signage.
- Extend the emergency messaging for the digital displays to the desktops of all the workers in the buildings. Then emergency content immediately plays at the desktop. This can be done simply with a general URL available to anyone. But it is more effective if the message can be pushed to a user’s desktop.
- Extend the emergency messaging to in-room displays. Then anyone in a meeting room or potentially a classroom will also get the emergency messaging instantly. This can work today with some platforms, provided the in-room hardware can support it.
- Integrate the digital display platform with more building sub-systems. Connecting these sub-systems is a real step to a connected Internet of Things (IoT) implementation. Then the displays show updates of data or the status of these sub-systems in real time. In the example of the fire alarm system described above, each emergency content stream must have its own URL. The URL is triggered by the other sub-systems which it is attached to. Emergency management digital signage.
Let’s summarize our discussion.
A digital media communications platform ideal for supporting any kind of onsite emergency would have the following capabilities:
1) The CMS:
A single CMS, which supports digital signs, video walls, in-room digital signs and room panels outside rooms. This would enable the use of all of the displays to be used for emergency messaging. Desirable CMS functionality specifically for emergency messaging:
- Rich set of widgets able to support any content type emergency management digital signage
- Capability to support On-Top emergency messaging emergency management digital signage
- Native support for sound files coupled with platforms ability to turn sound on/off across all displays
- Ability to extend to desktops emergency management digital signage
2) Emergency Content:
Emergency content should be classified and managed differently from regular content. The emergency content is tagged in different ways to allow automated switching. We also want emergency content administratively separated from regular content to keep it protected from regular users. The platform should allow the creation of an unlimited number of pre-planned emergency content messages, for any type of emergency. The content messaging for emergencies should be supported by a full function CMS, the same one used to create regular content, but separately managed.
3) Time to Switch Content:
Support instant, automated switching of regular content to any number of emergency content messages. Instant means greater safety, which can save lives.
4) Emergency Player Grouping:
The content switching of regular groups, or departments of screens, should allow a high degree of flexibility to target different emergency messaging groupings. Players should have the ability to have an emergency grouping which is distinctly different from its regular player group. Emergency grouping should be defined by floor, building, and zone.
5) Manage the Emergency:
Offer a separate Emergency management module which the building or campus security department would have exclusive access to, enabling them to switch emergency content messages as desired (ad-hoc). Ideally, this would include an emergency dashboard of some kind to make it easier to manage the emergency. Special user access levels for the department users who would manage the emergency management module.
6) Connectivity to other Building Sub-systems (IoT):
The ability to integrate to other building infrastructure, e.g. the fire alarm system, the security camera system, motion sensors or any of the many other IoT sub-systems which are part of a build’s infrastructure. These integrations support automated content switching, triggered by an event on one of these sub-systems.
Building and Campus Policies and Guidelines for Digital Signs
To provide everything discussed in this blog requires a digital display technology platform, not just a CMS. The platform will need a robust, feature-rich CMS, having separate functional capabilities which enable instant switching, desktop messaging, or screen volume control.
Display5’s platform has many of these capabilities and we continue to enhance and advance it as new requirements surface.
The next blog talks about the kind of emergency messaging that a robust CMS on its own can be capable of, using On-top messaging. Emergency management digital signage.