National Institute for Urban Search and Rescue
Requirements Committee
August 28, 2000 Activity Status Report
Bobby Hartway, Chairman
bobby.hartway@tbe.com
Charter: Develop the XII Blueprint
Members:
Brian Morgan
morgan.bryan@HQ.NAVY.MIL
Robert Chartrand
rlchartrand@prodigy.net
Jeff Ribel
jribel@snap.org
The committee emphasis over the last few months has been to produce an XII Blueprint Development Plan for the
development and publication of the XII BLUEPRINT for Domestic Preparedness against Weapons of Mass
Destruction and Emerging Infectious Diseases. The XII Blueprint will be a systems requirements document useful
across all disciplines and at all levels of Government, Non-Government, Industry, and Academia during efforts to
develop and operationally integrate the combined systems comprising Domestic Preparedness. The Blueprint will be
based upon a total integrated systems engineering model of the Domestic Preparedness System. The committee is
presently defining a systems engineering methodology that will be used to construct the integrated model. An early
draft version of the systems model has been established and is briefly introduced here, but much work remains to be
done. NSF grant funding is being sought to support a fulltime effort to finish the system model and then use it to
develop and publish the complete XII Blueprint document.
This report describes the activities to plan the technical accomplishment of the XII Blueprint.
Efforts to acquire funding to 1) fully develop and publish the XII Blueprint and 2) use the Blueprint to develop and
build the XII Development Testbed are described in the NIUSR Grants and Contracts Committee report.
Efforts to prototype and publicly demonstrate the enabling technologies available to implement an XII are described
in the Technical Committee report.
This report follows a six step sequence as shown by the flowchart below.
(1)
(2)
(3)
DEFINE THE
DOMESTIC
PREPAREDNESS
SYSTEM
WHY ARE
REQUIREMENTS
NEEDED?
DEFINE A SYSTEMS
ENGINEERING
APPROACH
(4)
DESCRIBE THE
INTEGRATED
SYSTEM MODEL
(5)
(6)
DEFINE THE PLAN
TO PRODUCE THE
XII BLUEPRINT
DEFINE
THE XII BLUEPRINT
PRODUCT
(1) What isThe Domestic Preparedness System?
The purpose of constructing an overall model for the “Domestic Preparedness System” is to establish a common
system environment model because it helps establish the present and future boundaries of the system. It doesn’t
matter whether these boundaries are firm or fuzzy. What is most important is to show what could be involved in the
overall model, whether now or two decades in the future. The idea is to provide a basis for the big picture over the
long haul. This big picture can then be subdivided and annotated as to what is real and right now, and what is fuzzy
and somewhere in the future. The single most important purpose is to have an integrated whole picture that shows
what the system is and could be to support collaborative discussion and integrated planning .
Our conceptual system model shows that the Domestic Preparedness system is truly a system of systems, many of
which are not yet well defined, but which must one day be accounted for. What is most clear is that there are so
many different organizations and disciplines involved, and so many different missions. Many of these entities
respond differently to the same common “threat”, and some entities have a unique threat. The important concept is
that in the event of an “extreme crisis”, many of these entities will have to work together as a single integrated
operational system. Worse yet, each type of “extreme event” will likely require a different combination of entities to
properly respond. In other words, the Domestic Preparedness System is a system of systems that will individually be
required to very rapidly harmonize, synchronize and interoperate under unpredictable extreme situations. Sounds
like the military concept for global joint rapid response force doesn’t it? Sounds a lot like an oxymoron since joint
and rapid are mutually contradictory. This is precisely why we call the solution an “extreme information
infrastructure”. Simply put, the system must have the flexibility that while each system is optimized for their
specific and individual missions, they may be operationally and informationally reconfigured very rapidly so that
any authorized operational entity at any location can have access to the right information at the right time. It is clear
that at the present time, most of the entities of the “system” are not technically structured or jurisdictionally
chartered to operate effectively outside their traditionally defined mission area.
IDIN
International Centers
Country Centers around World
DoD
NSA
NOOA
DMA
AGRICULTURAL SAFETY MISSION
DoD
GEOSPATIAL MAPPING MISSION
OPEN SOURCE INTEL MISSION
DoD
CHEMICAL TERRORISM MISSION
TECHNOLOGICAL DISASTER MISSION
DOT
NUCLEAR RADIOLOGICAL MISSION
FEMA
Regional Centers in a Country
BIOLOGICAL TERRORISM MISSION
DHHS
NATURAL DISASTER MISSION
PUBLIC HEALTH MISSION
NDINs
RESEARCH SENSOR-DATA MISSION
GDINs
Disaster Mission
Specialty Areas
Just a FEW Examples
of U.S. Agencies or
Groups
DOA
DOE
(2) Why are Requirements Needed?
The large Federal budgets established to address the problems associated with the threats of Domestic Terrorism and
Emerging Infectious Diseases were created in an attempt to quickly implement programs to counter and diminish
these threats. These funds were released in advance of any requirements other than vague references to the ominous
TOP-DOWN
VIEW
Interpret What Needs to Be Done
GOVT
PROCESS
REQUIREMENTS
BASELINE
SCENARIOS
THREATS
(Idealistic Concepts)
(Validation Tests)
Funded Things get Built Here
TARGETS
Demonstrate
Solutions
through
EXERCISES (2)
REQUIRED
!!
$$ FUNDING
AVAILABLE
(Profitable Products)
RESPONSE
Interpret What Can Be Done
PROVIDERS
PROCESS
Solutions
(1)
meet Funding
SOLUTIONS
AVAILABLE
BOTTOM-UP
VIEW
dangers presented by the collective threats. The legislation authorizing the funding left it up to committees, working
groups, and individual government departments and agencies to determine how best to allocate the funding. The
GAO has issued several reports on the lack of sufficient overall coordination and the complete lack of requirements.
The only mechanism to date set up by the Federal Government to establish an integrated set of requirements is
several multi-agency committees and working groups. There is inadequate central authority to manage the
committee and working group activities to any common goal. This means the implementation process for a
Domestic Preparedness System is “Here is Money, Bring Solutions”. Presumably, after enough of this process takes
place, the resulting individual solutions can somehow be integrated into a cohesive, operationally integrated system.
This has never worked in the past, and isn’t likely to work this time. What will have to be done is to work out the
integrated system requirements in parallel with the multiple implementation activities now going on, in the hope that
when a system vision is finally acquired, the aggregated solutions can somehow be fused into an operational whole.
This simply means a lot of retrofitting. But this will not be successful without a master integrated operational plan. It
is difficult to imagine how a single integrated operational picture could be established without a total system
requirements definition. It is difficult to see how a total integrated system requirements definition could be
established without a total integrated system model. It is inconceivable how a total integrated system model could be
established without using a systems engineering process. It is unlikely that an objective total view systems
engineering process could come from some jurisdictional player from “inside” the system. It is therefore easy to see
the very important role for the non-profit, multi-jurisdictional body of the NIUSR membership. This is the exact
purpose for the NIUSR Requirements committee effort to develop a plan to produce the missing and critically
needed systems model and XII Blueprint for the Domestic Preparedness System.
(3) What is a Systems Engineering Methodology?
A systems engineering methodology is nothing more than a process that breaks a large complex system into enough
smaller pieces that the system components and their individual interactions can be sufficiently defined to provide a
single integrated operational model of the system.
INCIDENT OPERATIONAL COORDINATION
INDUSTRY
PRIVATE
MULTIJURIDICTIONAL
COORDINATION AT
EVERY LEVEL
NON-GOVT
GOVT
Incident operational coordination is
different for every type of scenario
and for each operational phase of a
scenario
TYPES OF SCENARIOS
COORDINATION
Multiple
Agencies At
One Level
NATURAL
DISASTER
EXPLOSIVE
ATTACK
SYSTEM
LEVELS
SPILL
Command
Coordination
CHEMICAL
ATTACK
(KNOB)
ANTHRAX
ATTACK
PLAGUE
ATTACK
911
Responder
Coordination
SCENARIO “HEAT”
INCIDENT OPERATIONAL PHASES
Prevent
Plan
Prepare
Respond
Recover
Rebuild
The process can be described as one of developing and defining all the different viewpoints one can take in looking
at a system and its operations. For example top-down versus bottom-up. Every system has hierarchical levels,
breadth and depth. Every system has distinct operations types and operational phases. By defining the various
dimensions of a system, it is easier to focus any given discussion on characteristics of a model because there are now
common viewpoints that can be shared.
The best way to visualize the system dimensions is to think of them as VIEWPOINTS of an exercise game
participant. The viewpoints vary depending upon the hierarchical system LEVELs; (1)at the top are strategic policy,
strategic planning, strategic operations C2, (2) in the middle are tactical planning, tactical operations C2, tactical
logistics/dispatch, and (3)at the bottom are field operations C2 or incident command, and field response actions.
Coordination, interoperable communications, security/authority verification, and decision-support information are
needed at every one of these levels, but they each look a little different at each level.
These of course are exactly the same levels we have always had in military systems. Professionals in the C4I
business already know that there are tight parallels between military C4I and emergency management C4I. But one
VERY important difference in emergency management that NIUSR adds is that COORDINATION adds a fifth C to
make emergency management a C5I. This is because in combined operations in military systems, you have a rigid
hierarchy of authority, whereas in emergency management combined operations you have a lot of "organizational
anarchy" that requires coordination. So C5I is used to clarify the distinction between the usual military view and the
emergency management view. On top of the difficulty of organizational anarchy coordination, you add the
requirement for INTEROPERABILITY of multi-jurisdictional communications needed to make this already difficult
coordination possible. Again, this is more difficult than combined operations interoperabilty in the military, because
in C5I you are dealing with multi-jurisdictional, anarchical organizations.
Now, you add on the terrible condition that, oh, by the way, you will lose most of your normal communication links
and networks during the disaster, so you will have to have backups. So you must make sure your C5I
communications must be accessible and reliable during the disaster.
C5I
Government Infrastructure
Emergency Management
C4I
Industry Management
C4I
C4I
Int’l Agencies
GDIN/NDIN
INDUSTRY
Federal EOCs
Federal Agencies
Chemical
Nuclear
 Energy
 Transportation


State Agencies
State EOC
County Agencies
County EOC
911 Operations
Municipal Agencies
Industrial
911 call EOC
911 call
911 CAD
Response
Response
Teams/Cmd
Teams/Cmd
Incident
Scene
Local Care
Facilities
Response / Aid
Response
Teams/Cm
d
Unified Cmd
Combined
On-Site Response Teams
THREAT
Victims & Worried Well
(UNKNOWN
Concerned Public, Officials, and Media
Finally, you add on security and authority certification across all levels and all jurisdictions in your organizational
anarchy. And now you have the basic requirements for a C5I extreme information infrastructure (XII) system!
But don't stop here. Add a new level to the hierarchy of levels from top to bottom. Add a level below the bottom C5I
(tactical field operations) level. This new bottom level is the population or public level. If the C5I system is the
management system, the public is what's being managed. The public includes the victims, worried well, bystanders,
and public at large, as well as the media folks everywhere and in everyone's face. We call this viewpoint "inside-out
vs. outside-in". Inside-out is the view of C5I towards the situation and the victims, public, media. Outside-in is the
view of the victims, public, and media towards C5I. This may sound trivial, but you will be surprised how it, in
addition to the other levels/views, helps divide the Essential Elements of Information into more logical groupings.
So, there you pretty much have how to use a systems approach to visualize disaster/emergency management as a
"system", and how to break up the requirements into different segments or pieces or viewpoints, in order to tackle
them one at a time and keep them organized.
The final trick is to realize that this "system" looks different FOR EACH TYPE of disaster. It especially looks
different for scenarios requiring extensive medical facility use and medical care providers and specialized
medicines, as you have for bioterrorist events. Then, when you add in a contagious bioagent, it goes beyond our
present ability to control. But there is hope through modeling, planning, exercise, and coordination.
There are ENORMOUS differences in how you handle the scenario management depending upon the type of threat
agent. Contagious scenarios create very stressing time-factors and containment-control factors. You can liken this to
stopping a nuclear chain reaction and trying to contain the radiation. If you don't do the right thing very quickly and
correctly, it's all over, and irreversable. This is exactly why a plague or smallpox type scenario stresses any
emergency management system. But staying with the analogy, a nuclear reactor doesn't stress out professionals in
the nuclear energy business because they have completely modeled it, know exactly how to manage it, and have a
lot of continuous practice. (Of course, accidents can still happen, but they try to model and practice those too!).
It will thus be helpful to define an intensity scale to the scenarios. You can define a continuum or scale to the level
of scenarios, something like a knob or rheostat you could use to turn up "scenario HEAT". Everyday 911 type
emergencies at the lowest setting, then on to large scale natural disasters (like FEMA does all the time) about a third
up, to terrorist events using chemical agents (like sarin) higher yet, to terrorist events using bio-agents like Anthrax
(infectious) even higher yet (maybe two-thirds), and then to extreme terrorist events like Plague (highly contagious)
very high up (maybe nine-tenths), and finally, over the top (100+) would be combined extreme events, such as
warfare-type combined chem-bio events (yes, some are talking about this) or a really really nasty natural bug like we
had in the 1918 flu pandemic.
What is very interesting about this knob, is that you invoke different TYPES of response as you turn it up. For
example, just because you can handle a very large natural disaster (FEMA type) doesn't mean you can handle even a
small chemical terrorist event - - because you cross the boundary of the TYPE of response required! Most obvious is
that Firemen, Policemen, HAZMAT, and EMS techs are not going to be the medical responders for biological
disease agents, but they all DO need to be protected for their OWN safety against such agents.
When you train these first responders how to protect themselves and coordinate on-scene responses, you have only
addressed one-half of the equation. The other half, which is causing all the recent exercise failures, is when you
bring in the part about medical care facilities where all these victims end up. They are simply unprepared and
haven't been much involved so far in the big "WMD" movement. Most exercises can't bring in the public health and
medical care facilities as players simply because there usually is no way to "network" with them! Most state and
local public health systems don't have much networking at all (some small local ones don't even have web access).
Most hospitals, clinics, and other care providers each do their own thing. TOPOFF 2000 in Denver proved this out
as being a real big problem area, but everyone is having a lot of trouble figuring out how you fix the problem,
because there is no one in charge of the loose collection of health and medical care jurisdictions and institutions. The
Public Health Service community is only just now getting slightly increased funding, and help from CDC, but the
have a long ways to go. Each local area medical care faciltiy is necessarily motivated by the bottom line more than
the common cause (unless someone pays them).
The point is that if you turn the scenario knob up just one little notch past chemical terrorism, you go into a whole
new world or required response types. A small area Anthrax attack turns the knob just a crack into this new area, and
a larger wide-scale anthrax attack immediately takes you into another dimension of response altogether, namely the
medical facilities and health care side. When you add contagious bio-agents (natural or terrorist), the response
requirements go critical.
There you have it. The basic components of a systems approach for modeling the Domestic Preparedness System.
You have the scenario rheostat, the system levels, the system views, the coordination, the communications, the
security/authority certification, and finally all of these versus different types of disaster scenarios.
(4) What is a Total Integrated Systems Engineering Model ?
A total integrated system model is the descriptive system model resulting from using the system engineering
methodology and viewpoints described above. The advantage of a single integrated system model is that the
individual components may then be worked in parallel, in any order, with assurance they will correctly interface as a
single cohesive whole when put back together. This is obviously exactly what is needed for the Domestic
Preparedness System. The trick of course is to first have a good description of what the system is. In absence of this,
and if starting with an existing system or aggregate pieces that are to be made a system, the system must be
synthesized from information gained by reverse engineering. This can be done by aggregating the existing parts,
looking at their individual requirements, determining their interfaces, and then reverse engineering any translators as
needed to make them mutually interoperable. This is exactly the situation with the Domestic Preparedness System.
The individual component parts are individually known, but not described anywhere in sufficient detail that a
composite picture may be painted. The trick here is to construct a generic system model that allows placeholders for
all the existing pieces to plug in when information is gained on each. When sufficient information on all the pieces is
acquired, the multiple interfaces may be investigated and specified. Translators, retrofits, or re-engineering efforts
may then be identified and undertaken.
The draft concept for the NIUSR System Model for the U.S. Domestic Preparedness System shows the basic
structure for beginning the system modeling process just described. You can see it has most of the basic dimensions
discussed above in the systems engineering approach. There are many many details to be added for each of the
simple components shown, but the basic structure is there to support collaborative discussion. Closer inspection will
reveal that this model shows system features from only a single jurisdictional viewpoint. A “depth” must be added to
each entity to account for the jurisdictional divisions of Government, Non-Government, Private, and Industry.
You must also realize that every single arrow in the system model diagram indicates an information interface. Each
of these interfaces implies a network connection, a message protocol, a data format, and of course a scenario context
for when each type of data should be available or broadcast, and who is authorized to handle that information.
(5) How will the XII Blueprint be produced?
The Requirements Committee blueprint development process is a bottom-up process. It starts with taking a fresh
modeling look at the entire integrated system concept of crisis and consequence management for the Domestic
Preparedness System. It will go further than most other models by considering interfaces with the total Health Care
System from top to bottom in addition to the usual “WMD” entities and interfaces. In addition to better supporting
bioterrorism scenarios, this newer part of the model will address the recent concern for Emerging Infectious
Diseases (EID). This new part of the model is crucial to Bioterrorism scenarios, which become delayed response
medical problems. The model also considers interfaces with the Global Disaster Information Network (GDIN)
program, and DoD’s renewed interests in Operations Other Than War (OOTW) programs. The product resulting
from employing this bottom-up process will be a documented system architecture description, the XII Blueprint.
Preliminary work on this document serves as a base reference for NIUSR projects for any specifically targeted
funding area
Bottom-Up Process used
to Develop XII Blueprint
The XII BLUEPRINT is
based upon a NIUSR Developed System Model for
Domestic Preparedness
DEFINE
XII DEVELOPMENT /
IMPLEMENTATION
PLAN
DEVELOP ,
DOCUMENT,
AND APPLY
SYSTEMS
ENGINEERING
APPROACH
C5I
C
4
I
Incident
Scene
(UNKNO
WN)
Govt + Emergency
Management
Community users
NIUSR
users
THREAT
SYSTEM
MODEL
XII
BLUEPRINT
DOCUMENT
DEFINE
XII SYSTEM
BLUEPRINT
REQUIREMENTS
Sponsor $$
DEFINE
XII SYSTEM
USER NEEDS
(Uphill Climb)
REQUIREMENTS
COMMITTEE
PROCESS
(6) Exactly what is the XII Blueprint?
The XII Blueprint comprises the technical and operational requirements for an evolving and totally integrated XII
System that will fully support the Domestic Preparedness System. It defines XII functional system components and
their operational and technical interfaces at each operational level in the system and for each operational phase of an
extreme event. The Blueprint will serve as a “living documentation” of evolving XII System Description and System
Requirements. It will be a funded extension of work now being done in the XII Requirements Committee by
volunteers.
The XII Blueprint will be the system requirements for the NIUSR project to implement the XII Development
Testbed. The XII Development Testbed will be a stand-alone installation of an operational software suite and
equipment set comprising an XII development system in some customer/sponsor specified location. This equipment
set will not have to be tied to any specific facility – it would in fact be “transportable”. The equipment set
development will be a funded extension of the volunteer work now being done to produce the periodic XII Games
Demonstrations, such as the present “When Disaster Strikes” tabletop game and workshop being held here now in
Las Vegas. The basic testbed would be software configurable to function as an operational center model for any
jurisdictional entity at any level in the Domestic Preparedness System.
Conclusion
1) A plan has been established that will provide a structure to produce the XII BLUEPRINT.
2) The initial development of a Domestic Preparedness System Model has begun. It is being used as the basis to
develop the Implementation Plans for the XII BLUEPRINT document and the XII DEVELOPMENT
TESTBED.
3) We hope to be able to make available through the NIUSR website the draft material of both the Domestic
Preparedness System Model and the Systems Engineering approach used to develop it. The free availability of
this material should encourage better participation and collaboration among NIUSR membership by serving as a
common roadmap or point of reference. (Remember that NIUSR membership is a multi-disciplined, multijurisdictional group representing all sides of Domestic Preparedness – Government, Non-Government, Industry,
and Academia.)
4) This draft material will be useful to the Grants and Contracts Committee in support of the effort to capture
funding for full development of the XII BLUEPRINT document and the XII DEVELOPMENT TESTBED.
5) We need more membership participation in this critical activity, and anyone interested is encouraged to join the
effort.