Edited Version of September 6, 2000 Transcript
EIIP Virtual Forum Presentation
"Islands in the (Emergency Data) Stream -- Planning for Interoperability"
Scott Eyestone
Consequence Management Interoperability Services
Amy Sebring - Moderator
EIIP Technical Projects Coordinator
The original unedited transcript of the September 6, 2000 online Virtual Library presentation is available in the EIIP Virtual Library Archives (http://www.emforum.org/vlibrary/livechat.htm). The following version of the transcript has been edited for easier reading and comprehension. Typos were corrected, date/time/names attributed by the software to each input were deleted but the content of questions and responses are as stated by each participant. Answers to participants’ questions are grouped beneath the appropriate question to facilitate meaning.
[Opening / Introduction]
Amy Sebring: Welcome to the EIIP Virtual Forum!
Our topic today is a new program by a new EIIP partner, Consequence Management Interoperability Services (CMIS). Our session is entitled, "Islands in the (Emergency Data) Stream -- Planning for Interoperability." We are pleased to welcome Mr. Dick Munnikhuysen, leader of the project team, who will introduce our topic and our featured presenter. Please see the background page for biographical sketches. On behalf of EIIP and all our participants today, welcome and thank you for taking the time to be with us today. Dick, I turn the floor over to you.
Dick Munnikhuysen: I want to thank EIIP for inviting Consequence Management Interoperability Services to today's Virtual Forum. In a moment, Dr. Scott Eyestone, who leads our Functional Analysis Group, will present an overview of this program. Participants in the EIIP are true stakeholders in Consequence Management Interoperability Services. Active involvement of stakeholders is very important to this program, and especially so during September. We will soon host an online survey to establish stakeholders' priorities. Scott?
Scott Eyestone: Thanks, Dick, and thank you all for joining today's session. Let me introduce some key members of the CMI-Services support team. They will help me during the feedback portion of this session. Joining me from the Functional Analysis Group are Steve Keegstra, experienced in GIS, and Roger Fritzel, our team's Point of Contact with EIIP. And from our Design Group we have David Gilliam, a senior programmer; and Cathy Meconnahey, lead requirements analyst.
Let's dive into the presentation - here is our topic outline.
[SLIDE 1]
We are delighted to be a new member of EIIP. This is exactly the kind of forum we need to reach out to you, the stakeholders of CMI-Services. We hope today's presentation will prompt you to become involved. CMI-Services must satisfy your needs. We need to hear what they are and their relative priorities.
[SLIDE 2]
The problem is that few, if any, of the automated systems can "talk" to each other. Your colleagues, through such influential bodies as the InterAgency Board, have convinced Congress of the need for "horizontal" interoperability among the various systems at a given level, and "vertical" interoperability among the systems supporting the various levels of responders. Currently, there are just multiple islands (of capability) in the stream.
[SLIDE 3]
In response, Congress has funded the Consequence Management Interoperability Infrastructure initiative. This effort is to employ modern technologies to allow diverse automated systems to "talk" among themselves despite differences in platforms, operating systems, languages, and data. There are now distributed object computing technologies that can be assembled into a single interoperability infrastructure to bridge across system differences. This means that systems can "talk" with several other systems while maintaining only one interface to the "middleware."
[SLIDE 4]
Hopefully, the "what" provides insight into the "why." Traditional point-to-point interface approaches rapidly became unaffordable and unmanageable. A change to any system or interface propagated costly, time-consuming software changes throughout the integrated group of systems.
[SLIDE 5]
The modern middleware approach is now being adopted by many Fortune 500 companies and the U.S. Department of Defense (the Global Command and Control System, for example) because of time and money savings realized in the maintenance phase of the lifecycle.
[SLIDE 6]
So, we (CMI-Services) are in the glue / house wiring / community plumbing business (pick whichever analogy you like). We are NOT the parts / lamps and appliances / water plant and faucet business. We aren't building new systems; we're building the middleware that will allow those systems to work together. And speaking of "we," who are we, you may ask. The following slide will provide some insight into the emerging CMI-Services team. Please note that the CMI Services program manager is advised by both the InterAgency Board, a standing national standards body of responders, and the Executive Interoperability Council (EIOC). The EIOC will be made of executive level leaders such as Dr. Jack Harrald, Lt. Gen. (Ret.) Jim Clapper, George Foresman (Virginia State Department of Emergency Management), and several others.
[SLIDE 7]
But most importantly, as the Pogo comic strip character once said, "We is YOU." You, the body of response stakeholders, are the most important element of the CMI-Services team. So far, we have interviewed first responders in these municipalities.
[SLIDE 8]
And Second Responders in these agencies to learn about needs and priorities.
[SLIDE 9]
We have received a very large number of "raw" functional requirements from the interviews that we have "boiled down" to roughly 40 distinct functions. Our online survey, to be available on our web site next week, will ask the responder community to vote on priorities of those functions. For example, "tailorable" Situation / Status reporting templates are a frequently requested function within the general area we call Tactical Information Exchange. Agent Identification is a popular item in the general area of Expert Reference. Geospatial Information System (GIS) capabilities are commonly desired functions in our general category called Tools.
The "where" topic is easy. The Government's executive agent for CMI-Services implementation, the U.S. Marine Corps Systems Command, is at Quantico, Virginia. The support team is nearby in Stafford, Virginia. Stakeholders throughout the United States and its territories will use the CMI-Services infrastructure. The "when" is over the last 4 months and into the near future. We have been fully engaged in learning about stakeholder needs and priorities and collecting information on all the automation and communication resources that could / should be brought to bear. The "first wave" of requirements is in hand.
We would like to show some early prototype interoperations / common services by spring of 2001. Therefore, now is the time to 1) discuss details about the requirements and 2) hear about relative priorities within the first set of requirements. To those ends, we ask that you visit our Web site at <http://www.cmi-services.org> very soon. You will find much more information about CMI-Services there. You will also find "Threaded Discussions" under the Message Boards button. Please, please, please join in existing discussions and start new ones! We must continue to hear "wants, needs, and desires of the user community".
For example, we currently have a discussion on "on-scene computing." As we interviewed first responders around the country, we heard a full range of views. We would like a sense of the dominant view so we can best focus our limited resources. If very few communities are interested in on-scene computing (ever), we would do better to focus on Department and Emergency Operations Center level (and above) automation support. "Please speak your minds!" Our municipality and agency interviews were great, but we need to hear from even more people. This is the place to sound off, while being respectful of differing views.
At its (July) quarterly meeting in Seattle, the Interagency Board concurred in our recommendation to proceed with the development of capabilities in three general areas:
1) Tactical Information Exchange, 2) Expert Reference, and 3) Tools. Numerous functional requirements have been identified in each of these areas. Each requirement must be precisely defined, and its priority determined, because we cannot undertake simultaneous development of all requirements.
We now need to obtain Stakeholder "votes" on the relative priority of the first set of functional requirements. Beginning on or about September 15th, stakeholders can make an immense contribution to CMI-Services' efforts by participating in the Functional Requirements Priority online survey.
All this brings us back to today's bottom lines - again.
[SLIDE 10]
That concludes our presentation today. We would be pleased to take questions from our EIIP colleagues at this time.
[Audience Questions & Answers]
Amy Sebring: Thank you for that overview, Scott. We can get into some more detail during Q&A.
Question:
Ryc Lyden: How were the first cities chosen for responder interviews?
Scott Eyestone: Guidance from our client was "do 2 large, 2 medium, and 2 small". From there we tried for geographic and "expertise/experience" (e.g. recent TOP OFF) coverage.
Question:
Ed Pearce: I'm from the private sector. You mentioned Industry as a stakeholder. How is the private sector to be included?
Scott Eyestone: The InterAgency Board provides an in-road to the private sector. Beyond that, we seek your participation in the threaded discussions.
Question:
Ron Gloshen: Scott, you mentioned the three areas of concentration at your July meeting. By the way, we appreciated meeting with your organization here in Salt Lake City. How does the three services differ from the concept on FEMA's home page. They have a password secured and unsecured area. Is this a duplication?
Scott Eyestone: CMI Services is middleware - interoperability infrastructure - that connects the response community to information resources from multiple sources. We don't see this as a duplication of FEMA resources.
Question:
Donald Ponikvar: Will the IAB's Standardized Equipment List be made available to industry? It is presently restricted distribution.
Scott Eyestone: Our discussions with IAB co-chairs indicate that last year's SEL will be made available to the public on the IAB Web site later this year.
Question:
Christopher Effgen: Has the approach of creating a standard system or standards for systems to attain digital interoperability been looked at?
Scott Eyestone: Yes. Our standardization focus is at INTERFACES. We know standardization of platforms, operating systems, et al, is not feasible.
Question:
Amy Sebring: Scott, you mentioned GIS and Christopher just mentioned standards. Do you see the efforts of the Open GIS Consortium being a possible solution in this area?
Scott Eyestone: Over the longer term, yes. For the near term CMI Services will attempt to provide a "GIS information viewer" sort of like the Adobe Acrobat Reader concept.
Question:
Donald Ponikvar: Are you familiar with CapWIN, a new project in VA, MD, and DC which is designing and building a wireless network for First response organizations in those jurisdictions? It is co-funded by VDOT, MD State Hwy Safety Admin, and NIJ. Project Manager sits at the University of MD, but they are about to release a formal RFP, possibly in late September early October.
Scott Eyestone: Have not heard of that one. However, CMI Service focus for now tends toward EOC/DOC and higher info sharing. Having said that, we are looking at "forward computing" in an active threaded discussion right now.
Comment:
Christopher Effgen: The problem with your approach, it seems to me, is that it requires an unlimited number of interfaces to allow for interoperability, rather than the establishment of a standard for systems to comply with. It also assumes that all stakeholders will acquire their own systems rather than be provided with a standard system.
Scott Eyestone: Actually, it is only one interface per resource. The one to the central CMI Services "backbone." The overall architecture borrows from the CORBA concept. Definitely not multiple custom "point-to-point" interfaces.
Comment:
Guest24: Many local emergency response organizations are using Cerulian wireless technology-Aether Systems.
Scott Eyestone: Many local organizations are using Cerulian. This is part of our "forward computing" deliberations that we will attack depending on stakeholder demand.
Questions:
Avagene Moore: Two questions, Scott. 1) Many efforts have surveyed for user needs and requirements - GDIN for example; have you consulted their results? 2) Are you working with groups such as IAEM, NEMA, DERA, XII (NI/USR) to get input to your survey and to benefit from work that has already been done?
Scott Eyestone: Have not compared to GDIN yet but want to. Have compared to DOJ's and found ours/theirs to be congruent. We are meeting with GDIN reps this Friday. With respect to Question 2, we are meeting with NI/USR XII colleagues next week. So many players, so little time.
Question:
Alan Choutka: EDI uses standardized transaction formats - is this the type of data interchange standard that is being proposed here?
Scott Eyestone: David, could you jump in here please?
David Gilliam: No. We really are not talking about standard transaction; rather, we are looking at standard interfaces. For now we think we will rely heavily on enterprise Java Beans and XML.
Question:
David Crews: Are redundancy, supportability and survivability issues for the information and communication interfaces being considered as well as interoperability? Single node connections are vulnerable to disruptions and loss of capability.
Scott Eyestone: Absolutely, given the caveat that all want to play via Plain Old Telephone System (POTS) . We are prototyping data persistence features now, so that the operator will have use of his last data update, even if there is a break in communications.
Question:
Christopher Effgen: I understand that it allows for interoperability based of the interface model. However, in a large-scale disaster that may mean the inputs of hundreds of individual feeds into the standard interface. Why not at this early time attempt to establish basis standards? Most jurisdictions don't have the kind of systems that we are talking about.
Scott Eyestone: Not sure we understand the questions. Can you clarify?
Question:
Christopher Effgen: What we are writing about here is the construction of a system to digitally process the disaster message. Digital means afford us with technical capacities that we are just now beginning to understand. It is possible to construct standards and standard systems (programs) for the transmission and processing of that message. What you are doing is cutting down the number of programs required by using the interface model. Why not cut down the number of required interfaces even more by creating a standard and inter-operable program(s) that could be made available to jurisdictions?
Scott Eyestone: We are not in a position to mandate compliance or use of specific systems or standards. Therefore, our SERVICE will provide the ability to accommodate multiple systems (your favorites) using multiple standards. That's the power of "standardizing on the interface."
Question:
Amy Sebring: Will other factors weigh into priorities in addition to stated User Needs, for example, some areas may be easier candidates for implementation than others?
Scott Eyestone: Yes. Our client and advisory bodies have told us to "get some successes out there". Then take on the more complicated functions/features.
Question:
Amy Sebring: Guest 24 has a question about how you will handle system security. Raptor firewall, anti virus? A related question would be system access?
Scott Eyestone: Access will be controlled by UserID/password and a "user profile." The initial release will not deal with classified information.
Question:
Guest24: How about code key encryption? The Feds are supposed to have access via code key.
Scott Eyestone: PKI is under investigation by our technical staff at this time.
Question:
David Crews: Re: Large volumes of information during disaster events. Is there a plan to limit information overload in disaster responses? For large disasters, information will have to be analyzed and distilled for the absolute essential information, especially at the top of the leadership pyramid where overall decisions are made.
Scott Eyestone: Good point, David. The community must be its own "traffic cop." Our architecture will be able to handle the load.
[Closing]
Amy Sebring: We will have to end there I am afraid. Thank you very much for being with us today to Scott and all the project team members. We very much appreciate your time and effort. Please stand by a moment while we take care of some business. Today's session will be accessible via the Transcripts link on our home page on Monday, including links to the slides. The text version will be up later today.
Scott Eyestone: And thanks to you all. Please visit us and jump into the threaded discussions.
Amy Sebring: We have a couple of announcements about pledges. We have a new pledge from Monty Gearhart, who helps make the Virtual Forum possible with server support <//bell http://www.emforum.org/pledge.wav>. Thanks Monty! We also have a pledger who has completed 12 months of pledges during August. Our congratulations go to Gilbert Gibbs. Way to go Gilbert! Avagene, can you tell us about next week please?
Avagene Moore: Yes, Amy. I want to express my appreciation to Scott, Richard and other CMIS folks online with us today. Good discussion!
Next week, Wednesday September 13, 12:00 Noon EDT, we will meet in the EIIP Virtual Library. Kirstin Dow, Ph.D., will share findings from her research on "South Carolina's Response to Hurricane Floyd." Kirstin currently works in the Hazards Research Lab of the University of South Carolina. Watch for the background page on this session and read the research paper prior to the online discussion. Fascinating study! Make your plans to be with us next week. That's all for now, Amy. Back to you.
Amy Sebring: Thanks to all our participants today. We will adjourn the session for now, but you are welcome to remain for open discussion. You no longer need to use question marks. Please help us express our appreciation to Scott and the rest of the team for today's presentation.