1、IEEE Std 1512-2006(Revision of IEEE Std 1512-2000)IEEE Standard for CommonIncident Management Message Setsfor Use by Emergency ManagementCentersI E E E3 Park Avenue New York, NY10016-5997, USA1August 2006Intelligent Transportation Systems CommitteeSponsored by theIEEE Vehicular Technology SocietyIEE
2、E Std 1512-2006(Revision ofIEEE Std 1512-2000)IEEE Standard for Common Incident Management Message Sets for Use by Emergency Management CentersSponsorIntelligent Transportation Systems Committeeof theIEEE Vehicular Technology SocietyApproved 8 June 2006IEEE-SA Standards BoardThe Institute of Electri
3、cal and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright 2006 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 11 August 2006. Printed in the United States of America.IEEE is a registered trademark in the U.S. Patent +1 978 7
4、50 8400. Permission to photocopy portions ofany individual standard for educational classroom use can also be obtained through the Copyright ClearanceCenter.ivCopyright 2006 IEEE. All rights reserved.IntroductionThe Incident Management Working Group was formed from a cross section of ITS (Intelligen
5、tTransportation System) and incident management practitioners in 1997 to address the problems andconcerns of dispatching traffic management centers interacting with each other in the resolution of(primarily) roadway services disruptions (and certain other events on the highway) - generically referre
6、d toas incidents. Advancing the greater coordination of these centers and their cross servicing over variousjurisdictional boundaries is the primary objective of this Working Group.This standard is one of several related standards in this area and deals primarily with the communication ofvital data
7、of a public safety and/or emergency management nature involved in transportation-related events.It is the Base Standard. Other categories of communication, having to do with transportation management,hazardous material, and other cargo are addressed in other companion volumes generated by the Workin
8、gGroup. This Base Standard and other companion volumes together comprise what shall be known as theIEEE 1512 Family of Standards.This Base Standard includes more general introductory material for the family of standards, including theother companion volumes and the relationship between the family of
9、 standards and other ITS standards andthe National ITS Architecture.Problem statementIn the course of a transportation-related event where multiple public safety agencies are involved, there is acritical need to coordinate the management of the event among those agencies. Involved public safetyagenc
10、ies may include law enforcement, fire and rescue, emergency medical services (EMS), hazardousmaterial management, traffic management, towing and recovery, and others. Each agency has a separate setof tasks, resources, and communication gear; yet the agencies need to coordinate their separate actions
11、.The challenge to be met by the IEEE 1512 Family of Standards is to specify message sets to supportcommunication to coordinate those separate actions. That coordination extends to five categories ofinformation, as follows:a) Situation awareness: A common-format rendition of the situation, i.e., the
12、spatial layout, generalaspects such as smoke and fire, what each agency is doing, and tracking several variables in asummary way: injured, response personnel, response equipment, witnesses, perpetrators, involvedvehicles, and cargo. And as a special subject area of this volume, detailed information
13、relating to thecargo and any hazardous aspects that it may contain and of which others need to be aware.b) Each agencys plan of action: A flexible format for agencies to disseminate their plans, so that eachagency can take all other agencies plans into account in its own planning and management. Tha
14、texchange can support the specification of a single incident-wide action plan, or simply each agencyspecifying its own plan, to be followed separately but accounting for the plans of the other agencies.c) Asset management: An effective way for the agencies to share information about availability ofa
15、ssets for inter-agency management, and then to facilitate the inter-agency use of those assets, i.e.,where Agency A requests that an asset of Agency B be dispatched to the incident. This approachextends to informing other agencies of the need for services such as law enforcement, evacuation,medical
16、treatment, rescue, fire suppression, and hazardous material management.d) Warning information: Emergency evacuation, responder distress, cautions for responders, and “beon lookout for” information.This introduction is not part of IEEE Std 1512-2006, IEEE Standard For Common Incident Management Messa
17、geSets for Use by Emergency Management Centers.vCopyright 2006 IEEE. All rights reserved.e) Messaging overhead: Message priority, drill/not-a-drill, acknowledgment, ability to address byfunction as opposed to by agency name, and determining whether a center is functioning.That presents us with the b
18、asis for stating the goal.Goal of this Base StandardThe goal of this Base Standard is to specify message sets to support the exchange of the five types ofinformation just listed. More precisely, it is to specify the message sets that support that exchange, incombination with the message sets specifi
19、ed in the rest of the IEEE 1512 Family of Standards. As of thiswriting, that IEEE 1512 Family of Standards includes Base Standard: IEEE Std 1512-2006, IEEE Standard for Common Incident Management MessageSets for Use by Emergency Management Centers Companion Volume: IEEE Std 1512.1TM-2003, IEEE Stand
20、ard for Traffic Incident ManagementMessage Sets for Use by Emergency Management Centers Companion Volume: IEEE Std 1512.2TM-2004, IEEE Standard for Public Safety Incident Manage-ment Message Sets for Use by Emergency Management Centers Companion Volume: IEEE Std 1512.3TM-2006, IEEE Standard for Haza
21、rdous Material IncidentManagement Message Sets for Use by Emergency Management CentersAs part of its support of that exchange, this Base Standard will support existing conventions andnomenclature for established practices in public safety incident management, in particular the NationalIncident Manag
22、ement System (NIMS)aand existing formats for incident action plans. At the same time, themessage sets will not require that the local implementation use NIMS or any particular format for anincident action plan. Although in some local implementations any multiagency incident is coordinated witha sing
23、le plan, in other local implementations, conventions are oriented around each agency having its ownplan without any single, explicitly integrated plan. Both of those cases are supported by this standard.References to ICS and UCS in this volume shall be taken to also refer to the NIMS.This standard s
24、erves as a base standard for a family of standards in this area and deals primarily with thecoordination and exchange of information regarding incidents among emergency management and relatedcenters. More complex data and resource sharing, as well as message flows particular to transportationmanagem
25、ent, public safety, and hazardous materials, will be addressed in companion volumes to thestandard developed by the Working Group. In addition, an Implementation Guide for this standard willprovide an overview of the relationships between the messages and further examples of use with other ITSmessag
26、e sets that are not presented in the normative clauses of this standard.The national ITS architecture standards requirements document identifies the requirements for message setsto exchange data about incidents among emergency management and related centers. Incident or emergencymanagement is one IT
27、S service identified with centers that perform functions such as transportationmanagement, emergency management, transit management, and information service provider. The relevantarchitecture flows of the National ITS Architecture were identified and verified by the National ITSArchitecture Team. Th
28、e following problem statement forms the framework within which the messagestructures specification was developed. The problem can be stated as follows: A wide variety of separate organizations, each independentlydispatching its resources in the form of personnel and equipment, process incidents with
29、 a focus centric to itscommunity requirements. Each has established operational procedures and methods tailored to meet both itsindustry and its local requirements. The communication systems used by such centers are typically notaU.S. Department of Homeland Security, www.dhs.gov, March 1, 2004. As o
30、f this writing, exact URL: http:/www.dhs.gov/interweb/assetlibrary/NIMS-90-web.pdf.viCopyright 2006 IEEE. All rights mercial off-the-shelf in nature but have been developed to suit each center after an extensiveprocurement phase. Each center has a response territory, both geographic and administrati
31、ve, intertwinedwith other centers jurisdictions in complex ways. Each center has policies for dealing with the public-private release of information to others in unique ways. A degree of institutional distrust and concern forinadvertent release of information to the public prevents the full sharing
32、of information in most cases.NOTEMatters of safeguarding privacy will occur in implementing this base standard, e.g., managing the chain of cus-tody of incident data concerning individuals involved in an accident. Although beyond the scope of this base standard,such incident data concerning individu
33、als should be protected through state and federal laws. Only authorized officialswithin the chain of custody with a “need to know“ should be provided access. All data related to safeguarding privacyshould be protected by data security technology and audit procedures of the receiving information syst
34、em. All of theabove changes dynamically in some localities based on workload and requirements. These conditions vary considerably from state to state and among local jurisdictional implementationswithin a state. There is not a uniform model from which such incident management processes are built,mak
35、ing each a unique case. These issues are made more complex with the many communication alternativesamong motorists and the mobile public that can report and inform all parties about the occurrence of anincident in real time. This situation leads to many centers learning about the same event from man
36、y sourcesand requires a coordinated process. The goal of this standard is to provide common incident managementmessage sets in a uniform and open format that the local implementer can then tailor in a way that best suitsits requirements and policies for communicating among those centers.This standar
37、d specifically references a concurrently developed (and evolving) group of ITS standards thataddress transportation management centers, transit management centers, vehicles reporting Mayday events,and various preexisting public safety and incident response agencies, each with procedures and standard
38、s,e.g., the E911 community. This standard establishes ways for these separate groups to communicate witheach other at the emergency management center level, with each continuing to use the primarymethodologies already established and accepted among its constituency groups. Setting up such acommunica
39、tion system may require extant interagency agreements before implementing this standard.Those agreements may establish the communication protocols and messaging practices not specified in thisstandard and the actual messages, data frames, and data elements from this standard that should be used.Comp
40、anion volumesThis Base Standard provides definitions and use information on dialogs, messages, data frames, and dataelements that are then also used in the companion volumes listed above. To make full use of thisinformation, the Base Standard, companion volumes, and other references to ITS and indus
41、try standardsmay also need to be employed. That is particularly true in the area of message set reuse, where the contentsof various elements have been taken from well-established practices, both within and outside that of the ITSand the public safety industries.The standard and use with data registr
42、iesThe standard was developed in conjunction with entries designed to be made into a data registry. Thefollowing information may be useful to persons wishing to track the data structures described in thisstandard with those entries or in other similar registries.In each of the data structures found
43、in Clause 5 through Clause 7 of this standard, the following meta datafields are used and are equivalent to the named fields in a data registry. The mapping between these fields isas follows. The specific clause numbering and name of an entry is also the DESCRIPTIVE NAME of thatentry in the registry
44、 (the part that follows after the “:” is the name used). The one or more paragraphs thatthen follow, headed “Use,” forms the DESCRIPTION entry. The final one or more paragraphs, headed“Remarks,” forms the REMARKS entry. The section headed “Used by,” contains linkages to other datastructures that in
45、turn refer to this one. In a data registry, the fields RELATED DATA CONCEPT andviiCopyright 2006 IEEE. All rights reserved.RELATIONSHIP TYPE may be used to convey this information, along with other relationships. The sectionheaded by “ASN.1 Representation,” contains all ASN.1 defining code. In a dat
46、a registry, this information isbroken up among the fields: ASN.1 NAME, DATA TYPE, VALID VALUE RULE, and BODY. TheASN.1 NAME contains the formal ASN.1 Type Definition name of the object. The DATA TYPE containsthe base type from which it is defined. The VALID VALUE RULE, or the BODY, then contains the
47、 variousconstraints, declared constants, enumerations values, and comments of the rest of the definition. In the caseof data element entries, this information is found in the VALID VALUE RULE, whereas in the case of dataframes and messages, this information is placed into the BODY field. Other field
48、s used in a data registry (such as UNITS or FORMULA) are, typically, not provided with contentfrom this standard or are self evident and constant in nature. The SOURCE field is an example of this, andits value for all entries from this standard is IEEE Std 1512.3-2006.Notice to usersErrataErrata, if
49、 any, for this and all other standards can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL forerrata periodically.InterpretationsCurrent interpretations can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/interp/index.html.PatentsAttention is called to the possibility that implementation of this standard may require use of subject mattercovered by patent rights. By publication of this standard, no position is taken with respect to the existence or
