Web-based Signage Player Emergency Profile

From Web-based Signage Business Group
Jump to: navigation, search

Architecture and Requirements for Web-based Signage Player - Emergency Profile


Business Group Note Editor's Draft Nov 2016


This Version
TBD
Latest Published Version
TBD
Latest Editor's Draft
TBD
Previous Versions
TBD
Editor
Wook Hyun(ETRI)
Sung Hei Kim(ETRI)
Futomi Hatano(Newphoria Corporation)


Copyright © 2012 W3C® (MIT, ERCIM, Keio), published by the Web-based Signage Business Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.


Abstract

Digital signage plays a significant role in emergency situations, such as earthquake, tsunami, fire, etc. Many lives could be saved with appropriate information shown on signs in such situations.

This profile defines requirements for web-based signage in emergency situations. Emergency situations can be classified by severity levels. This profile shows the severity levels, and what and how signs should show. Besides, it illustrates how the requirements can be implemented with web technologies.

Status of this document

This specification was published by the Web-based Signage Business Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.


Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this document. [RFC2119]

Introduction

This section is non-normative.

The Architecture and Requirements for Web-based Signage Player defines detailed requirements for web-based signage players. The Architecture and Requirements for Web-based Signage Player defines various profiles for basic media, storage, basic reporting, interactive menu, emergency information, scheduling, etc. The profiles are based on the core profile.

These profiles are also intended to be used as product specification sheets of web-based signage products for vendors, RFP (request for proposal) used by the signage operators to request SDCs (Systems Development Corporations) to develop a web-based signage system, etc.

Digital signage plays a significant role in emergency situations, such as earthquake, tsunami, fire, etc. Many lives could be saved with appropriate information shown on the digital signage display. It is important to distribute emergency information as quick as possible using various distributed technologies such as broadcasting, P2P, LTE D2D, etc. Also, emergency Information should be handled in somewhat unified manner (display format) for the people to easily perceive and understand the information to minimize confusion during emergency. It is possible to classify emergency situations through severity levels.

The reader should note that the actual style and format of expressing the emergency information are national regulatory matter.

This profile defines emergency information profile for the web-based signage player. This profile deals with the basic architecture, requirements, presentation styles according to severity level, and use case to be considered for emergency profile in web-based signage player.


Scope and terminology

TBD and should be aligned with core profile.

Architecture

TBD

Requirements

Classification of severity level for presentation

The emergency information should be displayed differently according to the seriousness and urgency. Same information can have different impact according to the circumstances. For example, emergency information such as weather, emergency status of other area is informational and can be classified as minor alarm. Information such as earthquake, tsunami, and fire that involve threats to the surrounding are classified as major alarm. This part assumes there are different levels of alerts/alarm which can vary from minor alarm (such as weather, emergency news of other area) to major alarm (such as earthquake, tsunami, fire, etc.) that involves threats to the surrounding. This part intends to classify the severity levels and suggests method of display that can be used for each level. Some display method can include such as display format, display frequency, type of sound produced, etc. We can draw some requirements for each level in this process and make some gap analysis that may be needed. This part classifies the Severity Level based on the seriousness and urgency of the emergency information. It will not classify the actual type of emergency, since this is a national regulatory matter and is out of scope of W3C. For example, it will not assign earthquake as level something.

Exchanging emergency information

This part can describe how the emergency information can be received by the digital signage system using web technology. Regarding this, WebSocket or HTTP PUSH can be considered.

  • The digital signage system is recommended to be capable of collaborating with mobile devices through local area network for exchanging emergency information, if the local network is still alive. [UC1]
  • The digital signage system is recommended to be capable of uploading of emergency information from administrative devices, if the connection with content management system is lost. [UC1]
  • The digital signage system is recommended to be capable of giving detailed emergency information to user's devices, and recommended to display a method how to get the information. [UC1]
    • For example, a signage terminal in front of evacuation center just shows "Evacuation Center" and additional information how to get detail information, and a user can get detailed emergency information from the signage terminal.

Presentation of emergency information

This part describes how to display the emergency information using web technology. There can be various methods to consider in displaying emergency message, from use of ticker box, small window pop-up, full screen display with warning alarm, etc. This part can list some of the related web-technology that maybe used and include some example codes.


Presentation styles according to severity level

This section is non-normative.

The reader should note that the actual style and format of expressing the emergency information are national regulatory matter.

Severity Level Presentation Mode Effect Sound
Level 5 (Extreme) Full Box Blink Yes
Level 4 Full Box Static
Level 3 Pop-up Box Static
Level 2 Ticker Box Static
Level 1 (Informative) Ticker Box Scroll

Effect

it is effective to emphasize specific messages in the screen by giving some effects.

BLINK

Urgent messages can be emphasized by blinking. This features can be done by using animation of CSS as shown in following example codes;

.blink {
   overflow: yes;
   animation: blinker 2s ease infinite;
}
@keyframes blinker {
   50% { opacity: 0; }
}

SCROLL

Non-urgent messages can be presented as a scrolled texts as shown in following example;

.marquee {
   width: vw;
   margin: 0 auto;
   overflow: hidden;
   white-space: nowrap;
   box-sizing: border-box;
   animation: marquee 20s linear infinite;
}
@keyframes marquee {
   0%  { text-indent: 100vw }
   100% { text-indent: -200vw }
}


Ticker Box Properties

Ticker box is used to provide emergency information with text at the bottom of the viewport. If the severity level is informative(lv.1), information can be scrolled over time

  • background-color
  • This parameter specifies the background color of ticker box, and specified with CSSCOLOR.

  • z-index
  • Since emergency information should be provided on top of any viewport, the value of z-index should be as high as possible.

  • width
  • Width of ticker box tends to be same with the size of application viewport. In that case, the value will be '100vw'.

  • height
  • Height of ticker box may be different based on the policy of service provider or domestic regulation. However, this value needs to be responsible to the size of application viewport. Hence, it is recommended to use '10vh' that means 10% of height of viewport.

  • color
  • font-size
  • font size should be adjustable on the size of application viewport, and must be smaller than height parameter.

  • position
  • bottom
  • In general, ticker box is located at the bottom of the screen.

This is example CSS file for presenting emergency information using ticker box;

#wds-emergency-ticker {
   margin-left:0;
   z-index: 9999;
   vertical-align:middle;
   width: 100vw;
   height: 10vh;
   line-height:10vh;
   color: white;
   font-size: 8vh;
   font-weight: bold;
   background-color: blue;
   position: fixed;
   bottom: 0vh;
}

This example presents scrolling text in the ticker box.

<html>
 <head>
   <link href="wds-emergency-profile.css" rel="stylesheet">
 </head>
 <body style="padding:0px; margin:0px; width:100%;height:100%; ">
   <div id="main_contents">
         Main contents
   </div>
   <div id="wds-emergency-ticker">
     <p class="marquee"> Emergency information: Something happened 
        in this area. Just be cautious </p>
   </div>
 </body>
</html>
WDS-EMER-ticker.gif

Pop-up Box Properties

Pop-up box is used to provide emergency information with text at the middle of the viewport.

  • background-color
  • This parameter specifies the background color of box, and specified with CSSCOLOR.

  • z-index
  • Since emergency information should be provided on top of any viewport, the value of z-index should be as high as possible.

  • width
  • The width of pop-up box is dependent on the size of application viewport. For example, if it wants to display 50% of actual size of viewport, it can use '50vw'.

  • height
  • The height of pop-up box also can be dependent on the size of application viewport.

  • color
  • This parameter specifies the font color of pop-up box, and specified with CSSCOLOR.

  • font-size
  • font size should be adjustable on the size of application viewport, and must be smaller than height parameter.

  • position
  • top
  • In general, Pop-up box is located at the middle of the screen. Hence, it is recommended to use 'vh' notation for designating the coordinate of pop-up box.

  • left
  • In general, Pop-up box is located at the center of the screen. Hence, it is recommended to use 'vh' notation for designating the coordinate of pop-up box.

  • border
  • border-color

This is example CSS file for presenting emergency information using ticker box;

#wds-emergency-popup {
   margin-left: 0;
   z-index: 9999;
   vertical-align: middle;
   width: 50vw;
   height: 50vh;
   color: white;
   font-size: 5vh;
   font-weight: bold;
   background-color: blue;
   position: fixed;
   top: 20vh;
   left: 25vw;
   border:5px solid red;
   border-color: red;
   overflow: visible;
}

This example presents scrolling text in the pop-up box.

<html>
 <head>
   <link href="wds-emergency-profile.css" rel="stylesheet">
 </head>
 <body style="padding:0px; margin:0px; width:100%;height:100%; ">
   <div id="main_contents">
         Main contents
   </div>
        <div id="wds-emergency-popup">
            <h2 align=center class=blink><u>Emergency Alert</u></h2>  
            <p align="center"> 
                Heavy storm is coming. <br>
                Do not go out and stay in the building 
            </p>
        </div>
 </body>
</html>
WDS-EMER-popup.png

Full Box Properties

The full box is used to provide an urgent emergency alarm in level 4 and 5, which occupies the entire screen.

  • background-color
  • This parameter specifies the background color of box, and specified with CSSCOLOR.

  • z-index
  • Since emergency information should be provided on top of any viewport, the value of z-index should be as high as possible.

  • width
  • The width of full box must be equal to the width of the application viewport. It is recommended to use '100vw'.

  • height
  • The height of full box must be equal to the height of the application viewport. It is recommended to use '100vh'.

  • color
  • This parameter specifies the font color of pop-up box, and specified with CSSCOLOR.

  • font-size
  • font size should be adjustable on the size of application viewport, and must be smaller than height parameter.

  • position
  • top
  • It is recommended to use '0vh'.

  • left
  • It is recommended to use '0vw'.

This is example CSS file for presenting emergency information using ticker box;

#wds-emer-prof-lv4 {
    z-index: 9999;
    width: 100vw;
    height: 100vh;
    color : white;
    font-size: 7vh;
    font-weight: bold;
    background-color: blue;
    position: fixed;
    top: 0vh;
    left: 0vw;
}

This example presents scrolling text in the pop-up box.

<html>
 <head>
   <link href="wds-emergency-profile.css" rel="stylesheet">
 </head>
 <body style="padding:0px; margin:0px; width:100%;height:100%; ">
   <div id="main_contents">
         Main contents
   </div>
        <div id="wds-emer-prof-lv4">
            <h2 align=center class="blink"><u>Emergency Alert</u></h2>   
            <p align="center"> 
                EVACUATE IMMEDIATELY <br>
                Earchquake has stiked this area<br>
                <br>
                GO OUT TO DESIGNATED AREA 
            </p>
        </div> 
 </body>
</html>
WDS-EMER-full.png

Use cases

UC1: Sharing emergency information with users' devices

  • Description
    • In disaster situation, the Internet disconnection may cause ineffective performance of a networked signage system. One of the solutions to solve this problem is device collaboration to share emergency information with users' mobile devices.
  • Assumption/Background
    • Multiple digital signage terminals in a particular area are connected to a specific network devices that supports WiFi AP.
    • An emergency information server is connected to the AP.
    • The administrator already knows the location and authentication information for accessing the AP as an administrative mode.
    • The emergency information can be acquired from various source, such as mobile network and broadcasting systems, and it is also possible to upload by the decision of a person in charge.
  • Service scenario
    • When external network is disconnected due to some disasters, the AP is set to emergency mode that redirects HTTP requests to the emergency information server.
    • Administrator goes to the AP to access the local network, and upload disaster information to the emergency information server using his/her devices such as smart phones and tablets.
      • On uploading the information, he/she uses web browser application rather than using specific emergency application.
        WDS-EmerProf UC1 Fig1.png
    • The digital signage terminals show brief descriptions on disaster situation with some guidance how to acquire more detail information.
      • In disaster situation, it is likely to be heavily crowded in front of the terminals. This may lead to unexpected accidents.
    • A user around the terminal access to the AP, and get information from the emergency information server for further information.
      WDS-EmerProf UC1 Fig2.png

UC2: AMBER (Alerts or a Child Abduction Emergencies)

TBD

UC3: Sharing emergency information for effective distribution

  • Description
    • In disaster situations, some digital signage terminals can get disconnected with digital signage server. However, there may be a few terminals that may still have connection with the server. If emergency information can be acquired from the connected terminals, it can be distributed to other terminals through various network interfaces. Also, it is possible for the administrator to provide emergency information to a single terminal when all the terminals are disconnected from the server. In this case, the single terminal can distribute disaster information to other terminals in propagation.
  • Assumption/Background
    • It is assumed that all terminals knows the network address (e.g, IP address and port number) of other terminals.
    • It is assumed that terminals has various network interfaces such as WiFi, D2D, Bluetooth, etc.
    • Emergency information can be uploaded from remote server, or by administrator to any terminal nearby.
  • Service scenario
    • In normal mode, digital signage terminals get contents from signage server or CDN server of service provider as shown in the following figure.
      WDS-EmerProf UC3 normal.png
    • If signage terminals are disconnected with signage server without any interaction until pre-specified time, it assumes that the connection is lost with the server, and turns into emergency mode.
    • In emergency mode, it opens all available network interfaces to receive information from various sources, and tries to connect with other terminals.
    • An administrator alerts emergency state by
      • sending emergency information to available digital signage terminals that still have connections.
      • uploading emergency information to nearby arbitrary terminal manually.
    • A terminal with emergency information sends the received information directly to the neighboring terminals that are accessible through any network interface.
    • Following figure shows that area 1 has still connection with server, but area 2 and 3 are disconnected. Terminals of area 1 can have connection with terminals in area 2 and 3 with using any network interface.
      WDS-EmerProf UC3 emergency.png

References

[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF.