Integrated Public Alert and Warning System (IPAWS) Joint Practitioner and Developer Webinar Accessing the National Weather Service (NWS) HazCollect System via IPAWS Open Platform for Emergency Networks (OPEN) Wednesday July 18, 2012 12:00 Noon Eastern Amy Sebring: Good morning/afternoon everyone and welcome. I am Amy Sebring and will serve as your host. We are very glad you could join us, and a special welcome to any NWS Warning Coordination Meteorologists that may be with us today. Today’s program is about the National Weather Service’s HazCollect system and we hope it will be of interest to both alert originators and software developers. HazCollect is one of the principal dissemination systems that may be accessed through FEMA’s IPAWS-OPEN to provide additional pathways to alert the public of hazardous events. And as we all know, the more channels the better. The first part of our program will be non-technical and provide an overview of the system. We are pleased to welcome Michael Szkil, Chief of the Awareness Branch of the National Weather Service’s Office of Climate, Water, and Weather Services who has taken over from Herb White for HazCollect administration. The second part will be more technical in nature for the system developers who wish to make their alert origination software work with HazCollect. Gary Ham, IPAWS System Architect will highlight the unique requirements for Non-weather Emergency Messages, aka NWEMs. Without further ado, I will turn the floor over to Mike to start us off. [Slide 1] Michael Szkil: Good morning, everyone. What I want to do is give you an overview of what we are doing at the National Weather Service on the HazCollect program and how we are working with FEMA on issues and concerns. [Slide 2] I am the Chief of the Awareness Branch in the Office of Climate, Water and Weather Services in Silver Spring, Maryland. Herb White was our point of contact for HazCollect. Herb retired and we tried to get as much information from him as possible before he retired. My branch is responsible for dissemination. If you need to contact me for any information my telephone number and email address is on the slide. Feel free to contact me with questions, concerns of issues. There is one other person who is working on HazCollect. Her name is Mary Fairbanks. She is on leave today. We noticed when Herb retired that only one person was doing this but now we have another person. We work with FEMA, Amy and her group to look at what is happening with HazCollect and get progress made on it. One other person working with us, Kang Tran, in the Office of Operational Systems and he is the telecommunications software person. He will be implementing registration information that we get. We are working with FEMA on almost a daily basis. [Slide 3] HazCollect is an all-hazards emergency message collection system. The purpose is for non-weather emergency messages to be distributed to be distributed on NOAA systems for wider distribution. This began with a statement of need back in 2003. We have a process at the NWS that we put these types of programs through for implementation. We did some testing with the system in 2008 and we have been moving forward ever since. Right now the program is up and running. We are finding out that we are all new to the program and we had questions we had to get answers to. We are talking and trying to develop the process and get answers to our questions and questions that are sent to us. We are learning as we go. There is more we need to do and more to learn. We will get answers to your questions. [Slide 4] HazCollect allows authenticated and authorized external emergency managers to submit non-weather emergency messages into the IPAWS system which are sent to the Weather Service for distribution on our system. The process we use for authentication and authorization is in two parts. One part is FEMA’s authorization process and the other is the Weather Service authorization process. There is an application for an MOA agreement with FEMA as well as certification that they have done training. FEMA also makes sure the person applying is authorized before going through the rest of the process. There are different functions to apply for through IPAWS. They are CMAS, EAS and HazCollect. If HazCollect is applied for the Weather Service authorization is needed. We have to work in conjunction with FEMA on these requests. Applications must be made to FEMA first before the Weather Service can authorize for HazCollect. [Slide 5] This slide shows the process we have in place since March showing the Weather Service HazCollect process. If an applicant has checked the box to be authorized for HazCollect, the applicant will be guided through the process with the Weather Service for authorization. There is a link to a website where the application can be obtained. The registration form will be updated shortly. We are in the process of that right now. A form for outside sources is out for maintenance. We will come up with a way to figure out how emergency managers can send us registration forms. For now you can email me the information and we will manually put it in here. The server is not ready yet. Once we get a form, I take a look at it and make sure the information is correct. If I have questions on a form I contact Amy. Once we do that I send the form to the local WFO for their recommended approval. After that it is approved by the region and then it is sent back to us. We submit it to the communication group when Kang sets them up for production so they can access the Weather Service system. We are trying to redo the form so that we have all the information required at one time. FEMA wants the type of software package identified for HazCollect purposes, so that information will be on the new form. We are working these on a case by case basis. We have some old forms in the system that may cause some to have to reapply. We want to make sure the information is correct. Prior to me sending a registration form on the Weather Service side, I will send a email message to the WCM and the regional focal point for HazCollect notifying that we have a registration form that we will be sending shortly. When we send the form through the server you will get a message with a password you will need to access the form. When the WCM gets the form they have to tell us whether they recommend approval. Then it goes to the regional focal point for approval. We get the form back and it goes to the telecommunications people for setup. We are trying to find ways to improve this process and the form to make it easier. [Slide 6] These are examples of messages that are authorized through the non-weather emergency messages event types. There are 23 in the directive but these are samples. [Slide 7] How the process works: when an incident occurs, the responder notifies the emergency manager. They prepare the message with the software they have and submit it to the IPAWS system. If they have approval for HazCollect, it will come to the National Weather Service. Our server takes a look at it and sends it to NOAA and the correct offices where they will get a red banner alert that there is a non-weather emergency message to be transmitted. It will also go out to other systems the Weather Service has. The important thing is that only authorized messages are approved before they are sent out on these systems. [Slide 8] These are systems where HazCollect may be disseminated—NOAA Weather Radio, NOAA Weather Wire Service, and Emergency Managers Weather Information Network. [Slide 9] We are trying to identify issues and problems with the system. We work with FEMA regularly. We hold TELCONs every Monday to talk about HazCollect processes. FEMA lets us know which applications they have received. We check that they are aware of anything we receive. We look at websites we have and make updates. We are still continuing to look for issues with websites. If you see anything that needs to be updated we will address it. When we get registration forms in we will give you information of what the process is. In the last two years we have had very little movement on our side with registrations but that is increasing. The TELCONs have been helpful in answering questions we have and we get great recommendations from FEMA. We are developing a new registration form that will be available within the next few weeks. When we get the draft finished, we will send it to FEMA and all WCMs. Updating the National Directive for HazCollect—it is old and out of date and we need to update it. We are working with FEMA and our telecommunications people to get it updated. It is not a quick process. We have to go through a set motion and it could take longer than we had hoped. When we get the draft done we will send it to FEMA for approval before sending it to regions and offices. It could be a couple of months before the draft is sent out. We are not full-time on HazCollect but we are putting a big effort on getting it updated. [Slide 10] Here are some websites for the National Weather Service with information and forms for HazCollect. If you see mistakes or have questions send me an email. The FEMA IPAWS site also has information on HazCollect and what has to be done for FEMA. Amy Sebring: Thanks Mike. Before we turn it over to Gary, we will take any questions on HazCollect you may have for Mike. Please type your question into the Q&A panel. Audience Question: Does HazCollect still require passing the separate training course originally written for HazCollect? Michael Szkil: For FEMA registration you have to have certification for the EMI course. We are accepting that one as training requirements. Amy Sebring: When you get to the NWS HazCollect website there is a section for practitioners called “for government” that will review the steps Mike spoke about. There is also a section for developers. Amy Sebring: Now we will turn it over to Gary. For practitioners and WCMs you may want some of this information from Gary so that you will have some of the right questions for your developers. Gary Ham: This is functional technical information about data structures that are needed and responses that come out of IPAWS that developers can turn into knowledge for the users. It is something the consumers of software may want to hang on so they may understand what the complications might be in the process being built for them and what the opportunities are in a well-built piece of software to beat the problems as well as where to find information if you have issued with what you have purchased. I’ve taken some pieces from the web service interface guidance ordinarily provided only to providers with an MOA. I’ve taken out the technical things about how to do the formal connection and just talked about the data stuff so we can make it available for download. [NWEM Example] This is from the last section in the developer’s guide and it provides a sample NWEM message in CAP format, version 1.1 which is currently deprecated. Right now I am working on testing for version 3.02 of IPAWS-OPEN. Some of you working in TDL may want to talk with me about registering some of their issues in TDL once this is built up and we can use it in the UAP findings for the 3.02 version. It will be in testing for at least a month and a half before its release. It will be available in TDL probably by Friday. There may be an interruption of service today and tomorrow. This sample message, if you look down the document, you can see it has CAP fields in XML and annotation in XML comment form that explain what you need to do to build a CAP message. These things could be enforced by software on the clients’ side to make sure a message works for NWEM. These are for the NWEM interface 1.1 but all the requirements for the data structures themselves apply plugged into the CAP 1.2 format. This is still a good document for developers and others who need to know. It can still be used even though it is the 1.1 version. The event codes that are usable for NWEM are all on this document as well. They show the various types. There are no weather event codes because those are restricted to the Weather Service but they will take civil emergency messages that might come from a flood, for example. Non-weather emergency event codes are non-weather. This is a good example of what needs to be there applying to CAP 1.1 and CAP 1.2. [CAP Element Mapping] This is in the guide as well—it is an element by element in the structure of the CAP message table. It tells you what is needed and not needed for all the dissemination capabilities of IPAWS. We will do private message CAP exchange without signatures between two COGs. There are requirements for the 1.2 structure but not necessarily for the full IPAWS structure. This identifies what is required to make CAP exchange and the IPAWS profile passage work, and what is required for each of the dissemination channels in 1.2. If there are special requirements for any of those it is on the right side. If there is a question that comes back on a message this is helpful to see. There is also a guide to which elements are used and which are not used, which are important as far as each channel is concerned. This explains how the references tag works. It should be implemented by your software but you might review it if your software is having trouble. In NWEM you can use en-US or sp-US. In CMAS it can be empty or en-US. You can go through the table and each of these errors you might see the response type of requirements, how the event codes are handled—they are all identified there. [Post Response Codes] The first page of post response codes shows the 200 and 300 level response codes. We will have to put out another version of this file. The codes give you a response of 200 if it is a success for CAP and 2XX for any kind of response code where it fails basic CAP. It gives you a response of 300 if it passes the IPAWS profile. A response of 3XX is for anything in the data that causes it now to pass the profile. It has to pass the profile before it is even considered for NWEM in the processing of a CAP 1.2 message. That did not apply to 1.1. There is a response that tells you if it is an error or an informational block. The 400 shows an ACK. That is what you are looking for if you’re going for NWEM. That means it is valid for NWEM and that the COG that posted it is accepted for NWEM and the information is correct. The 401 is marked here as an error. In 3.02 it will not be marked as an error and it won’t be called invalid- NWEM-message. It will be called not-disseminated- by-NWEM. In the case where It was not intended for NWEM but for somewhere else, you will get a 401. Or in the case there was an error further down you will get a 401 meaning it did not go NWEM. Here are all the various codes possible for NWEM that explain why it did not go out on NWEM such as missing elements. A 412 means that there is an error on our side. We need to be notified of a 412. A 413 means you are not authorized for the geocode. A 414 means there is a time zone parameter that is missing. There are all the things that might be wrong and the reason they might be wrong. If you are a good software developer your clients will not get these error codes but if it should happen, these are the reasons. All the codes have a named value to them and what they mean and where they apply. These are the numeric values that go back to the previous table. You should be able to see why messages were not sent from these tables. If you get a 500, you get an ACK it went on the EAS feed. A 501 means the message did not go out on the EAS feed. The same is with the 600 codes dealing with CMAS messages. All of the following codes tell you why the message did not go out. These responses will be issued for every message issued through 3.02. As a developer you can take advantage of this for your interface or with debugging your software or assisting with debugging of the system. With this information you should be able to tell why a message has failed and give us an idea of where a problem occurred so it can be fixed. [CMAMtext Formula] This isn’t related to NWEM but people ask about it. People want to know how the text on the cell phone created when CMAS is done. The formula is described here. You have two options. If you have authority you can write it into a parameter called a CMAM text and that is what will go out. If you don’t there is a formula. It says what is happening and gives you a value from the CMAM text based on the event code, and then it goes to when the alert expires based on what is in the CAP message and what action should be taken based on the response type or event code. Finally it says who is sending the message. That is how it is built. If you have authority to do the CMAM text you can write your own 90 characters. This gives you an idea of how this text is created for developers and others. It is in the developer’s guide. It can be downloaded. Amy Sebring: Thank you very much Gary. If you have any questions for Gary, please go ahead and enter in the Q&A panel. In the meantime, we will get back to a few more for Mike. Audience Question: Why don't the initial applications go to the local NWS offices first? Michael Szkil: Before we send them to local offices we have to make sure they have met the FEMA requirements and processes. FEMA gets them and makes sure the person requesting access is legitimate. They check with state officials and make sure they have authorization to do that. Then they make sure the MOA is in place. We have to make sure all of that is in place before sending it to the local offices. Amy Sebring: The first step gets you an account on the IPAWS system which can get you access to HazCollect if you follow that path, but also the EAS and CMAS. You also have to complete the EMI training course. There is also a public alerting application piece. Audience Question: Will all HazCollect messages pass the local NWS office automatically or is manual authorization required? Michael Szkil: If we get a message that comes in from IPAWS it goes to the HazCollect server, to the telecommunication gateway servers, and then the appropriate office and there is a red banner alert that will let forecasters know the message has come in. They can review it and make sure everything is correct. It should then be distributed to NOAA radio for broadcast. I am trying to find out with our people is once we get a message if it is automatically transmitted or if there are procedures that require review. I will have to get back to you on that. That is how I know the system works now. Certain events have a higher priority than other messages. Amy Sebring: In the original NWS instruction, there was an opportunity for the local weather forecast office to review it to make sure the text is going to render correctly in the NOAA Weather Radio text-to- speech system. Audience Question: Do state SECCs have any saying on who may send alerts thru HazCollect? Amy Sebring: I have put up the public alerting application. This is part of the FEMA process. On the second page you can check off if you are interested in HazCollect access. FEMA is working with state emergency management agencies asking them to review applications from cities, counties, and other local jurisdictions to compare what is being requested to their existing plans for their state. Specific authorities should be consistent with the Emergency Alert System plans that are developed by the SECCs. Audience Question: Can one CAP message carry an alert to both EAS and HazCollect? If so, will the resulting EAS Header Code from both be the same so duplicates are detected? Gary Ham: They can both be the same. They come from the same source. The only issue that might be is that to go to HazCollect we have to translate back from CAP 1.1 and 1.2 to CAP 1.0 which is what the HazCollect server uses. We translate it as cleanly as possible so that it has the same information. If the message is translated appropriately from both sides then the header codes would be the same. That is an assumption but if the information is translated the same it should be the same but I can’t swear that it always will be. Audience Question: (Clarification of previous question.) When a fully approved emergency manager is sending a valid message, does the local weather office have to approve before releasing to weather radios? Michael Szkil: It is my understanding that once the message is in the system the approval process should be there already. I believe the offices can stop the messages although I can’t think of why they would do that. The messages should automatically go through and be transmitted. I don’t think they physically approve every one. Amy Sebring: The sender is identified so if there is an issue with the content, whoever is on duty should be able to contact the originator to resolve any issues. Michael Szkil: They should see a copy of the text message that is going to be broadcast. If they don’t want it to be transmitted they can stop it if they have a reason to do so. Amy Sebring: Time to wrap it up for today. Mike, Gary, thank you again for sharing this information with us. If you are not on our mailing list and would like to be subscribed, please drop me a line at asebring@emforum.org and indicate whether you wish to be subscribed to the general IPAWS Stakeholder mailing list or the developers list or both. Thanks to everyone for participating today and please come again. We are adjourned.