CEA-CEB25-2011 Best Practices for Implementing Common Alerting Protocol (CAP) based Alerts for Consumer Electronics Devices《基于消费电子仪器警报的公共警报协议(CAP)最佳实施规程》.pdf

《CEA-CEB25-2011 Best Practices for Implementing Common Alerting Protocol (CAP) based Alerts for Consumer Electronics Devices《基于消费电子仪器警报的公共警报协议(CAP)最佳实施规程》.pdf》由会员分享，可在线阅读，更多相关《CEA-CEB25-2011 Best Practices for Implementing Common Alerting Protocol (CAP) based Alerts for Consumer Electronics Devices《基于消费电子仪器警报的公共警报协议(CAP)最佳实施规程》.pdf（32页珍藏版）》请在麦多课文档分享上搜索。

1、 CEA Bulletin Best Practices for Implementing Common Alerting Protocol (CAP) based Alerts for Consumer Electronics Devices CEA-CEB25 October 2011 NOTICE Consumer Electronics Association (CEA) Standards, Bulletins and other technical publications are designed to serve the public interest through elim

2、inating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for his particular need. Existence of such Standards, Bulletins and other technica

3、l publications shall not in any respect preclude any member or nonmember of CEA from manufacturing or selling products not conforming to such Standards, Bulletins or other technical publications, nor shall the existence of such Standards, Bulletins and other technical publications preclude their vol

4、untary use by those other than CEA members, whether the standard is to be used either domestically or internationally. Standards, Bulletins and other technical publications are adopted by CEA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, CEA does

5、not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard, Bulletin or other technical publication. This CEA Standard is considered to have International Standardization implication, but the International Electrotechnical Commission act

6、ivity has not progressed to the point where a valid comparison between the CEA Standard and the IEC document can be made. This Standard does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Stan

7、dard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. This document is copyrighted by the Consumer Electronics Association (CEA) and may not be reproduced, in whole or part, without written permission. Federal copyright

8、 law prohibits unauthorized reproduction of this document by any means. Organizations may obtain permission to reproduce a limited number of copies by entering into a license agreement. Requests to reproduce text, data, charts, figures or other material should be made to CEA. (Formulated under the c

9、ognizance of the CEAs R6.3 Wireless Power Subcommittee.) Published by CONSUMER ELECTRONICS ASSOCIATION 2011 Technology one or multiple instances N N Instances may include different languages TTS generated O Mono; one or multiple instances N N Instances may include different languages Text Event R Co

10、mbined text N N May include multiple languages Headline O Combined text N N May include multiple languages Area description R Combined text N N May include multiple languages Description O Combined text N N May include multiple languages Instruction O Combined text N N May include multiple languages

11、 Coded elements Status R Code Y Y MsgType R Code Y Y Scope R Code Y Y Category R Code Y Y Urgency R Code Y Y Severity R Code Y Y Certainty R Code Y Y Geocode O Code Y Y SAME event code R Code Y Y Expiration time R Code (time format) Y Y (*R/O: R=Required / O=Optional, as defined in CAP v1.2 and IPAW

12、S v1.0) The content may be divided into three logical groups: audio, text and coded elements. 4.1.1 Audio Content While audio elements are believed to be the most common way for quickly alerting the public, CAP messages are not required to include audio content. Past experience with CAP-based messag

13、es and other origination systems suggests that audio elements will likely be included, though their inclusion is solely at the discretion of the message originator. CEA-CEB25 8When audio is not included in the original message different decoders/encoders along the distribution chain may turn existin

14、g text into audio using Text-To-Speech (TTS) software. Audio may be provided in more than one language, whether in consecutive audio segments or in parallel audio segments where possible (e.g., digital radio and TV broadcasts with multiple audio streams). This may occur independently of the audio so

15、urce. Neither original audio content nor TTS generated audio is assumed to have distinctive characteristics that would allow it to be specifically (and precisely) identified by the receiver. Therefore, it is not assumed that receivers may somehow act solely based on received audio content. 4.1.2 Tex

16、t Content Text fields are well defined at the original CAP-based message level. However, when encoded for broadcasting the distinction of a specific field may be lost in a combined text encapsulation. Such encapsulation may include text from required and optional text fields, assembled together up t

17、o the maximum length supported by the encoder and the broadcasting system. Typical limits for all-sources combined text vary from 90 characters (typical of CMAS) to 1800 characters (ECIG-IG-1.0). The reception of a text string may be identified by receivers, but association of the text string with C

18、AP-derived text fields might not be apparent to the receiver. Thus it is not assumed that the receiver may somehow act solely based on the received text string. 4.1.3 Coded Elements Certain CAP-based messages include coded elements with a finite set of values. Although the CAP format along with the

19、IPAWS profile indicate the required elements, this only applies at the message origination level. It may be practical to assume that not all broadcast formats and mediums support the broadcasting of coded elements. Yet, it may be useful to accommodate the reception of such coded elements for cases w

20、here they become available. a. Status. Although the OASIS CAP v1.2 standard and IPAWS Profile v1.0 require inclusion of this element in a CAP-based message, this element might not always be included in the encoded message for broadcasting and therefore might not always be available to receivers. Onl

21、y a few values out of a larger selection (e.g., Actual), are likely to be of practical use to receivers. b. MsgType. Although the OASIS CAP v1.2 standard requires inclusion of this element in a CAP-based message, it might not always be included in the encoded message for broadcasting and therefore m

22、ight not always be available to receivers. Only a few values out of a larger selection (e.g., Alert or Update or Cancel) are likely to be of practical use to the receivers. c. Scope. Although the OASIS CAP v1.2 standard requires inclusion of this element in a CAP-based message, it might not always b

23、e included in the encoded message for broadcasting and therefore might not always be available to the receivers. When available it may be useful for distinguishing between public or limited scope receivers. d. Category. Although the OASIS CAP v1.2 standard requires inclusion of this element in a CAP

24、-based message, it might not always be included in the encoded message for broadcasting and therefore might not always be available to receivers. When available it may be very useful for allowing quick detection of the indicated subject (e.g., weather, fire, etc.) of the alert. CEA-CEB25 9e. Althoug

25、h the OASIS CAP v1.2 standard requires inclusion of this element in a CAP-based message, it might not always be included in the encoded message for broadcasting and therefore might not always be available to receivers. Only a few values out of a larger selection may be of practical use for receivers

26、. f. Geocode. This element is optional in a CAP-based message. It might not always be included in the encoded message for broadcasting and therefore might not always be available to receivers. Yet, past experience indicates that multiple instances of this element (as applicable to each message) are

27、included. When available this element may be very useful for receivers, allowing for quick detection of the geographic area targeted by the alert message. g. EventCode. This element is not required in a CAP-based message, but the IPAWS v1.0 standard does require its inclusion when an alert is genera

28、ted using the IPAWS profile in SAME format. Thus, it might not always be included in the encoded message for broadcasting and therefore might not always be available to receivers. Yet, upon usage in EAS systems and with the potential future expanded adoption of the IPAWS profile, it should be assume

29、d that this element will be broadly available. When available, it may be very useful for receivers, allowing for quick detection of the indicated subject (e.g., weather, fire, etc.) of the alert. h. Expiration Time (expired). This element is not required in a CAP-based message, but the IPAWS v1.0 st

30、andard does require its inclusion when an alert is generated using the IPAWS profile. This it might not always be included in the encoded message for broadcasting and therefore might not always be available to receivers. When available, it may be very useful for receivers, allowing for better handli

31、ng (more sophisticated time based processing) of the received alert message. 5 Best Practice Behavior for Consumer Electronics Devices This section contains recommendations for how consumer electronics devices should process CAP information. 5.1 General Recommendations Hardware/software recommendati

32、ons: a. At minimum an alert receiver should be capable of receiving and producing a monophonic version of the received audible portion of the alert message. b. An alert receiver should be equipped with display capabilities for at least 40 simultaneous characters (e.g., in a single raw (40x1) structu

33、re or in two row (20x2) structure). c. At minimum an alert receiver should be capable of receiving and displaying 384 characters conforming to ISO/IEC 8859-1, while utilizing the minimum display capabilities described in step b. Preferably, an alert receiver should be capable of receiving and displa

34、ying an alert message to its full extent, as provided by an alert information issuer. Behavioral recommendations: a. By default all responses to alert data should be turned on. The receiver should provide the user with the ability to turn each response off. The process for turning responses off and

35、on should be as simple as possible, without requiring the user to remember a unique pattern or unique command menu. CEA-CEB25 10b. The presentation of alert text data should be in a way that is distinguishable from any other textual information. This should involve more than simply applying differen

36、t colors. It should be done by taking presence over part of the physical display and may employ different displayable patterns. Integrity recommendations: a. The receiver should fully employ all means of alert message signal integrity processing. It should guarantee message reliability to the extent

37、 supported by all means of error control and correction included within the message. b. Only an alert message that successfully passes all instances of processing for integrity should be considered for presentation to the user. 5.2 Introducing Alert Text and Sound Figure 3: Alert Attention Sound Pat

38、tern 5.2.1 Providing Audible Alert Attention Sound a. The receiver should be capable of producing a specified alert sound. The recommended default sound, as shown in Figure 3, spans five seconds and consists of composite sound and silence. The composite sound consists of two tones, one at a fundamen

39、tal frequency of 853 Hz and one at a fundamental frequency of 960 Hz. b. The receiver may provide the user with a custom alert sound. The custom alert sound may have a different duration, but should last for at least 2 seconds and should not exceed 5 seconds. The user should be allowed to replace th

40、e recommended default sound with a custom alert sound on a user-preference basis. c. The receiver should provide the user with the capability of muting the alert attention sound. Figure 4: Expanded Visual Alert Indication 2 Sec Tone CompositionTone CompositionTone Composition1 Sec0. 5 Sec1 Sec0. 5 S

41、ecSilenceSilenceCEA-CEB25 115.2.2 Providing Visual Alert Attention Indication a. The receiver should be capable of producing a recommended default alert textual indication. At a minimum the alert text should state Alert. The alert text should be displayed for three to five seconds, starting with the

42、 alert text and alternating every 0.5 seconds between the alert text and dimmed display. b. The receiver may provide the user with a custom alert text string, expanding the indication while including the string Alert. A sample expanded alert string is shown in Figure 4. c. The receiver may provide t

43、he user with custom alert text in any chosen language. d. The default language should be English. The receiver may support additional languages, either simultaneously or based on user controlled configuration. e. The receiver should provide the user with the ability to turn off the textual alert att

44、ention indication. Figure 5: Data Display Example 5.2.3 Alert Message Text Display Practice a. When employing a minimum display of 1x40 the receiver should display the visual alert attention indication starting from the leftmost side of the display. It should be displayed for three to five seconds.

45、The attention indication may be followed by identification of the source of the alert. Appropriate names might include specific names (e.g., FEMA), a call sign or frequency, a website name or other familiar identification. b. The alert message text should be appended to the source identification and

46、 the overall text should scroll from right to left at a rate of three characters per second. c. When employing a minimum display of 2x20 the receiver should display the visual alert attention indication on the top display line starting from the leftmost side of the display. When a custom attention i

47、ndication is employed and exceeds the top line character size (20) the attention indication should be cyclically scrolling from right to left at a rate of two characters per second. d. The attention indication may be followed by source identification. If the combined text exceeds the display top lin

48、e size (20) it should be cyclically scrolled from right to left at a rate of two characters per second. e. The alert message text should be displayed on the display bottom line. The text should scroll from right to left at a rate of three characters per second. CEA-CEB25 12f. An example for such a c

49、ase is shown in Figure 5. In this example the top line provides the alert attention indication (Alert) expanded to include the alert matter (such as Weather). The attention indication is followed by the message source identification (KNAX 101.3 Topeka). The bottom line displays the alert text. The attention indication and the text follow the scrolling recommended practice, thus after four seconds the alert matter (top line) has shifted eight characters to the left, while the alert text (bottom line), which is typically longer and moves faster, has shifted 12 cha