Design and development of touch-sensitive GUIs for a rapid deployment unit for emergency communications

Projecte Final de Carrera Design and development of touch-sensitive GUIs for a rapid deployment unit for emergency communications Author: Miquel Puig i Pey Director: Maci`a Mut Vidal Supervisor: Marta Fairen Gonzalez Final project for the degree in Enginyeria en Inform`atica done at TriaGnoSys GmbH Weßling, May 2016 “A picture is worth a thousand words. An interface is worth a thousand pictures.” Ben Shneiderman UNIVERSITAT POLIT` ECNICA DE CATALUNYA Resum Facultat d’Inform`atica de Barcelona Enginyeria en Inform`atica Design and development of touch-sensitive GUIs for a rapid deployment unit for emergency communications de Miquel Puig i Pey TriaGnoSys actualment participa al projecte europeu de recerca ABSOLUTE (Aerial Base Stations with Opportunistic Links for Unexpected and Temporary Events). Aquest projecte pret´en introduir una xarxa UMTS i LTE de desplegament r`apid basada en Plataformes de baixa altitud (LAPs) i Unitats M`obils Terrestres Portables (PLMUs) per a donar suport a les activitats d’emerg`encia en cas de cat`astrofe. En la xarxa ABSOLUTE, el tr`afic de veu i dades de les v´ıctimes i les unitats d’emerg`encia s’enruta a trav´es de les PLMU i d’enlla¸cos per sat`el·lit Ka-band cap a les xarxes p´ubliques, Internet o un centre de coordinaci´o d’emerg`encies remot. En aquest context, la PLMU agrega m´ultiples sistemes de comunicaci´o interoperables gestionats pels usuaris de la PLMU. Aquest projecte compr`en el desenvolupament de dues interf´ıcies d’usuari: una per als equips d’emerg`encia a trav´es d’una pantalla t`actil en la PLMU o en els seus propis dispositius m`obils i la segona per a les v´ıctimes a trav´es dels seus propis dispositius m`obils (tel`efons, tablets) per a enviar missatges de socors a la PLMU. UNIVERSITAT POLIT` ECNICA DE CATALUNYA Resumen Facultat d’Inform`atica de Barcelona Enginyeria en Inform`atica Design and development of touch-sensitive GUIs for a rapid deployment unit for emergency communications de Miquel Puig i Pey TriaGnoSys actualmente participa en el proyecto europeo de investigaci´on ABSOLUTE (Aerial Base Stations with Opportunistic Links for Unexpected and Temporary Events). Este proyecto pretende introducir una red UMTS y LTE de despliegue r´apido basada en plataformas de baja altitud (LAPs) y Unidades M´oviles Terrestres Portables (PLMUs) para dar soporte a las actividades de emergencia en caso de cat´astrofe. En la red ABSOLUTE, el tr´afico de voz y datos de las v´ıctimas y las unidades de emergencia se enruta a trav´es de las PLMU y de enlaces por sat´elite Ka-band hacia las redes p´ublicas, Internet o un centro de coordinaci´on de emergencias remoto. En este contexto, la PLMU agrega m´ultiples sistemas de comunicaci´on interoperables gestionados por los usuarios de la PLMU. Este proyecto comprende el desarrollo de dos interf´ıcies de usuario: una para los equipos de emergencia a trav´es de una pantalla t´actil en la PLMU o en sus propios dispositivos m´oviles y la segunda para las v´ıctimas a trav´es de sus propios dispositivos m´oviles (tel´efonos, tablets) para enviar mensajes de socorro a la PLMU. UNIVERSITAT POLIT` ECNICA DE CATALUNYA Abstract Facultat d’Inform`atica de Barcelona Enginyeria en Inform`atica Design and development of touch-sensitive GUIs for a rapid deployment unit for emergency communications by Miquel Puig i Pey TriaGnoSys currently participates in the European research project ABSOLUTE (Aerial Base Stations with Opportunistic Links for Unexpected and Temporary Events). This project will introduce a rapidly deployable UMTS and LTE network based on Low Altitude Platforms (LAPs) and Portable Land Mobile Units (PLMUs) for the support of disaster-relief activities. In the ABSOLUTE network, voice and data traffic from victims and/or first responders is routed through the PLMU and backhauled over Ka-band satellite links to public networks, the Internet or to a remote emergency coordination centre. In this context, the PLMU aggregates multiple interoperable communication systems steered by the PLMU users. The current thesis tackles the functionalities of the PLMU-user interface through the design of two Graphical User Interfaces: one to be used by First Responders through a touchscreen in the PLMU and on their own mobile devices and the second one to be used by Victims on mobile devices (smartphones, tablets) to send distress messages to the PLMU. Acknowledgements I want to thank all the people working at TriaGnoSys GmbH that have made this six months an amazign adventure, especially the ABSOLUTE team: Vincent, Raquel, Ga¨etan and specially my supervisor, Maci`a. Also Dani, for putting the fun in it. I want also to thank my whole family, for being so supportive when I decided to leave for Finland and when I returned with a new destination: Munich. I want to apologize for all the missed events, not only to my family but also to my friends. Finally, I want to express my gratefulness to all the people I have met in this adventure and that have treated me so well, making much easier to be away. Vielen Dank! Figure 1: The ABSOLUTE team at the final presentation of this final project at TriaGnoSys GmbH (Weßling, Germany, 23/07/2014) v Contents Resum ii Resumen iii Abstract iv Acknowledgements v Contents vi List of Figures viii List of Tables ix Abbreviations x 1 Introduction 1 1.1 Contents and aims ............................... 1 1.2 Development Methodology ........................... 2 1.3 Planning ..................................... 2 1.4 Project costs .................................. 3 2 The ABSOLUTE project 4 2.1 Description and aims .............................. 4 2.2 Overall architecture .............................. 5 2.3 Terrestrial Network ............................... 6 2.3.1 Description and role .......................... 6 2.3.2 Software architecture overview .................... 7 3 PLMU API 9 3.1 Context and aim of the API .......................... 9 3.2 Previous work .................................. 9 3.3 Design ...................................... 10 3.3.1 API resources .............................. 11 3.3.2 Data format ............................... 12 vi Contents vii 4 PLMU WS 19 4.1 Context and use ................................ 19 4.2 Message format design ............................. 20 4.2.1 Container message ........................... 20 4.2.2 Data types ............................... 22 5 Command & Control GUI 25 5.1 Previous work .................................. 25 5.1.1 Requirements .............................. 26 5.1.2 Mockups ................................ 27 5.2 Design & implementation ........................... 29 5.2.1 Software architecture .......................... 29 5.2.2 Components .............................. 32 5.2.3 Frameworks & libraries ........................ 37 6 Victims GUI 44 6.1 Previous work .................................. 45 6.1.1 Requirements .............................. 45 6.1.2 Mockups ................................ 45 6.2 Design ...................................... 48 6.3 Implementation ................................. 49 6.3.1 Software architecture .......................... 50 6.3.2 Frameworks & libraries ........................ 52 7 Conclusions and future work 53 7.1 Conclusions ................................... 53 7.1.1 Achieved goals ............................. 53 7.1.2 Non-considered goals .......................... 53 7.2 Future work ................................... 54 7.2.1 Technician GUI ............................. 54 7.2.2 Victims Control GUI .......................... 54 A Gantt diagram 56 B PLMU API previously identified resources 58 C Mockups 62 Bibliography 77 List of Figures 1 The ABSOLUTE team at the final presentation of this final project at TriaGnoSys GmbH (Weßling, Germany, 23/07/2014) ............ v 2.1 ABSOLUTE architechure ........................... 5 2.2 PLMU architechure ............................... 6 2.3 Software architechure .............................. 7 3.1 API resources .................................. 12 3.2 API data definition ............................... 14 5.1 C2 GUI mockup: messaging .......................... 27 5.2 C2 GUI mockup: map ............................. 28 5.3 C2 GUI mockup: system ............................ 28 5.4 C2 GUI software architecture ......................... 30 5.5 C2 GUI update cycle .............................. 32 5.6 C2 GUI modules driagram ........................... 32 5.7 C2 GUI messaging modules .......................... 33 5.8 C2 GUI map modules ............................. 34 5.9 C2 GUI system modules ............................ 35 5.10 C2 GUI communication controller ...................... 35 5.11 C2 GUI message adapter ............................ 36 5.12 Message adaptation process .......................... 37 5.13 Sample jQuery Mobile screen ......................... 39 5.14 Less code for DM filtering ........................... 40 5.15 Generated CSS code for DM filtering ..................... 41 5.16 Sample Handlebars template ......................... 42 5.17 RequireJS configuration excerpt ........................ 43 6.1 VGUI main screen ............................... 46 6.2 VGUI main screen ............................... 46 6.3 VGUI main screen ............................... 47 6.4 VGUI first implementation .......................... 47 6.5 VGUI first implementation .......................... 48 6.6 VGUI workflow ................................. 49 6.7 VGUI calls ................................... 50 7.1 VCGUI ..................................... 55 viii Chapter 2 The ABSOLUTE project 2.1 Description and aims The ABSOLUTE project, co-founded by the European Commission under the SEVENTH FRAMEWORK PROGRAMME aims to introduce a rapidly deployable UMTS and LTE network based on Low Altitude Platforms (LAP) and Portable Land Mobile Units (PLMU) for the support of disaster relief activities. In the aftermath of an emergency, disaster or related unexpected events; telecommunication infrastructures play a key role in recovery operations. In most cases, the terrestrial infrastructure is seriously compromised and cannot guarantee reliable services for citizens and rescue teams. It is also well accepted that current public safety networks cannot provide sufficient capacity for broadband applications. In the consequences of a disaster, the promptness, coordination and effectiveness of support actions can be dramatically improved by the availability of a communication system capable of offering in a quick and reliable manner, broadband links to interconnect different devices among each other as well as with remote operation centres. In order to achieve these goals, the ABSOLUTE system has been envisioned and will be developed following an approach that combines terrestrial, aerial and satellite communication capabilities. 4 Chapter 2. The ABSOLUTE project 5 2.2 Overall architecture The ABSOLUTE system architecture is designed with the aim to provide a network that is resilient and capable of providing Broadband multiservice, secure and dependable connectivity for large coverage areas affected by large scale unexpected events or disasters leading to the partial or complete unavailability of the terrestrial communication. The main elements of the system architecture, as shown in figure 2.1, are: •Low altitude Aerial LTE-A Base Stations (AeNB), embedded in LAPs providing high data rates and coverage areas. •Portable Land Mobile Units with LTE-A Base Stations interoperable with conventional PPDR systems (TETRA base stations) and Wireless Sensor Networks (through a Wireless Sensor Gateway), enabling dedicated coverage and broadband satellite backhauling capabilities in Ka-Band. •Advanced multimode LTE-A Professional Terminals (MM-UE) enabling direct mode LTE communications (LTE D2D) and direct messaging services via S-band satellite when outside of TeNB or AeNB coverage) Figure 2.1: Overall view of the complete architecture of the ABSOLUTE system. Chapter 2. The ABSOLUTE project 6 2.3 Terrestrial Network 2.3.1 Description and role The terrestrial network subsystem is a multimode lightweight energy-efficient Portable Land Mobile Unit (PLMU) which is deployed in adverse terrain where dedicated coverage requirements and network coordination are required, but which is not covered by the LAP(s). In the ABSOLUTE network, voice and data traffic from victims and first responders is routed through the PLMU and backhauled over Ka-band satellite links to the PSTN, the Internet or to a remote emergency coordination center. In this context, the PLMU aggregates multiple interoperable communication systems steered by the PLMU users. Figure 2.2: Overall view of the architecture of the PLMU subsystem. The PLMU is a standalone and self-sufficient communications platform. It provides a variety of communication services to the users of the ABSOLUTE system, as shown in figure 2.2. The PLMU developed within the ABSOLUTE project should include any combination of the following communication systems: •Mobile telephony and data over UMTS •Mobile telephony and data over LTE/LTE-A Chapter 2. The ABSOLUTE project 7 •Professional mobile radio over TETRA •Wireless connectivity (IEEE 802.11) •Data collection for a Wireless Sensor Network •Remote communication over a satellite link 2.3.2 Software architecture overview The software for the PLMU will be developed specifically for the unit and will include different subsystems to control all the communications systems in the PLMU. It will also manage a DB to store both configurations and data from victims, first responders and sensors. Figure 2.3: Overall view of the architecture of the software solution of the PLMU subsystem. As seen on figure 2.3, the functionalities of the system (grey area) will be exposed through a RESTful API that will be used both by the ABSOLUTE GUIs (C2, Victims and Maintenance) and external partners. Chapter 2. The ABSOLUTE project 8 The API and the GUIs, whose design and development process is described in this document (except for the Maintenance GUI which is to be developed in the future), serve as the main communication channel between the PLMU and the users (both FR an victims). they provide with a mean to gather information from victims and a centralized interface to see this information along with other relevant information gathered in the PLMU (such as sensor network data) and with a control interface for the PLMU subsystems. The maintenance GUI, to be developed in the future will allow technical users to change certain configurations of the PLMU. Chapter 3 PLMU API 3.1 Context and aim of the API The PLMU API is mainly aimed to be the interface through which the different GUIs of the ABSOLUTE system create, retrieve, modify and delete data. While this could be achieved in many other (and possibly simpler) ways, it is also aimed as a standard way to access the PLMU resources for future or external clients, were these to be developed. Following this spirit, the API uses standard formats for victims and first responder messages, specifically a subset of the Emergency Data Exchange Language. EDXL is a suite of XML-based messaging standards for emergency information data sharing, and using it will enable our data to be reused by already existing emergency application and also by future systems. 3.2 Previous work Before the start of the design of the PLMU API some work had already been done by the TGS team working on the ABSOLUTE project. Some resources had been identified and some parameters had been envisioned. Also, the general API response behaviour is described alongside such resources in Appendix B. 9 Chapter 3. PLMU API 10 Taking this resources as a starting point and a reference for functionality, the next section documents the final design of the API as it should be implemented for the ABSOLUTE project PLMU. 3.3 Design The API is envisioned to be RESTful-compliant, and as such it tries to follow its rules[1]: •base URI (defined by the server) •an Internet media type for the data (XML and JSON) •standard HTTP methods (GET, PUT, POST and DELETE) •hypertext links to reference related resources (e.g. items in collection identified by ID in URI) Nevertheless, as this API is defined over a limited and already defined set of resources, not all the expressivity and freedom of a RESTful system is needed, and such, for the sake of simplicity, the resources are defined beforehand and are assumed to be known by the clients (serving this document as a reference for future users of the API). As this will be the single interface for interacting with the data available in the PLMU it must implement a way to achieve the four basic methods of data manipulation: create, read, update and delete elements. This four methods, commonly known as CRUD[2] have been mapped as is usual for web APIs to the corresponding HTML methods (also known as HTTP verbs), as is shown in table 3.1. Data manipulation method HTTP method Create POST Read GET Update PUT Delete DELETE Table 3.1: Data manipulation to HTTP method mapping Chapter 3. PLMU API 11 Also, the semantics of the HTTPS methods have been maintained to keep it as standard as possible, and so the GET requests are nullipotent (they are safe[3] requests and have no side effects on the state) and the PUT and DELETE requests are idempotent[4] (multiple identical requests have the same effect as a single request) while the POST method is neither one nor the other (it effectively modifies the state by adding new items and multiple identical request produce multiple new different elements that, albeit having the same information, are treated as different, single elements. 3.3.1 API resources The API resources have been defined taking as a starting point the work described in the “Previous Work” section, with some minor modifications regarding resource grouping and hierarchy and adding ID-based URIs to adhere to the REST architecture and to achieve full CRUD functionality. The final design of the resources follows a typical approach with a base resource for a collection of elements of the same kind (e.g. /messages/DM for distress messages) which accepts GET (get whole collection) and POST (add a new element to collection) requests (the latter only in the /messages and /maps/custom collections, since the other collections’ items depend on physical elements and cannot be logically added/removed through the API). The collections’ individual items are addressable by appending their ID to the collection URI (e.g. /messages/DM/1 for distress message with ID 1). Message collections individuals accept GET (retrieve item), PUT (modify item) and DELETE (remove item) requests. The other collections’ individuals accept only GET and PUT requests, since they refer to physical elements that cannot be logically added and removed. The final defined resources with the methods they accept are shown in figure 3.1. The default return format for all GET requests is XML, nevertheless, all GETtable resources accept an optional asJSON boolean parameter (otherwise defaults to false) that allows the client to request the information in the JSON format. Moreover, some Chapter 3. PLMU API 12 Figure 3.1: Diagram of the API resources and their accepted HTTP methods. resources also accept other filtering parameters. All parameters are summarised in table 3.2. The data return or request formats for each resource are specified in the next section and are summarized in table 3.3, where also HTTP status code[5] is specified for successful request signaling: GET requests return HTTP 200 OK, POST requests return HTTP 201 Created and PUT requests return HTTP 202 Accepted. 3.3.2 Data format The data format definition has followed two different approaches. For the distress and FR messages (/FR and /DM) the EDXL standard has been used, since it allows easy data exchange with external providers/consumers which is of paramount importance in the case of disaster relief situations. In the other resources, unlike in the messages where an established standard existed, and since the resources are very specific to the PLMU, a custom data format has been defined. These data formats are defined in this section, and the data diagram is shown in figure 3.2. This is the complete definition of all the data formats of the API. Although all this data is returned in the XML format, a higher level description is provided in this section. Each element property is defined, its domain (valid range of values) is given and its Chapter 3. PLMU API 13 Resource Parameter Domain Description * asJSON boolean Return data in JSON format. /messages/FR before timestamp Retrieve messages from before a given time. /messages/FR after timestamp Retrieve messages from after a given time. /messages/FR hasLocation boolean Retrieve only geolocated messages. /messages/FR hasPicture boolean Retrieve only messages with images. /messages/DM before timestamp Retrieve messages from before a given time. /messages/DM after timestamp Retrieve messages from after a given time. /messages/DM urgency urgency1[*] Retrieve messages with a given urgency/ies. /messages/DM severity severity [*] Retrieve messages with a given severity/ies. /messages/DM hasLocation boolean Retrieve only geolocated messages. /messages/DM hasPicture boolean Retrieve only messages with images. /maps/custom type boolean Retrieve map items of a given type/s. /sensors metric(s) TBD TBD. Table 3.2: GET requests optional parameters Path GET: 200 OK POST: 201 Created PUT: 202 Accepted /messages/FR FRSet FR /messages/FR/<id>FR FR /messages/DM DMSet DM /messages/DM/<id>DM DM /maps/custom Map MapItem /maps/custom/<id>MapItem MapItem /sensors SensorSet /sensors/<id>Sensor Sensor /subsystems System /subsystems/<id>Subsystem Subsystem Table 3.3: Resource data definition for different requests Chapter 4. PLMU WS 20 To implement this, we use plain HTML5 WebSockets because almost all modern web browsers support them1, even those for mobile devices. This eases the implementation also on the server, since it doesn’t have to deal with fallback alternatives. 4.2 Message format design 4.2.1 Container message Field Cardinality Definition Domain sender 1 ID of the sender String type 1 Message type String data 1 Payload DataItem Table 4.1: Definition of the container message for the WS messages for the ABSOLUTE system. All the messages that the servers sends consist of a container message (table 4.1), which itself contains the sender ID (for now the server is the only sender in the system, but this could change in the future), the type of message and its data. All the valid message types and its associated data types (defined in next section) are shown in table 4.2. 1http://caniuse.com/websockets Chapter 4. PLMU WS 21 Type Definition Data type dm-add A new DM added in the system DM dm-update An update on an existing DM DM dm-delete ID of the DM to delete String fr-add A new FR message added in the system FR fr-update An update on an existing FR message FR fr-delete ID of the FR message to delete String map-add A new map item added in the system MapItem map-update An update on an existing map item MapItem map-delete ID of the map item to delete String system-add A new subsystem added in the system Subsystem system-update An update on an existing subsystem Subsystem system-delete ID of the subsystem to delete String dm-delete-all Delete all the DMs - fr-delete-all Delete all FR messages - energino-update New information from the Energino module EnerginoData sensors-update New information from the WSG SensorNode Table 4.2: Definition of the valid message types for the WS messages for the ABSOLUTE system and their associated data type. Chapter 4. PLMU WS 22 4.2.2 Data types Although the PLMU can store much more information than the displayed in the GUIs only the minimum information is transmitted through the WS to save bandwidth and simplify as much as possible the debugging of these messages. 4.2.2.1 DM Field Cardinality Definition Domain id 1 Unique ID of the DM String name 1 Human-readable name String timestamp 1 Creation time Integer text 1 Distress message text String priority 1 Mapped to EDXL-CAP priority {high, med, low, solved, none} position 1 Coordinates of the DM String of two commaseparated floats Table 4.3: DM websocket data definition 4.2.2.2 FR Field Cardinality Definition Domain id 1 Unique ID of the FR String name 1 Human-readable name String timestamp 1 Creation time Integer text 0..1 Report text String image 0..1 Attached image URL String video 0..1 Attached video URL String position 0..1 Coordinates of the FR String of two commaseparated floats Table 4.4: FR websocket data definition 4.2.2.3 MapItem Data definition from additional types can be found in Chapter 3. Chapter 4. PLMU WS 23 Field Cardinality Definition Domain id 1 Unique identifier of the map item String name 1 Human-readable name String text 0..1 Description of the item String type 1 Type of element {plmu, lap, area} position plmu/lap: 0..1 area: 1 Location of the element Position risk plmu/lap: 0 area: 1 Type of area to draw (high risk, low risk, safe zone). Not applicable for plmu/lap types. {high, low, safe} Table 4.5: Map item websocket data definition Chapter 4. PLMU WS 24 4.2.2.4 SensorNode Field Cardinality Definition Domain name 1 Sensor node name String located 1 Whether the sensor has a location Boolean position 0..1 (if located: 1) Location of the node Position timeFrequency 1 Refresh frequency of the node (in seconds) Integer sensorInfo 1..* Information of the sensors in the node URL SensorInfo Table 4.6: Sensor node websocket data definition Data definition from additional types can be found in Chapter 3. 4.2.2.5 Subsystem Field Cardinality Definition Domain id 1 Identifier of the subsystem String name 1 Human-readable name String status 1 Indicates whether the subsystem is active or not {on, off} usage 1 Indicates approximate use of the subsystem (load) {high, moderate, low, none} load 1 Indicates the current system load Integer maxLoad 1 Indicates the maximum load the system can handle Integer Table 4.7: Subsystem websocket data definition Chapter 5 Command & Control GUI The design and implementation of the Command & Control (C2) GUI is the most important part of this project, not only because it is by far the most complex piece of sofware, but also because it incorporates almost all of the other tecnhlogies, protocols and services designed and/or implemented as part of this project. This GUI aggregates all the functionalities of the PLMU that can be controlled by the operator, split in three main views: messaging, map and system. Through this GUI the operator and the FRs can control both the state of the emergency situation (through the messaging and map views) and the state of the PLMU itself (through the system view). For demonstration purposes, a “technician” mode was added to this GUI which enables additional features that would only be available to a technical expert in a real-world product. 5.1 Previous work At the beginning of this project, two pieces of information were provided to start with the development of the C2 GUI: a deliverable of the ABSOLUTE project containing the requirements of all the components and some mockups. 25 Chapter 5. Command & Control GUI 26 5.1.1 Requirements The deliverable D2.4.2 (System Requirements) of the ABSOLUTE project contains all the requirements for the absolute system. The requirements relevant to the C2 GUI are summarized in table 5.1, along with their accomplishment status. In this table are also shown the criticality of the requirement (optional or must have) and the setup that must comply with it (demo or final product). Number Statement Criticality Compliant setup Accomplishment PU F 7027 The PLMU shall provide a news feed about the deployment situation Optional Final OK PU F 7029 The PLMU application server shall provide information about the deployment situation Optional Final OK PU F 8012 The PLMU text markings shall be written in English Must have Demo OK PU F 8016 The PLMU shall have a maintenance GUI Optional Final OK PU F 8028 The PLMU GUI language shall be in English by default Must have Final OK PU F 8029 The PLMU GUI language shall be configurable to any of the 23 official languages of the European Union Optional Final Not accomplished PU F 7040 The PLMU shall allow viewing location data on a map Must have Final OK Table 5.1: Requirements from the ABSOLUTE D2.4.2 deliverable relevant to the C2 GUI Chapter 5. Command & Control GUI 27 5.1.2 Mockups The following images are the result of the work of the staff of TriaGnoSys GmbH before the start of this final project, as a way to demonstrate the intended look of the C2 GUI. The design and implementation of this GUI has been done so as to adhere as much as possible to these mockups while complying with the requirements of the previous section. Here only the basic mockups are shown, the complete set can be found in appendix C. Figure 5.1: Mockup of the messaging tab of the C2 GUI Figure 5.1 shows the messaging tab of the C2 GUI. It is divided in two, the DM are shown in the left and the FR messages in the right. For each DM a row of buttons allows to change the priority of the message. Both DMs and FR messages can have a location (displaying it in a small map). There is also a form to add new FR messages. Figure 5.2 shows the map view of the emergency situation. It has a layer filtering system to select which elements to see and allows to drag non-located elements to their desired position. It also allows to add some custom items such as zones. Chapter 5. Command & Control GUI 28 Figure 5.2: Mockup of the map tab of the C2 GUI Figure 5.3: Mockup of the system tab of the C2 GUI Chapter 5. Command & Control GUI 29 Finally, figure 5.3 shows the system tab of the C2 GUI. It shows the power status of the different subsystems and its current load. It also allows to the operator to turn on/off systems (e.g. Turn off a system that is not being used to save power). 5.2 Design & implementation The C2 GUI is a complex piece of software that manages a lot of different types of data, displayed in a wide array of views. For this reason, there is a need for some order in the code, specially concercing the data synchronization. This is achieved through the use of a framework. The chosen framework is Backbone (see section 5.2.3.2), because it allows us to use only the parts that we need (as opposed to others, such as AngularJS1, which come with a richer set of features) and also it gives us more freedom on the implementation of the views. Also, since the C2 GUI has some needs that have very well-known solutions, other frameworks and libraries have also been used to achieve them. In this section both the general software architecture and the libraries used are explained. 5.2.1 Software architecture The main architectural pattern followed in the design of the C2 GUI is Model-View- Controller (MVC). This pattern divides the application into three interconnected parts, separating the internal representation of the information, the handling of changes and the presentation to the user. Figure 5.4 shows a simplified diagram of the C2 GUI general architecture. The C2 GUI is divided into 4 main types of objects: models, views, controllers and a special type of controller that is in charge of the communication between the C2 GUI and the server. This special controller also uses another special object that is in charge of translating the XML messages recieved from the server to native Javascript object and vice versa. 1https://angularjs.org/ Chapter 5. Command & Control GUI 36 The communication controller is the object in charge of reacting to all the events fired by the controllers, taking the data they carry, converting it to the appropiate XML update message and send it to the API (through the corresponding post, put or delete function). It also provides the APIfetch function, used by the collection to get data from the API, indicating where to store the retrieved data and which processing function to use. This object also contains the connection object to the Websocket server and reacts to the messages recieved from it by updating the appropiate collection, which in its turn will fire the appropiate event that will trigger the correspondig view update. 5.2.2.5 Message adapter Figure 5.11: Object diagram of the message adapter of the C2 GUI. The MessageAdapter object is used to translate the XML converted in the collection convert function to an object containing only the information that will be displayed and cast it to the appropriate types if necessary. Essentially, it acts as a filter, picking the fields we want from the converted XML. Figure 5.12 shows how the complete process from raw XML response from the API is transformed to a Javascript object that will be fed to the model. The lines show how our information is changed and casted. Blue lines indicate our information goes from the XML version of the data to the Javascript object version. Green arrows indicate a name change and dotted arrows indicate also a data cast or conversion. Chapter 5. Command & Control GUI 37 Figure 5.12: Example of the process of adapting and transformation of a message from raw XML to a native object. 5.2.3 Frameworks & libraries Since this software aggregates multiple functionalities that have well known solutions it makes extensive use of many Javascript libraries for many things from map display to data conversion. 5.2.3.1 jQuery family jQuery jQuery is a cross-platform JavaScript library designed to simplify the clientside scripting of HTML. It is free, open-source software licensed under the MIT License. jQuery is, in its most basic use, a DOM2manipulation library, simplifying the syntax for finding, selecting and manipulating DOM elements. The main advantages of using jQuery are: •Separation of HTML and JS: simplifies the addition of event handlers to the DOM, avoiding the use of HTML event attributes to call JS functions. •Brevity and clarity: jQuery code is much simpler and easier to read than plain JS, thanks to features such as chainable methods and shorthand functions. 2The DOM is a tree-structure representation of all the elements of a Web page, see https://en. wikipedia.org/wiki/Document_Object_Model Chapter 5. Command & Control GUI 38 •Eliminates cross-browser incompatibilities: it provides a consistent interface that works across all browsers, abstracting the subte differences in JS implementation across them. •Extensible: jQuery provides an interface to extend it and create plugins, such as the ones used in this project, jQuery Mobile and jQuery UI, built atop jQuery. jQuery Mobile jQuery Mobile3is a touch-optimized4web framework, in the form of a JavaScript library, build atop jQuery and developed by the jQuery team. It allows us to easily define screens, this is, the different pages, using HTML5 semantic elements. In the C2 GUI jQueryMobile is used as its main application layout framework, since it is intended to be use mainly by touch-enabled devices such as smartphones and tablets. This frameworks provides us with a basic application display structure (the three tabs view) and takes care of the switching between them. It also provides the side panels that are used for menus for the different subviews. In figure 5.13 we can see an example5of how a page is defined using jQuery Mobile, with the following noteworthy elements: •A div with an attribute data-role=”page”. The id serves as the page id (for navigating between pages). •A div with an attribute data-role=”header” designating the header. item A div with an attribute role=”main” defines the page contents. •A link (HTML tag ”a”) with an id of a page will cause the link to navigate to that page on click. jQuery UI jQuery UI is a collection of GUI widgets, animated visual effects, and themes implemented with jQuery, Cascading Style Sheets, and HTML. Both jQuery and jQuery UI are free and open-source software distributed by the jQuery Foundation 3https://jquerymobile.com/ 4Which is of great help in the context of this project 5This example is taken from the Victims GUI, explained in chapter 6, for its simplicity Chapter 5. Command & Control GUI 39 <div id="page-sent-basic" data-role="page"> <div data-role="header" data-position="fixed" data-tap-toggle="false"> <h1>Ask for help</h1> </div> <div role="main" class="ui-content"> <h2 class="success-title">Message sent</h2> <p style="text-align: center;"> Your message has been successfully sent. <br /> Help will arrive as soon as possible. </p> <hr style="margin: 50px 0;"/> <h2>Provide details</h2> <p> You might want to provide additional details to the emergency services. </p> <a href="#page-details" data-role="button" id="button-provide-details" data-theme="b"> Provide details </a> </div> </div> Figure 5.13: Sample jQuery Mobile screen under the MIT License. In this GUI, its drag & drop functionalities are used, to add markers to the map. 5.2.3.2 Backbone The C2 GUI uses Backbone6for the data management. This allows us to benefit from the Model-Collection-View structure it provides and its event system on data modification, to react and change the corresponding view. The use of Backbone also imposes another dependency on us, in the form of another Javascript library: underscore.js. This library provides utility functions for common programming tasks, divided in four main categories depending on the data types which they manipulate: functions for manipulating arrays, functions for manipulating objects, 6The concrete use of Backbone is explained throughout section 5.2.1 Chapter 5. Command & Control GUI 40 #dm-board { .dm-item { display:none; } } .loop-show-dm(@prios,@index:1)when (isstring(extract(@prios,@index))) { @prio:extract(@prios,@index); @outer: ~"#dm-board.show-@{prio}"; @inner: ~".dm-item.dm-@{prio}"; @{outer} { @{inner} { display:block; } } .loop-show-dm(@prios, (@index +1)); } .loop-show-dm("high","med","low","solved","none";); Figure 5.14: Less code for DM filtering functions for manipulating both arrays and objects (the name of the category is ”Collections”) and functions for manipulating other functions. 5.2.3.3 Less Less is a CSS-preprocessor that extends the CSS language allowing for a more powerful and expressive syntax with variables, mixins, functions and many others that allow for a much more extensible and maintainable code. Less is compiled to plain CSS (whether in real time via Javascript when the page is loaded or precompiled and the CSS output added to the page) so it does not add a new dependency layer but rather allow the programmer to write normal CSS with a much better sintax and capabilities. Figures 5.14 and 5.15 show the Less code used to generate the filtering styles for DM messages, demonstrating the loop capabilities to generate repetitive code; and the generated equivalent CSS code. Chapter 5. Command & Control GUI 41 #dm-board .dm-item { display:none; } #dm-board.show-high .dm-item.dm-high { display:block; } #dm-board.show-med .dm-item.dm-med { display:block; } #dm-board.show-low .dm-item.dm-low { display:block; } #dm-board.show-solved .dm-item.dm-solved { display:block; } #dm-board.show-none .dm-item.dm-none { display:block; } Figure 5.15: Generated CSS code for DM filtering 5.2.3.4 Templating libraries As explained in this chapter, this application uses the Handlebars7templating system to render its views. With this, the different HTML representations of each element of a view are stored as partial HTML files with .hbs extension and loaded asynchronously through the template manager. This allows for a complete separation of the data and how it is presented to the user. The templates contain the structure with some special placeholders for where the data will be rendered but no data at all, and the data does not know nor care how it will be represented to the user. Figure 5.16 shows a sample of this templates, used to render a map pin content for a DM. 5.2.3.5 Map-related libraries For the application maps, Leaflet is used. Leaflet8is an open-source lightweight library for mobile interactive maps. It provides us with a way to display a map to the user and 7http://handlebarsjs.com/ 8http://leafletjs.com/ Chapter 5. Command & Control GUI 42 <div class="pin-dm" abs-id="{{ id}} "> <i class="fa fa-bell {{ priority}} "></i> <span class="name">{{ name}} </span><br /> <span class="timestamp">{{ #date timestamp}}{{ /date}} </span><br /> <p class="text">{{ text}} </p> </div> Figure 5.16: Sample Handlebars template lets us add elements to this map. To add the interactivity our map needs the leafletdraw9addon is used. This allows us to add, edit and remove the current markers on the map. Also in the context of maps, Chart.js is used to display the data history for the sensor nodes. Chart.js10 is a simple library to plot data based on HTML standards and with responsive capabilities, that suit very well the needs of this application. 5.2.3.6 XML conversion Since our server uses XML as a data exchange language we need a way to convert this into a Javascript object that we can use. For this we use the xml2array11 library which takes an XML string or preparsed document and transforms it into a native Javascript array. This array is later processed and converted into the data we want, as explained earlier in this chapter. 5.2.3.7 RequireJS RequireJS is a Javascript file and module loader. It is optimised for in-browser use, but it can be used in other Javascript environments, its use greatly improves the speed, load time and organisation of the code. In figure 5.17 we can see an excerpt of the configuration file for RequireJS in the C2 GUI. It is composed of three elements: 9https://github.com/Leaflet/Leaflet.draw 10http://www.chartjs.org/ 11http://www.openjs.com/scripts/xml_parser/ Chapter 5. Command & Control GUI 43 require.config({ paths:{ // [...] ’backbone’ :’vendor/backbone’, // [...] ’App’:’App’, // [...] }, shim:{ // [...] ’backbone’:{ exports:’Backbone’, deps:[’underscore’], }, // [...] ’App’:{ deps:[’TemplateManager’,’commons’,’xml2array’,’jquery-mobile’, ’touch-punch’,’handlebars-helpers’,’less’,’Listeners’, ’leaflet’,’leaflet-draw’,’CommunicationController’,’FRTypes’, ’DMTypes’,’MapTypes’,’SystemTypes’], }, // [...] }, }); /** * Application entry point */ require([’App’], function () { // [...] }); Figure 5.17: RequireJS configuration excerpt •Path definition for every library to be used. •Exports and dependencies definition. Dependencies of a module will be loaded before it. Only exported objects will be usable outside a module. •Require call. In this case, a call to the app code, which will initialize all the other modules, on which it depends. Chapter 6 Victims GUI The Victims GUI is the counterpart of the C2 GUI on the victims side. It allows for the capture of vital information in an emergency situation: everything concerning the victims, their number, conditions and distribution. This is key when planning a rescue in an adverse scenario, so we must capture the key essential information as soon as possible to allow the rescue teams to start their work as soon as possible. In this GUI the crucial aspect is ease of use. The interface must be very intuitive, as clean and simple as possible, since the users are not trained beforehand to use it and are usually in a very stressful situation. This GUI was designed following a clear iterative process with two iterations. This is because a preliminar version developed following strictly the mockups (found in Appendix C) was presented at the midterm presentation hosted at TriaGnoSys GmbH on May 7th 2014 and after collecting and analysing the feedback received, a two-part interface with much less required information and a much simpler first part was developed, allowing for easier recopilation of the most immediately needed data: only what was going to be displayed to the first responders in the C2 GUI, leaving all the accessory information for a second, optional part. 44 Chapter 6. Victims GUI 45 6.1 Previous work As for the C2 GUI there were only two sources of information to refer to when the project started: the requirements deliverable of the ABSOLUTE project and the mockups created by TriaGnoSys GmbH. 6.1.1 Requirements The requirements were almost nonexistent in relation to the Victims GUI in the D2.4.2 deliverable: only one relevant requirement could be identified, as reported in table 6.1. Although there was only one requirement it was a must have for the final product, and as such it had to be fulfilled in this final project. Number Statement Criticality Compliant setup Accomplishment PU F 7038 The PLMU shall provide a user with a preemption means to send short data messages including location data obtained by their personal GPS Must Have Final OK Table 6.1: Requirement from the ABSOLUTE D2.4.2 deliverable relevant to the Victims GUI 6.1.2 Mockups The mockups presented in this section have been the main guideline followed during the design and development of the Victims GUI. Nevertheless, the final result is quite different from the mockups presented in this section, because after an iterative process of refinement and especially after the midterm presentation of the project, the feedback was clear to simplify the design of the GUI or the users would totally reject it. Figure 6.1 shows the first screen presented to the user on load. The interface is cluttered with fields, many of which required, which makes the use of the interface really hard. This goes against the initial idea of the interface: ease of use and simplicity. Chapter 6. Victims GUI 52 6.3.2 Frameworks & libraries Given the simplicity of this interface, there is no need for very complex frameworks or libraries, stickying mainly to the jQuery family3for DOM manipulation, including page management. Other libraries used in this interface include Handlebars for templating, explained in section 5.2.3.4 and Less JS, explained in section 5.2.3.3. 3Explained in section 5.2.3.1 Chapter 7 Conclusions and future work 7.1 Conclusions The outcomes of this final project have been deemed satisfactory by both myself and TGS. On a personal level, I have not only put to practice many of the skills acquired during the degree that this project closes, but also learnt a lot about software as a professional developer and about how a real company operates, not to mention the great learning you get from living in a foreign country. 7.1.1 Achieved goals On a purely results-based point of view, the results can also be considered satisfactory. The ABSOLUTE project was a research project. Its aim was never to create a final working product, and even more, this was not the most critical part of the project. The original idea was just to have a simple way to quickly demonstrate the functionalities offered by the designed system. However, the final result of this project has gone probably further than originally expected in providing a good quality interface. 7.1.2 Non-considered goals Of course, many parts have been left out on purpose, to concentrate on the required functionalities of the ABSOLUTE team, probably the most important was to consider the security implications of such critical interfaces. These topics could constitute its 53 Chapter 7. Conclusions and future work 54 own project, or be the task of a professional team expert in this area, if the project was ever to become a commercial product. 7.2 Future work Apart from the aforementioned goals that were explicitly left out of scope, some other possibilities were seen as possible to be implemented, at least partially, atop of the C2 GUI, taking advantage of its modular nature. Two of those ideas are explained next, which were at least partially implemented for the convenience of the ABSOLUTE team who had to continue the project after this final project ended. 7.2.1 Technician GUI The C2 GUI is a GUI aimed at the first responders present on the field, which mostly need the information but do not have the time nor the concentration to administrate it. This is why some editions are possible on the GUI, such as changing the priority or the position of items, but further edition actions, or the ability to delete messages was left out of the interface. This is why a technician interface was envisioned, both as of a way of being able to ease testing (by avoiding manipulation the DB directly when it becomes to cluttered) and to provide a way to showcase these functionalities that are already considered in the API design and implementation. Since this technician interface was to be very similar to the C2 GUI with some extra funcionalities added, it was partially implemented atop of it, displaying the additional features on the very C2 GUI if a parameter technicial=true was provided in the query string1of the page request, and changing the interface colour to red, to make it more visible. 7.2.2 Victims Control GUI At some point at the end of the development phase of the C2 GUI, an idea came up in the team for a GUI that would allow the first responders to focus on the victims only, 1https://en.wikipedia.org/wiki/Query_string Chapter 7. Conclusions and future work 55 leaving all the other functionalities of the PLMU out. This was easily implemented as a copy of the C2 GUI with the unwanted functionalities stripped out, thanks to the modular nature of the implementation. This GUI can be seen on figure 7.1 and it features just the DM section on the left and the map, that used to be on a separate tab, on the right. Figure 7.1: Victims control GUI 56 Appendix A. Gantt diagram 57 Appendix A Gantt diagram Vacation February March April May June July 2014 03 07 10 14 17 21 24 28 03 07 10 14 17 21 24 28 31 04 07 11 14 18 21 25 28 02 05 09 12 16 19 23 26 30 02 06 09 13 16 20 23 27 30 04 07 11 14 18 21 25 28 01 Projectname: ABSOLUTE GUIs Date: Comments: Events Analysis and Study Know project Find suitable frameworks API design Analyse available code Design Document C2 GUI Evaluate mockups Design Implementation Document Testing & fixing Integration Victims GUI Evaluate mockups Design Implementation Document Testing & fixing Integration Thesis writing Project stages ... Appendix B PLMU API previously identified resources Method Resource Parameters Server response GET /messages/FR Optional: •since •until •event type •priority •location •picture •name Returns all the FR messages in an XML format 58 Appendix B. Previous resources 59 GET /messages/DM Optional: •since •until •event type •priority •location •picture •name Returns all the DM messages in an XML format GET /maps/custom Optional: •element type Returns all data related to our custom map in an XML format GET /maps/crisis Optional: •since •until •event type •priority •location •picture •name Returns all the events related to external crisis maps in an XML format Appendix B. Previous resources 60 GET /sensors Optional: •type •ID Returns data measured by all the sensors in an XML format GET /subsystems Optional: •subsystem name •parameter name Returns the status for all the subsystems in an XML format GET /links Optional: •subsystem name Returns the usage for all the subsystems links in an XML format POST /messages/FR Mandatory: •text •name Optional: •place Creates a new FR message with the information provided in the message body POST /messages/DM Mandatory: •text •name Optional: •place Creates a new DM message with the information provided in the message body Appendix B. Previous resources 61 PUT /subsystems Mandatory: •subsystem name •parameters description Updates any parameter in any subsystem Map with sidebar System Map Messaging Copyright TriaGnoSys 2013 S S S Incident zone Sensor Victim LAP S First Unit Control Panel Map layers: First Responders Board content Crisis map Custom scene Edit the custom layer: PLRDU Zone limits LAP Victim S Non-geolocated sensors: S S S S S S S S S S S Sensor 002 Time Temp Time Baterry System Q P O I U Y T R E W Z . : , ; M N B V C X Ctrl ? ! @ SYM A K K J H G F D S Options Menu First Unit Ka Satellite link 3G UMTS T TETRA LTEWLAN Copyright TriaGnoSys 2013 Messaging Map System Sensors First Unit Control Panel Low link usage Moderate link usage High link usage System - Confirmation Q P O I U Y T R E W Z . : , ; M N B V C X Ctrl ? ! @ SYM A K K J H G F D S Options Menu First Unit Ka Satellite link 3G UMTS T LTEWLAN Copyright TriaGnoSys 2013 Messaging Map System Sensors First Unit Control Panel TETRA Yes No Are you sure you want to turn it all off? Low link usage Moderate link usage High link usage C2_ GUI_mockup_energino Exported at: Tue Jan 14 2014 14:14:08 GMT+0100 (CET) System Q P O I U Y T R E W Z . : , ; M N B V C X Ctrl ? ! @ SYM A K K J H G F D S Options Menu First Unit Ka Satellite link 3G UMTS T TETRA LTEWLAN Copyright TriaGnoSys 2013 Messaging Map System Sensors First Unit Control Panel Low link usage Moderate link usage High link usage System - Battery Q P O I U Y T R E W Z . : , ; M N B V C X Ctrl ? ! @ SYM A K K J H G F D S Options Menu First Unit Ka Satellite link 3G UMTS T TETRA LTEWLAN Copyright TriaGnoSys 2013 Messaging Map System Sensors First Unit Control Panel Low link usage Moderate link usage High link usage Time Remaining: 6 hours 15 minutes Victims_ GUI_mockup Exported at: Thu Jan 09 2014 16:34:52 GMT+0100 (CET) DM Form Describe what is wrong: Describe what is wrong: (required) (required) Mark the types of help that you feel is needed: Mark the types of help that you feel is needed: Emergency Medical Services Where is the help needed? Where is the help needed? SEND MESSAGE SEND MESSAGE Law Enforcement Mass Care Search and Rescue Fire fighting Hazardous materials Chemical, Biological, Radiological, Nuclear or Explosives defense (required) (required) Provide additional details Provide additional details OR OR https://absolute ASK FOR HELP ASK FOR HELP ASK FOR HELP ASK FOR HELP Describe what is wrong: Describe what is wrong: Where is the help needed? Where is the help needed? SEND MESSAGE SEND MESSAGE (required) (required) https://absolute ASK FOR HELP ASK FOR HELP ASK FOR HELP ASK FOR HELP Building number/name Building number/name Street number/name Street number/name Postcode/zipcode Postcode/zipcode Landmark/road juntion Landmark/road juntion Describe location Describe location Mobile phone Mobile phone How can we contact you? How can we contact you? (required) (required) Other phone Other phone Email Email Other (Facebook, Twitter...) Other (Facebook, Twitter...) (required) (required) DM Form - Additional Details https://absolute How can you be contacted? How can you be contacted? e-mail, phone number, place,.. Provide additional details Provide additional details ASK FOR HELP ASK FOR HELP ASK FOR HELP ASK FOR HELP SEND MESSAGE SEND MESSAGE What is your name? What is your name? Are you where the help is needed? Are you where the help is needed? Describe the immediate needs in detail: Describe the immediate needs in detail: YES NO https://absolute ASK FOR HELP ASK FOR HELP ASK FOR HELP ASK FOR HELP What is your name? What is your name? Are you where help is needed? Are you where help is needed? YES NO First name First name Last name Last name Mark the types of help that you feel is needed: Mark the types of help that you feel is needed: Emergency Medical Services Hazardous materials Search and Rescue Law Enforcement Fire fighting Mass Care Chemical, Biological, Radiological, Nuclear or Explosives defense Tell us anything to help us find you and Tell us anything to help us find you and help you: Provide additional details How many people are with you? How many people are with you? DM Form - Additional Details - Not at help site https://absolute How can you be contacted? How can you be contacted? e-mail, phone number, place,.. Provide additional details Provide additional details Where are you? Where are you? ASK FOR HELP ASK FOR HELP ASK FOR HELP ASK FOR HELP SEND MESSAGE SEND MESSAGE What is your name? What is your name? YES NO Are you where the help is needed? Are you where the help is needed? Describe the immediate needs in detail: Describe the immediate needs in detail: Notification Your message has been successfully sent Your message has been successfully sent https://absolute ASK FOR HELP ASK FOR HELP ASK FOR HELP ASK FOR HELP Help will arrive as soon as possible Help will arrive as soon as possible Bibliography [1] Wikipedia. Representational state transfer, March 2014. URL https: //en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_ Web_Services. [2] Wikipedia. Create, read, update and delete, March 2014. URL https://en. wikipedia.org/wiki/Create,_read,_update_and_delete. [3] Wikipedia. Safe methods, March 2014. URL https://en.wikipedia.org/wiki/ Hypertext_Transfer_Protocol#Safe_methods. [4] Wikipedia. Idempotent methods and web applications, March 2014. URL https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Idempotent_ methods_and_web_applications. [5] Wikipedia. List of http status codes, March 2014. URL https://en.wikipedia. org/wiki/List_of_HTTP_status_codes. [6] OASIS. Emergency data exchange language (edxl) distribution element, v. 1.0, July 2014. URL http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_ Spec_v1.0.pdf. [7] OASIS. Common alerting protocol version 1.2, July 2014. URL http://docs. oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html. [8] OASIS. Emergency data exchange language situation reporting (edxl-sitrep) version 1.0, July 2014. URL http://docs.oasis-open.org/emergency/edxl-sitrep/v1. 0/cs01/edxl-sitrep-v1.0-cs01.html. 77