Information about the project can be also found in the EC portal, under this URL https://cordis.europa.eu/project/id/732189

The AEGIS project creates an open ecosystem of innovation and data-sharing over multiple sectors for public safety and security. In the second AEGIS video you can see how the developed platform orchestrates dataflows to exploit semantic technologies in big data environments and promotes new business models. Watch the video and find out more…

The overall session is expected to last for 30 mins and will provide an introduction on how the consortium used the AEGIS big data infrastructure to carry forward the development of services for personalised services for people belonging to vulnerable groups (in terms of health).

The topics to be presented/discussed during this event will be the following

• What is AEGIS?
• What is the SHAL demonstrator and who is it for?
• How SHAL works (technical blueprint and hands on demo)?
• How is SHAL linked to AEGIS?
• Open Questions

To declare you interest for following the online presentation, please visit the following registration form https://forms.gle/hSr6wjEfy9xDpkHs9 

Increasing road safety is still a major worldwide challenge. Though road safety in the EU has improved in the last decades, still more than 25.000 people have lost their lives on EU roads in 2017 [1]. Harsh driving remains one of the major causes of accidents [2]. Hence, making areas of harsh driving visible to people can be a useful tool for various stakeholders to develop strategies for road safety improvement.

The overall goal of the Automotive Demonstrator V3 – Regional Driving Risk Estimator is hence to aggregate all driving safety-reducing events detected within the trips of individual drivers and then visualise them on a geographic map to provide an estimation of a regional driving risk.

The safe driving indicator (Automotive Demonstrator V2 [3]) has already quantified all individual driving risks per trip and driver. To increase the value of this information for various stakeholders, the Automotive Demonstrator V3 aggregates all individual driving risks into a regional driving risk. Thereby the regional driving risk is visualised as a heatmap overlay on a geographic map of the respective region to provide decision-relevant information.

Again, this demonstrator is very useful for insurance companies that want to better assess the driving risk within certain regions in order to adapt the policies of new customers living in that region according to a higher or lower driving risk. In addition, this demonstrator is valuable for road operators to better assess driving risks and who may suggest speed limits or other measures to make driving safer. Finally, this demonstrator is useful for city planners and traffic planners to better assess driving risks in cities and implement measures.

The figure below shows the output of the regional driving risk estimator for the districts St. Peter and Liebenau in the city of Graz. Thereby, it becomes visible that especially crossings are dangerous hotspots, where aggressive driving behaviour was conducted.

Figure 1: Regional Driving Safety Risk Estimator Heatmap

[1] Annual Accident Report 2018, https://ec.europa.eu/transport/road_safety/sites/roadsafety/files/pdf/statistics/dacota/asr2018.pdf

[2] Why monitor harsh braking and acceleration, https://www.verizonconnect.com/resources/article/harsh-braking-acceleration-why-monitor/

[3] Automotive Demonstrator V2 – safe driving indicator: https://www.aegis-bigdata.eu/automotive-demonstrator-v2-safe-driving-indicator/

Figure: Christian Kaiser presenting results of AEGIS at Big-Data.AI Summit

Christian Kaiser from VIF had the opportunity to present results of the AEGIS project on the first conference day to about 100 interested parties, mostly from industry. Thereby Christian provided insights into the development of two concrete data-driven services for intelligent mobility on the AEGIS platform. While the first data-driven service deals with the detection of road damage by analysing vehicle sensor data, the second service provides safety-relevant feedback to drivers. After his presentation, Christian held a series of discussions with representatives of the automotive industry who were interested in joint activities.

The abstract to Christian’s talk accepted by the programme committee of the Big-Data AI.Summit is attached below:

The automotive domain is changing from purely offering goods and associated services towards exploiting data- and analytics-driven services, too. Thereby new players from the big data ecosystem are entering the market to co-develop data-driven solutions together with classical players from the automotive industry.

In our talk, we will provide insights into the development of two concrete data-driven services: detecting road damage and individual driving styles. Both services were created using an analytics platform developed in the AEGIS Big Data project [1] funded by the European Commission in the Horizon 2020 framework program. The AEGIS platform combines numerous components of the big data ecosystem including Hadoop, Spark, Hops, Jupyter, TensorFlow, Hyperledger, and Elastic Search. Besides offering integrated components for the development of data-driven applications, one of the project’s main goals is to provide easy and flexible integration of third-party data-sources.

The main data source of the presented data-driven services are unsurprisingly measurements of vehicle data, all of them recorded during normal vehicle operation on public roads. We collected the measurements using a self-developed, custom logging device, built using only cheap and widely available commodity hardware. Of course, these measurements need pre-processing before they can be put to use. Our contribution will highlight the various difficulties we encountered and how we overcame them. For example, it is inter alia necessary to detect the actual position of the logging device in the vehicle in order to align the measurements collected by accelerometer and gyroscope to the vehicle’s coordinate system.

The first data-driven service we will present deals with the detection of road damage. As the impact of road condition on driving safety is not neglectable, this service is targeted at road maintenance companies to better manage their road maintenance works. For this service all available measurement data is analyzed in its entirety. Within the data, we detect “rumbling events” which indicate a potential road damage. These events are then spatially aggregated and normalized by the number of measurements that cover the respective area. The result shows for each point of the map how many percent of measurements detected a “rumble event” at the respective position. Thus, it can be interpreted as the spatial probability density of road damage.

The second data-driven service provides safety-relevant feedback to drivers. The goal is to provide interested drivers with insights into their individual driving style, allowing benchmarks with other drivers to stimulate safer driving behavior. Again, we start by calculating events – but this time the events are not related to the road conditions but instead describe safety relevant situations like harsh braking or hard cornering. In a second step, the calculated event information is enriched with weather data. This process is not as straightforward as it may seem at first sight, as weather data is usually not available for every position and time. Typically, the weather is measured only at various locations (weather stations) every half hour or so; thus a complex merge strategy is required. Next, we compute a risk score which is based on events and weather for each trip and driver. The risk score indicates the driver’s relative risk and provides prompt feedback as well as the possibility to compare with other drivers.

[1] Advanced Big Data Value Chain for Public Safety and Personal Security – AEGIS, https://www.aegis-bigdata.eu/

Thanks to the cooperation between HDI and the AEGIS technical partners, the second Scenario of the Insurance Demonstrator continues to exploit at best the (updated) release of the AEGIS platform. The current results after the execution of the Scenario meet the needs of HDI, and at the same time open some interesting challenges that will be addressed with the final release of the platform and further improvements of the HDI tools.

The second Scenario of the Insurance Demonstrator is mostly related to the detection of a foreseen event of interest by the Event Detection Tool, differently from the previous one, in which the focus was on contacting the interested customers after a related event was just happened (anticipating their potential request). Through the AEGIS platform, the HDI Data Scientists can evaluate the risk exposure of the company by identifying the customers that could be affected by the events and the type of the policy/-ies held by them. Through the analysis of some features, for instance the number of accidents and the number of previous injuries, for each customer a priority value is assigned. The list of customers is then sent to the Web App for further processing by the HDI operators that will contact the customers.

The HDI Data Scientist may also send a push notification to the customers that have installed the HDI Mobile App, hence to those that had signed an AEGIS-specific terms and conditions agreement.

The notification received by the HDI customers, includes details of the event as well as information about further policy/-ies they could subscribe (type of policy, price, duration, restrictions) and contact references of the HDI agent that can support them. For this reason, every time a notification is sent to a customer, a mirroring notification is sent to the HDI Web App workspace of the responsible agent.

During the execution of the second scenario, an internal focus group has been organized at the HDI premises, involving data scientists and developers of the demonstrator, together for many iterations over the test cases, with the objective to provide a qualitative evaluation of the demonstrator.

Since the first round of evaluation, data scientists effectively run the Query Builder and Visualizer tools, correlating the features of the event with the in-house dataset regarding the customers’ policies and location, and having a fast overview of the interested customers on a map. They are now well trained in the use of the notebooks of the platform. The Web App that has been developed to allow the information exchange between the three actors involved in the process is working as expected, and the execution flow was tested by different users for each role and no issues were observed. The data scientists’ analyses within the AEGIS platform have also succeeded. The problems encountered in the first tests have been fixed in cooperation with the other partners of the consortium.

The general feedback is that the status of the demonstrator, although not yet fully integrated, is on a good direction and the different steps are clearly defined. The Event Detection Tool has been adequately trained for the second (medium) demonstrator in Italian, with the keywords ‘grandine’ and ‘grandinata’ (hailstorm), ‘polizia antisommossa’, ‘proteste’, ‘scontri’ (respectively riot police, conflict and protest). The number of tweets collected and labelled is around 5000 for each event type (including an enhanced training for the flood event, from 1000 tweets of the first phase to 5000 tweets) and neither retweets nor answers have been considered. The machine-learning algorithm of the Event Detection Tool has been improved. Developers highlighted the value of using the Event Detection Tool Python code potentially almost as-is for the streaming of tweets related to other keywords, languages and further scenarios. The use of the Web App by the data scientists has been effective and the tool has been considered clearly structured. The AEGIS platform was used for creating projects and upload datasets, and the offline Anonymiser was exploited for the management of sensitive in-house data.

The Mobile App has been used and tested, with its two basic functionalities developed ad-hoc: geolocalisation and push notifications, as well as the creation of the .csv file with customer reference name, current latitude and longitude, and the achieved results are satisfactory.

The main issue related to the second (medium) demonstrator and, in general, to the Insurance demonstrator is the privacy and security regulations. In order to respect the Italian and European Legislation about data treatment, and the Insurance specific policies, the in-house datasets stored in HDI databases are uploaded on the platform after their anonymization. The data are managed and handled only by the HDI employees that are working on the AEGIS project and only the columns of interest for the project evaluation purposes are kept.  Additionally, at the end of each analysis the in-house datasets are deleted from the AEGIS platform. Finally, a potential issue in the use of the mobile app is represented by the possible reluctance of the customers to give their consent for enabling the geolocation. In general, the second (medium) demonstrator has satisfied all the HDI actors, in terms of usability of the tools and accuracy of the analysis. Toward this end, the cooperation between the HDI employees and the technical team of the project was fundamental, from the definition of the user stories (D3.1) to the test cases execution.

The complete description of the Second Insurance Scenario Execution is available in the AEGIS Deliverable D5.4 – Demonstrators Evaluation and Feedback – v2 (to be published at https://www.aegis-bigdata.eu/public-results/).

Blog post authors: HDI – GFT

Scenario 3 – Notifications and alerts for (at-risk) individuals

Scenario 1 includes the steps that have to be performed in order to onboard an individual and a carer to the system, which results in the acquisition of personal data that are used to classify (at-risk) individuals into specific profiles (“€œpersonas”). The accumulated data is then used (in an anonymous manner) by the Care Service Providers (CSPs), in conjunction with external data, for further analysis and for issuing simple notifications. In parallel, cares are registered to the platform and are connected to the (at-risk) individuals.

Regarding the test cases, first, the framework for an outlier detection model was created, delineating sets of persona outlier identification medical rules per condition or per group of conditions or of combination of conditions facilitating the definition of “personas outliers”. Subsequently the development of the outlier algorithmic and notification model was evaluated. The SHAL Web App received data from the defined sources and executed on Aegis the Outlier Notification Model in a configurable period of time. The model identified at-risk individuals / outliers by processing the new data against the defined rules. Additionally, template notifications that relate to medical rules have been created and have been linked to the different personas.

Scenario 4 – Smart home comfort profiling and notifications

Scenario 4 pertains the comfort profile model fitting framework and associated notifications to the end users, and constitutes the intermediate level of the Smart Home service of the demonstrator. The profiling process concentrates on the identification of personalized preferences for an at-risk person, based on the monitored environmental conditions and operational status, when he/she is at his/her living premises. Such comfort profiles are subsequently enriched by limits regarding VOC conditions, extracted from respective standards and directives. Given these models, the real-time data are continuously examined, and notifications/alerts, shown to the mobile app of the individual and/or informal carer, are generated, when conditions are recognized as not comfortable or potential detrimental to the person’™s health. The respective user stories are the following:

• CSP: In order to enable the offering of the envisioned service, the CSP needs to estimate the personal preferences of individuals with respect to indoor living conditions. To that extent, the data scientist, working for the CSP, develops a comfort-profiling algorithm which is periodically trained on the smart home data, after the processing steps described in Scenario 2. The profiling framework is implemented in the AEGIS platform, allowing thus scalability of the used algorithmic processes. The model is then employed to continuously predict discomfort/potentially unhealthy indoor conditions, from the incoming data streams, and alert either the individual or the carer, through the mobile app, about the identified risks.
• At-risk individual/Carer: The person and/or his/her informal carer register to the SHAL notification service, which allows them to receive the generated alerts prescribed above.

Two test cases were defined for evaluation of scenario 4. Firstly, The comfort profiling algorithm was created as a Jupyter notebook in the AEGIS platform. The required data-streams were previously established and data were cleaned and normalized. Consequently, the algorithm estimates the required Bayesian classifier model parameters and exports the class conditional posterior probabilities for given temperatures. Through these, the algorithm identified the comfort limits, which are utilized in the following test case to generate warnings on adverse indoor conditions. Following the identification of the comfort limits, a notification process was established within the smart home gateway, which checks in real-time the indoor environmental conditions and posts warning notifications to the SHAL backbone server, upon noticing that these deviate outside the acceptable limits.

The test cases were completed with success. At the final stage of the evaluation process, an internal focus group, comprised of six participants, was organized among the data scientists and developers of the demonstrator, so as to perform a further qualitative analysis. The details can be found in the associated AEGIS Deliverable 5.4.

Overall, the SHAL demonstrator will implement two main services that can be offered by a care service provider to at-risk individuals and/or their (in)formal carers:

• Monitoring and analysis of an individual’s well-being conditions, physical activity, positioning and wearable information and external environment data (e.g. weather, crime, news, social media), towards provision of a service for personalised notification and recommendation system for at-risk individuals, including notifications for carers.
•  Additional service pertaining monitoring and analysis of weather, indoor environmental conditions, energy and operational device data towards the provision of a smart home application, which can be offered by care providers to at-risk people for increased indoor comfort and welfare.

These services were broken down to six implementation scenarios, three for each service pertaining the early, medium and advanced version of the demonstrator, following the time plan for the circulation of versions 1, 2 and 3 of the AEGIS platform. Here we discuss the results from the implementation and evaluation of the early demonstrator scenarios:

Scenario 1 – (At-risk) Individuals data fetching, processing and classification

Scenario 1 includes the steps that have to be performed in order to onboard an individual and a carer to the system, which results in the acquisition of personal data that are used to classify (at-risk) individuals into specific profiles (personas). The accumulated data is then used (in an anonymous manner) by the Care Service Providers (CSPs), in conjunction with external data, for further analysis and for issuing simple notifications. In parallel, cares are registered to the platform and are connected to the (at-risk) individuals.

Seven test cases were implemented to evaluate the functionality prescribed in Scenario 1. Specifically, the necessary registration mechanisms were implemented in the SHAL Web App, with a simple profile page created where each user (either an at-risk individual or a carer) would be able to specify some personal information, as well as some information regarding his health and his conditions, and register devices to the platform, so as to allow the system to perform simple queries and categorisation functions. Furthermore, the application allows individuals to view available care takers and connect their profiles. On the Aegis platform, the Algorithm Execution Container was utilized to create a custom cluster analysis of at-risk individuals into specific profiles (Personas). The profile data of the at-risk individuals were first anonymised by removing any sensitive data, thus ensuring that the individual records or subjects of the data cannot be re-identified. In addition, the Aegis event detection toolkit was utilized. Events that are of interest for the CSPs and relate to their patients have to be identified so that the CSP Analyst can decide on issuing notifications to his monitored individuals. A notification mechanism reaching both individuals and also care-takers (not included in the original test case) has been implemented, using FireBase which allows the real-time provision of notification to users of mobile devices. Finally, notifications are issued by CSP analysts and are sent to person groups, where the CSP analyst only knows the user-id of people belonging to a persona, and not their real personal data. Once a notification is sent, a copy of it is sent also to the care taker who is linked to an individual.

Scenario 2 – Smart home data monitoring and processing

Scenario 2 constitutes the early version demonstrator with relation to the added value service of smart home automation. The scenario includes the following user stories and associated test cases, from the perspectives of the CSP and at-risk individuals respectively.

CSP: The first step towards the implementation of the smart home offering, pertains the establishment, by the data scientist working for the CSP, of data flows regarding the at-risk individual’s indoor conditions, and associated external weather measurements, as well as the required pre-processing and normalization that will allow, in a subsequent step, to train the profiling mechanism and estimate the personal preferences of the individuals.

At-risk individual: The individual, after registration to the SHAL service, is supplied with a mobile application. The Smart Home monitoring UI allows real-time information on temperature, humidity, VOC concentration and HVAC status to be visualised for informative reasons.

Another three test cases were defined for evaluation of scenario 2. The first pertained the establishment of the necessary hardware and software infrastructure for the collection of the defined smart home data streams. To achieve this target, a number of sensing and actuation instruments were installed. In particular, a proprietary multi-sensor and gateway combo device, developed and manufactured by Hypertech was installed. The combo device is equipped with luminance, temperature, humidity and VOC sensors, as well as the gateway controller, which accumulates the signals and transmits them to a server through a rest interface, using Wi-Fi and TCP/IP communication protocols. The combo device was coupled two other actuation instruments.an air condition actuator module, which allows monitoring and control of the HVAC device and a dimmable ballast with wireless controller for measuring and setting the dimming level on lighting devices. The monitored data are sent directly to the SHAL backbone server through a secure Rest interface. No personal data are transmitted, apart from the asset id, whose details were provided by the user upon successful registration to the demonstrator’s app. The second test case concentrated on the evaluation of the data processing capabilities of the AEGIS platform. Datetime entries were transformed to a standard format, and all data points were sorted according to their measurement time. Missing values for all measurement variables were filled in. Interpolation of all measurements to a constant time frame were also performed, and finally, motion data from the PIR sensors were processed in order to extract binary occupancy data. For the final case, a preliminary subset of the visualisations of smart home data, for informative purposes were implemented in the UI app.

All test cases were successfully completed. Implemenation and evaluation continued without significant issues towards the delivery of hte second version of the demonstrator. More details can be found in the corresponding deliverable https://www.aegis-bigdata.eu/wp-content/uploads/2017/03/AEGIS-D5.3-Demonstrators-Evaluation-and-Feedback-v1_v1.0.pdf.

ATB is the coordinator of the H2020 Big Data project CROSS-CPP funded in the same call as AEGIS, namely ICT-14-2016-2017. CROSS-CPP aims at ‘establishing an IT environment offering data streams coming from mass products, such as vehicles and smart building automation systems’. CROSS-CPP is the successor project of AutoMat, which aimed at forming a ‘cross-border Vehicle Big Data Marketplace that leverages currently unused information gathered from connected vehicles’.

To facilitate knowledge exchange, VIF presented results of the AEGIS project to ATB and more specifically introduced the results from the automotive demonstrator with respect to inferring broken roads and safe driving. Many commonalities could be identified between AEGIS and CROSS-CPP. ATB has shown interest into the business applications developed by VIF in AEGIS, as similar ideas have been discussed by ATB in the AutoMat and CROSS-CPP projects with car manufacturers. ATB introduced the vehicle information model as a brand independent data model to make vehicle data available to cross-sectorial industries allowing cross-domain use cases, which will be extended in CROSS-CPP.

During this fruitful workshop many topics were aligned, and future cooperation activities were discussed.

Members from AEGIS and CROSS-CPP project team