5. Summarized description per Test-bed component

This chapter contains for each component an overview of what it is aimed at, who uses it and in which phase of the Trial it is used, in the form of a table per component. The table also contains a hyperlink to the detailed specification of this component.

5.1. Common Information Space (CIS)

5.1.1. Extra notes

The CIS itself is visible only to developers, not end-users. However, end-users may configure the CIS (or parts of it) to a certain extend using the Admin tool described in paragraph 5.4.

5.2. Common Simulation Space (CSS)

5.2.1. Extra notes

Simulators all have their own data model of how they represent the simulated world. The CSS allows these simulators to agree on a communication form that the simulators understand to create and maintain a joint simulated world. Next to the CSS, there also is the Common Information Space (CIS), that is used to connect all the solution tools with the Test-bed and thus with each other. The design to not connect the simulators to the CIS directly is mainly to ensure the two spaces of simulated truth and perceived/communicated truth are kept separate inside the Test-bed. Like with a lot of emergency management processes, obtaining relevant information from the real world to base a decision on is either done by: • actually being at a specific location observing the current state, or • receiving and sending messages via all kinds of communication channels from persons or systems at a specific location (e.g. radio communication, sensor input, camera feeds). These ways of obtaining information gives a (shared) perceived truth to be used in further emergency management decision making. However, due to a wrong observation or miscommunication, the perceived truth can be different than the simulated truth. The simulators should only be concerned with maintaining the current state of the simulated truth (including entities and processes), and shouldn’t have to deal with the different kinds of communication types for solution tools and users to create the perceived/communicated truth. The Common Simulation Space allows simulators to only focus on maintaining the current state of the simulated world (i.e. the simulated truth of the incident and the world around it). In order to communicate state changes with other simulators inside the CSS, self-created communication messages are allowed inside this space. This is different than the messages being sent over the CIS, because the CIS is more aligned with current emergency management standards (like Common Alerting Protocol (CAP) messages, or Emergency Data Exchange Language (EDXL) messages). In order to direct the simulated world towards a desired scenario relevant for the trial, the Trail/Scenario manager should be able to send out messages to change the simulated world. This should be done via inject messages that all simulators can understand in order to execute the requested inject (e.g. start the breach, let the container explode).

5.3. CIS-CSS gateways

5.4. Validation Service

5.5. Test-bed manager (Admin tool)

5.6. Scenario Manager

5.7. Time service

5.8. Observer Support Tool

5.8.1. Extra notes

The Observer Support Tool’s aim is to collect observations, inform observers about trial progress and visualize collected data. There are different perspective to look at this tool. Main user, who uses the mobile version of a tool to send his observations is called Observer. From the other side there exists Trial Manager, he focuses on collected data and analysing it on desktop. Each of them has their own functionalities provided by OST. There are also these functionalities which are connected with non-functional requirements.

Observer Support Tool provides different views for each user. Observer sees name and description of a trial, events that have already happened and observation templates which he can fill in, whereas Trial Manager have displayed summary of all observations that have been sent, what is more he can even see summary of observations in time and messages he sent to Observers. Trial Manager is responsible for assigning role to the user which can be an Observer or Participant of a Trial.

First, user selects trial he is interested in. He sees its name, description and list with events that have already happened. User can send his Observation by answering questions that are connected with events – each new event is a trigger and can change the set of questions.

OST Server does not provide data about events, it is responsible for data exchange but not for preparing them. It receives data packages about events and simulation time from Test – bed and reacts on triggers. Events can be also sent directly to users by Trial Manager.

If events are sent from Trial Manager, OST Server publishes them both to Test-bed and to the user. Trial Manager not only manages the trial and user but also prepares environment to obtain information that are needed. He is responsible for projecting questions and question types. Contents of questions and number of them are optional, only the form is imposed.

When Test-bed sends package with data about events and time, OST Server notifies Trial Manager and users about new event. OST Server reacts on triggers and matches proper set of questions, which are sent to Trial Manger and then published to Observer. When Observer sends his Observations, Trial Manager collects obtained data and has displayed reports about them and if he needs it he can generate it in CSV.

Questions have different purposes, which are indicated in Observation Types. Great advantage of it is getting better criteria of comparison. Database with observations is more varied but it also connects categories, so analysing is more efficient. Correctly prepared questions and labels lead to most efficient results and better conclusion. Questions can have also different answer type such as slider, checkboxes, radio buttons and text field. With sending Observation user can also add some extra material such as additional description, voice record, picture or location. Each observation refers to participant and enables change of time.

5.9. After-Action-Review (AAR)

5.10. Security Services

5.11. Play service

Related to this service is the open source csCOP (Common Operational Picture) tool, which can be used as a COP during a trial, but which can also be used to test the messages published by simulators and solutions.

5.12. Message Injector

5.13. Data services

Related to these data services is the AVRO schemas repository, which contains all the schema's that have been used (so far).

5.14. Docker-composer

Previous4. Aims Next6. Conclusions and way forward

Last updated 6 years ago