© EDP Sciences 2016

1 Introduction

The intent of the analytical platform (AP) is on one hand to allow easy and secure communication between experts and to provide them with means to analyse the current situation in case of a radiological incident. On the other hand, it should facilitate the communication between experts and public community to assure a consistent overview on the situation. The obvious approach nowadays is to realize such a system as web-based application as access is basically guaranteed worldwide by a wide range of different devices. The AP therefore was designed as web portal distinguishing between a web client and a web server. Experts and public community alike can connect to the AP with a web client e.g. using any major web browser like Chrome, Firefox, Internet Explorer, etc. once the server side has been setup. This in general eliminates any need for additional software installation on the client side, especially if the default browser capabilities are preferred e.g. neither a Java nor a Flash environment is used.

The server consists of two parts: the AP portal providing the web access and means for experts to analyse a situation and to communicate with each other as well as to the community and of the underlying AP system providing the means for the higher level AP portal to operate. In general, end users only need to know about the AP portal. Nevertheless, for a fully functional server an operating system is required as well as for tasks like maintenance and backup some knowledge on the AP system is essential for administrative users. To provide uniform structures and advice to handle the web server, the distribution of a pre-installed and fully configured web server is desirable. However, the large-scale distribution of the web server preinstalled on a physically existing hardware is not possible for obvious reasons.

An elegant solution to this request is the distribution of the web server as virtual machine, i.e. as a software bundle. A virtual machine is the software version of a physically existing computer. It describes the hardware as a software configuration and provides hard drive content as files. The configuration is executed by a specific virtual machine software which emulates the virtual machine on a physically existing hardware thus adding an abstraction layer. The virtual machine approach allows for a simple and fast distribution as only a copy of the files of the virtual machine, and the emulator software is required.

2 Structure of the analytical platform system

The AP realized as a virtual machine software bundle provides the already installed and configured AP system and the AP portal. The bundle is distributed as an OVA file (open virtual appliance) comparable to a zip file and can be imported in a virtual machine emulator, preferably VirtualBox¹. The computer running the virtual machine emulator is named Host, the emulated virtual machine is named Guest. The emulator software is available for a wide range of operating systems. Hence, the current minimum requirements for the host are PC or Mac hardware running either Linux, Windows or OS X as operating system, at least 4 GB system memory and at least 20 GB of hard drive memory. The guest is based on Ubuntu 14.04 LTS (long-term support) and open-source software and thus can be freely distributed.

The AP provides many dedicated servers with special purposes that depend on each other as shown in Figure 1. The natural service access points (ports) are shielded from external access for security reasons. However, the emulation software can bridge the natural access points to external ones to allow remote access. For simplification, the port numbers in the example are added to 40 000. In general, the host itself may be located in a local network behind a firewall. To access the host through the internet, a firewall proxy is suggested, bridging internet access to the host, which in turn bridges to the guest.

Figure 1 The services and access points of the pre-installed analytical platform.

3 Services and service users

Many services are installed and used in the AP system. In general, only the web application is required for the end users. The other services are used internally by the different modules of the AP. However, they are visible outside the virtual machine for convenience and administration.

4 Key aspects of the analytical platform portal

Liferay² was chosen as the basic content management system for the portal. The portal has to handle different incidents which are logically separated. In addition, two states have to be distinguished, whether an incident is currently ongoing or not. Liferay provides a very useful approach to address this prerequisite: it allows to organize the portal in distinct sites as displayed in Figure 2. Thus for each incident, a dedicated site can be created. For the case that no incident is going on, an idle site is provided. Site and page templates have been designed for this purpose, containing default content and the access to the tools, thus accelerating and simplifying site creation if a new incident occurs.

As not all users of the AP should be allowed to edit the content different access rights according to the user's type have to be established. We identified and provided three user types so far: community, expert and administrator. Community user may only read public content, access the forum and the wiki. Experts in addition are allowed to use the tools for analysis and to generate content. Administrators are also allowed to change the structures.

During the PREPARE project, multiple tools have been developed and embedded, in particular a virtual meeting room, which allows private and public message exchange between experts, an incident manager which provides a timeline overview, measurement management, simple dispersion and a map overview. Furthermore, a knowledge database with historic analysis is included, providing a prognosis of the current situation outcome, in addition to a web crawler component, which in the background permanently scans for developments in the social media. Though Liferay provides portlet support, most of these tools have been developed as standalone web applications based on the Google web toolkit and Vaadin and hence are embedded as such using HTML frames. Parameters like incident name are passed via HTTP GET method as query string. As only JavaScript was used, no plugins are required on the web client side, thus further improving the usability for end users.

Figure 2 Left: the portal is structured as sites containing distinct pages. Right: the actual structure of the AP portal. Sites and pages are created from predefined templates.

5 Conclusions

The AP has been realized as a virtual machine consisting of a Linux system and a Liferay web portal. The approach simplifies the distribution efforts and effectively overcomes the need for a local setup as all necessary services are installed and already preconfigured. During the workshops and dissemination, this was well received by the end users. Relying the embedded tools only on plain HTML and JavaScript greatly increases the usability for end users as a default web client without additional plugins is sufficient to work with the AP.

Acknowledgement

The research leading to these results has received funding from the European Atomic Energy Community Seventh Framework Programme FP7/2012-2013 under grant agreement 323287.

All Figures

	Figure 1 The services and access points of the pre-installed analytical platform.
In the text

	Figure 2 Left: the portal is structured as sites containing distinct pages. Right: the actual structure of the AP portal. Sites and pages are created from predefined templates.
In the text