The APEMAN is a predictive maintenance class system that detects potential failures of electric engines well in advance.

1. APEMAN
Speaker: Dobieslaw Chabrzyk

2. About Us
• Established 2011, 5 employees
• Development of Level 3 software for manufacturing industry
• Transitioning from service-based integrator subcontracting for market
leaders to knowledge based products supplier
• Main focus on discrete manufacturing solutions starting from train
assembly (China South Railway, Qingdao, China), through plastic moulding
(Bianor, Bialystok, Poland) to timing belts (Gates, Legnica, Poland)

3. Challenges & solution

4. Challenge
For large scale production companies minimizing scrap, improving yield is
critical to maintain operational margins and assuring satisfied customers .
Existing Predictive Maintenance solutions have several disadvantages:
• Companies often face hard-to-detect failure conditions while solutions
deliver classical value based alerting or AI supervised learning
• Solution adaptation to unique customer installation, operating conditions,
individual device configurations results in long running and expensive
projects
• Required PLC’s reprograming.
• Required infrastructure investments (e.g. network).

5. Solution
For the manufacturing companies who are willing to introduce step-wise
improvements in order to reduce number of unpredicted failures of electric
engines based assets The APEMAN is a predictive maintenance class system
that detects potential failures of electric engines well in advance.
Unlike competing products APEMAN:
• is capable of predicting failures that were never observed neither in
customer installation nor in device category
• operates without customer specific setup
• doesn’t require any infrastructure investment or PLC programming to start
operating
• has scalable number of monitoring sensors to deliver wide capabilities of
environment replication for AI model

6. Architecture &
technical details

7. Architecture
• The solution is based on the Apache toolchain
• Data acquisition & persistence module, based on Node-RED and InfluxDB
is responsible for collecting and storing sensor measurements.
• The Data & trained model bi-directional synchronization module, using
Flask and NGNIX, is responsible for sending measurements data to the
server and retrieving trained neural networks.
• The failure detection module compares the incoming measurements with
pre-trained failures models allowing for prediction of imminent failures.
• The Client App is responsible for preparation of the time series data,
alerting and visualization.
• On the server side the Data & model synchronization module is
responsible for collecting data and retraining model periodically.
• The failure detection training module ensures persistence of the training
data and re-trains the neural networks once new data is available.

8. ISAB
• The Integrated Sensing and Analysis Box (ISAB) is the edge device and is
responsible for collecting and processing measurements from sensors
attached to individual machines as well as for reasoning using the pre-
trained deep neural network.
• Developing a single edge device like that ensures portability and allows for
installing on different machines, collecting data, retraining the model off-
line and monitoring machines as needed.
• The box is based on the Raspberry Pi4 with specialized sensors attached –
current and voltage, frequency of the inverter, temperature and vibration.
• Additional sensors, measuring different modalities can be easily attached
further enhancing the capabilities of the device.

9. APEMAN MIDIH components
Component name Role
Apache Kafka (+ Zookeeper) Redundant message broker for transferring sensor data from multiple edge devices to server
Apache Spark Used for data pre-processing and AI learning management
Apache Zeppelin AI notebooks visualization
Cassandra Training data storage
Grafana Server and edge device monitoring visualization
TensorFlow (+Keras) Neural network for unsupervised learning
NGNIX
Reverse proxy.
ISMB and server web application hosting.
Logstash Logs gathering

10. Other APEMAN components
Component name Role
Flask
REST based data workflow automation & delivery (e.g. Node RED <-> influx, sensor data delivery to web app).
Offline functionality.
Other minor business logic.
Redis Queue + Worker
Queueing TensorFlow scoring calculations jobs and processing them in the background with workers.
Required in order to keep ISMB resources for sensor data gathering and preventing of Tensor Flow scoring
parallel calculations.
Kapacitor Data processing for creating alerts and detecting anomalies based on Tensor Flow calculations.
Telegraf
Agent for collecting, processing, aggregating, and writing metrics. Used for collecting non-sensor related data
(e.g. http pings, CPU readings, mem readings).
Node-RED Sensor data gathering.

11. ISAB Client app

12. Server client app

13. Autoencoders for anomaly detection
• Copies input values to output values and ignores „noise”
• The important part is the hidden core in the middle which extracts
important information
• Encoding and decoding is part of the network

14. Dimensionality reduction to find outliers
• Early adoption of autoencoders is dimensionality reduction
• Perform better than PCA as can perform non-linear transformations
• Reducing dimensionality identifies the main patterns and reveals outliers
• Outlier detection is a by-product of dimension reduction

15. How to detect outliers
• Number of input variables equals number of output variables
• When trying to reproduce input MSE is used as loss function
• While training the model learns „normal” data and compress it inside core
layer
• When anomaly is sent through the model it fails to reproduce
• Necessary to find the right threshold to differentiate between valid input
and anomalies

16. Acheived results, KPIs
and businnes impact

17. Achieved results
• The experiment ended with a success despite the unforeseen difficulties
caused by the outbreak of the Covid-19 virus.
• The experiment has proved the usability of the MIDIH Reference
Architecture for development of AI-capable systems operating both in
real-time and offline.
• The involved companies are committed to further development of the
system as they see an attractive and untapped market niche for it.

18. KPI’s
• All the Technical KPI’s were delivered (80h device operating time,
gathering data from 2 machines, 95% of identified failures)
• Business KPI were achieved as well.
8 companies took part in hybrid (remote/onsite) workshops.
3 companies signed letters of interests and confirmed their willingness to
become early adopters and rent out the next iteration for test trials in
their facilities.
• The TRL level of the presented solution was too low to attract more letters
of interest, since there was no immediately available product.

19. BUSINESS IMPACT
• The experiment allowed us to investigate the capabilities of the Apache
stack. The well though through architecture of MIDIH saved us effort on
designing the system and allowed us to focus on testing the software
components.
• Experiment uncovered many potential market opportunities and allowed
to identify technical means to address them.
• MASTA sees the system as a breakthrough product, which will support the
intended transition from a service-based integrator to a knowledge-based
product provider and is willing to continue investing in its further
development
• During the workshops potential customers pointed out that identification
of potential causes of imminent failures creates significant added value. In
the next development iteration supervised learning, with data annotation
containing information on the causes of failures, will be used.

20. THANK
YOU!