Difference between revisions of "RaspberryPiVolvoLogger"

From ISLAB/CAISR
Line 16: Line 16:
 
|Status=Open
 
|Status=Open
 
}}
 
}}
In the ReDi2Service project we are working together with Volvo Technology in Goteborg on collecting on-board data from a fleet of buses and comparing individual vehicles against rest of the group to detect faults and component wear.
+
In the ReDi2Service project we are working together with Volvo Technology in Göteborg on collecting on-board data from a fleet of buses and comparing individual vehicles against rest of the group to detect faults and component wear. In that project we are using a specialized hardware and software solution, but we are interested in exploring possibilities of using products such as Raspberry Pi http://www.raspberrypi.org/ in order to lower the costs and increase the flexibility.  
  
In that project we are using a specialised hardware and software solution, but we are interested in exploring possibilities of using products such as Raspberry Pi http://www.raspberrypi.org/ in order to lower the costs and increase the flexibility.
+
The purpose of the project is to implement a flexible data logging system and use it to log data transmitted through the CAN interface. Supervised and unsupervised techniques will be used to compress the data, to investigate the relations between the sensors and to identify deviations from normal operation. The system will consist of three separate components. A service for data collection, a process performing analysis on the data and a User Interface.  
 +
All the data will be stored in PostgreSQL DBMS and the data aggregation and compression models will be performed within the database. The system will be implemented for GNU/Linux. The hardware will be based on Raspberry Pi, but with no dependencies from it.
  
Therefore, the first task in the project would be to evaluate possible solutions for connecting Raspberry Pi to the CAN networks available in the vehicle, namely http://en.wikipedia.org/wiki/J1939 and http://en.wikipedia.org/wiki/J1587
+
The service will collect the data from the CAN interface and according to some rules store them in the database. The rules will include models for the expected values of the sensors, sensors to monitor, compression methods and sensor limits. If a reading from the CAN does not agree with the model the service transmits an alert to the interface or to the network and keeps a record of the deviation.  
  
Once this connection is realised, there is significant flexibility in the project and next steps depend on students' interests. Some selection of directions mentioned below, as well as other ideas, will form the main part of the thesis.
+
The data analysis component will be a process with input from the SQL database and output to the configuration files of the service. The origin and nature of the data will not be taken into account on this part, to keep this tool reusable in other domains. Supervised and unsupervised learning will be used to generate data compression models, to find relations between different sensors, to find visualizations that could depict the variation of the operation of the vehicle and finally to create predictive models and rules about the values of the sensors. The generated rules of compression or prediction will then be used from the service to log only deviations from the model. For the purposes of model creation and data reduction, the techniques that will be tested include Principal component analysis (instance data), neural Autoencoder(instance data), histograms(time series data) and Discrete Fourier Transform (time series data). For the clustering of the modes of operation the algorithms that will be tested include k-means, hierarchical cluster analysis and OPTICS.
  
* A flexible data logging system, allowing high-level specification of data to be collected, as well as conditions under which is should be done. This could also include high-level and (partially) learned usage and mission classification parameters.
+
The Graphical User Interface will allow customization of the conditions under which the data should be logged, setting rules that will trigger an alert, monitor real time data from the sensors and provide visualizations to the user, constructed either from the data analysis process, or defined by the user. The user feedback on an alert could be possibly used to improve the rules that define normal operation.
 
+
* A communication model which allows efficient transmission of collected data to the back office, based on different assumptions concerning network architecture, for example with fixed number of base stations and using other encountered vehicles as relays.
+
 
+
* On-board processing of collected data, especially generation of different forms of data aggregation and compression models (e.g. histograms, linear relations, etc), both defined by user and learned using supervised and unsupervised techniques.
+
 
+
* An algorithms for distributed comparison of collected data across the fleet, without the need of transmitting it all to the central server, but taking advantage of the dynamic network topology.
+
 
+
* Targeted diagnostics and monitoring, where the definition of data being collected adapts to the current needs of individual vehicle or the fleet. The focus can shift towards components or subsystems that require more attention, based on different criteria (both external conditions as well as internal component state).
+
 
+
* Modularisation is crucial for flexible data logging system, facilitating reuse, via standardised communication modules, abstracting device specific functions -- thus allowing it to be used in multiple domains, for example both in automotive and health care/home monitoring setting. One task in the project could be to integrate data received over CAN interface with PostgreSQL DBMS, implementing data aggregation and compression models within the database.
+

Revision as of 15:21, 22 January 2015

Title RaspberryPiVolvoLogger
Summary RaspberryPi-based solution for logging CAN data on Volvo trucks
Keywords GNU/Linux, CAN interface, Data Mining, Knowledge Representation
TimeFrame Spring 2015
References http://www.raspberrypi.org/

http://lnxpps.de/rpie/

http://islab.hh.se/mediawiki/index.php/ReDi2Service

http://www.youtube.com/watch?v=KJ5hMkWPEGY

Prerequisites Basic Linux knowledge, programming competence, possibly electronics experience,

Cooperating Intelligent Systems or equivalent basic Artificial Intelligence course

Author
Supervisor Slawomir Nowaczyk, Rune Prytz, Yuantao Fan
Level Master
Status Open


In the ReDi2Service project we are working together with Volvo Technology in Göteborg on collecting on-board data from a fleet of buses and comparing individual vehicles against rest of the group to detect faults and component wear. In that project we are using a specialized hardware and software solution, but we are interested in exploring possibilities of using products such as Raspberry Pi http://www.raspberrypi.org/ in order to lower the costs and increase the flexibility.

The purpose of the project is to implement a flexible data logging system and use it to log data transmitted through the CAN interface. Supervised and unsupervised techniques will be used to compress the data, to investigate the relations between the sensors and to identify deviations from normal operation. The system will consist of three separate components. A service for data collection, a process performing analysis on the data and a User Interface. All the data will be stored in PostgreSQL DBMS and the data aggregation and compression models will be performed within the database. The system will be implemented for GNU/Linux. The hardware will be based on Raspberry Pi, but with no dependencies from it.

The service will collect the data from the CAN interface and according to some rules store them in the database. The rules will include models for the expected values of the sensors, sensors to monitor, compression methods and sensor limits. If a reading from the CAN does not agree with the model the service transmits an alert to the interface or to the network and keeps a record of the deviation.

The data analysis component will be a process with input from the SQL database and output to the configuration files of the service. The origin and nature of the data will not be taken into account on this part, to keep this tool reusable in other domains. Supervised and unsupervised learning will be used to generate data compression models, to find relations between different sensors, to find visualizations that could depict the variation of the operation of the vehicle and finally to create predictive models and rules about the values of the sensors. The generated rules of compression or prediction will then be used from the service to log only deviations from the model. For the purposes of model creation and data reduction, the techniques that will be tested include Principal component analysis (instance data), neural Autoencoder(instance data), histograms(time series data) and Discrete Fourier Transform (time series data). For the clustering of the modes of operation the algorithms that will be tested include k-means, hierarchical cluster analysis and OPTICS.

The Graphical User Interface will allow customization of the conditions under which the data should be logged, setting rules that will trigger an alert, monitor real time data from the sensors and provide visualizations to the user, constructed either from the data analysis process, or defined by the user. The user feedback on an alert could be possibly used to improve the rules that define normal operation.