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 26 June 2014


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.

This section provides brief description of the overall lifecycle of emergency information that can be displayed in the digital signage system. Normally emergency information is officially generated by the national disaster related center such as weather center or national relief organization. This part can describe the overall structure of emergency information system and describes how the information data may be processed by the digital signage system in general.

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.

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

References

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