[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]