Concepts and Applications of Spatiotemporal ... - CiteSeerX

19 downloads 20026 Views 216KB Size Report
the synergies of coupling OGC-compliant services and HLA-based simulations ... using a Web Service Definition Language (WSDL) and published in directories.
Concepts and Applications of Spatiotemporal Interoperability in Environmental and Emergency Management Ulrich Raape ResilientDecisions, Magdeburg, Germany

Ingo Simonis University of Muenster, Germany

Thomas Schulze Otto-von-Guericke-University Magdeburg, Germany

Abstract: Interoperability of Systems and Services is gaining importance, but is mostly limited to a specific domain, e.g. the geospatial or modeling & simulation (M&S) domains. Spatiotemporal Interoperability describes an approach to exploit the synergies of coupling OGC-compliant services and HLA-based simulations in a standardized manner. The paper describes the current status of the Distributed spAtiotemporaL Interoperability Architecture (DALI), potential aplications as well as two prototypes in the area of Environmental and Emergency Management. Keywords: Spatial Data Infrastructures, Simulation, Interoperability, High Level Architecture, Critical Infrastructures, DALI

1

Introduction

Environmental and Emergency Management (EM) are two application areas where often processes in both the spatial and temporal dimensions need to be modeled, forecasted, analysed for decision support and other tasks. Above that, EM often poses additional requirements regarding flexibility, ad-hoc configuration, or applicability in more than one phase of the EM cycle of Mitigation, Preparedness, Response and Recovery. While the geographic information (GI) and the modeling and simulation (M&S) domain both offer a wealth of systems, tools, services and concepts or architectures for interoperability, the access to services outside the “own domain” still results in proprietary solutions, leaving the need for cross-domain

2

U. Raape, I. Simonis, T. Schulze

interoperability unaddressed. The paper describes the Spatiotemporal Interoperability approach which strives to make the synergies of coupling OGCcompliant services and HLA-based simulations usable in a standardized manner.

1

Interoperability

Interoperability is defined as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” [IEEE90]. Specific interoperability definitions exist in various domain, such as the M&S Interoperability being defined as “the ability of a […] simulation to provide services to, and accept services from, other […] simulations, and to use the services so exchanged to enable them to operate effectively together” [DoD94]. The complex topic of Interoperability needs to be structured in more detail, and among the well accepted approaches is the following one [MoLo05]: • Technical interoperability: the ability to technically exchange data. • Semantic interoperability adds the requirements to interpret exchanged data in a consistent way between different systems and services. • Substantive interoperability adds the ultimate requirement that systems should interoperate in such a way that the goals of the system are achieved. More refined approaches exist or are under development, e.g. LCIM [ToMu03].

2.1

General Interoperability Architectures

Among the many general (not domain specific) interoperability architectures the Service Oriented Architectures (SOA) are described here shortly. A SOA is a collection of services providing an ability, for example, to exchange information [Barr05]. Some of the first service oriented architectures were based on CORBA or DCOM technologies. Today SOA based on Web Service and XML/SOAP technology is in focus for civilian enterprise integration. Services are defined using a Web Service Definition Language (WSDL) and published in directories based on the UDDI meta-service. One of the main advantages is that Web services is supported by a wide range of operating systems and development/deployment environments. Figure 1 depicts the find-bind-execute paradigm of web services (Service Trading). A typical web service provides a domain oriented service, like “Get account balance”. It is usually provided by a front-end server that connects to enterprise servers, often using proprietary mechanisms. The exchange is done in a client server mode with a request/response scheme similar to a web browser.

Concepts and Applications of Spatiotemporal Interoperability

3

Figure 1: Service Trading

Elements and standards used by SOAs are also commonly used by domain specific architectures and approaches, such as the Extensible Modeling and Simulation Framework XMSF, GI Services and HLA Evolved (see section 2.3.4).

2.2

Interoperability in the Geospatial Domain

Interoperability of the geospatial domain is currently mainly provided through the standardization bodies ISO and Open Geospatial Consortium (OGC). ISO specification series 191xx provides a rather high level view on geospatial data and processes, while OGC specifications address both the abstract as well as the implementation level. One of the most promising approaches to foster interoperability within the geospatial community is provided by the OGC. The OGC is an international non-profit industry consortium with the mission “to lead the global development, promotion and harmonization of open standards and architectures that enable the integration of geospatial data and services into user applications and advance the formation of related market opportunities”. 2.2.1

“Static” OGC Services

The standardization work of the OGC is currently state of the art within the geospatial domain. Based on the ISO/IEC Reference Model for Open Distributed Processing (RM-ODP), it has produced mature specifications that provide a high level of interoperability. The OGC Web Services Framework provides a common set of interfaces and encodings that span the functional parts of the enterprise. Currently, five different web service types can be distinguished: • Registry services that allow service- and data discovery, • Portrayal services that support rendering of spatial and non-spatial data, • Data services that act as a standardized façade to geospatial data repositories,

4

U. Raape, I. Simonis, T. Schulze

• Data processing services that can process standard-encoded geospatial data, • Processing-Workflow services that provide geospatial data processing. 2.2.2

“Time-Dependent” OGC Services: Sensor Web Enablement (SWE)

While all current implementation specifications provided by OGC focus on static, non temporal dynamic geospatial data, it is up to the Sensor Web Enablement (SWE) initiative to address the integration of live sensors and simulation models into Spatial Data Infrastructures [Simo+03a]. Simulation model integration can be intepreted as a special way of sensor device integration: Models predict, estimate, or simulate features by analogy with Web Feature Services (WFS) that produce features from conventional data stores. Features produced by models are commonly observations which reflect the complexity of the acquisition process and provide information about how the data was collected, where, with what kind of a sensor, when and so on. Therefore, observations represent a model of the observing process. Developed within the SWE working groups, the Observation and Measurement (O&M) specification provides general models and XML encodings for observations and measurements made using sensors. Most of it became part of the Geographic Markup Language (GML) [Cox+04] during the last two years. The GML observation model understands an observation as the process of observing some phenomenon. It is not a simple object with a value, time stamp and location identifier, but a complete model that gives additional information about what and how the process was performed. The Sensor Model Language (SensorML) provides models and XML Schema for describing sensor systems and observation process models [Bott04]. A SensorML instance may be provided within or is referenced by an observation. To access the spatio-temporal data, a highly specific subtype of a WFS, the Sensor Observation Service (SOS) was developed. The Sensor Planning Service specification is currently undergoing some revision. It is an interface by which a client can obtain information about the feasibility of an observation or submit parameterized observation requests. Overall, the OGC SWE initiative provides a sound foundation to integrate simulation models. A weak point of the current SWE specifications is the poor design and handling of the metadata models for simulation models. For proper integration, purpose and applicability of the model as well as quality indicators have to expressed. Though a set of basic models are available, like the ISO 19115 models to describe geographic metadata or the UCSB content standard for computational models, a lot of integration and harmonization work with other standardization communities will have to be performed.

2.3

Interoperability in the Modeling & Simulation Domain

In the past decades simulations often have been specialised, monolithic applications not prepared to communicate or interoperate with other systems.

Concepts and Applications of Spatiotemporal Interoperability

5

Mainly in order to gain speed improvements considerable research has gone into the development of protocols and synchronisation mechanisms for distributed simulations [Fuji99]. It became obvious that standards for communication and coordination among participating simulations are necessary. It was in the military domain where the standards Aggregate Level Simulation Protocol (ALSP) and Distributed Interactive Simulation (DIS) have been developed and deployed widely for their respective application areas. Based on the experiences with ALSP and DIS and the requirements derived from the need to build interoperable, modular, cost-effective and flexible simulations instead of cost-intensive, large, monolithic simulators focus shifted to Interoperability and Reusability. As a result, the US Department of Defense (DoD) triggered the development of the High Level Architecture for Modeling and Simulation (HLA) currently being the state-of-the-art architecture for distributed simulation systems. 2.3.1

The High Level Architecture for Modeling and Simulation (HLA)

The HLA is a software architecture and infrastructure technology for distributed simulation systems (called Federations and, when being executed, Federation Executions) consisting of heterogeneous, distributed and dislocated subsystems (called Federates). HLA offers flexible communication and synchronisation services to allow federates and federations to operate under a wide range of different time regimes, which also led to the participation (“HLA-enabling”) of non-simulation systems like databases, sensors, etc. HLA is the prescribed DoD and NATO standard for military simulation interoperability and is used for military training, analysis and other purposes and for all types of military simulation (so-called virtual, constructive and live simulations). HLA was developed as a US DoD standard in several steps up to version 1.3 [DOD01]; it was then decided to develop future versions as open international standard through IEEE [IEEE01] to facilitate a broader adoption internationally as well as in all types of commercial industries. 2.3.2

Building Blocks of the HLA

The HLA consists of three major building blocks: the HLA Rules, the HLA Object Model Template (OMT) and the HLA Interface Specification (IfSpec). The Rules, OMT and IfSpec define how federations and federates shall behave, communicate and how their object models have to be described. The HLA rules describe the basic behavior of federations (rules 1-5) and federates (rules 6-10), e.g. that all communication takes place via the RTI (Rule 3). The Object Model Template (OMT) provides a common framework for the communication between HLA simulations. OMT consists of the Federation Object Model (FOM) which describes the shared objects, attributes and interactions for

6

U. Raape, I. Simonis, T. Schulze

the whole federation and the Simulation Object Model (SOM) which describes the shared object, attributes and interactions used for a single federate. The Interface Specification is object oriented (with some exceptions) and divided into six service groups: Federation / Declaration / Object / Ownership / Time / Data Distribution Management, and Support Services. The Time Management services allow the transparent management of federates under different time regimes (e.g. real time, time stepped, event driven, continuous) which is a major breakthrough compared to previous technologies. The Data Distribution Management (DDM) services introduced by HLA use a routing space paradigm, allowing federates to specify regions of interest or capability in a space formed by the attribute values; only if a publication and subscription region overlaps, data is transferred from the publisher to the subscriber of this object attribute. The HLA itself is an architecture, not a software; to support the execution of federations, a so-called Runtime Infrastructure (RTI) is provided which offers the necessary services needed to implement the HLA. Before transition to IEEE, the U.S. Defense Modeling and Simulation Office (DMSO) provided the so-called DMSO-RTI to the HLA community. Commercial RTI implementations are available, e.g. from Pitch, Sweden. 2.3.3

Extensions and Development of the HLA

The flexibility of the HLA especially regarding the support of different time management and synchronisation schemes soon led to the development of specific or generic interfaces to non-Simulation Federates such as databases, windows- and web-based animation tools, real-time sensor networks and others. The potential of HLA in civil application domains has been demonstrated soon after the HLA has been published [Schu+99], [Stra01]. The HLA Standard itself undergoes continous development (HLA 1516 was standardized through IEEE in 2000). Beside improvements regarding completeness, strictness of definition, and unambiguousness, the main differences between (pre-IEEE) HLA 1.3 and HLA 1516 are better filtering of information (with DDM), additions allow for better performance and scalability, and the use of XML and Unicode. The HLA 1516 standards are subject to a review process in which the next generation HLA, called “HLA Evolved”, is being developed [Möll05]. While no major changes to the HLA Rules are planned, the updated HLA OMT will include support of additional metadata and an XML schema for the OMT Data Interchange Format (DIF). Regarding the HLA Interface Specification, dynamic link compatibility will allow federates to change RTIs without relinking and web support will allow HLA-based simulations to run within a web services environment. Major improvements are expected in the area of fault tolerance. The DALI architecture will make use of the HLA web service functionality as soon as it is specified and available.

Concepts and Applications of Spatiotemporal Interoperability

3

7

Distributed Spatiotemporal Interoperability (DALI)

3.1

Approach

The OGC Specifications and the HLA provide a solid foundation for an spatiotemporal interoperability architecture; the key feature comparison shown in table 1 shows that in terms of the capability to model and support spatiotemporal processes in a modular and standardized way both technologies are complementary. An integration of both standardization approaches would offer features and services accessible to both basic architectures. Criteria

HLA

OpenGIS

Domain

Time

Space

Simulation

GIS

Distributed Heterogeneous Simulation-based Systems

Interoperable Geoenabled Web-Services

DoD, NATO, IEEE

OGC

Temporal Awareness

Yes

No

Synchronization/Time Management (TM)

Yes: Extensive TM Interoperability

No

No

Yes

Applications Approach Standardization

Spatial Awareness

Availability of Services During Federation Runtime Web-based Services Communication Style

Permanent

No (Communication via TCP/IP)

Yes

Stateful

Stateless

Table 1: HLA/OpenGIS Key Feature Comparison

Table 1 also indicates what bridges need to be built between both technologies, e.g. to make HLA-based simulation services permanent which is a prerequisite to make them part of a web-based service infrastructure (e.g. in the sense of OGC or UDDI), which normally presupposes permanent accessibility. On the other hand, OpenGIS services do not have the HLA type of context over a certain period of time such as the runtime of the federation, the logical time axis within, etc. [Schu+02]. In general, the DALI approach can be structured as follows: 1. making OGC services available to HLA federates,

8

U. Raape, I. Simonis, T. Schulze

2. making federations available to OGC services. Therefore, the following points have to be addressed [Simo+03b]: • Federations must be permanently available as OGC web service (by creating appropriate wrapper interfaces / services); • Provisions must be made to create, start, control and terminate Federation Executions remotely (e.g. using suitable management services); • Geographic objects must be made interchangeable. This results in a GI Reference FOM on the HLA side which has to follow the OGC Open Geodata Model as closely as possible. Achievement of semantic interoperability on the HLA side is an open research issue very important to the DALI approach. • Specialised federates have to be created that façade selected OGC services to ensure HLA compliancy. Using HLA declaration and object management services, they will listen to GI requests within federations and will transparently collect responses from appropriate OGC services.

3.3

DALI Architecture

What application scenarios should the DALI architecture cover and what are the requirements? The DALI approach cannot cover every potential application scenario equally, and for some specific cases other (proprietary?) protocols or architectures will be a better choice. However, we have to define those typical scenarios before going into implementation details. Figure 2 shows a few typical scenarios with different interactivity and synchronisation requirements: • „Just the Results“: The system or service requesting simulation services is only interested in the results of the simulation. Optionally a trace of the simulation run can be archived in a datastore for future use. The synchronisation and interactivity requirements are very low.

Interactivity

„Interactive online Visualisation“ „Online Visualisation“ „keep me informed“ „Just the Results“

OGC

SensorWeb

Low

Figure 2: Application Scenarios

HLA Synchronisation Granularity

High

Concepts and Applications of Spatiotemporal Interoperability



9

“Keep me informed”: The simulation service requester wants to be informed about the progress of the simulation run and/or about certain events (triggered by update frequencies or conditions previously defined). The requester might react and issue commands to the simulation side, but without any requirements regarding synchronisation or causality-keeping. Synchronisation requirements are higher than in the “Just the Results” scenario. Depending on the resulting update or event notification rate, the communication requirements will range from the “Just the Results” level up to a level where the application of specific protocols or architectures starts to be indicated.

• “Online Visualisation”: The requester wants to “see” what happens on the simulation side. Depending on the visualisation requirements, this scenario might range from a static picture being refreshed every n seconds up to smooth (but non-interactive) animations. The use of web-based visualisation, perhaps on mobile devices using communication channels with varying bandwidth and reliability, impose additional requirements. In this scenario, solutions might be the display of pictures (maps) being repeatedly refreshed or the transmission of consecutive animation sequences (covering the most recent n time units of the simulation) using flash, SVG or other formats. • “Interactive online Animation”: interactive visualization requires the visualisation client to be in the causality loop of distributed time management (otherwise causality could be breached when user interactions are received by simulations which have advanced their local time already). This scenario requires the visualisation and animation to be a HLA-federate participating in the federation to be monitored. This results in different synchronisation requirements which guide the decision what technology to apply to what communication link: obviously the upper right area of figure 2 needs to be covered by HLA-based federations, while (OGC) web services are suitable for the lower left area. This interactivity / synchronisation map is used in the DALI development process to deploy available technologies (OGC webservices, OMG Data Distribution Services (DDS), HLA, etc.). The development of specialised “GI”/”OGC” federates that mirror OGC service functionality transparently into HLA federations and the development of OGC SensorWeb services that transparently map HLA-based simulation services as “virtual sensors”, are not described in detail here. As an example of the many issues to be addressed in the DALI approach, we will take a closer look at making HLA-based simulation services available permanently. Different approaches have been evaluated to achieve permanent availability and remote control of federations. The Management Federation approach described in [Simo+03b] uses HLA to create a permanently running federation responsible for the management of simulation federations which execute real simulation runs. For each system on which simulation federates may be run a management federate acts as a bridge to the respective local federate and system resources.

10

U. Raape, I. Simonis, T. Schulze

Simulation Results Visualization of Results

Simulation Federate

Simulation Federate

Map

GI Federate Geo Data

Simulation Federate

Figure 3: Web service based approach to remote federation control

If a request to execute a specific federation populated with specific federates is received by the management federation it can analyze what systems are able to run what required federates and subsequently can decide (e.g. according to load balancing considerations) what management federate receives the order to start what federate locally. Local control to start, manage and stop federates is performed by the respective management federate. Another approach focusing on web service technology is currently being evaluated (see figure 3 for an overview). A so-called GeoSim Management Webservice is responsible for the management of (local) HLA resources. It offers well-defined simulation services which are performed by local or remote HLA federates (activated via “their” webservice) or, if the requested scenario has already been computed, retrieved from a datastore.

4 Applications in Environmental and Emergency Management Often OGC-based applications in Environmental and Emergency Management require dynamic information, delivered by sensor networks, simulations or archives. Sometimes different scenarios must be analysed and compared. E.g. in an emergency response application, a decision maker needs not only to have actual (if not realtime) information; in addition, to be able to forecast the spatiotemporal consequences of decision alternatives would be very helpful. On the

Concepts and Applications of Spatiotemporal Interoperability

11

other hand simulations often require spatial information, e.g. road networks, terrain information, infrastructures etc. Using the DALI architecture, much flexibility can be gained when an application can be orchestrated with specific modules / services and simulations dynamically be initialised at runtime (shift from pre-configured, sometimes hardwired initialisation to on-the-fly initialisation). A further DALI design principle uses the black-box feature where a simulation federate or service hides the implementation details; thus, using the same interface, the same object model can be served by a database, simulation or sensor network federate [Klei01]. These DALI concepts can be used to create (decision support) systems that are able to be applied in different usage scenarios ranging from analysis and planning, training and realtime decision support [KlWy01]. • A first Emergency Management prototype based on the DALI concept has been developed and implemented during a German R&D project and presented in [Schu+02]. The chosen scenario was to monitor and forecast spacially distributed runoff in a given area of Germany using a complex distributed hydrological simulation system. In addition to a set of static spatial input data provided by OGC Web Services, the simulation will be parameterized by extremely up-to-date rainfall data, provided by on-line measuring points which are integrated by appropriate Geofederates. Current runoff measurements are incorporated to continuously calibrate the model during runtime integrating water level measurement points. Interoperable sub-models can be integrated to forecast high water hazards and flood damage to supply suitable information for operative emergency management. The first prototype was developed to demonstrate the basic concepts described above and to serve as the platform for additional federates and spatio-temporal services. A case study region in Germany has been chosen that allows access to a (nearly) real-time sensor network in reservoirs and rain gauges.

4.4

Setting the European Context: the MEDSI Prototype

The DALI approach has been implemented in a first EM prototype as part of the European R&D project “Management Decision Support for Critical Infrastructures (MEDSI). The objective of MEDSI project is to develop a web-based integrated set of software services as a tool to enhance the capabilities of crisis planners and crisis managers in both private and governmental organizations. MEDSI will enable them to utilize various information sources for better monitoring and reduction of potential and actual risks and for more effective response in case of threats imposed especially to the subjects of the critical infrastructure. MEDSI will also be capable to create, maintain and optimise the typical scenarios and procedures how to solve the situations [MEDS05].

12

U. Raape, I. Simonis, T. Schulze

One of the MEDSI test scenarios deals with a flooding situation in the city of Magdeburg. As part of the Magdeburg prototype implementation, a generic evacuation simulation has been developed which operates in a lightweight prototype version of the DALI architecture.

Figure 4: Basic Elements of the Generic Evacuation Model

The application scenario describes the evacuation of people from risk-prone areas into evacuation areas. The historic flood situation in the city Magdeburg in 2002 is the background for this scenario. The area where evacuation was considered (but not carried out) included between approx. 20.000-30.000 citizens. The scenario includes a decision support system prototype to support the crisis management group of the region of Magdeburg. Modules provide the necessary geographical and non-geographical base data, and the generic evacuation simulation model was used to forecast and evaluate different evacuation scenarios under varying conditions as well as to identify potential bottlenecks during the evacuation process and the identification of critical success factors [RaPe04].

Figure 5: Generic Evacuation Model with urban traffic scenario

Concepts and Applications of Spatiotemporal Interoperability

13

The generic evacuation model itself models entities that can move on an infrastructure (network). Static or dynamic areas of equal “potential” can be defined which are used by the objects to decide from which areas to escape from (negative potentials, shown in red) into which areas (positive potentials, shown in green) (figure 4). The absolute number is equivalent to the importance or priority. According to the configuration of the model and the properties of the entities and the nodes and edges of the infrastructure (before or even during runtime) it is able to describe pedestrians on walkways, cars on a road network, etc. The following pictures shows a configuration example where multiple object types (cars, pedestrians) are modeled on a urban traffic infrastructure (figure 5). The MEDSI evacuation prototype uses the RTI-supported DALI architecture and consists of three major elements: OGC web services (to provide the geographical information), the evacuation model and a web-based client as the user interface to the crisis manager. According to the individual scenarios the system has already run or is currently running, an online or post-mortem visualisation is possible using OGC web services or animation software (see figure 6).

Figure 6: Animation of a single evacuation scenario

At runtime, the street network is requested from an OGC service and is made available to the HLA-based generic evacuation model. This results in ad-hoc configuration and initialization capability needed in the EM domain. At the current stage, the generic evacuation model uses simplified assumptions and algorithms (e.g. pathfinding and entity behaviour). The behaviour of entities follows the paradigm in potential models: Move from a source node with high danger potential to

14

U. Raape, I. Simonis, T. Schulze

an area with lower potential sinks. Entities have information where the nearest destination areas are located and they know the shortest way through the network from their source to their destination. As soon as the focus shifts towards modelling accuracy, the model can easily be updated with state-of-the-art algorithms and behavioural patterns for different entity classes.

5

Summary and Outlook

Spatiotemporal Interoperability describes an approach to exploit the synergies of coupling OGC-compliant services and HLA-based simulations in a standardized manner. The Distributed spAtiotemporaL Interoperability Architecture (DALI) presented in this paper addresses requirements and offers benefits often articulated in the Environmental and Emergency Management and other domains. The DALI architecture is under ongoing development, and still lot of issues and open questions need to be solved and answered. However, recent developments and standardisation initiatives in related areas are encouraging if not utilizable for the overall aim of spatiotemporal interoperability (e.g. Grid concepts and technologies). Especially the activities in the area of the OGC SensorWeb and HLA Evolved Web Services will help to concentrate on developing robust spatiotemporal solutions unique to DALI.

References [Barr05] Barry, D.: Web Services and Service Oriented Architectures. URL http://www.service-architecture.com [Bott04] Botts, M.: Sensor Web Enablement within the OpenGIS Consortium, GeoWorld. 2004. [Cox+04] Cox, S., Daisey, P., Lake, R., Portele, C. und Whiteside, A. (2004). OpenGIS® Geography Markup Language (GML) Implementation Specification: Open Geospatial Consortium. [DOD01] US Department of Defense. RTI 1.3-Next Generation. U.S. DoD. 2001. [DoD94] U.S. Department of Defence: “Department of Defense Directive 5000.59”, January 1994. [Fuji99] Fujimoto, R. M.: Parallel and Distributed Simulation Systems. John Wiley & Sons, New York. 1999. [IEEE01] IEEE: IEEE 1516, High Level Architecture (HLA). URL www.ieee.org, 2001.

Concepts and Applications of Spatiotemporal Interoperability

15

[IEEE90] IEEE: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990. [Klei01] Klein, U.: Verteilte Simulation im ausnahmetoleranten Verkehrsmanagement. Dissertation. University of Magdeburg. 2001.

städtischen

[KlWy01] Klein, U.; Wytzisk, A.: Space + Time: Interoperable IT Architecture for 4 Dimensional Scenarios. In: Drager, H. (Ed.): Proceedings of the 8th Conference of the International Emergency Management Society, 19.-22. Juni 2001, Oslo, Norwegen. [MEDS05] The MEDSI http://www.medsi.org

project,

EU

Contract

IST-

506991;

Homepage

at

[Möll05] Möller, Björn: HLA Evolved – the next version of HLA. 7th German HLA Forum, Magdeburg. URL: http://www.kompetenzzentrum-hla.de. 2005. [MoLo05] Möller, B., Löf, S.: Mixing Service Oriented and High Level Architectures in Support of the GIG. Proceedings of the Spring SIW 2005, Paper 05S-SIW-064. [RaPe04] Raape, U.; Petjoch, J.: Management of Critical Infrastructures. In Proceedings of the Annual International Emergency Management Conference, Shire of Yarra Ranges / Melbourne, Australia, May 18-21, 2004. [Schu+02] Schulze T., Wytzisk, A., Simonis I., Raape U.: Distributed Spatio-Temporal Modeling and Simulation. In: Yücesan, E., Chen, C.-H., Snowdon, J. L., Charnes, J. M. (Eds.): Winter Simulation Conference 2002. San Diego: 695-703. [Schu+99] Schulze, T.; Straßburger, S.; Klein, U.: Migration of HLA into Civil Domains: Solutions and Prototypes for Transportation Applications. In: Simulation, Special Issue: The DoD High Level Architecture (HLA), Vol. 73, Number 5, 1999, S. 296 - 303. [Simo+03a] Simonis, I., Wytzsik, A., Lutz, M.: Integrating Live Sensors and Simulation Models in Spatial Data Infrastructures. Proceedings of the 9th EC Gi & GIS Workshop, La Coruna, Spain, 25-27 June 2003. [Simo+03b] Simonis, I.; Wytzisk, A.; Raape, U.: Integration of HLA Simulation Models into a Standardized Web Service World. In: Simulation Interoperability Standards Organization (SISO): Proceedings of the European Simulation Interoperability Workshop 2003, Paper 03E-SIW-019. 2003. [Stra01] Straßburger, S.: Distributed Simulation Based on the High Level Architecture in Civilian Application Domains. SCS Series "Advanced Simulation", SCS-Europe BVBA. 2001. [ToMu03] Tolk, A.; Muguira, J. A.: "The Levels of Conceptual Interoperability Model (LCIM)," Fall Simulation Interoperability Workshop 2003, Paper 03F-SIW-007, Orlando, Florida, September 2003.

Suggest Documents