Implementation Plan

Analysis and Description of Methodology

The NAVARCHOS 2 project lifecycle and implementation plan is organized over 8 quarters (24 months). In order to guarantee smooth and effective project running and progress, seven (7) work-packages have been identified: two (2) project horizontal WPs related to 1) the project management (WP1 entitled “Project Management”) and 2) IPR handling, communication, scientific dissemination, exploitation and business planning (WP2 entitled “Dissemination Activities and Commercialisation Plan”); and five (5) project implementation WPs that will follow an iterative plan adopting a two-cycle development, integration, demonstration and evaluation approach, where refinements of each cycle will take place during the next one and milestones and deliverables are scheduled accordingly.

The architecture of NAVARCHOS 2 is conceptually split into 3 main layers, as illustrated in the following figure.

Figure 1. Architectural Layers of NAVARCHOS 2

The Data Layer is responsible for the deployment of the infrastructure which will facilitate the aggregation of big, transport related data, including OBD data and GPS data, as well as other available data including, for example, weather data, traffic data, social data etc. For the sake of better understanding, it needs to be clear that there are two kind of OBD devices: (a) Bluetooth OBD Scanner and (b) OBD GPS tracker with GPRS capability. The Data Layer will integrate 2 data gateways, namely the Mobile Data Gateway and the Server Data Gateway, and the Data Management Module as described below:

1. the Mobile Data Gateway which will be responsible for the retrieval of (a) OBD data from the Bluetooth OBD Scanner and (b) GPS data from the mobile. Data collected from the Mobile Data Gateway will be sent over 3G to the Server Data Gateway. The Mobile Data Gateway will be installed on in-vehicle mobile devices.
2. the Server Data Gateway which will be responsible for the retrieval of (a) OBD+GPS data (from either the Mobile Data Gate communicating over 3G, or directly from OBD GPS Tracker devices communicating over GPRS), and (b) other available data (e.g. weather data) as well as for posting this collected data to the Data Management Module,
3. the Data Management Module which will comprise the API for collecting and serving data to the rest of the components of the NAVARCHOS 2 architecture. The flow of data in and out of this module is depicted in the figure provided at the end of this section.

The Analytics Layer is responsible for the design, implementation and deployment of big-data enabled algorithms for facilitating proactive/post-action recommendations and notifications to fleet vehicle drivers as well as to fleet managers, and for the implementation of a complex event processing pipeline which will process aggregated data from the data layer and will extract valuable insights of added value to both user groups.

The analytics layer will integrate the Complex Event Processing Pipeline, which will constitute an efficient real-time processing pipeline for enabling complex situational awareness and for detecting any complex deviation / situation of interest. The cep pipeline will include data analytics in order to support a continuous learning of the new situations of interest in order to support proactive behavior. The consortium will also investigate the potential of the integration of edge processing (if appropriate) for enabling detection of the situations as close as possible to the data sources in order to support agility. With regards to the component responsible for the detection of the situations of interest, namely the cep engine, this is usually based on the so-called complex event patterns, coded in an event processing language. There are several engines which can be relevant for the above requirements, but based on our previous experience and the current usage, the consortium partners opt for the usage of Siddhi, a relatively new engine related to WSO2 Complex Event Processor (WSO2 CEP). The Siddhi engine is massively scalable (required for big data), while for example Esper that has been until recently the most widely used cep engine cannot scale efficiently. In addition, Siddhi is based on Apache Storm and enables the definition of complex, workflow based patterns, while Esper is based on the language (EPL) that cannot support workflow-like processing. Last but not least, Siddhi/WSO2 is available under Apache Software License Version 2.0, which is the best possible open source license for the commercialization. The CEP architecture will consists of the following components:

Event streams: Event streams contain unique sets of attributes of specific types that provide a structure based on which the events processed by the relevant event flow are selected. Event streams are stored as stream definitions in the file system via the data bridge stream definition store.
Event processors: Event processor handles actual event processing. It is the core event processing unit of the CEP. It manages different execution plans and processes events based on logic, with the help of different Siddhi queries. Event Processor gets a set of event streams from the Event Stream Manager, processes them using Siddhi engine, and triggers new events on different event streams back to the Event Stream Manager.
Event receivers: Optionally, event receivers receive events that are coming to the CEP.
Event publishers: Optionally, event publishers publish events to external systems and store data to databases for future analysis.

Driver-centric Notification and Recommendation Algorithm

In order to define the driver-centric notification and recommendation algorithm the following methodological general steps will be investigated:
Preprocessing step: A preprocessing step will performed so as to clean the data from noise and to apply map matching technique to normalize GIS data.
Clustering algorithm investigation: Clustering algorithm will be performed on trajectory data and data collected from heterogeneous sources such as vehicles data, and third parties data, to reveal efficient / in-efficient driving patterns in terms of fuel consumption. Based on driving patterns fuel efficiency metrics will be defined.
Recommendation and notification algorithm: Regression algorithms and fuzzy logic will be investigated in order to finalize the prediction model for proactive and post-action recommendations. Proactive and post action recommendations will be based on advices for eco-driving that are well documented and widely acceptable in the bibliography [2][18] such as 1) Drive in the highest possible gear at lowest possible rounds per minute (RPM) 2) Maintain a steady speed 3) Anticipate traffic flow and avoid frequent starts and stops. 4) Optimal (fuel efficient) deceleration. 5) Optimal (fuel efficient) acceleration. 6) Eliminate idling. 7) Drive at or below the speed limit. 8) Do not press the accelerator when switching on the engine. 9) Approach curves at correct speed and in the highest possible gear. 10) Minimise extra weight and air resistance. 11) Maintain correct tyre pressure. Avoid fuel consuming accessories. 12) Traffic based notifications 13) Weather based notifications

The Interface Layer is responsible for the implementation and delivery of the applications to the NAVARCHOS 2 users. More specifically, two main applications will be developed and delivered within the context of the project, namely:
1. A mobile application for fleet vehicles’ drivers. The application will be designed to be both user-friendly and powerful, and will deliver the following services to the specific user category: (a) a dashboard with vehicle-centric insights such as maintenance information, accidents report, mileage information, etc., and (b) an elegant mechanism to deliver driver-centric proactive/post-action eco-driving recommendations and push notifications such as traffic abnormalities, weather conditions, etc. to the driver at the right place, at the right time, regarding the right piece of information.
2. A web interface for fleet managers. This application can be viewed as a customized administration dashboard which will be developed on the basis of state-of-the-art web standards such as HTML5, CSS3, AngularJS while maintaining responsiveness to different screen sizes, will be hosted on the cloud and will deliver the following services to the specific user category: (a) driver-centric and fleet-centric monitoring views (for delivering performance metrics and analytics), and (b) driver comparison and benchmarking view delivering gauges charts, column charts, pie charts and comparison indicators in a visually appealing manner.

The following figure constitutes the data flow diagram of NAVARCHOS 2 and aims to graphically illustrate the interaction between the various components of the system in terms of data flow.

Deliverables