Alerting function has become an essential function of production monitoring systems. As an addition, the need to analyse, interpret, communicate and react to production data in near real time is becoming more and more widespread. But this is no wonder at all, because time is money – especially when it comes to a factory!
“Information is a Latin word which means information, news, message, information (…) Information in itself has a value – social, scientific, productive-economic or even power value. Information can be used to enhance an existing value, and is therefore value-adding. Since it represents value, it can also generate profit or extra profit. It is also characterised by its quantity, quality, usability, accessibility, understandability and protection.” – Wikipedia
As it is being summarised in the well-known online encyclopaedia, good quality information can be used to gain an economic advantage – even in production.
The more detailed information we have on all the details of our process, the greater the resolution with which we can analyse its anomalies and develop the necessary responses.
Today, IIoT and industry 4.0, as technology innovation trends have engaged both manufacturers and solution providers based on this approach. But is it enought to have a critical mass of information that is of high quality, usable, accessible, understandable and protected?
Time is money – especially in a factory
The rise of IT has added a new dimension to the fundamental properties of information: speed. We want to know everything, and preferably instantly. Time is money – especially when you enter a factory! There are plenty of examples of how much loss can be caused by an anomaly in different sectors, volumes and durations. In an average car factory this metric is in the order of millions of HUF/minute (because that’s about the time it takes a new vehicle to roll off the production line). Not to mention that in the case of a power plant, for example, the lack or slowness of information flow can even cause environmental and biological disasters… There’s no question that
in the event of a relevant incident, the necessary areas and persons must be informed immediately.
In our understanding, the so-called notification systems that respond to such challenges are essential functions of production monitoring platforms (which, of course, are also included in WaMeWo).
The basic requirements for the functioning of notification systems:
- have data already collected digitally,
- perform aggregations on it
- and ‘feed events’ to the notification layer by an underlying system
Let’s assume we have these!
The actual functioning of the notification system can be diverse, but typically it consists of the following chain:
Alert rules
As a first step we need to define the alert rules that we think are newsworthy for us and that we want to be informed about as quickly as possible. An alert rule consists of one or more queries and expressions, a condition, the frequency of the evaluation and optionally the time period during which the condition is fulfilled.
Some typical examples of such events are:
- Event monitoring (trigger): an immediate alarm is requested when a specified bit-level event occurs (e.g. a sensor is activated on the production line). This can be done in a time-parameterized way by specifying that an alarm is requested after the signal has been active for X seconds.
- Monitoring and comparison of a discrete value: we can also monitor the numerical value of certain variables and generate an alarm if it exceeds a set limit. A typified version of this is to monitor the equality of a nominal value and an observed value (for example, whether a welding robot is welding with the correct settings).
- Monitoring of the set trend, distortion: in this monitoring, we do not predefine the limits between which the values can normally move, but we record the trends that occur during normal operation (with what cyclicity, what values are typical, etc.) and try to detect the distortions that appear in them.
- Serial occurrence of events: a single occurrence of certain signals or warnings does not always exceed the threshold of the stimulus, but if they occur in succession, they may indicate a future failure which may cause a serious stop later on. To prevent this, we can subscribe to the occurrence of an arbitrary number of events (messages from the machine or downtime).
Recovery: in most cases, we consider a deviation from the normal state as an “incident” we want to know about. However, it is also possible to configure a return to OK status as an alert, i.e. if the previous anomaly is recovered, we can also request a notification of this.
Reminders: you can request reminders for certain tasks scheduled in time, so for example if a maintenance event is due to take place the next day, you can remind the maintenance staff to whom the task has been delegated.
Reports: not a typical alerting rule, but a typical request, for example from production, when at the end of shifts an automatic efficiency (OEE and details) report is generated for each machine, which can be viewed not only in the application’s user interface, but also sent by email (XLSX, PDF format) to subscribed users.
Severity
WaMeWo currently has 4 levels of severity defined for each alert rule, according to the most common customer needs:
- error
- alert
- info
- reason
These 4 levels help us to holistically review the alerts according to our own preferences of which event is critical for us.
Notification channels
Last but not least, when subscribing, you can choose the channel you want to receive each notification (configurable by type). This can be done in a number of ways depending on the size of the message, its content and the user environment (i.e. the expected network coverage between the application and the end user).
Currently the three most common notification channels are:
- In-app: while the user interface is open in their browser, it is possible to draw the user’s attention to events that have occurred by using different visual solutions within this interface. These schemes have emerged in recent years on social networking sites. An icon at the top of the application indicates when a new event has occurred and the most recent ones are listed by clicking on the icon. In addition, pop-up labels coloured by severity can be displayed on any page, regardless of which menu item the user is currently in and which functionality is affected by the alert.
- Chat: the majority of applications developed specifically for mobile can send push notifications that can appear at system level on your mobile phone. If the mobile app is not available, there are already many ways to send notifications to popular chat applications (e.g. Viber) via an API, so no extra app development or installation is required.
- Email: the most popular notification format, which requires only an email server (usually an existing one). One of the greatest advantage of this channel is that the necessary infrastructure is available almost everywhere in the world, and longer messages and larger files (reports) can be delivered too.
Our advice: request neither too much nor too little information!
A well-configured notification system should deliver a measured amount of information, and in good quality. In the first flush, most users like to subscribe to everything, to be notified of even the smallest events… Why is this a mistake? If users are flooded with irrelevant notifications (especially in a large factory with many machines), they can easily become annoyed. The risk of the user muting or even unsubscribing from the notifications, and thus missing important events later, becomes critical.
So try to think in advance about any eventuality that could be critical for the continuity of your production, and make rules for it! You should also consider the importance of each of these events, and take into account your personal information preferences, and subscribe to the channels that are most convenient for you.
But most importantly, act on the information you receive.
What is this series of articles about?
This series of articles has been compiled by our team in order to provide both technological and business know-how for professionals involved in the digitalisation of the industrial sector. The chapters follow two guiding principles:
- exploring the reasons behind the manufacturing digitisation software technologies used and
- demonstrating their potential for business use.
We trust that our content will provoke constructive professional discourse. We welcome your feedback, opinions or questions on info@indeveyes.com-on or our social media platforms!
- In a previous article in this series, we wrote about Robot diagnostics
- In our next article, we will talk about Customizable, no-code dashboards
