Emergency management on digital signage is increasingly important. 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 be a part of the building code, providing 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:
This blog focuses on item #1, but #2 is critical as well, and #3 is a huge bonus to have for emergency management of 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. But, how that content is activated on the targeted digital signs or displays is critical. We need to ask some important questions about the emergency management of digital signage.
Our intent is to switch the currently playing content to the correct emergency messaging content.
To accomplish this, some solutions store the emergency content on the player connected to the screen. And, it only takes 2-10 mins to switch the content. Further, some will even store two different sets of emergency content. But, there are at least 6 to 12 different types of emergency content. For example fire, shelter in place, weather warnings (hurricane, tornado), a bomb threat, shooter on-premise, etc.
How many different emergency content shows can a player store? This approach is clearly not practical.
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 capability find 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 of digital signage is great, but it must be effective as well.
A few keywords start to surface, which define requirements for emergency messaging on a network of digital displays. Switching content streams. Switching is also be thought of as overriding the current content stream with a new content stream. Further, automated switching can only be enabled with an Advanced Emergency Management module as you will read below. There is another alternative that we refer to as, On-top (or over-programming) 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 cover On-top messaging in this third blog.
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 that supports triggered content switching also means that the platform will 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 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 used are commonly supported on hardware systems such as door locks and cameras, etc. They are the GET and PUT methods of HTTP. That is to say, a unique URL with arguments is passed to the emergency system. In addition, other devices or systems can trigger content: webcams, motion sensors, factory equipment, or almost any IoT subsystem.
Ad Hoc, triggered switching means the content can be manually switched by someone with the authority to do so, when necessary or needed. For example, the security office for a building or campus, switches 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. Further, the building or campus security team will have the ability to switch to any existing emergency content show; on any players; in an emergency zone, building, or building sub-zone; instantly.
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.
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 its 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.
If someone pulls the fire alarm in the small building, we want the displays in the small building to immediately start playing the content for a fire. The content might include instructions on what to do and where to proceed. Let’s say 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 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 is 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. As a result, we see in the bottom-left part of the image below where there are two different emergency messages, purple and gray.
If there was a tornado, hurricane, or other imminent severe weather then the security department pushes a message to both buildings. The message replaces the departmental content immediately, communicating to both buildings. This is shown in the top-right part of the image above, with the purple emergency content going to both buildings.
Moreover, in a large office tower like the larger building above, the security office is able to target the messaging on the displays by floor. For instance, they either send different emergency messages, like the image in the bottom-right picture above. Or, they simply send the purple or gray message to the target floors and let the regular content play on the other floors.
The examples above 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 want the ability to group the buildings by Zone. We then switch content by zone instead of by one building at a time or switch the content in all zones instantly.
Unfortunately, this type of emergency occurs too frequently 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 is described above.
On a large campus different messaging is required for the dynamics of the situation. For example, a “shelter in place “for the building with the shooter. On the other hand, for the other buildings on campus, the messaging is to “stay away from the building”, with the shooter. Above all, as in any emergency, time is critical. In short, 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.
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 are known. For example, the student body, faculty, or office employees’ data is available. However, 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 will allow for either switched content 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.
Finally, integration with a Mass notification system like Omnilert can work with either switched or on-top messaging. For switched emergency messaging, 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 then triggers the automatic switching to emergency messaging on the digital displays.
There are always new ideas which will enhance the capabilities of an emergency messaging system. And, some things will make the emergency management messaging system more robust from an IT point-of-view. Here are some quick ideas for both.
Let’s summarize our discussion.
A digital media communications platform that is capable of supporting any kind of onsite emergency has the following capabilities:
A single CMS, which supports digital signs, video walls, in-room digital signs and room panels outside rooms. As a result, all of the displays are part of the emergency messaging system. To sum up, the CMS requires these functions for emergency messaging:
Emergency content should be classified and managed differently from regular content. The emergency content is tagged in different ways to allow automated switching. Additionally, emergency content is administratively separated from regular content to keep it protected from regular users. Further, the platform should allow the creation of an unlimited number of pre-planned emergency content messages, for any type of emergency. And, the content messaging for emergencies is supported by a full-function CMS. Moreover, it is the same CMS used to create regular content, but is separately managed.
Most importantly, it supports instant and automated switching of regular content for any number of emergency content messages. In short, instant means greater safety, which can save lives.
In addition, the content switching of regular groups, or departments of screens, allows a high degree of flexibility. So, targeting of different emergency messaging groupings is possible. And, player management allows an emergency grouping, which is distinctly different from the regular player group. Similarly, emergency grouping flexibility by floor, building, and zone is possible.
A separate Emergency management module is part of the platform. So the building or campus security department has exclusive access to emergency messaging if needed. In other words, they will switch emergency content messages as the situation dictates (ad-hoc). Ideally, this would include an emergency dashboard of some kind to make it easier to manage the emergency. Finally, special user access levels for the department users who would manage the emergency management module.
The ability to integrate into other building infrastructure is not yet mandatory, but it will be. For example, 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. Importantly, these integrations support automated content switching, triggered by an event on one of these sub-systems.
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 that 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.