Emergency Simulation Solutions Delivered in Record Time With Eclipse

Emergency management is one of the most difficult occupations that exists, where there are no second chances and no room for error. Emergency management simulation has become one of the most popular methods of preparing decision makers for various scenarios they may face in the real world. Within the Texas Engineering Experiment Station, which is the official engineering research agency of the state of Texas, there exists a research center that turns fundamental research into real technological solutions. Since 2003, the Texas Center for Applied Technology (TCAT) has developed a simulation used for the training provided by the Texas Engineering Extension Service (TEEX), which is one of the leading training service providers for emergency responders in the United States. After the events of 9/11, TCAT conducted a comprehensive study of existing simulations that could be used in emergency management training and found that most existing systems were too restrictive, written for an incompatible domain, or did not allow user-defined scenarios. In order to provide an efficient and cost-effective solution that adjusts to the varying requirements of trainees, the team decided that the solution must be dynamic, and allow simulations to increase or decrease in complexity depending on the training audience. To this end, TCAT set forth developing a versatile, scalable and extensible system, the result of which is now their flagship RCP product the Emergency Management Exercise System (EM*ES).

One of the main processes that EM*ES supports is the National Incident Management System (NIMS), a standardized management approach that unifies federal, state and local lines of government for incident response. However EM*ES has been designed to be adaptable for other simulation contexts, not just restricted to NIMS. The system supports the authoring and presentation of an unlimited diversity of scenarios, ranging from a tornado or hurricane hitting a populated area, to man-made disasters including WMD events, to flooding or cryptosporidium outbreaks in a water supply. The students need to deal with the fallout from an event, and as the class works their way through the response, instructors can add different variables (e.g., someone stealing an ambulance) to test how the trainees react. To enable such flexibility, the Eclipse platform has proven itself as a key technology for the Emergency Management Exercise System (EM*ES), an innovative, scalable solution for emergency management training.

Adaptable Software For A Range Of Users

The system has different sets of users depending on whether it is being used at design-time, during course preparation, or at runtime while a course is being taught. Scenario developers and trainers use an advanced view of the system to design intricate scenarios, and to provide a collaborative runtime environment. During a course, trainers can adjust different variants of a scenario accordingly, changing the speed of the scenario, and adding in new dependencies and stimuli. These changes in state are propagated to all trainers as the system is developed as a collaborative, distributed solution. During a course, the system is used to stimulate groups of students that need to work together, many of which may or may not be familiar with each other, each having their own unique roles and responsibilities within the exercise. One of the key challenges that the software faces is in helping these groups share information quickly and effectively, working as a collective team, yet these students must learn how to use the system very quickly. A high level of usability is required for this, as a single spin up training session on system usage usually only lasts for one hour.

Creating Systems From Reusable Components

Early on, the team realized they needed to build a toolbox consisting of a number of different components that could be assembled to form many types of simulations. By breaking the solution down into components, the team can provide systems for different domains of training and also support different operational contexts quickly and easily. This decoupled approach, core to Eclipse, allows the developers to take out unnecessary plug-ins, and resulting capabilities, for specific customers without the need to re-architect the entire system. All the OSGi bundles are capability based, allowing a real mix-and-match approach to developing systems. Having used Eclipse as their development environment, the team already had the best possible example of a well-tested, complex, robust system built on the RCP. Because Eclipse is open source, if the developers required something in particular they could look into the Eclipse source code and find out how it was accomplished in Eclipse, leaning on what other people had already achieved before them.

Building The System On Top Of Eclipse

In addition to using capabilities provided by SWT and JFace, the team developed their own custom user interfaces for EM*ES. Rather than using any pre-built map components, EM*ES has its own custom map view to fit into the training, showing the required level of detail necessary for strategic decision making across many different types of exercises. One of the key challenges for a map in this environment is to obscure certain details from decision makers so that they maintain their attention at that particular strategic level. The map has its own custom marker and shape drawing tools, and de-cluttering features. It also provides ultra-fast route calculations and support for almost all conventional GIS-based data types, all implemented over a basic SWT canvas.

Figure 1: EM*ES as seen by the trainees during a training simulation. The main part of the screen shows the custom map created by TCAT of a real scenario developed by TEEX.

The timeline editor is developed using GEF (Graphical Editing Framework) and allows drag-and-drop commands in the authoring and execution of the simulation. This editor gives a single point of control for all commands and allows the simulation to be easily modified during the training exercise. This enables the system to act as a collaborative authoring tool, allowing trainers to focus on different parts of the timeline during the training exercise. New commands can be dynamically dropped-in to stimulate the players during the simulation, prompting certain responsive actions. The timeline can also be dynamically adjusted to control the flow of an exercise. For example, commands can be enabled/disabled, moved around in time, paused, or immediately executed. These capabilities provide infinite control over the flow of an exercise.

Figure 2: The scenario authoring editor, used by scenario developers and trainers at design-time and run-time.

One of the core parts of the tool is the collaborative, distributed nature, which ECF (Eclipse Communication Framework) lends itself to nicely. The team grew their own network handling functionality from concepts, such as shared objects, available in ECF.

Web Dashboards for the Real World

Some organizations have requirements for emergency information management solutions that go beyond just training, so TCAT has also developed web-based dashboards for both training and real-world operational use. TCAT has developed solutions to support the United States Air Force, Coast Guard, Department of Agriculture, various agencies within the Department of Homeland Security, and many others. While carrying out feasibility studies into dashboards across multiple domains, the team established the requirements for a larger framework to support dashboards for information sharing. These systems are normally known as a Common Operating Picture. TCAT has evolved this concept by providing a customizable Common Operating Picture, where data can be shared and presented according the the user's own requirements. Aside from just using the components that TCAT provides, the dashboard framework was designed to facilitate the integration of third party components into this operating picture.

Figure 3: Illustrating the composition of Common Operating Pictures using a web dashboard.

Single Sourcing With RAP

Flash was used in initial experiments for providing a customizable operating picture, backed by a Java Servlet. However, using Flash was limiting for the team on the client side, especially after coming from the adaptable nature of their EM*ES system built on RCP. Initial prototypes that demonstrated dashboard framework concepts were then written using RCP. When RAP 1.1 (Rich Ajax Platform) arrived on the scene, the team found that they were able to leverage much of their existing JFace and SWT code, and simply reuse much of the back-end code to provide a rich web interface. RAP gave the opportunity to port their existing code to the web domain. A significant amount of the intellectual capital that had been invested into making EM*ES robust, and much of this work was harnessed and re-used in RAP. A useful by-product of this was that the EM*ES code was made more robust by making it more reusable in different presentation layers.

Figure 4: Dynamic Preparedness System - an example of a dashboard created by TCAT.

Single-sourcing is a term used to describe using a single code base for various platforms, and is one of the key strengths in the RCP-RAP relationship. TCAT started to reverse single-source, by bringing components written for the dashboards in RAP back into the EM*ES application. Also, as they have customers in the government, the web dashboards have to withstand a rigorous security evaluation and the team contributed relevant fixes back to the RAP project. Now, when writing new interfaces, the developers keep both the RCP and RAP environments in mind.

Working Effectively With Eclipse

Many of the issues that the team had in the early days of adopting Eclipse arose from not knowing what was available, or not utilizing the technologies properly. The team has since learned that thorough analysis of existing frameworks and projects is very important, as well as understanding the proper way to develop software in an application framework. In some cases the team diverged and wrote in-house solutions, shared objects being an example of this. Diverging from what Eclipse provides has long-term effects on their development, as it makes it more difficult to adapt back to another framework. Therefore, developing an extensible framework required an entirely different mindset to that of one-off application development. The goal for extensibility and scalability is made easier by following the guidelines and principles set forth by the Eclipse runtime technologies.

TCAT recognizes that they would not have been able to achieve such a great success without Eclipse. The team is focused on solving domain specific problems and Eclipse allows members to pay less attention to the enabling technologies and focus on domain problems. Application solutions are delivered rapidly with a small workforce, 3 full-time developers and 1 manager, at a low cost. Having seen the quality and robustness of the Eclipse codebase, the team usually suspects their own code as the cause of bugs over the open source code that they use.

The Future Of EM*ES

One of the hopes for the future is that EM*ES will move outside the classroom and into operational contexts, similar to the success of the dashboards. One of the principles of the training is to train as you fight. As such, the EM*ES development team needs to provide a seamless, sophisticated and cohesive set of tools to deal with large scale incidents. One key point that the team has to keep in mind during development is to provide software that is powerful enough to be an aid during training, but also simple enough that it does not become a crutch, or something the students depend on to get the job done once they leave the classroom. Eclipse will continue to be at the core of software development at TCAT for the foreseeable future, where they will continue to harness the innovation and productivity benefits obtained by using Eclipse runtime technologies.