Guide PDF

Guide to the IEEE 1512™
Family of Standards
Prepared by:
Michael A. Ogden, P.E.
With assistance from:
Anita C. Ricketts
Ann R. Lorscheider, P.E.
Jerry Althauser
Wayne L. Gisler, P.E.
Katherine A. Mears, P.E.
Trademarks and Disclaimers
IEEE believes the information in this publication is accurate as of its publication date; such information is
subject to change without notice. IEEE is not responsible for any inadvertent errors.
Library of Congress Cataloging-in-Publication Data
Ogden, Michael A., 1963-

Guide to IEEE 1512 family of standards / prepared by Michael A. Ogden ; with
assistance from Anita C. Ricketts…[et al.].
p. cm.
Includes bibliographical references.
ISBN 0-7381-3868-1
1. Emergency communication systems--United States--Standards. 2. Traffic

safety--United States--Data processing--Standards. 3. Emergency management--
United States--Data processing--Standards. I. Title.
TK5105.55.O33 2004
363.1'062'0973--dc22
2004040718
The Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA
Copyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc.

All rights reserved. Published April 2004. Printed in the United States of America.
No part of this publication may be reproduced in any form, in an electronic retrieval system, or otherwise, without the prior
written permission of the publisher.
IEEE is a registered trademark of the Institute of Electrical and Electronics Engineers, Incorporated (www.ieee.org/).
IEEE Standards designations are trademarks of the Institute of Electrical and Electronics Engineers, Incorporated.
Yvette Ho Sang, Manager, Standards Publishing

Jennifer Longman, Managing Editor
ii
IEEE Press/Standards Information Network publications are not consensus
documents. Information contained in this and other works has been obtained from
sources believed to be reliable, and reviewed by credible members of IEEE
Technical Societies, Standards Committees, and/or Working Groups, and/or
relevant technical organizations. Neither the IEEE nor its authors guarantee the
accuracy or completeness of any information published herein, and neither the
IEEE nor its authors shall be responsible for any errors, omissions, or damages
arising out of the use of this information.
Likewise, while the author and publisher believe that the information and guidance
given in this work serve as an enhancement to users, all parties must rely upon their
own skill and judgement when making use of it. Neither the author nor the publisher
assumes any liability to anyone for any loss or damage caused by any error or
omission in the work, whether such error or omission is the result of negligence or
any other cause. Any and all such liability is disclaimed.
This work is published with the understanding that the IEEE and its authors are
supplying information through this publication, not attempting to render
engineering or other professional services. If such services are required, the
assistance of an appropriate professional should be sought. The IEEE is not
responsible for the statements and opinions advanced in the publication.
Review Policy
The information contained in IEEE Press/Standards Information Network publications is reviewed and
evaluated by peer reviewers of relevant IEEE Technical Societies, Standards Committees and/or Working
Groups, and/or relevant technical organizations. The authors addressed all of the reviewers’ comments to
the satisfaction of both the IEEE Standards Information Network and those who served as peer reviewers for
this document.
The quality of the presentation of information contained in this publication reflects not only the obvious
efforts of the authors, but also the work of these peer reviewers. The IEEE Press acknowledges with appreci-
ation their dedication and contribution of time and effort on behalf of the IEEE.
To order IEEE Press Publications, call 1-800-678-IEEE.

PDF: ISBN 0-7381-3868-1 SP1133
See other IEEE standards and standards-related product listings at:

http://standards.ieee.org/standardspress/
iii
Acknowledgement
... In memory of Dr. Kamal Karma.
iv
Dedication
 2001 The Record, (Bergen County, NJ), Thomas E. Franklin, Staff Photographer.
(www.groundzerospirit.org)
The IEEE 1512 Family of Standards is dedicated to the memory of those who
lost their lives responding to the tragic events of September 11, 2001. The
Working Group honors the men and women who continue to maintain
vigilance in protecting freedom and security. It is our hope and expectation
that these standards will enhance multi-jurisdictional communications.
v
Contents
Abbreviations and Acronyms........................................................................................................ viii
Executive Summary ..........................................................................................................................1
Chapter 1 Introduction .....................................................................................................................6

Purpose of this Guide .............................................................................................................6
History of the Standards.........................................................................................................7
Scope of this Guide ................................................................................................................7
Chapter 2 Potential Issues Related to Information Sharing .............................................................9
Chapter 3 Overview of the IEEE 1512 Family of Standards ........................................................11

The Content of the Standards...............................................................................................11
The Need for the Standards..................................................................................................12
Levels of Implementation of the Standards .........................................................................13
Systems Engineering Process Utilized for Standards Development....................................14
Table Top Exercises .............................................................................................................16
Relationships of 1512 Standards with Other Documents and Activities .............................18
Relationships to Other Standards Development Organizations ...........................................18
Relationships with Companion Volumes.............................................................................21
Relationships to the ITS National Architecture ...................................................................22
Relationship to Public Safety Interoperability .....................................................................24
Relationship with Justice Standards Registry ......................................................................25
Incorporating Standards to Existing Communication Systems............................................26
Future Revisions to the Standards........................................................................................26
Chapter 4 IEEE Std 1512-2000 (Base Standard) ...........................................................................28

Summary of the Standard.....................................................................................................28
Purpose of the Standard .......................................................................................................28
Basic Structure of the Message Sets ....................................................................................28
Adapting this Standard to Local Applications .....................................................................29
Chapter 5 IEEE Std 1512.1-2003 (Traffic Management) ..............................................................31

Chapter 6 IEEE Std 1512.2-2004 (Public Safety Standard) ..........................................................35

Chapter 7 IEEE Std 1512.3-2002 (HAZMAT Standard)...............................................................37

vi
Chapter 8 IEEE Std 1512a-2002 (Emergency Management Data Dictionary)..............................40

Chapter 9 Case Study Implementations .........................................................................................42
Appendix A Message Set Tables ...................................................................................................43
Appendix B Case Study Implementations .....................................................................................51
Appendix C Potential Implementation Guidelines ........................................................................62
Appendix D Bibliography ..............................................................................................................65
Appendix E Web Site Information.................................................................................................66
Appendix F Contact Information ...................................................................................................68
Appendix G Committee List ..........................................................................................................69
vii
ABBREVIATIONS AND ACRONYMS
AASHTO American Association of State Highway and Transportation Officials

ADUS Archived Data User Service
APCO Association of Public-Safety Communications Officials
ASN.1 Abstract Syntax Notation One
ASTM American Society for Testing and Materials
ATIS Advanced Traveler Information Systems
CAD Computer Aided Dispatch
CapWIN Capital Wireless Integrated Network
CCTV Closed Circuit Television Cameras
CDSI Communication and Data System Infrastructure
CFR Code of Federal Regulations
CVISN Commercial Vehicle Information Systems and Networks
CVO Commercial Vehicle Operations
DATEX Data Exchange
DE Data Element
DF Data Frame
DOT Department of Transportation
DR Data Registry
EMC Emergency Management Center
EMDD Emergency Management Data Dictionary
EMS Emergency Medical Services
ETS Emergency Telephone System
ETTX Electronic Table Top Exercises
FEMA Federal Emergency Management Agency
FHWA Federal Highway Administration
FOP Functional Operating Procedures
FR Functional Requirements
GAC Global Advisory Committee
HAZMAT Hazardous Materials
HTML HyperText Markup Language
IDX Incident Description
IEEE Institute of Electrical and Electronics Engineers, Inc.
IEEE-SA IEEE Standards Association
IIMS Integrated Incident Management System
IMWG Incident Management Working Group
ISO International Standards Organization
ISP Information Service Provider
ITE Institute of Transportation Engineers
ITS Intelligent Transportation Systems
viii
JPO Joint Program Office
JSR Justice Standards Registry
MCT Mobile Computer Terminal
MS/ETMCC Message Sets for External Traffic Management Center Communications
NEMA National Electrical Manufacturers Association
NENA National Emergency Number Association
NFPA National Fire Protection Association
NFIRS National Fire Incident Reporting System
NTCIP National Transportation Communications for ITS Protocol
NTFI National Task Force on Interoperability
NTIMC National Traffic Incident Management Conference
OSI Open Systems Interconnect
PAR Project Authorization Request
PSAP Public Safety Access Point
RIT Required Information Types
RMS Records Management Systems
SAE Society of Automotive Engineers
SAFECOM Wireless Public Safety Interoperable Communications Program
SDO Standard Development Organizations
SOPS Standard Operational Procedures
TCIP Transit Communications Interface Profiles
TESCNET Transportation and Emergency Services Communications Network
TMC Traffic Management Center
TMDD Traffic Management Data Dictionary
TRANSCOM Transportation Operations Coordinating Committee
TTX Table Top Exercise
USDHS United States Department of Homeland Security
USDOT United States Department of Transportation
XML Extensible Markup Language
ix
EXECUTIVE SUMMARY
Introduction
This Guide, developed for the Institute of Electrical and Electronics Engineers, Inc. (IEEE)
1512 Family of Standards, highlights the advantages of the implementation of the IEEE 1512 Family of
Standards. It summarizes the technical aspects of the 1512 Standards and presents the information in a
usable format for decision makers and public agency managers. The audience for this document includes
the decision makers and public agency managers who will benefit from the IEEE 1512 Family of
Standards for implementation at their public safety center or transportation center.
A standard is a published document that defines specifications and procedures designed to ensure that a
material, product, method, or service meets its purpose and consistently performs to its intended use.
Standards solve issues ranging from product compatibility to addressing consumer safety concerns.
Standards also simplify product development and reduce non-value-adding costs thereby increasing a
user's ability to compare competing products. Only through the use of standards can the requirements of
interconnectivity and interoperability be assured. The credibility of new products and new markets
verified enabling the rapid implementation of technology are another benefit of the standards.
The IEEE 1512 Family of Standards is incident management and traffic incident-related. Traffic incident
management consists of managing available resources of various agencies to address the incident in an
efficient and appropriate manner. A traffic incident includes any transportation-related event that is
received by an emergency management system, including planned roadway closures at special events,
whether or not the incident actually affects traffic flow, and whether or not a response is required. An
emergency management system can be any organization or person that coordinates or designates
resources in an emergency. Some examples of emergency management systems include a 911 system,
local police, or a public works department.
Facilitating the exchange of messages among these centers and agencies for coordinating traffic incident
management is the primary task of the 1512 Standards. The focus of this Guide is to discuss how the
IEEE 1512 Standards can improve the distribution of traffic incident management information by using
common message sets as a structure for communicating between various centers. A center is any point
of communication used in the control of resources. A description of the basic structure of the message
sets and how they could be used in a local implementation is also covered in this Guide.
Issues Related to Information Sharing
Several issues should be considered when using a set of standards in an existing traffic incident
management system. There are several fundamental barriers to information sharing. At the onset of
implementation of new standards, there is a reluctance to change by many institutions as well as a lack
of understanding of other agencies’ needs. An absence of regional vision by self-sufficient agencies can
hinder acceptance of new procedures. The absence of known and respected champions of new
standards can also be a hindrance. Addressing issues related to Standard Operational Procedures
1
(SOPS) between the agencies is a local choice and outside the standards, but sound system engineering
and user requirement practices will ease implementation and help overcome institutional issues.
Legacy or closed communication systems at an agency can cause an issue with compatibility with
systems at other agencies. Fundamental system differences between agencies create a gap in
communication or significantly slow the transfer of information. If a regional communication and
information architecture has not been established, additional problems could arise concerning agency
jurisdiction and responsibility in regard to incident management.
In any computer system, there is a network architecture and various deployed choices regarding
systems protocols. The Open Systems Interconnect (OSI) is a seven-tiered layering system that defines
these system protocols. It is used as a framework for international standards to maintain consistency in
computer network architecture.
The 1512 Family of Standards defines the messages to exchange in communication protocols.
Communication protocols, which are critical to any communication system, are at a lower OSI layer and
will have to be addressed separately. This issue sometimes creates challenges with Departments of
Transportation (DOTs) implementing Intelligent Transportation Systems (ITS) Standards because it
requires detailed systems integration. To address the challenge, various different standards and
protocols must be combined to address each layer of the OSI stack including security, physical media,
etc.
Overview of the IEEE 1512 Family of Standards
The IEEE 1512 Family of Standards consists of a Base Standard and a set of companion volumes. The
standards include the following:
IEEE Std 1512 -2000, Common Incident Management Message Sets for Use by Emergency
Management Centers
Also known as the Base Standard, this document is the foundation of the family of related standards that
address the intercommunication needs of emergency management centers and other types of centers
engaged in traffic incident management. It establishes a framework of basic forms that the other volumes
all rely on and extend. This standard includes general introductory material for the Family of Standards,
and contains message set information that focuses primarily on the exchange of information between
centers that respond to traffic incidents.
IEEE Std 1512.1 -2003, Traffic Incident Management Message Sets for Use by Emergency
Management Centers
This standard focuses primarily on the coordination and exchange of information supporting real-time
traffic incident management between traffic management centers. Agencies involved in traffic
management collect data unique to their operation that may be useful to other agencies that respond to
traffic incidents. This volume provides the means of sharing this data with other agencies involved in the
2
incident response through the application of the 1512 Family of Standards. Additionally, information
needs associated with traffic management centers are also defined in this volume.
Asset management during traffic incident response is specifically addressed in an effort to facilitate the
assignment of multi-jurisdictional resources. Further, work zones are defined as a specific class of traffic
incident. Needs associated with the management of this class of traffic incident are also specifically
addressed. This standard also covers connecting to roadside devices and the related message set work
of Traffic Management Data Dictionary (TMDD) and Advanced Traveler Information Systems (ATIS)
messages.
IEEE Std 1512.2 -2004, Public Safety Incident Management Message Sets for Use by Emergency
Management Centers
IEEE Std 1512.2-2004 covers the exchange of information necessary to support traffic incident
response across all public safety agencies including law enforcement, emergency medical services
(EMS), and fire and rescue. An extensive review of public safety requirements by representatives from
this community maximized the use of messages that already exist in public safety standards.
This standard defines the message sets for public safety agencies to coordinate with other response
centers through efficient sharing of data and information. Local traffic control functions are specified in
the standard. Additionally, a mechanism to address local implementation issues exists in the standard.
Special care was taken not to impose or assume a specific incident command structure in the Standards.
IEEE Std 1512.3 -2002, Hazardous Material (HAZMAT) Incident Management Message Sets for
Use by Emergency Management Centers
This document describes a system of information exchange between agencies involved in situations
where hazardous materials have been released on or near a roadway in such a manner that a need for
traffic incident response exists. This standard provides the framework for communication between the
incident site and off-site databases and a method to coordinate multi-jurisdictional response. Messages
that request aid and resources from associated centers are also contained in this volume. The message
sets detailed in the HAZMAT Standard provide the responding agency with specific information about
the particular cargo and content based on available information. The message sets have also been
designed to accommodate information from response personnel who do not necessarily have specific
exposure to HAZMAT training.
IEEE Std 1512a -2002, Emergency Management Data Dictionary (EMDD)
The IEEE 1512a-2002 Emergency Management Data Dictionary (EMDD) Standard is the
development of a comprehensive set of data elements, data frames and messages specific to the 1512
Family of Standards. This standard is contained within each of the individual standards and is also
published within the ITS Data Dictionary. The data dictionary is a record of data elements and their
definition, date of revision, and any other relevant information. Creating this dictionary is a requirement
of the USDOT/Federal Highway Administration/ITS National Architecture.
3
Application of the IEEE 1512 Family of Standards
The IEEE Standards 1512.1-2003, 1512.2-2004, and 1512.3-2002 are companion volumes to IEEE
Std 1512-2000, or the Base Standard. The message sets in each of the companion volumes work in
conjunction with the message sets in the Base Standard; therefore, at least two standards must be used
together for useful results. In addition, each standard contains versatility to adapt the recommended
message sets to conform to local implementation needs. Volumes covering other topics will be
developed in the future and coordinated with these existing volumes.
Whenever possible, the 1512 Standards utilize data elements that were previously created and/or
defined in other standards. New data elements were created only when necessary. The exchange of
information supported by the IEEE 1512 Family of Standards specifically facilitates communications
between transportation management centers and the various types of public safety centers including 911
public safety access points and emergency operation centers. As a result of extensive coordination with
and use of the existing message elements contained in existing transportation and public safety
standards, the IEEE 1512 Family of Standards establishes a common interface between systems to
allow for an easier exchange of information.
The standards are not designed to drastically change systems that are operational, and they are not
designed to replace radio communication. Rather, they are designed to define an interface that can be
retrofitted to existing systems and/or incorporated into new systems.
Development and Maintenance of the Standards
The Federal Highway Administration (FHWA) through the Joint Program Office (JPO) recognized a
need for a standardized form of communication between transportation and public safety agencies to
improve traffic incident management. Because of their experience writing standards, FHWA selected
IEEE to prepare the IEEE 1512 Family of Standards. The Incident Management Working Group
(IMWG), a group of transportation professionals, public safety professionals, and hazardous materials
experts, was formed by IEEE to use their expertise to create the standards as a collaborative effort. The
content of the standards is based on a sound system engineering process built on a foundation of
consensus-based requirements elicitation.
The IEEE has more than 375,000 members in approximately 150 countries. IEEE is one of the most
recognized Standards Development Organizations (SDO) in the world. Through its members, the
organization is a leading authority on areas ranging from aerospace, computers and telecommunications
to biomedicine, electric power and consumer electronics. The IEEE produces nearly 30 percent of the
world's literature in the electrical and electronics engineering, computing and control technology fields.
This nonprofit organization also sponsors or cosponsors more than 300 technical conferences each
year.
The IEEE Standards Association (IEEE-SA), a globally recognized standards-setting body, develops
consensus standards through an open process that brings diverse parts of an industry together. These
standards set specifications and procedures to ensure that products and services are fit for their purpose
4
and perform as intended. The IEEE-SA has a portfolio of more than 870 completed standards and
more than 400 standards in development. Over 15,000 IEEE members worldwide belong to IEEE-SA
and voluntarily participate in standards activities.
Developing and maintaining standards for implementation in real world situations requires timely and
appropriate revisions and updates. There is some difficulty faced by volunteers for a long-term
commitment by their employers to support development and maintenance of the standards. Even so,
established IEEE processes will ensure long term maintenance of these Standards. Future work on the
standards is in initial phases. IEEE has shown an ongoing commitment to keep the standards current and
relevant to the entities that utilize them.
Case Study Implementation
There are several examples of projects that have implemented the IEEE 1512 Family of Standards to
improve communication between public safety and transportation agencies. These case studies illustrate
how various agencies implemented equipment, software, or policies to enhance interaction between the
participating 1512 Standard users. These case studies are provided as a resource to the reader in the
Appendix of this document.
5
Chapter 1 – Introduction
Purpose of this Guide
The purpose of this Guide for the Institute of Electrical and Electronics Engineers, Inc.
(IEEE) 1512 Family of Standards is to provide the reader with an understanding of how implementation
of these standards can facilitate a coordinated multi-jurisdictional response to traffic incidents, and to
provide the reader with some background issues associated with their development. This document
identifies the benefits of implementing the standards and acts as a bridge between the actual standards
documents and the users.
A general approach to using the standards within a new or existing system is detailed in this Guide. This
includes a basic description of the multi-agency involvement in traffic incident management with regard
to each standard. The audience for this document includes the decision makers and public agency
managers who would utilize and implement the IEEE 1512 Family of Standards for their public safety
center or transportation center.
This Guide also includes a summary of each of the standards and the topics covered under each
standard. The summaries include identification of the focus group associated with each volume, as well
as why and how they were intended for use during implementation. Local implementation issues are also
identified and discussed.
The goal of the 1512 Family of Standards is to support efficient communication between centers for the
real time, interagency management of transportation-related events. A center, or agency, is defined as
any point of communication used in the control of resources. The types of agencies that are considered
centers include but are not limited to police departments, fire departments, emergency medical services
(EMS), towing companies, traffic and/or transportation organizations, and Departments of
Transportation (DOT). A center can be a laptop computer in the case of a remote or mobile Traffic
Management Center (TMC) or public safety dispatch system, an in-vehicle device, or a wireless laptop
controlling roadside equipment.
Centers can communicate with one another, and each center is capable of sharing different types of
information in different ways. The use of common message sets as a format or structure for
communication between agencies that are involved in traffic incident management provides a means of
overcoming obstacles that relate to infrastructure ownership, response duties, political boundaries, and
jurisdictional responsibility. The 1512 standards establish the specification criteria for a standardized
format of communication.
A traffic incident includes any transportation-related event that has information concerning the event
relayed to an emergency management system, including planned roadway closures and special events,
whether or not the incident actually affects traffic flow, and whether or not a response is required.
This Guide describes a set of standards that, when implemented, will provide a unified operational
approach to activities that involve multiple agencies. Operational integration between public safety and
6
transportation agencies is critical to effective, efficient response. Interoperable voice, data, and video
systems (technological integration) as they support operational integration must also be standardized to
ensure product compatibility which will lead to interconnectivity and interoperability between agencies.
The goal is for one dispatch system to disseminate information to all the entities that need it in a
consistent format, and each entity would receive the same information in real time and could respond in
the most efficient way possible.
History of the Standards
The United States Department of Transportation (USDOT) and the Federal Highway Administration
(FHWA) through the Joint Program Office (JPO) recognized a need for a standardized form of
communication between transportation and public safety agencies to improve traffic incident
management. Public safety agencies have been limited by these communication issues for decades;
however, the transportation agencies are a relatively new component in this organization. A system that
uniformly shares information using legacy systems and can be customized for local applications is
necessary to improve data flow between agencies.
The National Intelligent Transportation Systems (ITS) Architecture was established by the FHWA in
the mid 90’s and recently updated to provide a common framework for planning, defining, and
integrating intelligent transportation systems. This framework defines how agencies involved in incident
management transmit information back and forth, or illustrates data flows through various agencies. This
framework shows that the transportation agencies have ineffective or minimal data flows to the public
safety agencies.
By following data flows within the National ITS Architecture, the IEEE 1512 Standards were
developed for outreach and improvement of communications to public safety agencies. The FHWA
selected IEEE to establish the IEEE 1512 Family of Standards in order to create a standard set of
messages that facilitate the transfer of information between transportation and public safety agencies.
The Incident Management Working Group (IMWG), a group of transportation professionals, public
safety personnel, and hazardous materials experts, was formed to use their expertise to create the
standards as a collaborative effort. The process for the development of the standards included following
the requirements of 23 Code of Federal Regulations (CFR) Parts 655 and 940.
Scope of this Guide
This Guide describes the IEEE 1512 Family of Standards and how they can improve the distribution of
traffic incident management information by using common message sets as a structure for communicating
between various centers. This includes an explanation of what each standard is and the structure of the
message sets used in each standard.
This Guide will identify the purpose for each standard and summarize the contents of the standards. A
description of the basic structure of the message sets and the flexibility that is built into the standards to
address local implementation issues is also included.
7
The 1512 Standards complement the existing traffic incident management response systems and
practices in of the United States and beyond. Using the standards with other related documents and
practices, as well as using a combination of two or more of the standards, is covered in this Guide.
Direction on how to adapt the standards for localized use is also discussed.
This Guide Document does not describe how to implement the 1512 Standards, and it should not be
used as a substitute for the standards. Since implementation will vary widely based on need and level of
application, each implementation will be different. An implementation guide for these standards would
provide an overview of the relationships between the messages and specific examples of use. It is
necessary for local implementers to prepare an implementation guide for the standards. Preparing an
implementation guide is also part of the systems engineering documentation and process. Implementation
of the standards will be the responsibility of the user.
Development of the implementation guide at a local or regional level is critical because of existing local
incident management issues, communication systems, and institutional relationships between agencies.
The existing communication systems for each agency and the regional architecture also need to be
examined to determine the best possible implementation. The preparation of an implementation guide is
the responsibility of the agency that is having the standards implemented. In addition, implementing the
standards is the job of the software company hired by the agency doing the implementing. IEEE is not
responsible for the application and/or implementation of the standards.
All of the 1512 standards will continue to evolve after publication. The standards will continue to be
revised to address issues that arise during use. Additional standards may be added in the future to
include new areas of application. Thus, users of the Standards need to be aware of possible changes
that may have occurred since the publication of the version of the standards they are using.
8
Chapter 2 – Potential Issues Related to Information Sharing
A presentation at the National Traffic Incident Management Conference (NTIMC) covered the
technical and institutional issues related to integrating public safety and transportation information.
Several issues related to the implementation of multi-jurisdictional information sharing while responding
to traffic incidents were discussed. This type of information sharing is the focus of the 1512 Standards.
One concern discussed at the NTIMC conference was the issue of maintaining certain elements of
information in a secure database. Another issue addressed privacy and legacy issues relating to
retrofitting the existing systems that are currently being used to provide services. Legacy systems within
multiple agencies typically result in incompatibility between these systems. Incompatibility results from
fundamental differences in the hardware, software, and/or database structures that are presently being
utilized. Without a recognized, established platform that allows for managed sharing of information,
jurisdictional issues frequently derail efforts to enhance traffic incident management activities through
improved communication.
Another multi-jurisdictional issue that was identified relates to whether or not benefits will result from
improved information sharing between agencies. These benefits are not necessarily clear due to the
absence of known champions of this approach. Further, identification of these benefits and the funding
mechanisms and/or resources needed to implement these types of changes to standard operating
procedures are typically outside of traditional responsibilities.
Several suggestions were made for future integration efforts.
• A clear concept of operations should be defined prior to implementation.
• Establish a regional architecture and/or approach to information sharing and development

of the communication systems based on this architecture before a system is installed.
• Develop processes that utilize recognized systems engineering principles.
• Follow up with requirements-based engineering as a mechanism to develop consensus. (See 23

CFR Parts 655 and 940.)
Local champions of this approach are needed to ensure complete and successful implementation.
Keeping all the agencies and their directors involved in the process of implementation and apprised of
the progress provides a smoother transition. Maintaining an adequate outreach to the agencies at all
levels, not just at the administrator level, is an excellent way to obtain feedback on the practicality and
usefulness of each aspect of the proposed system.
Communication systems should be designed to a set of standards, and agencies should participate in the
development and modification of the standards to guarantee relevance to real world situations. Actively
monitoring technological advances to minimize changes is necessary to assure adaptability of systems
and standards to rapidly developing technology.
9
In any computer system, there is a network architecture and various deployed choices regarding
systems protocols. The Open Systems Interconnect (OSI) defines these system protocols. It is used as
a framework for standards to maintain consistency in computer network architecture.
The OSI reference model is the ISO (International Standards Organization) structure for the “ideal”
network architecture. This Model outlines seven areas, or layers, for the network.
These layers of the OSI model which make up the “Stack” are: 1-Physical interconnection,
2-Transmission of Frames or Data Link, 3-Routing of Packets or Network, 4-Controls end-to-end
connection or Transport, 5-Adressing Conversion or Session, 6-Interprets character streams or
Presentation, and 7-Application. Figure 1 depicts the layers in the OSI Stack.
There are several advantages of the OSI Model. If a network conforms broadly to agreed standards,
users are insulated against some of the adverse effects of technological change – equipment does not
become obsolete quickly. It promotes modularization of network support software. Each module takes
the form of a layer in the model and is responsible for providing selected services to the layer above. In
theory, any layer can be replaced by a new layer that provides the same services but in a different way,
without affecting the user's view of the framework.
Despite these advantages, certain disadvantages to the system exist. Due to the complexity of the
system, poor performance can result, especially in some real time applications. Direct substitution of
layers is not always possible. Although protecting equipment from becoming obsolete, it simultaneously
hinders technological advancement.
The 1512 Family of Standards exists “above” the uppermost level (#7) of the Stack. The 1512 Family
of Standards deals primarily with defining the messages to be used in data exchange in communication
protocols. Communication protocols, which are critical to any communication system, are at a lower
OSI layer and have to be addressed separately. This issue sometimes creates challenges with
Departments of Transportation (DOTs) implementing Intelligent Transportation Systems (ITS)
Standards because it requires detailed systems integration. To address the challenge, various different
standards and protocols must be combined to address each layer of the OSI stack including security,
physical media, etc.
• Layer 1 – Physical interconnection

• Layer 2 – Transmission of frames
• Layer 3 – Routing of packets
• Layer 4 – Controls end-to-end connection
• Layer 5 – Addressing conversion
• Layer 6 – Interprets character streams
• Layer 7 – Application
Figure 1 – OSI Layers
10
Chapter 3 – Overview of the IEEE 1512 Family of Standards
The Content of the Standards
The IEEE 1512 Family of Standards consists of a Base Standard and a set of companion volumes. The
purpose of these volumes is to more fully establish the message sets used by various user groups within
the realm of transportation management, public safety, and hazardous materials. The standards include
the following:
• IEEE Std 1512-2000, Common Incident Management Message Sets for Use by
Emergency Management Centers, or The Base Standard
• IEEE Std 1512.1-2003, Traffic Incident Management Message Sets for Use by
Emergency Management Centers
• IEEE Std 1512.2-2004, Public Safety Incident Management Message Sets for Use by
Emergency Management Centers
• IEEE Std 1512.3-2002, Hazardous Material Incident Management Message Sets for
Use by Emergency Management Centers
• IEEE Std 1512a-2002, Emergency Management Data Dictionary (available electronically

only)
Further volumes covering other topics are being developed and coordinated with the existing volumes.
These standards define the message sets that can be used in a format of data exchange to share real-
time information between transportation-related traffic incident management agencies included in traffic
incident management communications networks. Each agency will transmit and share information
through a standardized format common to other agencies. These message sets are listed and defined in
the Family of Standards, and they are consistent with the National ITS Architecture.
The message sets defined in the IEEE 1512 Family of Standards will be conveyed and shared across
systems that all agencies can access as deemed appropriate in the local application. The data from an
incident will be entered into the system using a structure of common sets of messages that describe any
incident. Some interface or adjustment to allow legacy systems to work together will translate the
message sets to a common language that each existing system can interpret. With minor adjustments to
the legacy systems, the message sets convey the incident information consistently and in real time.
There are multiple ways the standards can be applied to systems. In some instances, the standard can
be implemented across multiple systems operated by different centers. A common system used by
multiple agencies may be designed to share information. Existing systems can be modified to use the
message sets, or new systems can be installed that were designed for the message sets. The purpose of
the common system and messages is to minimize the technical barriers associated with data exchange
11
among emergency management and related centers as well as translation discrepancies between similar
data fields in the different systems.
A system of common message sets will aid in the sharing of information and allow each agency to work
with other responding agencies in a more efficient manner. Information directly from the scene of the
incident, from transportation management centers, and from emergency response centers will be
combined and confirmed for relevant agencies to respond to and utilize. Sharing incident information will
prevent confusion, help eliminate false information, and combine information from all sources into one
common format for everyone to use so that all incidents can be handled in the safest, most efficient and
quickest possible way.
The Need for the Standards
With the increase of vehicular travel throughout the United States, ITS is essential to enhance safety,
protect the environment and relieve traffic congestion. To guarantee the smooth operation of ITS,
standardization of a common method for ITS components to communicate with one another is key.
Standardization of ITS promotes and ensures interoperability and interchangeability.
The procedure under which a community of centers communicates varies widely. Different computer-
aided centers must agree to use the same mechanism to exchange messages between each other if they
want their communication systems to be compatible. Use of one common method is likely to gain wide
acceptance among responding agencies. However, there are a wide variety of legacy public safety
center computer-aided dispatch (CAD) systems currently in place. Therefore, the IEEE 1512 Family of
Standards is written to encompass the widest possible accommodation of legacy systems. These legacy
systems include message brokers, CAD vendors, database systems, wireless vendors, etc.
A common problem in managing traffic incidents across the country is the communication gap between
various responding agencies. A lack of efficient communication exists because these agencies have
different jurisdictions, communication systems, and procedures for response. Typically, each agency has
its own dispatch or communication center that works well on its own; however, it does not have a direct
connection to other agencies and their communication systems in the area.
A lack of compatibility between systems is also an issue. When more than one responding agency is
involved in an incident, there is difficulty in getting information from the scene to the appropriate
response agency and between agencies at the scene. The lack of compatibility across systems and/or
jurisdictions significantly limits the efficiency of transportation and public safety professionals in managing
these incidents.
The 1512 Standards address the difficulty of interaction between the various centers involved in incident
response in the resolution of roadway service disruptions and certain other events generally referred to
as incidents. Organizations looking to gain interoperability between transportation and public safety
centers can apply the standards in part or as a whole in order to improve communication. By
implementing the 1512 Standards, the transfer of information and ultimately the incident response will be
faster and more efficient, effectively minimizing the impact to traffic flows.
12
The Family of Standards is adaptable for specific situations for different types of agencies. Each agency
looking to implement the standards will determine what is needed from each standard for their particular
application. Only the messages and that are needed and necessary to a specific local system will be
incorporated into the structure of data exchange.
Adopting the standards will generate the need for products that can be used to update existing
communication systems. As a result of several organizations showing interest in adopting the standards,
software companies will, over time, develop off-the-shelf products which will continue to lower the cost
of implementation.
Utilizing the 1512 Standards improves interagency coordination among public safety and transportation
management agencies, allows for more rapid dispatching, and increases the effectiveness of coordination
of response vehicles and personnel. By reducing the traffic incident clearance time, congestion and
secondary collisions are reduced, the air quality is impacted less, and safety for travelers and emergency
personnel improves at incident scenes.
A key role for the IEEE 1512 message sets is to describe the incident to off-site response personnel.
Often information that is quite obvious to on-site personnel never gets communicated to off-site
personnel. Yet the information is important for off-site decision-making.
The IEEE 1512 Family of Standards facilitate the sharing of incident management messages among
different ITS systems and public safety entities. These standards are on a short list of standards
identified by the USDOT as “critical” for the ITS infrastructure.
Improvements in agency communication during an incident will be beneficial to the people involved in
the incident, the traffic affected by the incident, and the agencies responding to the incident. The 1512
Family provides the possibilities of having more efficient communication, reducing confusion, and
improving incident clearance time. A theoretical example of a typical traffic incident response with 1512
Standards implemented and without shows an approximate 20% improvement in response time for the
incident that had the 1512 Standards in place. The specific benefits of implementation are dependent on
local, geographic, and institutional relationships, but this example shows that the possibility for
improvement exists.
Levels of Implementation of the Standards
There are varying levels of implementation of the Family of Standards into an existing communication
system. An example of a low-level implementation would be to install a device to translate an existing
CAD screen into a format a TMC’s database and/or operator could use. This is called a “CAD
scraper.” Transportation and Emergency Services Communications Network (TESCNET) is an
example of a CAD scraper. The concept of the TESCNET program is to create a regional perspective
of the communication environment for public safety and transportation entities in Southeast Wisconsin
for regional, state, county and municipal authorities. This is an example of the most simplistic and lowest
level implementation. Integration between legacy systems is merely a translator of the 1512 message
sets. The exchange of data between the legacy communication systems may prove more difficult, but
that is outside the scope of the 1512 Standards.
13
Capital Wireless Integrated Network (CapWIN), the first multi-state, inter-jurisdictional transportation
and public safety integrated wireless network in the United States, is being facilitated through the Center
for Advanced Transportation Technology at the University of Maryland, College Park, Maryland.
Implementing the Base Standard using CapWIN would be a medium-level implementation. Numerous
systems are involved including highly secured landlines and wireless communications. Due to these
systems, this project also has a great challenge marrying numerous communications systems as well as
standards from the justice community, but it uses only a central server design.
High-level implementation of the 1512 Family of Standards would include creating a new
communication system for all of the participating agencies. This level of implementation would require
new equipment and software for every responding agency in a particular community. The New York
State DOT/Veridian Experience, also known as Integrated Incident Management Systems (IIMS), is
the most advanced level of 1512 deployment to date. That system is facing challenges in tying the new
IIMS system with internet-based communication protocols (XML) to a legacy Data Exchange
(DATEX) communication system in place with the Traffic Management System Transportation
Operations Coordinating Committee (TRANSCOM).
Each local agency that implements the standards must decide on the level of application of the
standards. This decision will be made based on the types of investment, existing resources and
infrastructure, institutional issues, systems currently being used, existing relationships, information
sharing, interoperability, flexibility in the current system, user requirements, and how much is needed in
that particular area. Each agency looking to implement the standards will determine what is needed from
each standard for their own application.
Systems Engineering Process Utilized for Standards Development
There are many interpretations of the systems engineering process utilized for standards development.
Most importantly, the development of standards by a systems engineering process, or “top-down”
methodology, requires that the agencies that participate in traffic incident response activities be involved
in the development of the standards.
The systems engineering process consists of three main categories: requirements, users and testing.
Those three categories can be expanded into four operations. They are the following:
1. Define requirements using as close to the actual application of the system, with as close to
the actual users of the system, as you can get. Do that as early as possible.
2. Use those requirements to define the system and to guide the development of the system.
3. Iterate those requirements as you learn more about what you can and can not do as you
develop the system.
4. Test the system against the requirements as early as possible; then re-test as often as is
useful.
14
This system was followed when preparing the IEEE 1512 Family of Standards. Initially, requirements
documents were written for each volume of the standards.
On December 9, 1997, a Project Authorization Request (PAR) form was approved to begin work on
the 1512 Base Standard document. At this time, the Concept of Operations was loosely defined. Given
the National ITS Architecture, the scope was set, the users were recognized, and the need for the
standards was identified. The scope was defined as the following: research, compile, analyze, and
consolidate information leading to the publication of a standards message set for incident management.
This scope initially was limited to address message sets from the Emergency Telephone System (ETS)
to the TMC and Emergency Management Center (EMC).
In 1999, the PARs were prepared for the companion volumes of the IEEE 1512 Family of Standards.
Each volume had a specific requirements listed to direct the progress of the system. All of these PARs
were developed before work began on any of the standards.
The requirements were tested and revised in Table Top Exercises (TTX). Then, the requirements
documents were turned into direct guidance as to what messages and data elements were required and
what should be specified in each companion volume.
Each of the TTXs consisted of several steps. The exercise script was reviewed in detail after assembling
and organizing the participants. After a thorough review, the exercise script was implemented. Upon
completion, a post-exercise briefing was conducted with the exercise participants, and an evaluation
team completed evaluation forms on the TTX. A recommendations report based on the outcome of the
exercise evaluation was written, and necessary modifications to the 1512 standards were determined
from the exercise action plan.
Each companion volume systematically progresses from the problem statement and goal material in the
front end of the document, to a statement of requirements, then to a specification of messages and data
elements, then to an illustration of the use of the messages and data elements. Example uses of the
messages are presented based on the established user requirements. A partial test of the messages
against the requirements was performed at each of the table top exercises.
The IEEE 1512 Family of Standards was developed by following a “top-down,” or systems
engineering, methodology as described above. A working group came together to develop the
standards. The working group consists of professionals who work in public safety and other incident
management related occupations. The systems engineering process on IEEE Standard 1512 started
before the working group met.
Once the consultant contracts were first let, a meeting was held to review exactly where traffic incident
management was in the National ITS Architecture (data flows, etc.), what the interfaces and terminators
were, and what extensions to the architecture would be needed. The first draft of the architecture was
presented at the traffic incident management working group kick-off meeting. Since the kick-off
meeting, the traffic incident management portion of the National ITS Architecture has continued to
expand.
15
The spiral model – build a little, test/deploy, learn, and iterate – has also been used. The table top
exercises are the best example of this methodology. Not only do these exercises validate what is being
done, they help identify the shortcomings and differences in even the best designs.
All of the key components - Concept of Operations, Functional Requirements, Dialogs, Message Sets,
and Data Elements, are a case study in “top-down” design. One of the biggest benefits to a “top-down”
design is the ease of determining test requirements. A draft of the “core functions” for a number of the
standards was developed.
The most important part of systems engineering is the process of driving out the requirements. The user
typically has problems stating their needs in a requirement format. Current technology is desirable even
though it may not provide the functionality format that is needed. In every IEEE working group, the
requirements of the standards were the first topic discussed. Then there was an effort to define a
simplified concept of operations. Usually these top level requirements and the operations concept lead
to more and finer detailed requirements. A function was then assigned to a particular message.
Throughout the development of the 1512 Standards, the working group met every four to six months. A
list of working group members can be found in Appendix G under “Committee List.”
Established standards were used wherever possible to develop the format and content of the new 1512
Standards. ITS Standard Message Templates were utilized in the development of the 1512 message
sets. The process used to write the standards was modeled after IEEE 1488 and 1489, which are the
existing standards on how to write and develop standards.
Every standard went through several drafts, and then a balloting process followed. IEEE as well as the
Incident Management Working Group invited experts in the appropriate fields to review each standard.
This is called the “Peer Review.” According to IEEE 1488 and 1489, the requirements on how to write
standards, the Peer Review process is required to put the standard under review to a national ballot.
Once the standards pass the ballot, they are approved for distribution and/or sale. In addition, the 1512
balloted standards will continue to be updated and evaluated as directed by the FHWA and IEEE.
Table Top Exercises
The TTXs were done as part of the Systems Engineering Process to test the message sets in the draft
versions of the 1512 Standards. Some of the TTXs were performed at the IMWG meetings. The
IMWG is made up of professionals from the public sector, the private sector, software vendors, public
safety officials, HAZMAT officials, and traffic engineering professionals. The makeup of this group
represented the variety of agencies that would use the standards to test the message sets for their
usefulness and practicality. The Electronic Table Top Exercises (ETTX) were conducted by email to
test message sets.
The following table is a list of the dates, locations and types of tests done at the TTXs that were held
during preparation of the standards.
16
Table 1 – Incident Management Working Group
Table Top Exercises for the 1512 Standards
IMWG Table Top Exercises

Date Location Methodology
March 2000 Phoenix Passed notes to test message sets.
July 17, 2000 ETTX1 Messages were shared electronically
to test message sets. Role players
from multiple centers and disciplines
often with spontaneous phone
exchanges (which do occur in real
situations) participated.
August 2000 ETTX2 Electronic messages were shared to
test message sets. Same as above, but
more scripted.
October 2-4, 2000 DC/Maryland Paper exchange of messages between
multiple mock centers with a “ground
truth” changing scenarios to test
message sets.
December 11-13, Houston TranStar Used TranStar system, two-way
2000 radios, and whiteboards to test
message sets and simulate actual
environment of centers with poor
radio communications and information
from field.
April 17-19, 2001 San Diego Separate, small table top exercises to
address individual standards using
white board as scenario developed.
June 7-8, 2001 Miami Completed an electronic test of
message sets using Microsoft Access
The first Electronic Table Top Exercise (ETTX1) utilized blank forms/templates for sending messages.
Each of the participants was assigned a role and the possible operations for each role. For example, one
person acted as the law enforcement agency, and assigned operations included performing traffic
control and collecting evidence. These participants represented the incident management users in the
field and at various remote dispatch locations.
Each participant received emails at their individual work stations from the coordinator. They determined
the appropriate response for the particular situation, and using their template, responded with the
messages that were available to them. Participants emailed their responses to the entire group for
review. The goal was to see if the 1512 messages could carry the information necessary. This exercise
proceeded slowly; however, a great deal was learned about the messages’ capabilities to transfer the
necessary information. After the evaluations of the TTXs and the ETTXs, the 1512 Standards were
revised to correct the problems in the test situation.
17
The ETTX2 was fully scripted. Each participant had a complete script about what needed to be said to
whom, though improvisation was allowed if necessary. The emailed responses were not in real time. The
ETTX coordinator set up an incident, then each person was given a half day to respond. Two rounds of
communication were completed per day. This was done to account for the participants implementing the
script in different time zones. Roles were assigned to each of the participants, and the participants were
given a role they were familiar with when possible.
The complete scripting meant that this ETTX was not designed to help determine what messaging is
required, but to determine if the 1512 standards supported the messaging. The TTXs that were
completed at the IMWG meetings produced similar results and provided useful input that was
incorporated into the message sets of the 1512 Standards.
Relationships of 1512 Standards with Other Documents and Activities
Relationships to Other Standards Development Organizations
The IEEE 1512 Family of Standards was created out of a need for an efficient and effective method of
communication between multiple organizations and agencies, regardless of jurisdiction or
communications/operations system constraints. The IEEE 1512 Family of Standards was developed
with other ITS Standards in mind. IEEE 1488 and 1489 were used to develop the 1512 Standards with
proper process and protocol.
A systems engineering process was utilized to create the standards. The messages, or data elements,
defined in the standards were identified through the systems engineering process. The people involved in
the systems engineering process included transportation and public safety professionals, as well as
various private companies involved in integrating systems that are utilized by these professionals. The
involvement of these people in the development of the 1512 Standards ensured that members of the
organizations that will utilize the standards provided input during the creation of the standards. This also
minimized the creation of new messages, or data elements. Another goal was to create flexibility within
the message sets to accommodate specific information that is necessary to meet local implementation
needs.
Many of the data elements in the standards reference and utilize data elements that make up various
National Transportation Communications for ITS Protocol (NTCIP) standards. The NTCIP is a Family
of Standards that provides both the rules for communicating and the vocabulary necessary to allow
electronic traffic control equipment from different manufacturers to operate with each other as a system.
NTCIP was developed by several Standard Development Organizations (SDO) including Institute of
Transportation Engineers (ITE), American Association of State Highway and Transportation Officials
(AASHTO) and National Electrical Manufacturers Association (NEMA), and it includes TCIP (transit).
The NTCIP is the first set of standards for the transportation industry that allows traffic control systems
to be built using a “mix and match” approach with equipment from different manufacturers. Therefore,
NTCIP standards reduce the need for reliance on specific equipment vendors and customized one-of-
a-kind (proprietary) software. The 1512 Standards are related to standard transportation protocols
based on the work of the NTCIP.
18
The Transit Communications Interface Profiles (TCIP) serves as the transit component of the NTCIP.
To a large extent, incident management data requirements within transit are the same as those for other
transportation centers. The TCIP Project relied heavily on the work of other standards regarding
incident management data such as the ITE/ITS Traffic Management Data Dictionary. The TCIP
document highlights those data that are specific to transit incident management. The TCIP suite of data
object standards is central to transit’s data communications.
Another SDO, the Society of Automotive Engineers (SAE), has a set of standards addressing traveler
information called the Advanced Traveler Information Systems (ATIS). ATIS has defined a set of
messages and dialogs to convey data to travelers, Information Service Providers (ISPs), the news
media, and other users. The purpose of ATIS is to establish a set of medium-independent messages and
data elements needed by potential ISPs to deploy ATIS services, and provide the basis for future
interoperability of ATIS devices. This dictionary of messages was also utilized in the development of the
data elements to create consistency and compatibility with SAE’s work.
In addition to transportation-related standards and protocols, standards and protocols that are used by
public safety agencies were also examined. The public safety SDOs and other public safety standards
were incorporated into the 1512 Standards to optimize consistency with their current practices. Some
public safety SDOs include: the Association of Public-Safety Communications Officials (APCO), the
National Emergency Number Association (NENA), the National Fire Incident Reporting System
(NFRIS), and the National Fire Protection Association (NFPA). The standards of the public safety
organizations are closely linked to the 1512 Standards.
The USDOT has developed a National ITS Program Plan for ITS which provides a new vision for
surface transportation in America. The ITS Program includes seven major elements, one of which is
Commercial Vehicle Operations (ITS/CVO). The ITS/CVO element includes the ITS technologies
which uniquely support Commercial Vehicle Operations (CVO). The scope of CVO includes the
operations associated with moving goods and passengers via commercial vehicles over the North
American highway system and the activities necessary to regulate these operations. It includes activities
related to safety assurance, commercial vehicle credentials and tax administration, roadside operations,
freight & fleet management, and vehicle operation.
The term Commercial Vehicle Information Systems and Networks (CVISN) refers to the ITS
information system elements that support CVO. CVISN includes information systems owned and
operated by governments, carriers, and other stakeholders. It excludes the sensor and control elements
of ITS/CVO. The 1512 Standards include specific CVO operations regarding the potential severity of
incidents as well as potential hazardous material spills.
The Archived Data User Service (ADUS) describes the need for an ITS Historical Data Archive and
expands the National ITS Architecture to encompass the needs of the stakeholder groups of this user
service. ADUS was developed by the SDO American Society for Testing and Materials (ASTM).
ADUS requires ITS-related systems to have the capability to receive, collect, and archive ITS-
generated operational data for historical or secondary uses. The goal is an unambiguous interchange and
reuse of data and information throughout all functional areas. There is a broad spectrum of users who
19
must rely on any and all available sources of data to feed the applicable planning models, simulations,
and control strategies.
During the development of the standards, the creators had to remain cognizant of evolving ADUS and
the data warehousing potential by standardizing data and messages of transportation stakeholders’
needs once the standards were implemented. The 1512 Standards focus on real-time information;
however, storing that information was also addressed so ADUS could benefit from the implementation
of the standards as well.
The relationship of the agencies described in this section is illustrated in Figure 2 below.
Public Safety (Justice, Homeland

Security, Dispatch, Etc.)
Commercial
Traveler Info Vehicles Security
(In-Vehicle, Info (CVISN)
Providers, Archive
Media, Etc.) Data
IM (IEEE)
ATIS (SAE)
ADUS (ASTM)
Transportation Infrastructure (Devices such as DMS,

Signals, Sensors, and Transportation Communication
Protocols) (NTCIP)
Figure 2 – 1512 Organizational Relationships
The Traffic Management Data Dictionary (TMDD) provides consistent names, definitions, and concepts
similar to spelling and parts of speech to the word-like “data elements” in the Standard. It enables
concepts from traffic management to be defined and used in the same way by different systems and
centers. However, it also anticipates and provides for the use of locally unique data elements to
recognize the individuality of each system or center. The Message Sets for External Traffic Management
Center Communications (MS/ETMCC) uses these data elements by combining them together in
sentence-like way in the sharing of data or pre-defined typical messages between systems or centers. It
also anticipates that every center will have its own unique messages to send and receive.
Together, these two standards provide a framework for interoperability that is consistent with the
National ITS Architecture and work in conjunction with other standards, such as the Standard for Data
Dictionaries. There is a need to have a clear plan for migrating from current systems to those that are
being planned, designed, and implemented to be in conformance with these two standards.
The 1512 Standards utilize data elements that were previously created and/or defined in other national
systems standards. New data elements were not created unless deemed necessary. The typical standard
20
contains over 100 such entries; by contrast, the entire Base Standard has 12. There are twelve new
data elements in the Base Standard, however, there are significantly fewer in each of the companion
volumes. New data elements in the companion volumes were created only to bridge the gap between
information that is currently collected and what is needed in existing standards but not otherwise
supported.
Relationships with Companion Volumes
The Base Standard sets requirements for all responding agencies. The companion volumes extend the
message functionality with additional content and operating requirements as needed. This does not
eliminate the need for local agreements and further profiling of the resulting message sets; rather, it
provides implementation insights and requirements that any center of a specific type must follow to
remain operable with other centers.
The relationship of the existing and future companion volumes to the Base Standard in the IEEE 1512
Family of Standards is illustrated in Figure 3.
In-Vehicle Systems 1512.4**

Implementation Guide*
Public Safety 1512.2
HAZMAT 1512.3
Future Volumes
Traffic 1512.1
Incident Management Base Standard 1512
Figure 3 – Relationships with Companion Volumes

(* = Local Area Development, ** = Future)
This base standard contains some messaging for managing centers on and off line and for coordination
of incident creation, management, and numbering. These features can be used in a local implementation
to define a lead agency for any incident, according to practices agreed upon in that local implementation.
These message sets are not further profiled in the companion volumes since all centers use them in a
similar way.
21
The ITS traffic management community is in the process of developing a wide set of encompassing
message sets related to this standard. A TMC (unlike many other types of centers) often shares data
with other centers, which stimulated the development of a rich set of pre-existing messages. Incident
Description (IDX) (the principal information exchanging message) was designed to reuse many of these
messages as shown in the first companion volume, IEEE Std 1512.1-2003, Traffic Management
Standard.
Public safety centers, such as where 911 public safety access points and fire dispatch are located, are
typically supported by CAD and records management systems (RMS), which tightly integrate these
centers with other internal nodes (stations, apparatus, support and administrative locations). Integration
between different systems is less common and much more difficult to achieve. While there are
established and standardized information exchange practices addressing external systems, most are
concerned with after-the-fact reporting of various types of incident information to higher echelons or
record-keeping systems. This standard differentiates between criminal justice management systems and
real-time asset management systems, such as CAD. Criminal justice systems are more concerned with
the flow of crime incidents through the court and corrections systems than with getting assets to an
incident scene.
The scope of these systems greatly exceeds that of the TMC, as public safety addresses not only with
the highway and traffic, but also responds to all types of emergency situations including crimes, fires, and
medical needs. Some of this subject matter is reusable in ITS. As a result of these factors, the IDX
information to be found in the public safety volume may be both larger and more diverse than the TMC
volume, and suitable for inclusion in IEEE Std 1512.2-2004, Public Safety Standard. The justice
community is also looking at harmonization of data between these types of systems.
Because a HAZMAT situation has specific personnel, equipment, response plans, and serious
implications, IEEE Std 1512.3-2002, HAZMAT Standard was created with messages specifically for a
HAZMAT center. HAZMAT centers operate within a more restricted scope than traffic or public safety
centers, are a division of the fire department, and sometimes participate from a remote location in a
consultative mode. Voice coordination procedures are well understood and commonly practiced;
however, automated HAZMAT information exchange would be new to the community.
The Implementation Guide will incorporate all the messages from the standards into the User’s specific
communication systems. Since the Implementation Guide will be created by the User, certain data
elements that are designed to be modified for local conditions will be defined for that User.
A future volume for In-Vehicle Systems will be created to relay information to appropriate local centers.
The message sets would be created to correspond with all general messages defined in the IEEE Family
of Standards, so that local vehicles involved in incident management activities can communicate with
other local centers.
Relationships to the ITS National Architecture
The National ITS Architecture provides a common structure for the design of intelligent transportation
systems. It is not a system design nor is it a design concept. It is the framework around which multiple
22
design approaches can be developed and refined, each one specifically tailored to meet the individual
needs of the user, while maintaining the benefits of a common architecture noted above. The architecture
defines the functions that must be performed to implement a given user service, the physical entities or
subsystems where these functions reside, the interfaces/information flows between the physical
subsystems, and the communication requirements for the information flows. In addition, it identifies and
specifies the requirements for the standards needed to support national and regional interoperability, as
well as product standards needed to support economy of scale considerations in deployment.
One of the fundamental guiding philosophies in the development of the National ITS Architecture has
been to leverage the existing and emerging transportation and communication infrastructures in its
design. This minimizes the risk and cost of deployment, and maximizes marketplace acceptance,
penetration, and early deployment.
The National ITS Architecture provided a framework from which the ITS standards activities were
partitioned and then mapped back to the Architecture as the ITS standards were defined. The
standards were developed based on the architecture interfaces and data flows packaged in the
Standards Requirements Packages that were considered by the IMWG. For each of the standard’s
packages, a detailed list of architecture data flows is provided so that SDOs can readily apply the
architecture to each interface under consideration.
Standards development is of interest to nearly all organizations involved with the deployment of ITS. It
is anticipated that product developers, communication providers, and private service providers will play
an equal role in standards activities with local, regional, state, and federal public infrastructure agencies.
It may be to their advantage to become involved with international activities as well, since significant
efforts are underway outside the United States. In particular, the adoption of common standards with
Canada and Mexico would be beneficial to all three countries.
The basic continuing benefit of the architecture is to provide a structure that supports the development
of open standards. The benefits derived from the architecture are defined as follows:
• Integration: The architecture makes integration of complex systems easier. This is achieved by
presenting the structure around which standards can be developed. Because of improved
integration, ITS services will benefit from better availability and sharing of traveler information,
such as congestion information, and better utilization of shared resources, such as roadside
surveillance data.
• Compatibility: The same mobile equipment will work over the entire country. Because equipment
becomes compatible everywhere, there is a larger total market for services, resulting in more
capable and cost effective products. Similarly, infrastructure systems can use standards to
improve product quality and lower product costs. Future growth is enhanced by open standards
being available, allowing everyone a chance to participate.
• Support for Multiple Ranges of Functionality: Because the architecture does not dictate a design,
standards can be developed to support a wide range of designs or levels of functionality in
deployment, providing services ranging from free to pay-for-use.
23
• Synergy: An overused concept, but in this case, well suited due to the careful methodology used
in development of the architecture. The methodology began with the architecture functional
requirements and then mapped common requirements into specific applications. This allows
developers to support a range of applications with similar functions and thereby serve larger
potential markets with their products.
Figure 4 illustrates how the information flows between public safety, emergency and transportation
management centers. The FHWA (USDOT) ITS Architecture includes public safety as part of the
“emergency management” category. As a “center” within the architecture’s perspective, this figure
shows how public safety and emergency management centers are connected to other parts of the
architecture. All areas of the IEEE 1512 Standards fit in the architecture. There are “X’s” in areas
where 1512 does not impact the relationship.
Figure 4 – 1512 and the ITS Architecture
Relationship to Public Safety Interoperability
A National Task Force on Interoperability (NTFI) is currently working to address the need to improve
communication between public safety agencies. The need to communicate life-saving information quickly
between different public safety agencies and jurisdictions has come to the forefront since the events of
September 11, 2001, Oklahoma City, and Columbine; however, the need is equally important during
natural disasters like forest fires or hurricanes and during day-to-day operational events like high-speed
pursuits across jurisdictional boundaries. Yet, surprisingly often, law enforcement agencies from
24
neighboring city, county, and State jurisdictions cannot communicate with each other or with fire and
rescue and emergency medical services.
Working to educate and inform local and state elected and appointed officials nationwide on this public
safety communication problem, the NTFI held its second meeting in Washington, D.C., attended by
more than 50 state and local representatives, key association staff, and representatives from the public
safety community. Interoperability is the ability of multiple agencies or jurisdictions to communicate—to
exchange information seamlessly, when and where it is needed.
The reasons for communication problems are numerous—incompatible systems, limited funding to
update equipment, different policies from jurisdiction to jurisdiction, and limited availability of radio
spectrum. The purpose of the task force is to find ways to achieve real-time communication between
different communities, jurisdictions, and responders so that more lives can be saved in a crisis, property
can be protected, the environment can be protected from hazardous materials, pollution can be
reduced, and the economy can be improved.
The NTFI, funded by the National Institute of Justice’s Office of Science and Technology, provides a
forum for public policymakers to partner their efforts with the efforts of the public safety community to
address interoperability issues in a more comprehensive way, and assists them in addressing the policies
needed to overcome current institutional barriers. The task force brings Local and State elected and
appointed officials together with representatives of the public safety community to develop national
strategies for addressing this critical public safety need.
The NTFI meeting included a roundtable discussion of the issues with representatives from the Council
of State Governments, the International City/County Management Association, the National Association
of Counties, the National Association of State Chief Information Officers, the National Governors
Association, the National League of Cities, and the United States Conference of Mayors.
Wireless Public SAFEty Interoperable COMmunications Program (Project SAFECOM) and pending
United States Department of Homeland Security (USDHS) Interoperability Initiatives have similar
relationships to the 1512 Family of Standards.
Relationship with Justice Standards Registry
The Justice Standards Registry for Information Sharing (JSR or Registry) is a repository regarding
standards and specifications that help practitioners increase the nation's safety. The JSR is a special
project of the Global Justice Information Network (Global) Advisory Committee (GAC).
This dynamic Registry was developed as part of the U.S. Department of Justice interoperability effort to
facilitate information sharing. The site captures existing standards and alerts users of new or emerging
standards. It also provides comment areas for users to offer support for the listed standards. By
establishing this repository, those involved in the design and implementation of justice system information
technology and communication have a place to share technical information so as to facilitate exchange
and sharing of information between the various systems.
25
The JSR provides details about technology and communications standards promoting information
sharing. An automated system enables users to enter, store, and search a variety of information relating
to various standards. Every user can comment and submit additional justice and public safety-related
information. Registering also provides the benefit of automatic notification when standards or
specifications are added and/or updated.
Incorporating Standards to Existing Communication Systems
The message sets of the 1512 Standards can be incorporated into existing communications systems in
multiple ways. The Base and companion volumes have sections in Abstract Syntax Notation One
(ASN.1) and DATEX to ease integration.
Data Exchange (DATEX) is a proprietary Transportation Communications protocol. It is easily written

from ASN.1, but would be seldom used by non-transportation agencies.
Extensible Markup Language (XML) is a simple, flexible text format and set of rules for designing text
formats that structure data. XML is not a programming language; however, it makes it easy for a
computer to generate data, read data, and ensure that the data structure is unambiguous. XML would
typically be used in conjuction with web services applications and is commonly used with Internet
communications protocols. It has fast become an extremely popular text format for systems integration
because it is easily understood, and it offers a way to define message format content.
Each standard contains mappings for XML use. Therefore, if the standard is going to be implemented
locally, the option for using XML is another choice.
Future Revisions to Standards
Developing and maintaining standards for implementation in real world situations requires timely and
appropriate revisions and updates. IEEE has taken this into consideration, and future work on the
standards is already in the planning stages. IEEE will officially manage the maintenance of the standards,
and the IMWG will make the revisions as long as it is in place.
Some of the planned revisions include updating the base standard based on changes in other
organizations’ message sets from which the message sets in the standard originated. An amendment for
data elements found in the message sets defined in the standards will address the changes to NTCIP,
Transit Communications Interface Profiles (TCIP), ATIS, etc. standard data elements used by traffic
incident management. This amendment is required for the continued usefulness of the base standard. The
amendment will also incorporate common message sets determined during the development of
subsequent volumes and issue a complete set of XML schemas.
Various supplements to IEEE Standards 1512.1-2003, 1512.2-2004, and 1512.3-2002 will also be
developed to allow the standards to address XML as requested by agencies and contractors deploying
the standards as well as the justice community, whose standardization effort evolves around XML. The
IEEE 1512.1-2003, 1512.2-2004, and 1512.3-2002 Standards have been developed and will be
26
published with XML documentation for ease of integration with public safety communication systems.
The base standard will require a similar effort, and that will be addressed with the supplements.
Feedback from early deployments and the testing program will be included as well. The emerging rules
will be incorporated to ensure consistent implementation, and documentation will also be required.
One specific example to revisions to the standards is in the HAZMAT Standard. Possible security
issues are addressed in a section of the standard that was not included in the original draft. Potential
threats and hazards in relation to hazardous materials were also added to the standard.
By scheduling and planning for the revisions to the 1512 Standards, IEEE has shown an ongoing
commitment to keep the standards current and relevant to agencies that use them. This will ensure that
the standards will be implemented through the years with long-term success.
27
Chapter 4 – IEEE Std 1512-2000 (Base Standard)
Summary of the Standard
IEEE Std 1512-2000, Common Incident Management Message Sets for Use by Emergency
Management Centers, or the Base Standard, is the foundation for a family of related standards that
address the intercommunication needs of emergency management centers and other types of centers
engaged in transportation incident management. This standard includes general introductory material for
the Family of Standards, and focuses primarily on the coordination and exchange of information
regarding incidents among emergency management and related centers. The Base Standard defines
message sets intended to transfer basic information about an incident between agencies. This basic
information includes a description of the incident, the agency’s or center’s jurisdiction where the incident
occurred, and the establishment of the center that will be in charge of the incident.
Purpose of the Standard
There is a need to communicate specific data between responding agencies and TMCs in a concise and
rapid manner using a format of data exchange that is common to every agency involved. The Base
Standard contains a common set of established procedures and operational methods to exchange
information between agencies that respond to incidents.
This standard contains a set of basic messages to allow the exchange of information between agencies
that respond to traffic-related incidents. It provides a common system for data exchange between local
agencies, and it allows the agencies to determine what level of cooperation and message exchanges best
meets their requirements. The Base Standard is applicable to all centers.
Basic Structure of the Message Sets
The Base Standard sets requirements for all responding agencies. Its message sets define the basic
information to be transferred for every incident. The Incident Management Message Sets are broken
into three basic categories: the Status Message Set, the Incident Management Message Set, and the
Center Management Message Set. The content of these messages is made up of general content as
defined in the Base Standard and more specific content defined in the companion standards.
Each of the three specific message sets is further divided into the messages listed in the table in
Appendix A. Established procedures were used to derive the elements of the message sets, and the
origin of the data elements can be found in each of the standards. Definitions for the messages are
presented in the subclauses of the standards as listed.
The Status Message Set has several purposes. One message is generated by the issuing center when
new information is accumulated, however, any center can enter additional information as it becomes
available. Another type of message is intended for public dissemination and can be filtered on an
28
element-by-element basis to control information that the public and media receive. A third set is a means
to request additional information about an incident from other agencies or within the issuing agency.
The Incident Management Message Set is used to manage the ownership and numbering of incidents.
One group of messages handles creating, splitting, merging and ending messages, respectively, between
centers and to inform others of how the issuing center is numbering the incident. Another set of
messages allows a center to hand off authority to the appropriate emergency center based on local
practices. Two other messages act as requests for centers to be notified of active incidents to prevent
overlapping data on the same event. These messages are especially useful when more than one agency
is receiving unverified information from various sources concerning one incident.
The Center Management Message Set exists to convey to all centers which centers are currently
operational and what their responsibilities are. The message sets will be used to establish the center of
authority, determine and change the center’s obligations, disable a center, and request response plans
between centers. The message sets are defined in the Appendix.
The Data Elements (DE) or Data Frames (DF), the basic wording for items in a message, that make up
each of the messages in the message sets are defined in each standard. Data elements or data frames
established in previous standards were used whenever possible, but some new DEs and DFs were
developed. Data elements or data frames could consist of specific information such as the location of an
incident, the type of event, or the time that the event occurred. This is the information that the emergency
centers will input as they receive it from the field or from other technology.
Adapting this Standard to Local Applications
The Base Standard provides a common mechanism for data exchange within the defined National ITS
Architecture with local agencies determining what level of cooperation and message exchanges is most
appropriate for their requirements. This standard is independent of communication protocols used in any
local implementation.
This standard’s computer code is set up to be modified for local situations and preferences as are each
of the standards. In essence, the system is standardized, however, the particular information gathered
and the centers involved will be specific to the local conditions. The particular needs and requirements
for specific applications must be determined in local user requirement meetings among all stakeholders.
The standard was developed to cover the generic and/or common implementations. Using XML to
implement the standards is another local decision.
Local customization in some areas is required and may also require new data unique to that area and not
covered in the standard. For example, the Incident Management Message Set from this standard will be
set up to assign ownership of various types of incidents based on the available responding agencies in
the area. The centers that are established and their properties will also be localized in the Center
Management Message Set.
There are several specific message sets that can be tailored to meet local requirements and
characteristics. The Public Incident Description message can be modified for each application to contain
29
information that the local user considers suitable for dissemination to a particular target center, typically
a public media center. The entire Center Management Message Set will be established based on the
local policies and local center operations. The properties and abilities for each center in a local system
will be defined and established by the local stakeholders and incorporated into the Center Management
Message Sets. These message sets were created for and are adaptable to local conditions.
30
Chapter 5 – IEEE Std 1512.1-2003 (Traffic Management
Standard)
IEEE Std 1512.1-2003, Traffic Incident Management Message Sets for Use by Emergency
Management Centers focuses primarily on the coordination and exchange of information supporting
real-time traffic incident management. This includes sharing information among transportation and other
responding agencies based on the IEEE 1512 Family of Standards.
The message sets specified in the standard were created to exchange data between a TMC and other
involved agencies and to improve asset management between responding agencies. Possible types of
transportation-related events that are included in the message sets are incidents, emergencies, collisions,
planned roadway closures, special events, disasters caused by humans, or natural events. Those events
include any such event that impacts transportation systems or that causes a report to be received by an
emergency management system, whether or not the event actually affects a transportation system, and
whether or not a response is required.
The 1512.1-2003 Standard defines the term “transportation-related incident” as being one of the
following two types of events:
• A non-recurring event, such as a motor vehicle accident, other unplanned road closure,
planned road closure, or planned special event (such as a parade, sporting event or
demonstration) that affects transportation services (and, e.g., could be a structural fire,
because the incident response affects the traffic grid);
• Any transportation-related event reported to a public safety access point (PSAP) (where
911 and other incident-reporting calls are received), whether or not a response is required,
and whether or not the event actually affects transportation services.
The Traffic Management Standard details how professionals on the scene of an incident can relay
information to the involved agencies and how the agencies can distribute and manage the complex and
often partial information provided to them. There are often disparities and variances between the
available information and what involved agencies need to know to manage the incident with regard to
traffic management and infrastructure. By using this standard, agencies involved in traffic management
can collect traffic-related data for collation and analysis, make traffic data available to any person or
agency involved in the incident, collect information to support necessary cleanup or repair, and distribute
appropriate response plans for any situation.
A key concept in this standard is work zones – designated areas within which certain controls apply
concerning personnel, equipment, training and/or operations. There are a number of zone schemes in
use for incident management. The standard designates a single, standardized format for describing any
zone scheme. It also designates a large freetext data item to carry a description of a zone scheme in any
format.
31
Another primary issue addressed in the Traffic Management standard is asset management. These
messages include requesting information on asset availability, responding to that request, requesting the
dispatch of an asset, verifying that dispatch, requesting information on asset status and responding to
that request, as well as sharing information necessary for the transfer of an asset. Efficient inter-agency
sharing of assets calls for each agency to know the location and status of the assets of all other agencies
on the network, or those assets available for inter-agency use. So each agency needs to be able to
broadcast that information to all other agencies that might want to use its assets or deploy its own in a
support role.
Incident management presents special challenges for routing emergency vehicles, and this standard
addresses route guidance. Normal routing functions apply; for example, to be able to route a message
to a particular center or agency by the name of that center/agency; and to be able to route to various
groups of centers/agencies with a single specification of the name of the group. In addition, it is highly
desirable that the addressee be able to be specified in terms of title or function, such as “local traffic
control.” The mapping from title/function to agency/center may be changed from incident to incident and
even during an incident. A message in this standard is used to designate and revise which title/function is
paired with which center.
Information in a transportation-related event is crucial to effectively manage the incident. Information

about the current traffic flows and the impact the incident has on the flow should be relayed to support
decisions involving traffic management including evacuation and the routing of response vehicles.
Necessary cleanup, repair or replacement of infrastructure needs to be determined in order to deploy
the required crews and equipment. The response agencies also need to know what traffic management
assets are available for use to assist with the traffic incident management decisions and execution of
plans.
The wide variety of information at the incident site, upstream and downstream of the incident, and in the
immediate area can come from several different sources and/or management centers. Information on
traffic flows, infrastructure damage, traffic control assets, and management plans for traffic, evacuation
and infrastructure all figure in managing the incident. In the course of an incident, the available
information may be complex, disorganized, spatially scattered and partial. This information needs to be
collected, compiled, and verified in order to be beneficial to the various responding agencies.
The message sets in the Traffic Management Standard work in conjunction with the message sets in the
Base Standard. While the Base Standard message sets provide information about the location of the
incident, the center responsible for the incident, and the type of incident, the Traffic Management
message sets are used to share data about traffic-specific issues. The two standards must be used
together. The Traffic Management Standard is compatible with all of the companion volumes.
32
To distribute and manage transportation-related data, exchanges of information of five kinds will occur.
The five types of exchanges are:
• Traffic-related information: collected from those other agencies for collation and analysis to
support the second exchange.
• Current and predicted traffic conditions: made available to the many agencies that may be
involved in the incident – in particular, route information for routing traffic and response vehicles.
• The need for cleanup, repair, and replacement of damaged infrastructure: to support responses
to carry out that cleanup, repair, and replacement.
• Plans for traffic management, evacuation management and infrastructure cleanup, repair and
replacement.
• Asset management information: to coordinate traffic control assets between agencies.
The messages in this standard communicate the available information, often quite partial, among the
involved agencies to accomplish three decision-support functions corresponding to the five kinds of
information exchange listed above. They are:
• To describe information about current and future traffic flows in the transportation grid, including
in particular impacts of an incident and particular route information, to support decisions
concerning traffic management, evacuation management, and the routing of response vehicles,
then to describe the corresponding traffic management plans, to support the implementation of
those decisions.
• To describe information about infrastructure cleanup, repair and replacement, to support

decisions concerning infrastructure management, then to describe the corresponding
infrastructure management plans, to support the implementation of those decisions.
• To describe information about traffic management assets, to support asset management

decisions, then to describe the corresponding asset management plans, to support the
implementation of those decisions.
In the Traffic Management Standard, the message sets are organized into three decision-support
functions corresponding to the five kinds of information exchange listed above. The specific information
on each data type is defined within the standard. The subclauses of the requirements are listed in a table
in Appendix A.
The messages in this standard also have the ability to be customized to local conditions and
requirements. The messages to request and broadcast a traffic control plan will have specific responses
33
that will meet local requirements for traffic control. For example, the Closed Circuit Television (CCTV)
camera messages would only be useful in applications that had a CCTV system in place. The status and
location messages regarding assets correspond to available assets for a particular area. Using XML to
implement the standards is a local decision as well. These are just some of the possibilities for adapting
the messages to local needs.
34
Chapter 6 – IEEE Std 1512.2-2004 (Public Safety Standard)
IEEE Std 1512.2-2004, Public Safety Incident Management Message Sets for Use by Emergency
Management Centers addresses the real-time exchange of vital data about public safety issues involved
in transportation-related events through common traffic incident management message sets. The
message sets used to share information supporting real-time incident management among public safety
agencies and between public safety agencies and other responding agencies are defined in this standard.
The definition for “transportation-related incident” is the same in the 1512.2-2004 Standard as the
1512.1-2003 Standard.
The Public Safety Standard covers the exchange of information across all public safety agencies
including law enforcement, EMS, TMCs, and fire and rescue. The standard identifies message sets to
be used to convey information concerning public safety issues internally within public safety agencies and
externally to other agencies that respond to transportation-related incidents.
Many of the message sets are related to asset management. While the Base Standard includes
provisions for basic information at the scene, it does not provide an adequate basis for managing
specific assets. This standard defines the message sets for public safety agencies to become involved in
a useful way and to provide them with the information they need to handle each situation effectively. The
messages include information for the need of traffic management, traffic control, ingress or egress routes,
towing, cleanup, law enforcement, evacuation planning, emergency medical services, rescue, fire
suppression, and/or HAZMAT management.
The message sets in the Public Safety Standard work in conjunction with the message sets in the Base
Standard. The Base Standard messages convey information about the location of the incident, the
responsible center and the type of incident. The public safety message sets relay information pertaining
to data specific to public safety interests. The two standards must be used together for useful results.
The Public Safety Standard is compatible with all of the 1512 companion volumes.
The message sets are framed in terms of four basic incident management operations: Warning
Information, Situation Awareness, Plan Dissemination, and Inter-Agency Asset Management. For each
basic operation, data types supporting that operation are provided. The subclauses of the five general
requirements are listed in the table in Appendix A.
The Warning Information message sets advise emergency evacuation, request immediate assistance,
publish cautions for responders, and publish and respond to “watch for” information. The message sets
35
under the Situation Awareness operation include collating and disseminating situation status including
response services, involved persons, and GPS information. Plan Dissemination message sets are used to
disseminate a plan and support the information exchange necessary to carry out that plan and coordinate
actions among agencies including zone information, patient information, and the incident management
command structure. The Inter-Agency Asset Management message sets relay asset requests, inventory,
location and status.
While the standard shall specify a list of functions, the local implementation may add local functions in
addition to the functions specified in the standard. The functions specified in the standard may include
but not be limited to: local traffic control, public information officer, incident commander, or information
officer.
One message defined in the Public Safety Standard is Advise All Personnel to Immediately Evacuate.
The components of this message as listed in the standard may not be compatible with simple and rapid
dissemination of evacuation advice. Specifying those components leaves room for creative development
by local implementations. The same situation applies to the Request Immediate Emergency Assistance
message, the Publish Cautions for Responders message, all of the tracking messages, and several others
as identified in the standard. XML implementation is also a local deployment option for this standard.
36
Chapter 7 – IEEE Std 1512.3-2002 (HAZMAT Standard)
IEEE Std 1512.3-2002, Hazardous Material Incident Management Message Sets for Use by
Emergency Management Centers describes a system of information exchange to be used in a situation
where hazardous materials have been unintentionally released on or near a roadway. The message sets
used in the information exchange are primarily for use among HAZMAT response agencies and
between HAZMAT agencies and any other agencies involved in incident management communications
networks. The information included in the message sets includes information specific to the control and
confinement of hazardous materials.
A serious problem at a HAZMAT incident is a lack of information concerning the contents of the vehicle
carrying the hazardous material and the best way to respond to a spill. This problem is a concern
especially when the spill is significant or if the material spilled is a deadly substance. The message sets
detailed in the HAZMAT Standard provide the responding agency with specific information about the
particular cargo and content based on available information. This information can be obtained from a
number of sources including shippers, carriers, and fleet and freight management centers. The message
sets also provide a mechanism to exchange information between on-site and off-site incident responders
including information and response plans for the particular chemicals, amounts and situations involved.
This standard provides the framework for communication between the incident site and off-site
databases and a method to coordinate the complex decision support process. These messages support
communication of the available information, often quite partial, to and from off-site databases, and often
among off-site databases.
The HAZMAT Standard describes a method to relay information dealing with transportation-related
incidents involving HAZMAT as cargo of vehicles or as a danger in adjacent areas. The message sets
address specific response plans associated with communications dealing with the control and
confinement of Hazardous Materials during and following an incident.
The goal of this standard is to support the response agency with all available information concerning
cargo and content in a HAZMAT situation. This includes collecting information at the site of the incident
and from several off-site databases or other relevant information sources. Efficient coordination between
the responding personnel at the site and other off-site agencies can provide timely information to support
the complex and often quick decisions that must be made in a HAZMAT situation. As information is
collected and verified, it can be relayed to the response agency for more efficient management at the
incident. Also, related agencies can be contacted for appropriate response plans and available
equipment.
37
The message sets in the HAZMAT Standard work in conjunction with the message sets in the Base
Standard. A center will use the Base Standard message sets to transmit information on the type of
incident, the location and the center responsible for handling the incident. The message sets defined in
the HAZMAT Standard communicate specific information about any incident involving hazardous
materials. The two standards must be used together for useful results. The HAZMAT Standard is
compatible with the other standards in the 1512 Family.
The basic intent of the messages, data frames and data elements specified in this standard are to support
the communication of information about contents, including but not limited to hazardous material and
hazardous waste, and to assist in real-time inter-agency management of an incident. Two functions must
be performed to satisfy this mission:
1. Retrieve further information about what the cargo and/or contents is, based on what are often
quite partial cues available on site. That information is available in off-site databases managed by
shippers, carriers, and Fleet and Freight Management centers.
2. Retrieve information about the characteristics of the cargo and/or contents that is important for
incident management, such as toxicity, flammability, danger of explosion, size of a potential toxic
plume, environmental damage, recommended set-back distances, and evacuation areas.
The functions lead to the following list of requirements the system of messages, data frames
and data elements specified in this standard will fulfill in concert with the Base Standard.
The requirements fall into three categories:
1. Messages or sets of messages that describe on-site cues about the cargo and/or contents to a
remote cargo/contents database, to retrieve more complete data on that cargo and/or contents.
Examples of on-site cues range from statements by the driver to placards to labels on packages
to the shipping papers. That database can be very general, such as providing a mapping from
package labels to contents types, or very specific, such as might be available from the shipper.
2. Messages or sets of messages that describe the cargo and/or contents to a remote hazard-
management database, to retrieve data on how to manage any cargo/content-related hazards in
the course of the management of the incident. The cargo/contents information can range from
quite cursory, such as the first on-site cues, to quite complete, such as the complete information
form the shipping papers and even more information from the shipper.
3. Messages or sets of messages that contain information available from telematics messages
broadcast from the vehicle. Those messages may be broadcast automatically by the vehicle
(triggered by on-board cues indicating an incident, including cues indicating leakage), or upon a
command action by the driver of the vehicle. In either case, the message can be considered a
computer file of information that a local implementation may want to transfer some of all of the
nodes on a 1512 network, i.e., a network of nodes where each node is in conformance with the
1512 Family of Standards.
38
Seventeen Functional Requirements (FR) were developed to provide an unambiguous basis for
determining that the messages, data frames and data elements in this standard satisfy the three
requirements listed above. Ten Required Information Types (RIT) are worded much like the FRs,
except limited to the information type required for each FR. The parts of the FR that extend beyond the
RIT can be addressed by the way the message is labeled and defined. The FRs and RITs are listed in
Appendix A.
Similar to the other standards, the HAZMAT Standard contains versatility to adapt the recommended
message sets to conform to local conditions. The basic structure of the messages is set; however, the
particular information gathered and dispersed is a decision that is made locally. Managing the
operational complexities of collecting the on-site data, then querying multiple databases to gather all
relevant information, is a task for the local implementation.
39
Chapter 8 – IEEE Std 1512a-2002 (Emergency Management
Data Dictionary)
The IEEE 1512a-2002 Emergency Management Data Dictionary (EMDD) Standard is limited to the
development of a comprehensive set of data elements, data frames and messages specific to the 1512
Family of Standards. This work is a functional partition of the Incident Management Base Standard and
was developed as a separate project. The EMDD is suitable for submission to the ITS Data Registry.
This standard produces an EMDD for Incident Management and is a requirement of the ITS National
Architecture.
The ITS Data Registry (DR) is a logically centralized data dictionary or repository for all ITS data
elements and other data concepts that have been formally specified and established for use within the
national ITS domain. As such, the ITS DR is intended to serve as a common or shared data reference
for the national ITS domain. The primary objective of the ITS DR is to support the unambiguous
interchange and reuse of data and data concepts among functional-areas of ITS (i.e., among associated
ITS subsystems and their application systems) by recording unambiguous definitions of data concepts.
The DR functional design is intended to be the primary guide to the development of the ITS DR. It
draws upon various documented user requirements for the DR (e.g., from IEEE Standard 1489-1999,
the DR Functional Operating Procedures (FOP), DR design group meeting notes) and specifies them in
terms of functional system requirements. It then takes the functional system requirements and allocates
them to logical modules. These logical modules will be realized by actual software components during
the physical development of the DR.
The DR functional design specifies the contents and functions of the DR. It relates general system
functions back to the major procedural roles and responsibilities assigned to various users of the DR. It
identifies specific system functions, including users authorized to perform the functions, the nature of the
processing, the content against which the processing may be performed, the specific validations
performed during processing, and the specific processing logic flow. The design also addresses, at a
logical level, the system processes by which the specific functions and their associated functionality can
be realized. Additionally, the DR functional design includes logical database design, both an overview
and specifications of normalized logical view tables, as they are used during validation and processing.
The DR functional design does not address detailed physical aspects of the system, including specific
user interface and report layouts, nor does it prescribe quasi-code or other programmatic-level designs.
The DR is a physically-centralized, but logically-distributed information system. The central DR server is

a Unix-based server residing at IEEE's facilities in Piscataway, New Jersey. Users access the server via
the Internet as distributed clients, operating from any geographic location. Standard HyperText Markup
Language (HTML)-based web browsers provide platform-independent user interface to the DR for
40
data acquisition and presentation. A commercial-off-the-shelf relational DBMS resides on the server
and hosts the structures (i.e., data concepts and their meta attributes) used to organize and manage the
contents of the DR. The DBMS also provides for physical data storage, and for acquisition and
presentation via a CGI-based interface between the back-end DBMS and the web browser front-ends.
To perform various DR functions, authorized users invoke the functionality of the DR through specific
browser-based user interfaces. Which functionality the user is permitted to perform depends on the user
class. Much of the functionality may be invoked on-line, however, heavily data-intensive processing is
complemented by batch import capabilities. Reporting (both pre-packaged and ad hoc) is supported via
the creation of electronic or hardcopy output files, including a standard export file.
Commonality among functions is exploited through the application of basic operations and underlying
generic system processes. These basic operations and their generic processes operate against state
tables for purposes such as data validation. This, along with flexible data structures for implementing the
data concepts, their meta attributes and various relationships, provides built-in flexibility, thereby making
the system easier to maintain and extend.
Figure 5 depicts the flow of information (data elements) from application data dictionaries up through
the functional area data dictionaries to the data registry, the inclusion of foreign data elements in ITS
data dictionaries and the coordination between the ITS and the foreign data registry.
ITS Data Foreign Data

Registry Registry
Functional Area Foreign Data

Data Dictionary Dictionary
Application
Data Dictionary
Figure 5 – Information Flow
41
Chapter 9 – Case Study Implementations
Listed below are individual case studies that were utilized to incorporate the IEEE 1512 Standards and
enhance communication and safety. Detailed descriptions of each of the case studies are located in
Appendix B.
• Appendix B.1 – New York State DOT/Veridian Experience

• Appendix B.2 – San Diego InterCAD
• Appendix B.3 – TESCNET
• Appendix B.4 – The CapWIN Project
• Appendix B.5 – The San Diego Regional AVL System
• Appendix B.6 – Various Combinations of the Standards
Recent initiatives that have just begun or may be in development should be investigated as part of local
implementation. State and regional authorities that may be planning for public safety interoperability
should be contacted. These authorities may include state office of justice assistance, emergency
government, state DOT ITS offices, FHWA division offices and resource centers, and others. In
particular, Wireless Public SAFEty Interoperable COMmunications Program (Project SAFECOM),
pending United States Department of Homeland Security (USDHS) Interoperability Initiatives, and
other public safety interoperability programs should be researched.
Again, this Guide is not an implementation guide. An implementation guide must be developed based on
local needs, geographical issues, regional architecture as well as local agency relationships. Appendix C
includes an approach to taking the next step towards implementation. This is not a full implementation
guideline, but it includes some of the issues to be considered before implementation.
42
Appendix A – Message Set Tables
Message Set Tables for IEEE Std 1512-2000, Common Incident

Management Message Sets for Use by Emergency Management Centers
(the Base Standard)
Figure A-1: Incident Management Message Sets
Figure A-2: Status Message Set
43
Figure A-3: Incident Management Message Sets
Figure A-4: Center Management Message Set
44
Table A-1: Base Standard Message Sets
Status Message Set

Message Subclause
Incident Description (IDX) 5.1.1
Public Incident Description (PID) 5.1.2
Request Information (RIN) 5.1.3
Incident Management Message Set
Message Subclause
New Incident Event (NIE) 5.2.1
Split Incident Event (SIE) 5.2.2
Merge Incident Event (MIE) 5.2.3
Close Incident Event (CIE) 5.2.4
Poll for Hand Off (PHO) 5.2.5
Available for Hand Off (AHO) 5.2.6
Request Hand Off (RHO) 5.2.7
Grant Hand Off (GHO) 5.2.8
Request Verified Incidents (RVI) 5.2.9
Request Unverified Incidents (RUI) 5.2.10
Center Management Message Set
Message Subclause
Establish Center On-Line (ECO) 5.3.1
Disable Center On-Line (DCO) 5.3.2
Establish Center Properties (ECP) 5.3.3
Change Center Properties (CCP) 5.3.4
Request Center Plans (RCP) 5.3.5
45
Message Set Tables for IEEE Std 1512.1-2002, Traffic Incident
Table A-2: Traffic Management Standard Message Sets
Subclause Acronym Requirement

4.2 Request and Share Information about Work Zones
4.2.1 RZD Request Work Zone Description
4.2.2 WZD Work Zone Description
4.3 RTC Request Local Traffic Control
4.4 DTC Describe Local Traffic Control Plan
4.5 Share Information about Ingress/Egress Routes, and Request Route
Services
4.5.1 RRA Request Route Advice/Services
4.5.2 ORA Offer Route Advice/Services
4.6 Share Location/Priority/Preemption Information on a Response Vehicle
4.6.1 RLP Request Location/Priority/Preemption Information on a Response
Vehicle
4.6.2 SLP Share Location/Priority/Preemption Information on a Response
Vehicle
4.7 Information on Clean Up or Infrastructure Repair: The Need for It and
Plans
4.7.1 NCI Need for Clean Up/Infrastructure Repair
4.7.2 CRP Clean Up/Infrastructure Repair Plan
4.8 RNC Request Information on Network Conditions or Route Status
4.9 Share Information on Asset Management
4.9.1 AFA Ask for Assets
4.9.2 RAA Respond to Ask for Assets
4.9.3 RAS Request Asset Status
4.9.4 AST Asset Status
46
Message Set Tables for IEEE Std 1512.2-2004, Public Safety Incident
Table A-3: Public Safety Standard Message Sets
Subclause Acronym Requirement

4.4 Warning Information
4.4.1 ISE Advise All Personnel to Immediately Evacuate: Immediate Site
Evacuation
4.4.2 RIA Request Immediate Emergency Assistance
4.4.3 CFR Publish Cautions for Responders
4.4.4 “Watch For” Cycle
4.4.4.1 WCH Publish “Watch For” Message
4.4.4.2 RWF Respond to a “Watch For” Message
4.5 Situation Awareness
4.5.1 Inform of Need For . . .
4.5.1.1 INL Law Enforcement
4.5.1.2 INM Emergency Medical Services
4.5.1.3 INR Rescue
4.5.1.4 INF Fire Suppression
4.5.1.5 INO Other Response
4.5.2 Track Persons and Vehicles
4.5.2.1 TIP Track Involved Persons
4.5.2.2 TSC Track Response Personnel in Special Circumstances
4.5.2.3 TRP Track Response Personnel On Site
4.5.2.4 TWT Track Witnesses
4.5.2.5 TIV Track Involved Vehicles
4.5.3 DGC Publish Differential GPS Information
4.6 Plan Dissemination
4.6.1 ZON Publish Zone Information
4.6.2 MCS Publish Incident Action Plan Info, Management Command Structure
4.7 UAI Inter-Agency Asset Management: Update Asset Inventory Location,
Status
4.8 Asset Linking
47
Functional Requirements (FR) and Required Information Types (RIT) for
IEEE Std 1512.3-2002, Hazardous Material Incident Management Message
Sets for Use by Emergency Management Centers
Functional Requirements (FR)
FR1: … vehicle/cargo information observable from outside the vehicle, or from external observation of
cargo containers, but not shipping papers, to an external database for the purpose of retrieving more
detailed information about the cargo. As such, the message constitutes a request for information from
the external database.
FR2: … vehicle/cargo information available from any typical vehicle shipping papers, to an external
database for the purpose of retrieving more detailed information about the cargo. As such, the message
constitutes a request for information from the external database.
FR3: … HAZMAT and other building contents information observable from outside the building, or by
observing package units, not records, to an external database for the purpose of retrieving more
detailed information about the contents of the building that may be of particular interest for incident
management. As such, the message constitutes a request for information from the external database.
FR4: … hazmat and other building contents information obtainable from records inside the building to an
external database for the purpose of retrieving more detailed information about the contents of the
building that may be of particular interest for incident management, such as SARA Title III Community
Right-to-Know (CR2K) information. As such, the message constitutes a request for information from
the external database.
FR5: … queries from off-site databases about on-site observable data, of the type specified in FR1
through FR4. An off-site cargo database system may want to query on-site personnel about observable
data.
FR6: … responses to queries specified in FR5 about observable data. This entails information of the
type specified in FR1 through FR4.
FR7: … requests for detailed hazmat or non-hazmat cargo information, while providing information of
the type specified in FR1 through FR4 or a more detailed level based on a database lookup, as a basis
for that.
These requests differ from the requests specified in FR1 through FR4, in that they may come from
another database rather than on site. That is, on-site data could be communicated to one off-site
database for one level of information, via communication specified in FR1 through FR4; then the results
of that database lookup could be used to query a more detailed database via communication specified
here as FR7. This FR is included to be sure to cover the situation where the information sequence may
48
start with data available on site (FR1 to FR4), then go to one database to be supplemented, and then go
to a second database for further information.
FR8: … vehicle/cargo or building contents information retrieved from a DB look-up in response to

queries based on information of the type specified in FR1 through FR4 and FR7. This information is at a
more detailed level than the information carried in FR1 through FR4 and FR7. For example, the
querying information might be at the level of types of mixtures, while this more detailed information might
include actual concentrations.
FR9: … requests for hazard management information, while providing data of the type specified in FR1
through FR4, FR7 and FR8 as a basis for that. Not keyed to the actual leak/spill situation (for that, see
FR11 to FR12).
FR10: … hazard management information retrieved from a DB look-up in response to queries specified
in FR9.
FR11: … requests for hazard management information specific to the actual situation, while providing
data of the type specified in FR1 through FR4, FR7 and FR8 as a basis for that.
FR12: … hazard management information, for the actual situation of hazardous materials, leaks, spill
pool sizes, and potential and actual hazards. That is, the information provided in response to queries
specified in FR 11.
FR13: … requests for current status information of the incident particular to cargo/content.
FR14: … current status of the incident particular to cargo/content. That is, the information provided in
response to queries specified in FR 13.
FR15: … requests for static document information, such as the Emergency Response Guide Book.
FR16: … static document information in response to requests as specified in FR17.
FR17: … mayday-like (telematic) messages, i.e., telematics messages automatically transmitted from an
involved vehicle, or transmitted upon a command action by the driver.
Required Information Types (RIT)
RIT1: … vehicle/cargo information observable from outside the vehicle, or from external observation of
cargo containers, but not shipping papers.
RIT2: … vehicle/cargo information available from any typical vehicle shipping papers.
RIT3: … building HAZMAT and other contents information observable from outside the building, or by
observing package units, not records.
RIT4: … building hazmat information obtainable from records inside the building.
49
RIT5: … vehicle/cargo or building contents information retrieved from a DB look-up in response to
queries based on information types RIT1 through RIT4. This information is at a more detailed than RIT1
through RIT4. For example, the querying information (RIT1-4) might be at the level of types of
mixtures, while this more detailed information (RIT5) might include actual concentrations.
RIT6: … hazard management information, keyed to the types of materials but not keyed to the actual
situation (for that, see RIT7).
RIT7: … hazard management information specific to the actual incident leak/spill situation.
RIT8: … current status information of the incident particular to cargo/content.
RIT9: … static document information.
RIT10: … mayday-like (telematic) messages, i.e., telematics messages automatically transmitted from
an involved vehicle, or transmitted upon a command action by the driver. This is intended for special
telematics messages particular to HM carriers, as opposed to “civilian” telematics.
50
Appendix B – Case Study Implementations
New York State DOT/Veridian Experience
This particular case study addresses the technical issues that were encountered in a simulated
implementation of an enhanced communication system. The goal of this project was to improve incident
management and emergency response by enhancing communication of incident data among incident
management and emergency response personnel; both on-scene and at multi-modal communications
and operations centers.
The NYSDOT Region 11, in partnership with the agencies listed below, are developing a real time
incident management system that will enhance the communication of incident data among incident
managers at operations centers and incident response personnel at the incident scene. Veridian
Engineering is the project consultant. The Integrated Incident Management System (IIMS) is a multi-
agency project managed by NYSDOT, in partnership with New York City Department of
Transportation (NYCDOT) and the New York City Police Department (NYPD). Recently, USDOT
added support to IIMS as part of the ITS Public Safety Program. IIMS is being enhanced under
USDOT funding to improve the dispatch of resources to the incident scene. This expanded initiative
includes additional IIMS Field Operational Test evaluation, outreach to the Public Safety and ITS
community, and support of ITS standards deployment and testing.
The participating agencies are:
• New York State Department of Transportation (NYSDOT)

• New York City Department of Transportation (NYCDOT)
• New York Police Department (NYPD)
• New York Fire Department/EMS (NYFD/EMS)
• New York City Department of Sanitation (NYCDES)
• NYC Department of Environmental Protection (NYCDEP)
• Metropolitan Transportation Authority-NYC Transit (MTA NYCT)
• New York City Office of Emergency Management (NYCOEM)
Effective incident management achieves the ITS goals of improved safety, reduced congestion,
improved mobility, and increased efficiency and productivity. The IIMS is unique in its ability to transmit
incident scene data real time to incident operations centers. These data include the information required
to effectively select the proper responders and equipment for clearance.
Incident responders use mobile computers to collect and transmit the incident information required to
clear that particular incident type. During a major incident, the incident management system can also be
used at the incident scene by equipping an on-scene incident command center.
Mobile equipment was installed in nine NYPD vehicles and one NYSDOT vehicle. The equipment was
operated by eighty NYPD highway officers and two NYCDOT incident managers. Four centers are
51
equipped and are operated twenty-four hours a day, seven days a week, by seventy-five incident
managers to respond to the equipment users.
The features of the new equipment included:
• real-time incident data shared among field units and multiple centers/agencies,
• data including pictures, location, and dispatch information,
• data needed for dispatch of proper equipment and resources,
• open architecture for sharing data with existing operations center applications,
• and the storage of incident data for long-term analysis.
Both the agencies involved in the project and the public benefited from the enhanced communication
system. Benefits to the agencies included:
• a reduction in time to verify and clear incidents,

• a reduction of need for supervisors to travel to the incident scene before dispatching
response equipment,
• an improvement in equipment and personnel dispatch decisions,
• accurate Global Positioning System location,
• and an improvement of incident data analysis.
The benefits to the public included:
• reduced congestion,
• improved safety,
• improved operations,
• and improved incident status reporting.
The project is an example of a high-level implementation of incorporating an enhanced communication

system into an existing system.
For additional information on this case study, contact Edward Mark1. Additional information about this
case study can be found at www.dot.state.ny.us/reg/r11/iims/.
San Diego InterCAD
Overview
In 1996, the San Diego InterCAD Project was well on its way to becoming the first in a series of “Early
Start” projects for the Southern California Priority Corridor Showcase Program. This project was the
first in the Early Start series to receive approval of a Federal Work Plan and the first to develop a set of
functional requirements. From then until now, the project enjoyed some early deployment success, but
the original objectives have not been fulfilled due to a series of institutional, technical and financial issues.
1
Edward Mark can be contacted at the New York State Department of Transportation. emark@gw.dot.state.ny.us.
52
Taking a look backward at these issues may provide some useful insight on the problems to avoid in the
integration of public safety communications systems with transportation management systems. Given the
intense current interest in this integration goal, these “lessons learned” will hopefully shed some light on
“the good, the bad, and the ugly.”
The San Diego InterCAD (San Diego Regional Computer Aided Dispatch (CAD) Interconnect)
project, designed to facilitate improved incident management in San Diego County’s portion of the
Southern California ITS Priority Corridor, began in the fall of 1995. By summer 1996, the California
Division of FHWA had approved the Federal Work Plan. InterCAD was originally envisioned as a
two-phase project, leading to implementation in more than one region within the Priority Corridor.
As part of the local match funds required to receive federal funding for the project, the San Diego
motorist aid call box authority, known as the Service Authority for Freeway Emergencies (SAFE),
provided operating fund reserves to complete Phase 1 of the InterCAD project. Phase 2 of the project
was funded from the FHWA FY 96 Priority Corridor Showcase budget administered by the San Diego
Association of Governments (SANDAG).
The Phase 1 participants in the InterCAD project included San Diego Police Department (SDPD), San
Diego Sheriff’s Department (SDSD) and the Border Division of the California Highway Patrol (CHP).
Phase 2 of InterCAD was planned to incorporate the new Caltrans Transportation Management Center
(TMC) when that facility’s new computer system became operational. Other public safety agencies
within San Diego County, including fire and EMS, also planned to join the project in Phase 2. A similar
project, Inland Empire InterCAD, had been proposed for Riverside and San Bernardino counties as
part of the Showcase Increment II funding request – this project has not been funded to date. Thus far,
the only agencies on the InterCAD network include Caltrans District 11 TMC, Heartland Fire
Communications (an East San Diego County Joint Powers Agency for fire/EMS communications) and
the Federal Fire Department (a unified department consisting of local US Navy and Marine Corps base
fire departments).
Lessons Learned
Institutional. As with all projects of this type, the major issues revolved around difficulties with
institutional considerations. Law enforcement agencies had difficulties assuring themselves that the
InterCAD system had adequate security safeguards. The security issue stalled the project for almost a
year, and law enforcement agencies gradually lost interest in participating. At a critical point in the
project’s life cycle, several agencies switched CAD vendors, which combined with an over-reliance on
one CAD vendor to develop a workable CAD integration solution, struck a severe blow to project
progress. Communications managers were understandably preoccupied with getting critical new CAD
systems operational and much less interested in regional interoperability. Although senior law
enforcement executives in the County had been briefed on the project early on, they were not kept
apprised of the ongoing issues. Their counterparts in the fire service and EMS agencies were never
briefed.
The project champion, a senior uniformed law enforcement communications commander, retired, and
there was no leadership to fill the void. Since there was only one champion, his departure led to an
53
onset of a “Not Invented Here” syndrome and a lack of qualified and motivated senior personnel to
take over. The leadership mantle passed from law enforcement to fire/EMS, thus the focus of the
project changed in mid-stream. At this point, the project gained two fire service advocates that kept the
project alive.
Technical. As mentioned above, an over-reliance on a single CAD vendor to solve the technical
integration issue with host CAD systems led to a technical stalemate when that vendor lost several
contracts to upgrade key law enforcement and fire/EMS CAD systems in the region. Although the
technical solution proposed by that vendor was effective and executable, new CAD vendors were not
made project stakeholders when they became the new agency consultants. As a result, new CAD
systems were not designed to take advantage of the InterCAD architecture. There appeared to be no
compelling reason for agencies to address InterCAD issues when they had more than enough issues
with just converting to new CAD systems.
One of the more difficult technical problems that had to be solved was the methodology to convert
internal CAD incident representation on different CAD systems into a common language for regional
dissemination over the InterCAD network. At the time, there was no generally accepted standard to
accomplish this (i.e. the 1512 standard), therefore the InterCAD project defaulted to a plain English
representation of major incident record details such as location, incident type, response status, etc.
As a result of the above, the InterCAD project today consists of workstations that are installed in the
three agencies listed earlier – these workstations are connected using a messaging protocol called
MQSeries from IBM and a Switched Multimegabit Data Service (SMDS) network provided by the
local wire line telephone carrier. The workstations are not connected to the host CAD systems as was
originally envisioned, but operate as standalone terminals in the centers involved. For an integration
project this is not an operationally satisfactory solution, since CAD and TMC operators do not typically
have time to enter incident information on two different systems.
The SMDS network that is currently operational for InterCAD has never been given an official “green
light” for security by law enforcement agencies. In retrospect, the use of a law enforcement-sanctioned
network such as the San Diego Automated Regional Justice Information System (ARJIS) would have
been a strategically more acceptable choice than a private network. The prospect of increased support
costs and reluctance to address additional bureaucracy drove the decision to use a more readily
available and cheaper communications alternative.
Financial. Although the InterCAD project had a reliable source of local match funding for
Phase 1 and what initially appeared to be a sufficient federal funding level for Phase 2, technical
difficulties with the change of CAD vendors and uncertainty in how to approach integration with the
evolving Priority Corridor Showcase network led to a significant funding shortfall that has not yet been
addressed. The one CAD vendor who prototyped the initial technical solution lost a significant amount
of money in the process and was not able to recoup this loss before losing several local CAD contracts
to other vendors. The eventual funding shortfall can be at least indirectly attributed to not involving a
broader segment of the CAD industry as stakeholders in public safety-transportation integration
projects in general, and this project in particular.
54
For additional information on this case study, contact Bruce Churchill2.
TESCNET
The concept of the TESCNET program is to create a regional perspective of the communication
environment for public safety and transportation entities in Southeast Wisconsin for Regional, State,
County and Municipal authorities. TESCNET will engage these agencies early on in the development of
communication projects in the region so that multi-agency needs can be considered and integrated, as
appropriate to maximize the benefits to the public. The goal of TESCNET is to collaboratively develop
an action plan to deploy a communications network in Southeastern Wisconsin to accommodate traffic
management and emergency communications and to encourage information sharing among multiple
agencies.
The TESCNET project is a pilot project that will link the “Monitor” Freeway Traffic Management
System with county and state law enforcement computer-aided dispatch systems. The pilot project will
be the cornerstone of a regional communications network in the Milwaukee area to connect
transportation and public safety agencies.
Monitor collects data on the freeway system through a series of cameras mounted on poles, detector
loops embedded in the pavement, and overhead microwave detectors located on bridges over the
freeway. This information is collected and sent to the Traffic Operations Center in downtown
Milwaukee. Engineers and control room operators evaluate the data to determine current freeway traffic
situations.
Monitor system components include: the Traffic Operations Center (TOC), embedded pavement
detectors, ramp meters, variable message signs, Traveler Advisory Radio (TAR), trailblazer signs,
service patrols, and CCTV.
The intent of this project is to effectively address the needs that were conveyed by the participating
TESCNET agencies during the previous project phases. Furthermore, it also reflects needs conveyed
from other similar programs throughout the country.
The key tenets of the TESCNET business plan are:
• A common core transmission network that would support both public safety and transportation
operations is envisioned. This network leverages and builds upon the infrastructure developed
under the Communication and Data System Infrastructure (CDSI) program. The network
consists of a backbone and access segments to the participating agencies. The backbone
segment will be developed to accommodate multiple overlaid backbone networks, such as
those needed for video distribution, wireless services and mobile radio services. Access
networks will consist of a variety of access technologies such as fiber-based, copper-based, ore
wireless, as dictated by prevailing circumstances of the local area.
2
Bruce Churchill can be contacted at National Engineering Technology Corporation. bchurchill@nateng.com.
55
• An ability to share relevant information and content in real time among the participating
TESCNET agencies is to be developed. Information consists of voice, data, and video. The
plan will seek to identify and develop common solutions to store and distribute relevant public
safety and transportation data.
• Mobile interoperability at the voice and data levels will be sought as it relates to TESCNET
operations. The plan will seek to identify solutions to enable mobile interoperability among the
agencies and between the agencies and the core transmission network.
• Cross-functional dispatch capabilities are envisioned. This entails consolidating the dispatch
functions across multiple agencies within a jurisdiction and eventually among multiple
jurisdictions. Consolidation can be physical and/or virtual.
• Connectivity to other external private networks (e.g. Federal Emergency Management Agency
(FEMA), etc.) and the Internet will be a necessity.
For additional information on this case study, contact John Corbin, P.E. 3 Additional information about
this case study can be found at www.tescnet.net/getpage.asp?PageApp=body&PageID=53.
The CapWIN Project
The public's concern for safety in the Washington Metropolitan area has generated a need for improved
coordination and information sharing between numerous public safety and transportation agencies and
organizations in Maryland, Virginia, and the District of Columbia. Citizens are demanding greater
accountability from all public safety and transportation agencies. To meet this demand, public safety and
transportation agencies are looking to use technology to share more timely and accurate information
between agencies serving the Capital Beltway and surrounding Washington area road network. These
agencies are also becoming interested in developing partnerships that will allow them to share limited
resources towards the common goal of improving safety for their customers.
In the transportation arena, traffic incident management has become an important tool to alleviate
incident related congestion on the Capital Beltway and surrounding road network. Effective incident
management requires coordination and information sharing among multiple responders including: law
enforcement, fire and rescue, emergency medical services, transportation agencies, motorist assistance
services, information service providers, and the media. While this coordination continues to improve,
incident response and scene management is hampered by the inability of agencies to communicate,
particularly in a mobile environment. In order to get a message from one agency's response unit to
another, responders must communicate with their respective communication centers and request that
they phone their counterpart agency communication center and have them relay a message to their
responding mobile unit. This fragmented and indirect communication takes time and adds unnecessary
delay in situations where every second counts.
3
John Corbin can be contacted at the Wisconsin Department of Transportation. john.corbin@dot.state.wi.us.
56
For public safety agencies, traffic incident management is only one of many job-related duties.
Coordination and information sharing are also critical in the fight against crime in the Washington, D.C.
area. Fire and rescue operations are hampered by the inability to communicate in the region. Critical
“incidents” for these agencies are not just those related to major traffic collisions, but also include school
violence, major crimes, aircraft crashes, building fires, and other rescue type missions. After action
reports for major incidents involving multiple agencies point to lack of communication as a serious
problem.
A lack of inter-agency guidelines and data standards between public safety and transportation
communication systems fosters discordance and escalates the cost of providing service. Current and
planned investments in incompatible technologies by local, state, and federal agencies continue to
exacerbate the problem. Adding to the problem is the fact that public safety and transportation agencies
cannot stop implementation of systems mid-deployment and therefore will continue spending funds for
new technology and updating communications systems without focusing on resource sharing
opportunities. The cost of new technology can be costly, however, through partnerships and resource
sharing, each agency can potentially save money over the long term.
The CapWIN project is a partnership between the States of Maryland and Virginia, the District of
Columbia, the DOJ, and the FBI to develop an integrated transportation and criminal justice information
wireless network. This unique project will integrate the participating areas’ transportation and public
safety data and voice communication systems and will be the first multi-state transportation and public
safety integrated wireless network in the United States. The project will have national implications in
technology transfer including image/video transmission and the inclusion of transportation applications in
an integrated system. National observers will be able to monitor the progress and development of the
system during the evolution of the project. This project can potentially build a foundation for networks
throughout the United States and other countries. The project will be completed in multiple phases
including an initial strategic planning phase (completed), the implementation phase (currently underway)
and a continuous development and expansion phase.
A pilot test was initiated during the strategic planning phase of the project. The pilot included twenty-
two in-vehicle mobile computer systems that allowed messaging between police and fire vehicles in
Maryland, Virginia and Washington, D.C. and transportation vehicles in Maryland and Virginia. These
mobile platforms and other developmental transportation and public safety systems were successfully
interfaced during the pilot project. The primary goal of the project is to have multiple mobile data
platforms communicating seamlessly across the network regardless of their jurisdiction or geographical
location. These CapWIN end-users will include federal, state and local police, fire, and EMS vehicles
as well as state DOT service patrols.
A strategic plan was developed with input from transportation and public safety agencies (Federal,
State, Local) serving the Washington Metropolitan area to determine the following: functions needed,
system requirements, security requirements, information priorities, evaluation methodology, a multi-year
phased implementation strategy, and a long-term business plan that addressed ongoing operations and
maintenance. The strategic plan is available on the website.
Transportation agencies need information to plan and implement traffic control during major traffic
incidents. Transportation agencies also operate traffic control centers that collect information that could
57
be useful to responding agencies. Law enforcement agencies need current information to coordinate
alternate routes and rapidly changing traffic flow problems. The potential benefits of having agencies
communicate directly with each other via an integrated wireless network in the transportation arena are
as follows:
• Reduction in secondary crashes and associated deaths, injuries, and property damage
• Reduction in traffic delays
• Reduction in lost productivity
• Increased customer satisfaction
• Shared historical information between agencies
• “Real time” information to improve resource allocation
• Increased worker safety in construction zones
• Ability to expand network to cover other major highways (e.g., I-95 corridor)
• Improved response to natural and man-made disasters (hurricanes, floods, aircraft crashes, etc.)
• Increased transportation and public safety assistance to communities through increased
information.
Critical needs for information among law enforcement agencies in a mobile data environment are
focused around: vehicle registration checks, stolen/wanted vehicle checks, wanted persons checks,
driver information checks, stolen article checks, stolen gun checks, criminal case histories, conceal
handgun permits, sex offender registration files, and domestic violence orders files. This information is
useful, but it is outside the scope of the 1512 work. Future mobile data initiatives could include digital
mapping, suspect identification through remote fingerprint process and digital photographs. Using the
system, officers can make better and smarter decisions in approaching vehicles. Officers making traffic
stops are killed each year because the violator is wanted for serious crimes. Potential benefits of the
system are as follows:
• Increased Officer/Citizen safety.

• More time for police to be on the streets instead of the office doing “paper work”.
• More fugitives captured and taken off the streets.
• Better information to make critical decisions involving the safety of the public.
• More accurate reports and data.
• More effective and efficient police operation.
• Open technical architecture network that will accommodate additional software and hardware
needs in the future.
• Safer communities.
• Cost savings due to better use of personnel. (For example, the North Carolina Highway Patrol
reports that an average of twenty minutes can be saved using electronic forms on every collision
investigated. Officers can use the savings to do preventative patrols in high collision areas. This
time saved also translates to reduced incident duration and the associated benefits of reduced
delay and secondary incidents.)
• Increased ability to respond to a domestic terrorism situation (coordinated response).
• Increased current information for public safety and transportation personnel thru electronic on-
line procedures, policies, and laws.
• More effective and efficient multi-agency operations in addressing major events such as:
Presidential Inaugurals, state visits, major sporting events, celebrations.
58
Law enforcement agencies in the Washington area are meeting and discussing the concept of sharing
information. Several departments are using mobile data on stored platforms. These agencies are eager
to work together and better serve their citizens. Several agencies are currently working on a mobile data
networks. This project could be integrated into a regional system saving money for both the agencies
and CapWIN. Critical needs for information among fire and EMS agencies in a mobile data
environment are focused around the ability to coordinate response, protect the public from hazardous
materials, and improve patient care. In major incidents national databases with critical information is
needed to make life saving decisions. Information needs to be timely and available on scene so that fire
and EMS agencies can do their
jobs more effectively. EMS needs more reliable communications to Trauma Centers in life and death
situations.
Potential benefits of the system are as follows:
• Enhanced safety for public safety personnel and the public.

• On-Scene access to national databases with critical information on hazardous materials and
other related information.
• Better communications between on-scene units and Trauma Centers for more effective patient
care.
• A coordinated multi-agency response due to improved communication.
• Automated EMS and Fire field reporting.
The Maryland Board of Public Works unanimously approved the awarding of the CapWIN Systems
Integrator contract to the IBM Corporation. The project is ongoing.
For additional information on this case study, contact George Ake4. Additional information on this case
study can also be found at www.capwinproject.com.
The San Diego Regional AVL System
San Diego is in the process of acquiring a CAD system that is specific to the Freeway Service Patrol
(motorist assistance) and to the Caltrans Traffic Management Team vehicles (incident management).
This system is referred to as the San Diego Regional AVL system and is being supplied by Siemens ILG
as part of their ResponseMaster product family.
Both agencies will use a common Mobile Computer Terminal (MCT) that is a Panasonic laptop
(Toughbook), however, the MCT input processing is different in the FSP version than in the TMT
version. The FSP focuses on data that is gathered as part of motorist assistance stops (type of problem
encountered, location, action taken, etc.) whereas the TMT MCT has more of an incident management
data collection focus that closely parallels the incident data entered into the Caltrans ATMS system
(incident type, location, time, queue lengths, current sign board message, report logs, etc.). Both CHP
4
George Ake can be contacted at the Center for Advanced Transportation Technology. gake@wam.umd.efu.
59
and Caltrans Field Supervisors will also have the hardened MCT in their vehicles. Field supervisor
MCT's will be capable of displaying maps and real-time vehicle positions. The FSP's operate in
assigned beats on the freeway system whereas the TMT vehicles generally operate in response to
incidents.
Integration of this system into other TMC systems is planned for the future and will take different forms
because of the different institutional issues in Caltrans and CHP. The Caltrans integration will be to take
key ResponseMaster functions and move these to the ATMS operator workstation, thus reducing the
number of workstations required in the TMC. This is planned to be a part of the “Intermodal” ATMS
upgrade currently in advanced design stage in Caltrans District 11. This gives the TMC operator
another tool to supplement current ATMS incident management features by seeing the real-time position
of the TMT vehicle on the ATMS map. This feature will be useful for incident queue management since
the TMT vehicles are often used to protect the end of the queue. The CHP integration, on the other
hand, will be to exchange certain data elements between the ResponseMaster workstation and the CHP
CAD system while retaining the ResponseMaster workstation for FSP dispatchers. These differences
also reflect the difference in the way a TMC operates in incident management versus the way a public
safety CAD system works, even though the two systems in this case are co-located.
For additional information on this case study, contact Don Murphy5. For more information on the case
study, go to www.neiassociates.org/rcs.htm.
Using Various Combinations of the Standards
A TTX was held at an IMWG Meeting in Miami, Florida. A computer network was set up with
connections to the Internet. The Working Group participants utilized several unique, forward-thinking
tools to conduct the TTX. IMWG members developed unique capabilities and computer tools specially
designed to test the IEEE 1512 Family of Standards. These tools were utilized to develop a new
method of testing software standards.
The purpose of this TTX, like the other exercises, was to determine if the 1512 messaging adequately
conveyed the necessary communication. The participants reenacted the actions of various agencies
during an incident by using scenario scripts to determine if 1512 message sets covered the
communication that was called for in each particular incident situation. Ideally, the messages were to
come from a list provided by the 1512 Standards or even be entered as free text in a tightly defined
field. Improvements were made if a general message had to be entered as free text.
Each script was prepared based on an actual observed incident. The Working Group participants
followed the script using the message sets in the draft 1512 Standards. The messages were entered into
the “Message MakerTM” software, and those messages were sent to the other participants.
The messages the TTX participants used were analyzed and used to adjust the draft standards. These
incident scenarios were carefully and thoroughly covered by all of the participants acting as responding
agencies.
5
Don Murphy can be contacted at URS Corporation. don_Murphy@urscorp.com.
60
The results of this TTX were not just changes to the message sets. Getting the expertise of Public Safety
representatives into standards development was another benefit. The participants were also familiarized
with the 1512 Standards development. Finally, validating the standard on the results of simulated use is
the best way to test the standards for completeness.
61
Appendix C – Potential Implementation Guidelines
This Guide is not an implementation guide. An implementation guide must be developed based on local
needs, geographical issues, regional architecture as well as local agency relationships. This appendix
includes an approach to taking the next step towards implementation. This is not a full implementation
guideline, but it includes some of the issues to be considered before implementation.
Briefly harvest other interoperability guidance documentation to sketch out a generic skeletal approach
to developing interoperable systems (acknowledging a systems engineering process). Include typical
questions and considerations within each phase of the generic approach. For example (building on the
Systems Engineering Process Utilized for Standards Development on page 14):
A. Identify the geographic scope of your objective area of improvement.
• Decide if the targeted area for enhancement or review is the entire state, a specific region or just
a given highway corridor.
• Clarify what levels of government are to be included in which increment of analysis (state,
regional, county, municipal).
• Identify any relevant interjurisdictional entities that may have authority (e.g. regional planning
commission, state interoperability executive committee, etc.).
B. Inventory existing public safety and transportation management systems and centers
within the study area or review area.
• Utilize available information within regional and statewide ITS architectures.
• Recognize centers that may not currently have computerized capabilities.
• Consider mobile centers and command posts.
C. Analyze and document how field operations are coordinated inter-jurisdictionally between
public safety and transportation agencies under various routine operations and emergency
response scenarios.
• Utilize table top exercises involving command and field staff from appropriate public safety and
highway operations agencies.
• Interview representative groups of emergency response personnel from law enforcement, fire
and rescue, emergency medical service, emergency management, towing and recovery, highway
maintenance and operations, and public works agencies.
• Identify and highlight procedural as well as technological opportunities for improved emergency
response, traffic incident clearance, and traveler warning and information services.
62
• Be aware “concept of operations” and other systems engineering terminology, but do not be
constrained or confused by it.
D. Identify what relevant traffic flow, incident, and emergency response information is
collected by each agency. Also identify what information is needed but not available to
respective agencies.
• Apply the National ITS Architecture to structure the procedural approach, if the architecture
has not yet been applied within the study area.
• Include information that is collected or exchanged purely by voice communications.
• Recognize available or desired video images. These may include traffic condition and emergency
scene images, as well as maps, facility plans, weather-related images, and organizational and
command structures.
E. “Sketch plan” links between existing, pending, and planned transportation and public
safety management systems.
• Incorporate information flows that address available and needed information exchanges
between agencies.
• Clarify the prospective operational benefits of possible interagency links and information
exchanges. Consider reductions in emergency response time, avoided costs of redundant or
excessive emergency response, and costs saved by the potential for shared surveillance and
communications infrastructure.
• Recognize traveler and victim benefits from improved response, such as enhanced survivability
of crashes and other life-threatening health emergencies as well as avoided travel delay or
decreased probability of secondary crashes.
F. Clarify and document interagency consensus on which of the “sketch planned” links should
be incorporated into existing and planned systems.
• Develop appropriate levels of system architectures, and layers of automation and

communications systems designs.
• Define an implementation plan and corresponding institutional provisions (such as interagency

agreements and memoranda of understanding) to ensure incremental implementation of desired
systems.
G. Establish and maintain interagency project management team structures to maintain

commitment and coordination during coordinated system development or modification.
63
H. Test and evaluate the degree of interoperability, and the extent of information exchange
afforded by linked systems as they are implemented and integrated.
I. Continue routine joint training and table top exercises between agencies to assess systems
performance. Identify additional information exchange needs and opportunities for procedural
as well as technological enhancement.
64
Appendix D – Bibliography
Capital Wireless Integrated Network. 2000. CapWIN. 15 Oct. 2002

<http://www.capwinproject.com>.CAPWIN
Fehlberg, Jeff. San Diego InterCAD Fact Sheet. July 2000. Southern California ITS Priority Corridor.
15 Oct. 2002 <http://www.dot.ca.gov/hq/newtech/its/07-2000_Fact_Sheets/SDInterCAD07-00.pdf>.
Reference: Bruce Churchill and Pam Scanlon, 2002. “The San Diego InterCAD Project – A
Retrospective View.” 2002 Annual Meeting Proceedings, ITS America.
IEEE Std 1512-2000, IEEE Common Incident Management Message Sets for Use by Emergency
Management Centers.6
IEEE Std 1512.1-2003, IEEE Traffic Incident Management Message Sets for Use by Emergency
Management Centers.
IEEE Std 1512.2-2004, IEEE Public Safety Incident Management Message Sets for User by
Emergency Management Centers.
IEEE Std 1512.3-2002, IEEE Hazardous Material Incident Management Message Sets for Use by
Emergency Management Centers.
Integrated Incident Management Systems. 30 May 2001. Veridian Engineering. 15 Oct. 2002
<http://www.dot.state.ny.us/reg/r11/iims/>.
Justice Standards Registry for Information Sharing. U.S. Department of Justice. 15 Oct. 2002
<http://it.ojp.gov/jsr/public/index.jsp>.
National ITS Architecture. 18 June 2002. National ITS Architecture. 15 Oct. 2002
<http://itsarch.iteris.com/itsarch/>.
TESCNET Business Plan Overview. 26 Apr. 2001. 15 Oct. 2002

<http://www.tescnet.net/getpage.asp?PageApp=body&PageID=53>.
U.S. Code of Federal Regulations, Title 23, Sections 655 and 940.
6
IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331,
Piscataway, NJ 08855-1331, USA (http://standards.ieee.org/).
65
Appendix E – Web Site Information
AASHTO
http://www.aashto.org/aashto/home.nsf/FrontPage
ADUS Resource Page

http://www.itsa.org/resources.nsf/urls/adusr.html
APCO International Home Page

http://www.apcointl.org
CapWIN
www.capwinproject.com
Department of Justice Standards Registry

http://it.ojp.gov/jsr/public/index.jsp
Federal Highway Administration

http://www.fhwa.dot.gov/
IEEE Home Page

www.ieee.org
IEEE Standards Association

www.standards.ieee.org
IMWG
http://grouper.ieee.org/groups/scc32/imwg/index.html
Integrated Incident Management Systems (IIMS)

www.dot.state.ny.us/reg/r11/iims/
ITE
http://www.ite.org/
ITS
http://www.its.dot.gov/
ITS America
www.itsa.org
MONITOR
http://www.dot.state.wi.us/dtd/hdist2/monitor/index.htm
66
National ITS Architecture
http://itsarch.iteris.com/itsarch/
NENA
http://www.nena9-1-1.org/
NFIRS
http://www.nfirs.fema.gov/
NFPA
http://www.nfpa.org/catalog/home/index.asp
NTCIP
http://www.ntcip.org/
SAE
http://www.sae.org/servlets/index
San Diego Regional AVL System

http://www.neiassociates.org/rcs.htm
TESCNET
www.tescnet.net/getpage.asp?PageApp=body&PageID=53
67
Appendix F – Contact Information
The following individuals were involved in the development of this Guide.
Anita C. Ricketts Ann R. Lorscheider, P.E., Michael A. Ogden, P.E.

Manager, Business Programs P.T.O.E. Traffic/ITS Division
and Services Regional ITS Engineer Manager
IEEE Standards Metrolina Regional Klotz Associates, Inc.
445 Hoes Lane Transportation Management 1160 Dairy Ashford,
Piscataway, NJ 08854-1331 Center Suite 500
North Carolina Department of Houston, Texas 77079
a.ricketts@ieee.org
Transportation mike.ogden@klotz.com
732-562-3847
2327 Tipton Drive 281-589-7257
732-562-1571 281-589-7309 (fax)
Charlotte, NC 28206
alorscheider@dot.state.nc.us
Jennifer McClain Longman 704-342-6814 Katherine A. Mears, P.E.
Managing Editor Project Engineer
IEEE Standards Information Wayne L. Gisler, P.E. Klotz Associates, Inc.
and Industry Publishing Manager, Traffic Management 1160 Dairy Ashford,
445 Hoes Lane and Operations Section Suite 500
Piscataway, NJ 08854-1331 Houston TranStar Houston, Texas 77079
j.longman@ieee.org 6922 Old Katy Road katherine.mears@
732-562-6355 Houston, TX 77024 klotz.com
WGisler@eng.hctx.net 281-589-7257
732-562-1571 (fax)
713-881-3189 281-589-7309 (fax)
713-881-3171 (fax)
Althauser, Jerry
Maintenance/Operations
Superintendent of Traffic
Washington State Department
of Transportation
15700 Dayton Avenue North
Seattle, WA 98133-9710
206.440.4451
206.440.4804 (fax)
althaug@wsdot.wa.gov
68
Appendix G – Committee List
The roster below identifies the individuals affiliated with the process of developing the IEEE 1512 Family of
Standards.
Current Officers:
Ann R. Lorscheider, Chair (2001-Present)

Jerry Althauser, Vice-Chair (2001-Present)
Wayne L. Gisler, Secretary (1999-Present)
Past Officers:
Chester Chandler, Chair (2000-2001)

Ann R. Lorscheider, Vice-Chair (2000-2001)
Andy McFarlane, Vice-Chair (1998-2000)
Ken Brooke, Secretary (1997-1999)
Kamal Karma, Chair (1997)
Ake, George Franklin, Robert B. (Tip) Mark, Edward

Althauser, Jerry Gisler, Wayne L. McEwen, Harlin
Aufschneider, Kurt Gojanovich, Robert Miller, S. Robert
Barrett, Robert M. Granados, Sr., Michael Mona, James A.
Bounds, Marcellus (Marc) Helman, David Ogden, Michael A.
Brooke, Ken Ice, Ron Paxton, Clay
Burch, Ron Kelley, David Rajendra, Kunwar
Chandler, Chester H. Kurihara, Tom Ritchie, Michael
Churchill, Bruce Lake, David Roberts, Rich
Cope, David Lathrop, John Strickland, Bo
Corbin, John Lorscheider, Ann R. Walker, April
Einreinhofer, Paul A. Manuel, Charles Wilkins, Steve
69

Guide PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Guide PDF

Transféré par

Droits d'auteur :

Formats disponibles

Guide to the IEEE 1512™

Library of Congress Cataloging-in-Publication Data

Ogden, Michael A., 1963-

1. Emergency communication systems--United States--Standards. 2. Traffic

The Institute of Electrical and Electronics Engineers, Inc.

Copyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc.

Yvette Ho Sang, Manager, Standards Publishing

To order IEEE Press Publications, call 1-800-678-IEEE.

See other IEEE standards and standards-related product listings at:

Abbreviations and Acronyms........................................................................................................ viii

Executive Summary ..........................................................................................................................1

Chapter 1 Introduction .....................................................................................................................6

Chapter 2 Potential Issues Related to Information Sharing .............................................................9

Chapter 3 Overview of the IEEE 1512 Family of Standards ........................................................11

Chapter 4 IEEE Std 1512-2000 (Base Standard) ...........................................................................28

Chapter 5 IEEE Std 1512.1-2003 (Traffic Management) ..............................................................31

Chapter 6 IEEE Std 1512.2-2004 (Public Safety Standard) ..........................................................35

Chapter 7 IEEE Std 1512.3-2002 (HAZMAT Standard)...............................................................37

Chapter 8 IEEE Std 1512a-2002 (Emergency Management Data Dictionary)..............................40

Chapter 9 Case Study Implementations .........................................................................................42

Appendix A Message Set Tables ...................................................................................................43

Appendix B Case Study Implementations .....................................................................................51

Appendix C Potential Implementation Guidelines ........................................................................62

Appendix D Bibliography ..............................................................................................................65

Appendix E Web Site Information.................................................................................................66

Appendix F Contact Information ...................................................................................................68

Appendix G Committee List ..........................................................................................................69

AASHTO American Association of State Highway and Transportation Officials

Issues Related to Information Sharing

Overview of the IEEE 1512 Family of Standards

IEEE Std 1512a -2002, Emergency Management Data Dictionary (EMDD)

Development and Maintenance of the Standards

Case Study Implementation

Purpose of this Guide

History of the Standards

Scope of this Guide

Several suggestions were made for future integration efforts.

• A clear concept of operations should be defined prior to implementation.

• Establish a regional architecture and/or approach to information sharing and development

• Develop processes that utilize recognized systems engineering principles.

• Follow up with requirements-based engineering as a mechanism to develop consensus. (See 23

• Layer 1 – Physical interconnection

Figure 1 – OSI Layers

The Content of the Standards

• IEEE Std 1512a-2002, Emergency Management Data Dictionary (available electronically

The Need for the Standards

Levels of Implementation of the Standards

Systems Engineering Process Utilized for Standards Development

Table Top Exercises

IMWG Table Top Exercises

Relationships of 1512 Standards with Other Documents and Activities

Relationships to Other Standards Development Organizations

Public Safety (Justice, Homeland

Transportation Infrastructure (Devices such as DMS,

Figure 2 – 1512 Organizational Relationships

Relationships with Companion Volumes

In-Vehicle Systems 1512.4**

Incident Management Base Standard 1512

Figure 3 – Relationships with Companion Volumes

Relationships to the ITS National Architecture

Figure 4 – 1512 and the ITS Architecture

Relationship to Public Safety Interoperability

Relationship with Justice Standards Registry