Common Alert Protocol: UK Profile Discussion … · Web viewCommon Alert Protocol: UK Profile Discussion Document Page 8 March 2015 Version 0.1 - DRAFT March 2015 Common Alert Protocol:

.

Common Alert Protocol:UK Profile Discussion

Document

Version: 0.1 - DRAFT

March 2015

Common Alert Protocol: UK Profile Discussion DocumentPage i March 2015

PrefaceThis document draws heavily upon the work undertaken by the Organisation for the Advancement of Structured Information Standards (OASIS) in developing the Common Alert Protocol (CAP). The United Kingdom is grateful to OASIS for agreeing to work together on this matter.

Acknowledgement"OASIS" is the trademark of the Organisation for the Advancement of Structured Information Standards, who are an open standards consortium where the CAP v1.2 specification is owned and developed.

Common Alert Protocol: UK Profile Discussion DocumentPage ii March 2015

Contents

1. Introduction....................................................................................................1

1.1 Purpose.................................................................................................1

1.2 Scope....................................................................................................1

1.3 United Kingdom Emergency Management Context...............................2

1.4 Document Structure...............................................................................2

2. CAP-UK Description.......................................................................................2

2.1 CAP-UK Scope......................................................................................3

2.2 CAP-UK Description (Source)...............................................................4

2.3 CAP-UK Structure Requirements..........................................................4

3. CAP-UK Methodology & Requirements........................................................6

3.1 CAP-UK Elements.................................................................................6

ANNEX A: CAP-UK USE CASES............................................................................... I

No notice incidents............................................................................................ I

No notice incident at a hazardous site:.............................................................II

A flood alert...................................................................................................... II

Rising tide events............................................................................................ III

National Disaster............................................................................................. III

ANNEX B: ABBREVIATIONS AND ACRONYMS....................................................IV

ANNEX C: UK EVENT LIST.......................................................................................V

Common Alert Protocol: UK Profile Discussion DocumentPage 1 March 2015

1. IntroductionThe UK is committed to make better use of open standards and this is a key part of the UK’s Technology Strategy. Overseen by the Open Standards Board1, a transparent process exists to identify and agree open standards that might suit the needs of the United Kingdom. Once agreed, all central Government departments are expected to have regard to that standard when developing new technology services. The Open Standards Board has agreed that the Common Alert Protocol2 (CAP) meets the challenge of a Public Emergency Alert Message3 - on the proviso that a UK Profile is developed.

Working with OASIS, Her Majesty’s Government looks forward to developing a common standard for the dissemination of alert and warning messages during an emergency. Throughout this document, the words “warning,” “alert,” and “message” will be used interchangeably.

1.1 Purpose

This document: “The Common Alerting Protocol – UK Profile Discussion Document” provides interested stakeholders with the initial views of the United Kingdom on the content of a UK-profile.

Because public warnings can be encoded various ways in CAP, a standardised guideline is desired across all equipment manufacturers and warning practitioners. The Cabinet Office (CO) and the UK CAP stakeholder community have developed this document to pose questions to the CAP community. The answers to these will enable the UK to better understand the rationale and logic behind the CAP standard and guide the UK with its decisions.

1.2 Scope

CAP-UK will initially design the capability to pass CAP v1.2 alerts and warnings through UK alerting systems. The primary use case supported by CAP-UK requires an originator to create and send a message that complies with the CAP-UK structure. Annex A highlights a number of scenarios where an alert message might be issued.

The aim is that an alert message can be disseminated to multiple target systems or exchange partners.

1 For more information please visit http://standards.data.gov.uk/how-we-select-standards 2 The Common Alert Protocol, Version 1.2; OASIS, http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html3 http://standards.data.gov.uk/challenge/public-emergency-alert-messaging

Version 0.1 - DRAFTMarch 2015

http://standards.data.gov.uk/challenge/public-emergency-alert-messaging

http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html

http://standards.data.gov.uk/how-we-select-standards


1.3 United Kingdom Emergency Management Context

The United Kingdom operates a localised approach to emergency management. The legislative framework for the UK is set by the Civil Contingencies Act 2004 (CCA), which outlines the activities that need to be undertaken and by whom. This includes a statutory duty on category 1 responders4 to maintain arrangements to warn and inform the public of emergencies alongside other core tasks such as identifying risks, developing emergency plans and maintaining business continuity arrangements. This can include agreeing that a nominated category 1 responder undertake this function on behalf of another. This is clarified by the statutory guidance accompanying the act.

Should an emergency occur within Scotland, Northern Ireland or Wales; the relevant government may provide additional support and coordination mechanisms.

1.4 Document Structure

In addition to this introductory section, there are two further sections:

a. Profile Requirements: Presented in the form of requirements and guidelines that any subsequent UK profile will need to address. It is important to note that CAP-UK is not intended to become new a messaging standard, but it is only a constrained version of the existing CAP v1.2 standard.

b. Technical Questions: Presented in the form of a table identifying the CAP elements and questions or comments that the UK would be grateful for views from the CAP community on.

4 Category 1 responders are those likely to play a role in responding to most emergencies and includes the Police, Fire and Ambulance, local authorities and acute healthcare bodies.



2. CAP-UK DescriptionCAP-UK has been established to meet the UK’s ambition to improve end-to-end incident communications between agencies and the public. The goal for CAP-UK is to provide the vehicle by which alerts and warnings can be sent to the greatest number of people, including those with disabilities and those who do not have English as their primary language. CAP-UK shall be required to disseminate messages over as many platforms as possible to ensure the widest dissemination.

2.1 CAP-UK Scope

The scope of CAP-UK has two dimensions. The first is to become the end-to-end system of message dissemination. CAP-UK provides the United Kingdom with the capacity for immediate communication to the general public at the national, regional and local levels during periods of emergency. The Profile will be available for use by Ministers, Commanders from the emergency services, utility providers and other public and private sector entities dependent on the situation.

The second dimension is as an alert and warning medium. The three basic components of any communication are the message, the medium, and the audience. CAP-UK forms part of the medium by providing a structure for the way that messages are issued. It neither influences the message nor the audience; although, all three components interrelate. It provides a capacity to transmit simultaneous translations of messages into one or more languages for all users, and it is the means for disseminating alerts and warnings at all the levels of an incident.

Within the domain of a message, there are differing roles and responsibilities:

There is an individual who sends the message (for example a Minister, or Police Gold Commander, Public Health Official etc).

There is an organisation that may be involved in this message (e.g. the Environment Agency or the Police service).

The audience for that message is made up of organisations (partner agencies, government departments, Devolved governments, local governments, and the private sector) and individuals (people).

CAP-UK is the means and the mechanism for a message to reach its audience. The mode can be broadcast (television, radio, internet) or targeted (telephone contact or Internet), but the means does not influence who provides the message, what the message says, or the intended audience. It is solely the manner through which the message is conveyed. CAP-UK provides communications and interoperability



capabilities that transcend the life cycle of a disaster or hazard event as alluded to by the UK Risk Register of Civil Emergencies5. The Civil Contingencies Act 2004 and its accompanying guidance advise what emergency responders are expected to do, with each emergency responder determining the level and scale of notification. CAP-UK offers the following benefits to the United Kingdom:

a. Provide an endorsed Government standard to jurisdictions and government Agencies that will guide future implementations of CAP during upgrades to alert and warning system technologies;

b. Establishes a requirement upon future users of CAP-UK to implement a consistent standard of CAP terminology and message structure; and

c. Provides a common standard and interoperability matrix that all organisations can use when interoperating with neighbouring or partner organisations.

2.2 CAP-UK Description (Source)

By starting with the complete CAP v1.2 specification, together with other profiles that have been developed internationally we can map the needs of the CAP-UK. To follow UK policy and the direction provided by its Open Standards Board, the reference CAP specification is constrained and may define <parameter> tags for any unique needs of the United Kingdom that do not correspond to existing OASIS CAP elements. Requirements in following sections define the “source Profile” by tailoring and constraining CAP v1.2.

In particular, consideration will be given to likely dissemination technologies and their operating constraints to maximise the value of any given alert or warning message.

2.3 CAP-UK Structure Requirements

Any message that is compliant with the Profile must validate against the original XML Schema as well as the resulting XML Schema of the Profile.

CAP v1.2 is an XML message standard that also contains an XML Schema, which is to be used for validation of the CAP v1.2 message. The CAP-UK must result in a constrained XML message adhering to the following requirements.

5UK Risk Register of Civil Emergencies, https://www.gov.uk/government/collections/national-risk-register-of-civil-emergencies


https://www.gov.uk/government/collections/national-risk-register-of-civil-emergencies

https://www.gov.uk/government/collections/national-risk-register-of-civil-emergencies


Table 1: CAP-UK Criteria and Miscellaneous Requirements

CAP-UK Criteria and Miscellaneous RequirementsNumber Requirement

1. A developed and agreed-to CAP-UK Schema must adhere to the requirements contained herein.

2. Unless otherwise stated within this “CAP-UK Requirements” table, all OASIS CAP v1.2 elements SHALL be adhered to exactly as specified in the OASIS CAP v1.2 Standard.

3. The CAP-UK MUST not become a new or additional messaging “standard” (i.e. another Alerts and Warnings standard or another CAP v1.2 “version”). It is simply a more constrained version of an existing messaging standard.

4. The CAP-UK message MUST comply with the CAP v1.2 standard.a) A CAP-UK message MUST always validate against the CAP v1.2

standard Schema.b) Definition and Development of the CAP-UK message may result in

a more restrictive Schema.c) A CAP-UK message MUST validate within the CAP v1.2 standard

namespace with no changes to root elements.d) A CAP-UK message MUST use all elements defined as mandatory

within CAP v1.2 e) A CAP-UK message MUST not change attributes for mandatory

fields.5. A CAP-UK MUST be capable of using an existing CAP v1.2 standard service (i.e.

software designed to apply the standard) to receive and understand a CAP-UK message.6. A CAP-UK message MUST NOT be of a Proprietary Format.7. A CAP-UK message MAY further constrain the CAP standard.*

(* may be thought of as a “constraint Schema” against the standard)8. A CAP-UK message MAY add to required element definitions.*

(*only to extend or clarify interpretation of the definition)9. A CAP-UK message MAY limit the size of required elements.

10. A CAP-UK message MAY exclude optional elements.11. A CAP-UK message MAY define elements in a specific, agreed-upon way – as defined

and adjudicated for the Profile12. A CAP-UK will adhere to broader UK policies and principles set out by the UK Open

Standards Board. 13. The inclusion of MIME extensions shall be prohibited.14. Any digital signatures used shall adhere to guidance from CESG as the UK’s National

Technical Authority.

3. CAP-UK Methodology & Requirements

In line with CAP v1.2, the <alert> block of the CAP v1.2 message will be utilised by CAP-UK to determine routing and handling. The <alert> block is not specific to any included <info> block, but a general reference to all associated <info> blocks and their content. No specific information about any particular <info> block will be



included in the <alert> block, unless it will not impact any subsequent <info> blocks. The <alert> block is designed for CAP-UK general use. Each <info> block is designed to meet the needs of individual message exchange partners.

The methodology applied while proceeding through the CAP v1.2 elements list gives preference to CAP-UK for each element interrogated. CAP extensions must be added using the <parameter> element, which may duplicate the intent of some of the <alert> elements.

Unless otherwise stated within these tables, all OASIS CAP v1.2 elements SHALL be adhered to exactly as specified in the OASIS CAP v1.2 Standard. Terminology within these tables SHALL be interpreted in accordance with Request for Comments (RFC) 2119. “Shall” and “Must” represent absolute requirements, while other terminology represents guidelines or instructions. Where the "Non-Conformance Impact” is blank no impact applies.

3.1 CAP-UK Elements

The elements table below identifies the elements present in a CAP version 1.2 message. In some cases questions are posed against these to better understand the rationale behind choices and inform the UK’s position on these matters. These questions are informed by consideration of other national profiles developed.

The following statements apply to the information presented in the table below:a) An emboldened Element Name denotes that the element is REQUIRED to

be used by this Profile to assure conformance with the OASIS™ CAPv1.2 standard.

b) A plain element name denotes that this Profile will accept that use of the element is OPTIONAL as per the OASIS™ CAPv1.2 standard.

c) Conformance with this Profile can be assured through implementation of the requirements that modify existing OASIS™ CAP v1.2 requirements are denoted against a particular element name in the column titled “CAP-UK Requirements”, unless otherwise stated in the table.



Element Name CAP-UK Requirements Discussion questions“alert” Element and Sub-elements

1 alert (1) Limit one <info> segment per alert, except where additional <info> segments have a different value for <language>.

It’s noted that several other profiles have revised this to limit one alert to one info black. It is assumed that this to minimise the length of

an individual CAP message – is this correct? What are the disadvantages to this?

2 identifier (1) A unique number assigned to each message. The UK’s initial thoughts are that this is a combination of an identifier for each organisation and then its own message ID – assume this is satisfactory?

3 sender (1) Must be traceable to an UK agency that is publicly recognisable.

(2) To be based on the organisation’s domain name. 4 sent As per OASIS™ CAP v1.2 requirements What are the implications of following CAP time rather than

ISO 8601? These differ on that the time at UTC is referred to -00:00 for CAP rather than +00:00 for ISO 8601?

5 status As per OASIS™ CAP v1.2 6 msgType As per OASIS™ CAP v1.2 7 source As per OASIS™ CAP v1.2 requirements, in addition:

(1)The Role of the individual authorising the message should be entered here.

(2) If the alert message is being processed on behalf of another organisation, details of the requesting agency must be entered here.

How should we reference the Source for audit purposes?

8 scope As per OASIS™ CAP v1.2 requirements, values of public, restricted or private on;y.

Either public, restricted, or private.

9 restriction As per OASIS™ CAP v1.2 requirements10 addresses (1) ? Our current thoughts are that this will be to a designated email

address – are there any problems foreseen with this?11 Code (1) REQUIRED

(2) Value SHALL include the string “CAP-UK v1.0” to indicate originator assures compliance with this Profile approved for use within the UK environment

It has been assumed that including this is necessary Would this be flagged in message header in any case?



Element Name CAP-UK Requirements Discussion questions12 note As per OASIS™ CAP v1.2 requirements13 references (1) To include the entire update trail, and not just the

most recent update.(2) To accommodate multiple-event scenarios, an alert

message may include a reference to an alert message previously issued by another authority.

(3) All related messages that have not yet expired MUST be included as a reference for all “Update” and “Cancel” messages

Linked to “identifier” above

Placing a conditional requirement seems sensible? I.e. if mesg = Update / Cancel then this is mandatory?

14 incidents As per OASIS™ CAP v1.2 requirements How have others solved this problem which for example may arise through having many alerts referring to the same incident. Super storm Sandy for example.

“info” Element and sub-elements15 info (1) Limit of one <info> per <alert>, except where

additional <info> segments differ from one another in content language and <language> value.

(2) When the <msgType> is an “Update”, and one but not all <info> segments are being updated or added, a <parameter> <valuename> of “Update” with a value of “Same” or “Revised” SHALL be included.

Note: <info> blocks will be specifically tagged with <parameter>information as to identify which exchange partner is applicable to that block. The order in which the exchange partner <info> blocks appear in the <alert> is not constrained.

It would be interesting to understand the rationale why others have followed this path of constraining 1:1

16 language (1) REQUIRED(2) If not present, an implicit default value of "en-GB"

SHALL be assumed.(3) A null value in this element SHALL be considered

equivalent to “en-GB”(4) The profile requires that <language> be completed

The UK would make this mandatory to default the language to en-GB.



Element Name CAP-UK Requirements Discussion questionsby alert message originators to ensure an appropriate value is used.

Note: The language value is important for message distributors 17 category As per OASIS™ CAP v1.2 requirements18 event (1) The UK notes that Aus, Can, US have developed a list of

events for this. What is the benefit of doing so?

19 responseType As per OASIS™ CAP v1.2 requirements20 urgency As per OASIS™ CAP v1.2 requirements. Code values are Immediate,

Expected, Future, Past, UnknownThe UK notes these values We need to map CAP values vs UK terms.

CAP values: Immediate, Expected, Future, Past, Unknown21 severity As per OASIS™ CAP v1.2 requirements. Code values are: Extreme,

Severe, Moderate, Minor, Unknown.The UK will need to map its existing terms against these values.

22 certainty As per OASIS™ CAP v1.2 requirements. Code values are Observed, Likely (p>~50%), Possible (p<=50%), unlikely (p~0), unknown

The UK will need to map its existing terms against these values.

23 audience As per CAP v1.2 24 eventCode As per OASIS™ CAP v1.2 requirements The UK notes that Aus, Can, US have developed a list of

events for this. What is the benefit of doing so?

25 effective As per OASIS™ CAP v1.2 requirements The UK will look to make this field mandatory – are there any views on this?

26 onset As per OASIS™ CAP v1.2 requirements27 expires (1) REQUIRED The UK will look to make this field mandatory – are there any

views on this?28 senderName (1) STRONGLY RECOMMENDED

(2) To be the publicly-recognisable name of the agency issuing the alert.

(3) The full text, or at least the first ten words, of this element could be used in the construction of recorded audio or text-to-speech audio.

(4) The full text, or at least the first 60 characters, of this

Why not require?

Plain text version of “sender”



Element Name CAP-UK Requirements Discussion questionselement could be used in the construction of video display text.

29 Headline (1) REQUIRED For Twitter purposes could we constrain this to 140 characters?

The UK will look to make this field mandatory – are there any views on this?

30 description As per CAP v1.231 instruction (1) STRONGLY RECOMMENDED

(2) <instruction> should be completed by alert-message originators to improve clarity and provide public with direction concerning what actions to take in order to stay out of harm’s way

(3) Address essential information first as content may get truncated during transmission

(4) The full text, or at least the first ten words, of this element could be used in the construction of recorded audio or text-to-speech audio.

(5) The full text, or at least the first 60 characters, of this element could be used in the construction of video display text.

Again, detail on content to be informed by work to validate Alert Message content. The UK will look to make this field mandatory – are there any views on this?

32 web As per OASIS™ CAP v1.2 requirements33 contact As per OASIS™ CAP v1.2 requirements34 parameter The UK are considering adding an additional parameter for

“Risk Rating”. For example, the Met Office issue weather warnings which are a product of its likelihood and impact. (See www.metoffice.gov.uk/guide/weather/warnings for more information) Is a problem foreseen with this?

“resource” Element and sub-Element35 resource As per OASIS™ CAP v1.2 requirements The UK is considering prohibiting use of this Element in the

profile due to concerns that linked to files might contain


http://www.metoffice.gov.uk/guide/weather/warnings


Element Name CAP-UK Requirements Discussion questionsmalicious content.

What are the views on this? 36 resourceDesc (1) Content is identified by use of the <mimeType> value37 mimeType (1) Single format be specified for each of these types

(2) Preference should be given to use of open, non-proprietary standards

(3) Address essential information first as broadcast content may get truncated during transmission depending on length of content

38 size As per OASIS™ CAP v1.2 requirements39 uri As per OASIS™ CAP v1.2 requirements40 derefUri As per OASIS™ CAP v1.2 requirements41 digest As per OASIS™ CAP v1.2 requirements

“area” Element and sub-Element42 area (1) REQUIRED

(2) Must include a recognised <geocode> value.(3) To maximise effectiveness to the public, the use,

where possible, of one <area> block per <info> block is encouraged.

(4) Additionally, where multiple <area> blocks are used, consolidation of <area> blocks into as few <area> blocks as possible is also encouraged.

(5) In the case of both single and multiple <area> blocks, each <AreaDesc> will have one value and will be in the language of the <info> block.

(6) In cases of multiple <area> blocks, each <area> block will differ by their <AreaDesc> value and recognised <geocode> value(s), without additional parameterisation, in order to maintain the integrity of

The UK is considering following the precedent set in other profiles where one area block is constrained to each info block.

What might the risks of doing this be?



Element Name CAP-UK Requirements Discussion questionsInternational CAP-XML messages within this Profile.

43 areaDesc (1) As per OASIS™ CAP v1.2 requirements We may provide guidance on here. Where possible this should be recognisable to the local community.

44 Polygon As per OASIS™ CAP v1.2 requirements Do we need to consider how the polygon is drawn?

Point-to-point line drawing of polygons butts against current ways of working with the Met Office in particular using splines. The Environment Agency get around this by using many many points but this complicates the message somewhat.

45 circle As per OASIS™ CAP v1.2 requirements46 geocode (1) At least one nationally recognised <geocode> value is

REQUIRED. (2) Other geo-codes may also be included, including Post

Codes with 4 decimal character, with no space between characters:<geocode>

<valueName>GB National Grif Reference<valueName>

<value>TQ299804</value></geocode>

(3) A location code consisting of six zeros ("000000") shall indicate a message intended for the entire United Kingdom.

The UK is considering using GB National Grid Reference or Irish Grid Reference.

Can we cross reference polygons defined elsewhere? This may be “Flood Warning Area AFW10342”, boundaries of public agencies, postcodes or regions. Many of these are already publically available at http://data.gov.uk/data/search?theme-primary=Mapping

Are there any views on these points?

47 altitude As per OASIS™ CAP v1.2 requirements48 ceiling As per OASIS™ CAP v1.2 requirements The internationally accepted measurement for this is metres,

yet CAP uses feet – why was this?


http://data.gov.uk/data/search?theme-primary=Mapping

http://data.gov.uk/data/search?theme-primary=Mapping

Common Alert Protocol: UK Profile Discussion DocumentPage I March 2015

ANNEX A: CAP-UK USE CASES

This Annex provides an overview of the scenarios where a CAP-UK profile might be used. They represent different scenarios in the audience and lead times.

No notice incidentsA no-notice incident within this category is one where the specific location and timing of the emergency could not have been reasonably predicted. In this situation a fire has occurred within a city centre. Activation of the system here would be a judgement call at the discretion of the Incident Commander.

Scenario type Representative emergencyShort Synopsis of scenario

23:00 A fire breaks out at the bar of a large nightclub in the centre of Liverpool. The club is at maximum capacity of 600 people inside with a queue of a further 100 people outside the building. The fire alarm sounds and the club is evacuated within 15 minutes.

Not everyone is clear why the club is being evacuated and there is a crush to get out as some people start to panic. People are confused about what is going on and some have minor injuries.

Some people are not convinced that there is a genuine emergency and are trying to re-enter the premises to collect their belongings.

The Fire Incident Commander locally makes the decision to issue an alert to the surrounding area to a radius of 400 metres advising them to evacuate due to storage of propane canisters at a neighbouring property.

Time of day 0230-0430 on Friday 26th August 2014Population and demographics in the area

The club is located in the centre of Liverpool on Fleet street. The city has an approximate night time population of 21,000 – a rise of 7,000 from the daytime population.

Current arrangements for public alerting. None, apart from an on site fire alarm.


Common Alert Protocol: UK Profile Discussion DocumentPage II March 2015

No notice incident at a hazardous site:The Control of Major Accident Hazards (COMAH) Regulations set out what the emergency measures must be in place for the legal operation of chemical sites within the UK. The Regulations require site operators at higher risk sites to provide an alert mechanism to inform local residents or businesses that there is a risk to their health.

Off site plans for these scenarios will be defined and will already include sections on public communication arrangements.

Scenario type Representative emergencyShort Synopsis of scenario

0300: A large explosion occurs at a chemical site resulting in a fire. Thick heavy smoke is billowing from the site and travelling in a westerly direction towards a large residential area. It is possible that the plume contain harmful contaminants that could impact public health. Those with respiratory problems are thought to be of particular risk.

0800: The fire is finally extinguished after 5 hours and it is confirmed that no toxins are in the plume however the smoke still could cause issues for those with respiratory problems. The large plume is still present and travelling in a south easterly direction.

Time of day 0300-0800 on Thursday 25th August 2014Population and demographics in the area

This incident is a 0300 in the morning so the population is almost exclusively residential and approximately 13,000. It’s summer time and residents are likely to be sleeping with the window open.

Current arrangements for public alerting.

An on site siren is sounded within 5 minutes of the explosion occurring.

A flood alertScenario type Representative emergencyShort Synopsis of scenario

Heavy rain and storms hit the UK and in particular the south west of England. Flooding is widespread in these areas with several villages having to be evacuated due to rising water levels. Thousands of homes and business are impacted. Some villages and towns have experienced partial flooding, for which there was a longer lead in time and therefore the opportunity to move belongings, however


Common Alert Protocol: UK Profile Discussion DocumentPage III March 2015

some areas have also suffered from very short notice flash floods or have been impacted by a sudden rise in water levels due to groundwater flooding.

Timeframe December 2013 - February 2014. Population and demographics in the area

Thousands of people impacted, particularly across the south-west of England. This includes residential properties, business, and schools.


TV and radio have been covering the events over the period but it is the Environment Agency’s FWD (Floodline Warnings Direct) system that has been delivering flood alerts, and in many cases severe flood warnings to impacted areas. Severe flood warnings are the highest level of flood alert and indicate risk to life.

Rising tide events Scenario type Representative emergencyShort Synopsis of scenario

Analysis of meteorological data lead to the conclusion that the west coast of Scotland will be affected by extremely strong winds in several days time. This however is an early forecast and therefore the precise impact and location of the areas affected is subject to change.

Timeframe 04 April 2014 06:00 – 10:00 hours BST

Forecast made 31 March 2014 at 15:00 BST and a Yellow Weather warning issued.

Population and demographics in the area

Thousands of people impacted, across the west coast of Scotland including some largely rural communities.


The weather warning would be featured on weather forecasts and local TV and radio stations will provide further information on possible preventative action.

Given the lead time, newspapers and websites will also carry the warnings.

National Disaster Central Government Activation. This would only be appropriate for incidents affecting large areas of the country, or for a catastrophic incident affecting the whole nation.


Common Alert Protocol: UK Profile Discussion DocumentPage IV March 2015

ANNEX B: ABBREVIATIONS AND ACRONYMS

AUSeventLIST Australian Event Code ListCAP Common Alert ProtocolCAP-CP Common Alerting Protocol Canadian ProfileCDC Center for Disease ControlCIV Civil authoritiesCMAS Commercial Mobile Alerting SystemDAB Digital Audio BroadcastDBS Direct Broadcast SatelliteDE Distribution ElementDOM Document Object ModelEDXL Emergency Data Exchange LanguageEDXL-CAP Emergency Data Exchange Language Common Alert ProtocolEDXL-DE Emergency Data Exchange Language Distribution ElementEOC Emergency Operations CenterAGD Attorney-General’s DepartmentISO International Organisation for StandardizationOASIS Organisation for the Advancement of Structured Information

StandardsPMO Project Management OfficeRFC Request for CommentsSDARS Satellite Digital Audio Radio SystemURL Uniform Resource LocatorXML Extensible Markup Language


Common Alert Protocol: UK Profile Discussion DocumentPage V March 2015

ANNEX C: DRAFT UK EVENT LIST

# TIER I EVENTS TIER II EVENTS EVENT CODE CAP CATEGORY VALUE

AUTHORITY TO MODIFY

1 Administration 2 Air Quality3 Animal Health4 Animal Disease5 Animal Feed6 Plague7 Sheep grazier warning8 Animal Attack9 Dangerous Animal10 Aviation 11 Aircraft Crash12 Airport closure13 Airspace closure14 Falling object15 Notice to Airmen16 Satellite/Space re-entry

debris17 Civil18 Building collapse19 Civil Emergency 20 Demonstration


Common Alert Protocol: UK Profile Discussion DocumentPage VI March 2015

21 Public Event 22 Volunteer Request 23 Criminal activity24 Cyber crime25 Dangerous person26 Home crime27 Industrial crime28 Retail crime29 Terrorism 30 Vehicle Crime31 Fire32 Bushfire33 Fire ban34 Fire danger level 35 Forest fire36 Grass fire37 Industrial fire38 Smoke alert39 Structure fire40 Total fire ban41 Flood42 Dam failure43 Flash Flood

TBC- Check methodology first.


Documents

Common Alert Protocol: UK Profile Discussion … · Web viewCommon Alert Protocol: UK Profile Discussion Document Page 8 March 2015 Version 0.1 - DRAFT March 2015 Common Alert Protocol: