OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [emergency] Proposal for Presentation atOASIS Symposium 2007


Here is the paper thus far with much use of existing material in the TC.

Is there anyone else out there on a fine Friday night?

The text below is formatted in the Word file attached.

- Michelle


Continuing through Emergency: eBiz/eGov Continuity and Contingency
functioning throughout emergency incidents

Brief Description


Emergency Incidents of any size or source have the capacity to disrupt
business, government and 'life' as usual.

Increasing reliance on electronic information exchange may impact the
level of disruption. However, well managed information exchange during
an incident may also provide business, government and other
organizational structures means for direct involvement in mitigation
of the incident and its aftershock. In some cases it may even enable
specialized operational functions that can bring continued
productivity, alternate revenue and positive publicity for the
participating entities.

Keys to success include:
 - data access during an incident,
 - information sharing expedited by data format and vocabulary
standards within   organizational silos,
 - resource registries,
 - common model and protocol structure for information exchange and
integration into incident response systems,
 - and other applicable Service Oriented Architecture (SOA) practices.





Position Paper



Problem Statement



[Around the world], government agencies, non-governmental
organizations and private sector emergency management offices use a
wide array of software platforms for managing data about emergency
conditions, resources and response activities. Most of these are
stand-alone systems with limited capability for data sharing with
other agencies or other levels of government.[1]



During an emergency it is generally believed that it is desirable to
keep 'business-as-usual', particularly in regions and
business/government sectors not directly impacted by the emergency.  A
lot of the recent and emerging information technologies aid in keeping
things running.



We suggest that these information technologies can also play a role in
emergency incident mitigation by opening up more information to the
emergency responders from nontraditional sources, make emergency
alerting available to organizations beyond emergency responders and to
aid businesses and organizations in the management of just-in-time
resource provisioning.



1. Emergency Management interoperability leveraging and support

of eBiz/eGov practices



Advances in information technology have paralleled the movement toward
more integrated approaches to emergency management. In particular, the
emergence of service-oriented architectures has created new
opportunities for interoperability among diverse emergency information
systems utilizing existing industry-standard technologies. At the same
time, other data communication facilities, such as digital television
and radio broadcasting, are being brought to bear on the challenges of
emergency information exchange.1

Application of these technologies to the emergency management domain
requires the design and refinement of new standards for data
structures and message-exchange processes. [The Emergency Management]
Technical Committee [continues to] design, develop, and release
XML-based standards that provide a framework for interoperability
among diverse emergency information systems.1



The standard information format and exchange policies are aligned with
the information needs for enabling quick, effective emergency
mitigation. These requirements were expressed by emergency management
and response professionals and regulatory agencies.  The standards are
designed to meet the emergency responders' need for interoperability
and policy enablement.  The results of the standards may be even more
far reaching, facilitating quick interconnection with non-emergency
communities both for alerting and for the providing of services and
resources when the incident suggests the need.



The standards developers have chosen to follow the best-practices of
information exchange learned from eBiz/eGov and SOA practices and to
recommend adoption of external standards within the emergency
standards for information loads that already have a solid standard.
One example is the use of portions of the OASIS CIQ (Customer
Information and Quality) Standard for how to represent people or
parties location in a non United States restricted representation.




2. Using Emergency Data Exchange Lanaguage – Distribution Element
(EDXL-DE) as a common framework for information sharing



[The] Distribution Element specification describes a standard message
distribution framework for data sharing among emergency information
systems using the XML-based Emergency Data Exchange Language (EDXL).
This format may be used over any data transmission system, including
but not limited to the SOAP HTTP binding.[2]



The primary purpose of the Emergency Data Exchange Language and its
supporting standards is, and should continue to be, structured
information management for emergency response.  However, this does not
preclude the use of this structured approach to add value to the
emergency response system by supplying additional pertinent
information and services.



The Distribution Element (DE) may be thought of as a "container". It
provides the information to route "payload [content]" message sets
(such as Alerts or Resource Messages), by including key routing
information such as distribution type, geography, incident, and
sender/recipient IDs.[3]



For example, previous to the DE specification, during Hurricane Andrew
a notification went out over a specialized shared information space
for emergency response that additional routers were needed for
computer connectivity at some of the emergency shelters. Management
from a large, multi-site store was monitoring the notifications. The
business delivered routers directly to the sites that needed them from
nearby stores. In this case it was quick thinking on the part of the
business management that got the shelters the needed equipment.  Due
to the information system's configuration, no electronic response to
the notification could be made. As a result, four separate stores
delivered the requested routers to one shelter. With the upcoming
Emergency Data Exchange Language – Resource Messaging (EDXL-RM)
Specification, this resource request / response scenario could play
out with all involved parties aware of the process as it unfolds.




3. Using Emergency Data Exchange Lanaguage – Resource Messaging
(EDXL-RM) as a common format to communicate about resources needed and
available during an incident



The primary purpose of the Resource Messaging Specification is to
provide a set of standard formats for properly formatted XML emergency
messages that are specifically designed for information payloads
related to Resources required for all activities associated with
emergency incidents.




4. Common data format and vocabulary for sectors



4a. Information specifically integrated into Data Exchange Language
        (example: EDXL-HAVE (Hospital AVailability Exchange)



4b. Sector standards specific information exchange via distribution wrappers
        (example: oBIX (Open Business Information eXchange))




5. The fit of Service Oriented Architecture (SOA) aspect of eBIZ/eGov
into emergency response

- Show quoted text -




----------------------------------------------------------------------------------------------------



Fodder



1. EMTC Charter
Across the nation, government agencies, non-governmental organizations
and private sector emergency management offices use a wide array of
software platforms for managing data about emergency conditions,
resources and response activities. Most of these are stand-alone
systems with limited capability for data sharing with other agencies
or other levels of government.

Advances in information technology have paralleled the movement toward
more integrated approaches to emergency management. In particular, the
emergence of service-oriented architectures has created new
opportunities for interoperability among diverse emergency information
systems utilizing existing industry-standard technologies. At the same
time, other data communication facilities, such as digital television
and radio broadcasting, are being brought to bear on the challenges of
emergency information exchange.

Application of these technologies to the emergency management domain
requires the design and refinement of new standards for data
structures and message-exchange processes. The purpose of this
Technical Committee is to design, develop, and release XML-based
standards that provide a framework for interoperability among diverse
emergency information systems.

2. EDXL-DE spec
This Distribution Element specification describes a standard message
distribution framework for data sharing among emergency information
systems using the XML-based Emergency Data Exchange Language (EDXL).
This format may be used over any data transmission system, including
but not limited to the SOAP HTTP binding.

3. EDXL-RM draft
The primary purpose of the Resource Messaging Specification is to
provide a set of standard formats for  properly formatted XML
emergency messages that are specifically designed for information
payloads related to Resources required for all activities associated
with emergency incidents. The Distribution Element may be thought of
as a "container". It provides the information to route "payload"
message sets (such as Alerts or Resource Messages), by including key
routing information such as distribution type, geography, incident,
and sender/recipient IDs

4a. EDXL-HAVE draft
HAVE is a draft XML specification that allows the communication of the
status of a hospital, its services, and its resources. These include
bed capacity and availability, emergency department status, available
service coverage, and the status of a hospital's facility and
operations.

4b. oBIX draft
oBIX is designed to provide access to the embedded software systems
which sense and control the world around us.  Historically integrating
to these systems required custom low level protocols, often custom
physical network interfaces.  But now the rapid increase in ubiquitous
networking and the availability of powerful microprocessors for low
cost embedded devices is weaving these systems into the very fabric of
the Internet.  Generically the term M2M for Machine-to-Machine
describes the transformation occurring in this space because it opens
a new chapter in the development of the Web - machines autonomously
communicating with each other.  The oBIX specification lays the
groundwork building this M2M Web using standard, enterprise friendly
technologies like XML, HTTP, and URIs.

The requirements and vertical problem domains for M2M systems are
immensely broad - too broad to cover in one single specification.
oBIX is deliberately designed as a fairly low level specification, but
with a powerful extension mechanism based on contracts.  The goal of
oBIX is to lay the groundwork for a common object model and XML syntax
which serves as the foundation for new specifications.  It is hoped
that a stack of specifications for vertical domains can be built upon
oBIX as a common foundation.

The following design points illustrate the problem space oBIX attempts to solve:
 · XML: representing M2M information in a standard XML syntax;
             The principle requirement of oBIX is to develop a common
XML syntax for representing information from diverse M2M systems.  The
design philosophy of oBIX is based on a small, but extensible data
model which maps to a simple fixed XML syntax.  This core object model
and it's XML syntax is simple enough to capture in it's entirety in
one illustration provided in Chapter 4.  The object model's
extensibility allows for the definition of new abstractions through a
concept called contracts.  The majority of the oBIX specification is
actually defined in oBIX itself through contracts.
 · Networking: transferring M2M information in XML over the network;
             Once we have a way to represent M2M information in XML,
the next step is to provide standard mechanisms to transfer it over
networks for publication and consumption.  oBIX breaks networking into
two pieces: an abstract request/response model and a series of
protocol bindings which implement that model.  Version 1.0 of oBIX
defines two protocol bindings designed to leverage existing web
service infrastructure: a HTTP REST binding and a SOAP binding.
 · Normalization: standard representations for common M2M features:
points, histories, and alarms;
             There are a few concepts which have broad applicability
in systems which sense and control the physical world.  Version 1.0 of
oBIX provides a normalized representation for three of these:
                      · Alarming: modeling, routing, and
acknowledgment of alarms.  Alarms indicate a condition which requires
notification of either a user or another application.
                      · Histories: modeling and querying of time
sampled point data.  Typically edge devices collect a time stamped
history of point values which can be feed into higher level
applications for analysis;
                     · Points: representing a single scalar value and
it's status - typically these map to sensors, actuators, or
configuration variables like a setpoint;
   · Foundation: providing a common kernel for new standards;
             The requirements and vertical problem domains for M2M
systems are immensely broad - too broad to cover in one single
specification.  oBIX is deliberately designed as a fairly low level
specification, but with a powerful extension mechanism based on
contracts.  The goal of oBIX is to lay the groundwork for a common
object model and XML syntax which serves as the foundation for new
specifications.  It is hoped that a stack of specifications for
vertical domains can be built upon oBIX as a common foundation.

5. OASIS website
Service Oriented Architecture (SOA) represents a collection of best
practices principles and patterns related to service-aware,
enterprise-level, distributed computing. SOA standardization efforts
at OASIS focus on workflows, translation coordination, orchestration,
collaboration, loose coupling, business process modeling, and other
concepts that support agile computing.

- Show quoted text -


--------------------------------------------------------------------------------

[1] OASIS EMTC Charter, 2005.

[2] EDXL-DE Specification

[3] EDXL-RM Draft Specification

Continuing through Emergency.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]