WebEOC ARES-RACES WebEOC Input

Transcription

1 WebEOC ARES-RACES WebEOC Input Auxcomm input for Michigan CIMS John McDonough Copyright 2012, Michigan Section of the American Radio Relay League The text of and illustrations in this document are licensed by the Michigan Section of the American Radio Relay League under a Creative Commons Attribution--Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at The original authors of this document designate the Michigan Section of the American Radio Relay League as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. The Michigan Section, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. The ARRL Diamond and logo, the ARES logo and the ARPSC logo are registered trademarks of the American Radio Relay League in the United States and other countries. All other trademarks are the property of their respective owners. 1

2 ARES-RACES WebEOC Input Abstract The State of Michigan is updating its critical incident management system (CIMS). This document outlines functional suggestions from the Auxcomm perspective. 1. Introduction State RACES Officer Situation Update Station Status Local Jurisdiction Status ARES/RACES Station Station Status Message Log ARES/RACES Public Information Coordinator ARES Emergency Coordinator Assignment Entry Assignment Summary MARS Station Other Auxcomm Communications Considerations HSMM/Mesh Node A. Revision History 21 2

3 Introduction 1. Introduction The State of Michigan is updating its Critical Incident Management System and is in the process of identifying processes to be supported. This paper deals primarily with auxcomm roles. In the following sections, key ARES/RACES roles will be described, as well as U.S. Army MARS and a generic auxcomm role for CAP, REACT, etc. These other auxcomm organizations have quite a low profile across the state and will typically not be involved in most incidents. However, over time it is hoped they may be strengthened. The following roles are described at the state EOC level: State RACES Officer (ARES/RACES agency EMC). ARES/RACES Station ARES/RACES Public Information Coordinator MARS Station Other Auxcomm The following local role is described: Emergency Coordinator (County level ARES/RACES EMC, known as RO under National Communications Emergency conditions) In addition, a panel for communicating the current state of scene communications is described. Example Screens Only Note that throughout this document there are a number of mock-up screens. There is no suggestion that the particular cosmetics of these screens needs to be as shown in this document. The screens are only for illustrative purposes and in no way meant to imply a requirement. Screens should be as lean as possible to facilitate connection over slow circuits. 3

4 ARES-RACES WebEOC Input 2. State RACES Officer The Section Emergency Coordinator (SEC)/State RACES Officer, coordinates ARES/RACES operations throughout the state, and may also be called on to coordinate other auxiliary communications activities. The SEC will use the CIMS for a few key tasks: 1. Provide status updates to other agencies 2. Monitor status updates from other agencies 3. Monitor the status of ARES/RACES programs in the affected jurisdictions 4. Monitor the status of the station It is presumed that screens will be available to monitor significant updates from other agencies and that functionality is not described here. Figure 1. State RACES Officer 2.1. Situation Update The Situation Update portion of the screen is used to communicate agency status to other agencies. This role has no special needs, and it is assumed that this portion of the screen will reflect what is common to all agency coordinators. 4

5 Station Status 2.2. Station Status This section is used to monitor the station status. This is a read only view of the Station Status panel of the Station Manager (Table 2, Station Status ) Local Jurisdiction Status The SEC coordinates activities of local ARES organizations. While these are typically counties, some response is organized on a district basis. ARES has 11 districts; the 7 EMHSD districts and one for each of the National Weather Service offices in the state. In addition, a few cities also have programs although these are typically coordinated through the county. The SEC monitors the status of the local activities and organizes mutual aid when appropriate. He may also report significant local events to the other State agencies. The fields below are repeated n times. If all available rows must always be displayed then it is better to be stingy on the number of rows available (5-10). If only used rows can be displayed then a much larger number is preferred. (There are 98 possible jurisdictions, but it is difficult to imagine a case where all would be needed.) Jurisdiction CHAR 20 NOT NULL Contact VARCHAR 32 Issues/ Status VARCHAR 128 Table 1. Local Jurisdiction Status 5

6 ARES-RACES WebEOC Input 3. ARES/RACES Station The SEOC ARES/RACES station is the primary auxcomm resource for an incident. The station is manned by from two to five operators, but only one is likely to use the CIMS Station Status Figure 2. Station Status Situation Update The Situation Update portion of the screen is used to communicate agency status to other agencies. This role has no special needs, and it is assumed that this portion of the screen will reflect what is common to all agencies Station Status The SEOC station may operate on as many as six frequencies simultaneously, although one of those is usually in-building, so five channels are relevant. The station is capable of a wide range of modes and frequencies. During an incident, the station typically opens a circuit to a site near the incident, usually the local EOC. In many cases, there are multiple circuits open. It is useful for other agencies to be aware of the sites in contact with the station. In addition, 6

7 Station Status programs outside the SEOC may have need to know the current SEOC frequencies and modes in order to contact the SEOC. The following fields are repeated five times, once per row. Frequency CHAR 20 Frequency often includes a modifier, hence not simply a number. For example, /131.8 or waterfall. Mode ENUM Allowable Values: CW SSB FM Packet Olivia 8/500 Olivia 16/500 Olivia 8/1000 Olivia 32/1000 MT MT-63 1K MT-63 2K BPSK-32 MFSK16 MFSK32 Pactor Pactor III Winmor WL2K In contact with Table 2. Station Status VARCHAR 32 If enumeration is difficult to implement, it may be preferable to make this field simply a CHAR 16 string Message During the course of an incident, the station will exchange "formal" traffic with other stations. These messages must be logged, and that log should become part of the incident history. While there is some logic to associating a message with a status update, a preferable technique would be a separate message log (Section 3.2, Message Log ). 7

8 ARES-RACES WebEOC Input Number CHAR 6 All fields allowed to be NULL unless otherwise noted. Orig Call CHAR 12 Time Rec'd DATETIME This and other date time entries could default to the current date and time, but the operator must be able to change. No need to store seconds, minute resolution is adequate. Time Sent DATETIME Addressee VARCHAR 32 From Call CHAR 12 To Call CHAR 12 Signature VARCHAR 20 Time Del'd DATETIME Delivered To VARCHAR 32 Oper Call CHAR 12 Table 3. Message 3.2. Message Log A message log independent of the station status would be preferable to including the log in the status update. The message log will maintain a list of formal messages exchanged with other involved stations. Although in a typical incident the number of formal messages exchanged is small, in some cases the number can be quite large. The station has demonstrated the ability to sustain a rate of over 30 formal messages per hour. 8

9 Message Log Figure 3. Message Log The following fields should not have a limitation on the total number of repititions. A display of five to ten rows on a single screen should be adequate. Number CHAR 6 All fields allowed to be NULL unless otherwise noted, however an entirely NULL record should not be stored. Originating Station Message Date/Time CHAR 12 DATETIME Addressee VARCHAR 32 Signature VARCHAR 20 Delivered To VARCHAR 32 Date/Time Delivered Operator Call DATETIME Table 4. Message Log CHAR 12 Date only with no time is permissible for this field. This and other date time entries could default to the current date and time, but the operator must be able to change. No need to store seconds, minute resolution is adequate. Unlike Message Date/Time, a time is required for this field. 9

10 ARES-RACES WebEOC Input 4. ARES/RACES Public Information Coordinator The ARES/RACES Public Information Coordinator is responsible for coordinating communications with the media relevant to ARES/RACES activities. Because ARES/RACES operates only in support of other agencies, it is the policy of ARES/RACES that any media communications during the incident come from the served agency. As a result, the PIC tends to not be involved during the incident. The ARES/RACES Public Information Coordinator will only be engaged during an incident at the request of the MSP EMHSD PIO. Figure 4. Public Information Coordinator It may be desirable to evaluate whether fields from other agency PIOs are appropriate for this role. 10

11 ARES Emergency Coordinator 5. ARES Emergency Coordinator The ARES Emergency Coordinator is the local representative for ARES/RACES. This role is concerned with assigning operators to the various needs within the local jurisdiction. As a county role, these secreens are per county rather than systemwide. Since this activity involves the relationship between a number of entities, from a data architecture perspective, it would be preferable to have a number of tables statewide, with relationships between the tables. However, maintenance of such an approach would be burdensome, so an approach using plain text fields is proposed. It seems likely that "facility" may well become a system-wide entity. If that is the case, there are a number of attributes that are important to ARES/RACES but might not be important to other agencies. Contact information for an entity should include a frequency, which is likely to change per incident. Availability of emergency power for the facility should be recorded. Drop-downs for selection of facility should be filterable by county. ARES/RACES operators are often stationed at non-traditional facilities. Flexibility in facility type should be provided Assignment Entry The assignment entry screen allows the Emergency Coordinator to track operators assigned to various facilities for various shifts. Note that shifts are often not eight hours, but rather an amount of time appropriate to the particular role, or available from the volunteer. 11

12 ARES-RACES WebEOC Input Figure 5. Assignment Entry Facility Name VARCHAR 20 Address VARCHAR 32 Facility Type CHAR 20 Facility Status ENUM Phone CHAR 16 Emergency Power BOOL Freq 1 CHAR 16 Freq 2 CHAR 16 Table 5. Facility Information Allowable values: OPEN CLOSED Scheduled open Pending close 12

13 Assignment Summary Shift CHAR 16 Call CHAR 12 Name VARCHAR 32 Cell CHAR 16 Notes VARCHAR 128 RACES BOOL HF Capable BOOL Has APRS BOOL Table 6. Operator Information Button Action Clear Clear all fields for this operator Up Move this entry up one in the list of three Down Move this entry down one in the list of three Table 7. Button Actions 5.2. Assignment Summary The assignment summary panel gives the Emergency Coordinator an overview of the assignments for the incident. Fields are from the previous screen. Figure 6. Assignment Summary Button Action Opens a read-only view of the assignment entry form (Figure 5, Assignment Entry ) for the current record. 13

14 ARES-RACES WebEOC Input Button Action Opens the assignment entry form (Figure 5, Assignment Entry ) for the current record. Opens the assignment entry form (Figure 5, Assignment Entry ) for a new record. Table 8. Actions 14

15 MARS Station 6. MARS Station U. S. Army MARS is a small group of individuals who provide communications for the United States Army. These stations provide communications to various Federal agencies on frequencies separate from ARES/RACES frequencies. Under certain propagation conditions this frequency diversity can be advantageous, as can the relationship with Federal agencies. U. S. Army MARS maintains a station at the SEOC and should be provided a way to deliver status updates. However, unlike ARES/RACES, MARS tends not to maintain open circuits to the field. In addition, MARS frequencies are classified, so the Station Status panel is not useful for this station. Furthermore, Army MARS has indicated a preference to log messages independently of the CIMS. Figure 7. Army MARS Station 15

16 ARES-RACES WebEOC Input 7. Other Auxcomm There are a large number of additional organizations potentially cabable of delivering auxiliary communications resources. These include, but are not limted to: U.S. Air Force MARS Navy/Marine Corps MARS REACT - The Citizen's Band Emergency Communications Team Civil Air Patrol Michigan Volunteer Defense Force These organizations may need a way to communicate their status, so a generic status update for them should be provided. However, it is important to note that this is quite a low priority. Currently, no use is being made of these resources. Figure 8. Other Auxcomm 16

17 Communications Considerations 8. Communications Considerations Communications to the scene is critical, and many things can disrupt this communication. The Scene Communications Considerations panel is intended to provide a means to communicate the status of the various technologies to the agencies. In addition, the list of technologies and a place to record concerns could be a valuable asset when developing the Communications portion of the Incident Action Plan. Figure 9. Communications Issues The following fields repeat for each concern: Issue TEXT 256 Resolution TEXT 2048 Table 9. Scene Communications Considerations 17

18 ARES-RACES WebEOC Input 9. HSMM/Mesh Node HSMM/Mesh nodes should be inventoried, with capabilities and key configuration information recorded. Figure 10. HSMM/Mesh Node Name CHAR 20 UNIQUE Table 10. Mesh Name Note that location information uses the UTM coordinate system. While geographic location information is only occasionally useful, in those cases it is, UTM coordinates are far more usable than traditional lat/long. If integration with GIS is possible, it would be preferable to have the Height filled from the GIS based on UTM. Another desirable feature would be to select between coordinate systems with buttons. 18

19 HSMM/Mesh Node UTM Grid ENUM Valid Values: Easting INTEGER 7 Zero filled 15T 16T 17T Northing INTEGER 7 Zero Filled (although not particularly relevant since valid values for this field are > 4,000,000) Height INTEGER 5 Portable BOOL Table 11. Location Information Mesh Name CHAR 20 Mesh Address CHAR 16 Node Name CHAR 20 Node Address Encryption Type CHAR 16 ENUM Table 12. Mesh Network Information Valid Values: none WEP Antenna Height INTEGER Gain DECIMAL 2.1 Direction Beamwidth Omni Feedline Length INTEGER INTEGER BOOL INTEGER Type CHAR 16 Total Loss ERP INTEGER INTEGER Table 13. Mesh Antenna Information ** Right antenna duplicates left antenna ** 19

20 ARES-RACES WebEOC Input Network Name CHAR 20 SSID CHAR 10 Network Type Encryption Type ENUM ENUM Address CHAR 16 Valid Values: Valid Values: Netmask CHAR 16 default Gateway CHAR 16 Nameserver CHAR 16 DHCP BOOL Start CHAR 16 End CHAR 16 Key CHAR 128 Table 14. WiFi Network Information Table 15. WiFi Antenna Information ** WiFi antennas duplicate mesh antennas ** a/b/g n b g b/g none WEP WEP Passphrase Dynamic WEP WPA WPA Enterprise LEAP 20

21 Revision History A. Revision History Revision 2 Sat May John McDonough wb8rcr@arrl.net Add HSMM/Mesh Node Revision 1 Fri May John McDonough wb8rcr@arrl.net Released to EMHSD Still lacking HSMM Revision 1 Thu May John McDonough wb8rcr@arrl.net Initial draft Revision 0 Wed May John McDonough wb8rcr@arrl.net Initial creation of book by publican 21

22 22