Executive Summary

This document describes the solution for condition monitoring of industrial machines by providing data independently to multiple third-party data partners (OEMs).

Purpose and Scope

In any industrial machine, there are a lot of moving parts that need regular maintenance, and surveillance. The pain point is not about the number of parts, it's about the different manufacturers and vendors who supply these parts as they all need to monitor all the parts they supply. Data collection and distribution to the concerning partners is not an easy job to do, especially when data security and custody need to be taken into consideration.

Moreover, some machines and parts cannot be serviced remotely, they need to be sent to the service stations for service and maintenance. If some repairs are needed, new spare parts have to be ordered which costs downtime and money. Sometimes the service partners have to travel to the site, and if they need to do some repairs, spare parts tools have to be ordered and that comes with a cost.

Business value

Exchanging data with multiple third-party data partners (OEMs) with each of them having their own data policies and security regulations is a headache for manufacturers and the users of the machines. To tackle the problem, weeve is creating a data service that will securely supply OEMs with the data they need, and providing data insights that can help in deciding on the maintenance cycle of the machines.

Solution Overview

Weeve platform, allows a manufacturer to build data services that pass selected data to the specific OEMs. This means that  if a manufacturer wants to share only a specific type of data, or a specific value, or all of the data when a specific event occurs, this is now possible with weeve.

Furthermore, a manufacturer might use the weeve platform to gain specific information from data and set thresholds or triggers for alerts. All of the above mentioned, reduces costs and saves operational time.

Assumptions

  1. Source of data → CAN data from a hydraulic motor
  2. Parameters
  3. Temperature
  4. RPM
  5. Torque
  6. Oil Pressure
  7. Environment conditions
  8. Uptime
  9. Manufacturer [OEM]
  10. ID / Part Number

Architecture and Setup

  1. All the machines are connected in a CAN network and send the parameters above mentioned.
  2. The gateway runs a Linux based OS and is capable of handling docker containers.
  3. The gateway has a CAN BUS Tx/Rx interface to connect to the internal CAN network.
  4. The gateway can access the internet so that it can send data to the cloud or generate alerts when needed.
  5. There are four egress options:
  6. OEM API
  7. InfluxDB
  8. Vonage API (Alerts)
  9. Writing encoded CSV to a file

Case I → Deliver parameter data to the concerned OEM.

The OEM needs the data from the machines into their systems in one of the two ways.

  1. The OEM has a REST API, where data can be sent directly.
  2. The OEM has a cloud DB where data can be pushed directly

Data Service

  • The filter allows only the data for a particular OEM to pass through.
  • The data is then batched for the given amount of time or the number of data points.
  • The API Egress sends the batched data to an HTTPS REST API or alternatively, the DB egress module can send the data to a DB directly.

Case II → Apply some aggregation functions and send only the results to OEM.

It is not always required to acquire all the data points to the OEM. Some aggregation functions can be used and the data can be stored locally. The aggregated data then can be send using the API or directly to the database. Another option can be to save the data locally in encoded CSV files. The files can be copied later.

Requirements

  • Technical and Hardware
  • Constant connection to the internet for data transmission to Vonage or Databases
  • All the machines are connected in a CAN network and send the parameters above mentioned.
  • Functional Requirements
  • The gateway runs a Linux based OS and is capable of handling docker containers.
  • The gateway has a CAN BUS Tx/Rx interface to connect to the internal CAN network.
  • Non-Functional Requirements
  • The system should be always running
  • The system should be able to update its data service when required

Constraints

  • Privacy and Intellectual Property(IP): The amount of data that is being sent will be very limited, as the data about the running and condition of the moving parts can be used to reverse engineer the process of manufacturing,  propriety machine design and/or parts.

Written by Sanyam Arya & Jakub Grzelak