synchronicityiot/traffic-flow-estimator repository overview

UPDATE: This image requires the interaction with a Keras Server + API, which is not part of it (and it is not available yet on Docker Hub). This means that the estimation part will not work properly. We are working on a solution that embraces the whole funcionality.

⁠Description

By means of the information retrieved from the different traffic intensity context entities, this service will generate an estimation of the traffic intensity flow in the short term (namely, in the next 15, 30, 45 or 60 minutes).

⁠Interface and API

API Documentation⁠ (Apiary)

⁠Service Architecture

The traffic-flow-estimator is the consequence of the joint operation between various micro-services. We briefly outline each of them below:

• core: Main module, responsible for: 1- gathering all the data from the different Reference Zones (both last values and historical data). *2-" Expose the predictions to users, obtained from the keras-server component. This means that the service has a REST API from which it delivers the information to users
• keras-server: Actually, the key element. Based on Keras⁠, we are building a neural network based on an LSTM (Long Short-Term Memory) model to predict the values upon the historical data retrieved from each of the context entities
• ELK stack: In order to keep track of the performance of the whole traffic-flow-estimator service, all the modules communicate with this one (based on the popular ELK stack⁠), which will behave as a centralized logging component to monitor and analyze the behaviour of the system

⁠Service configuration

The service relies on two different configuration files to work properly. Although one of them is already present in the image (it is ready-to-use as it is), there is another that handles private data (i.e. the tokens to access the different RZs context Brokers). Namely, this file is called auth.js and must be present within the /usr/src/app/configfolder; otherwise, the service will basically not behave normally. As a illustrative example, this is how the file should look like, where users have to tamper all the RZs that require an Oauth token:

'use strict';
var auth = {};
/**
 * Orion CB data discovery. Specification of the different context brokers
 */
auth.orion = {
  Santander: {
    'X-Auth-Token': '<token>'
  },
  Porto: {
    'X-Auth-Token': '<token>'
  },
  Helsinki: {
    'X-Auth-Token': '<token>'
  },
  Milano: {
    'X-Auth-Token': '<token>'
  },
  Manchester: {
    'X-Auth-Token': '<token>'
  },
  Carouge: {
    'X-Auth-Token': '<token>'
  },
  Eindhoven: {
    'X-Auth-Token': '<token>'
  },
  Antwerp: {
    'X-Auth-Token': '<token>'
  }
};
module.exports = auth;

UPDATE: It is also possible to use a centralized logging system based on Loggly⁠. In case any user wants to use it, he/she must add the corresponding token and subdomain into the config/auth.js file (example in config/auth.js.sample).

⁠Service Deployment

To run the service, it is only needed to run the following Docker command:

docker run -p <host_port>:3000  -v "$(pwd)/config":/usr/src/app/config --name="<container_name"  synchronicityiot/traffic-flow-estimator

Where <host-port> is the listening port at the host and <container_name> will be the label of the container, Besides, as hinted above, users must include both config.js and auth.js files within the config folder. This is the part set after the -v option, where users have to specify the path to the auth.js file in their host machines.

⁠Support

The support for this baseline services can be request via the issue tracker here⁠

⁠License & Terms and Conditions

This atomic service is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. Please refer to gnu licenses for more information.

The software is released as it is and we discharge any liability.