U-NOVUS 2018: workshop
In mid-October, as part of the U-NOVUS youth forum in Tomsk, we held a workshop on Data Science.
Tomsk, in principle, deservedly enjoys the fame of a city of scientists and students, after all, 15 research institutes, 9 universities and several business incubators - this is serious. Therefore, we decided to invite both students and experts from various companies to participate. We gave a case from life (read - from production), it was a task for advanced analytics at a petrochemical enterprise. About how it was - under the cut.
The workshop lasted 3 days, it was exactly how much time the teams had to solve our problems and show that the solution they created was something that would actually help the industry, or simply carry a number of useful mechanics that could be applied in the production of digital chemistry in the future.
It was necessary to create a working scenario, within the framework of which the development and implementation of a system of proactive monitoring of technological equipment that we use in production would be carried out.
At the same time, it was important to take into account that it is logical to divide such equipment into several types (according to criticality), therefore the approaches to their management and monitoring should not be the same, and a single script would not work here. It was also necessary to take into account that the company uses the simplest visualization systems for already collected data, which can also be used. Plus, we gave a number of factors to the load - the influence of the condition of the equipment on the product margin; frequency of scheduled repairs; Scenarios for installing additional stands in cases where a basic monitoring system is already in place, and so on.
And we immediately prescribed a number of frameworks and limitations that must be taken into account, otherwise it will turn out that you made a decision, but you won’t be able to apply it, because you forgot about some of these factors. This helps, because such a solution should work in live production, and many different things can happen in the process.
Among these factors were:
Obligatory components of the system: a module that finds anomalies in the equipment (something is warming up, not supposed to, something is hanging out, but it should hold on, and similar behavior), and a forecasting module that can predict a similar situation based on already collected data .
At the output, I wanted to get a detailed description of the solution, which will allow, taking into account all these conditions, to introduce a system of proactive monitoring of equipment. It could include machine learning algorithms, any ready-made solutions and frameworks.
And quite ideally (and this is why there were people from the business as part of the teams) - to note those business processes that will be affected by the introduction of such a system; you may even have to introduce new business processes to ensure that the solution works.
We must pay tribute to the teams - they proved to be excellent. The teams were rather mixed, within the framework of one, both students and programmers with data analysts, and heads of directions, and directors of local companies could work immediately. And such a composition greatly influenced the resulting solutions, we checked and immediately noted that someone had a great emphasis on the architectural part, someone put interaction with users at the forefront, someone decided that the main thing was planning and compliance with KPI. In general, you look at the solution - and immediately imagine who exactly invented it.
Evaluation criteria for us were quite simple. The main thing is the practical applicability of the solution at our enterprises. Almost everyone managed, out of the 6 solutions presented, only 2 did not suit us at all (although, with a sample of 6, this is a third). But the thing was that the guys either did not complete the solution itself without going into details, or the solution was not suitable for the petrochemical industry. Alas, this also happens - and it seems that the solution itself is not bad, it solves problems, maybe it even scales, but specifically, we don’t use it at all, the stack is not the same. At all.
The remaining 4 solutions showed themselves perfectly, we decided that the guys understand exactly what they did and what they will do, so they will now participate in our projects.
Nikolay Ksenzik, Head of the Center for Digital Technologies in Tomsk, SIBUR IT.
Tomsk, in principle, deservedly enjoys the fame of a city of scientists and students, after all, 15 research institutes, 9 universities and several business incubators - this is serious. Therefore, we decided to invite both students and experts from various companies to participate. We gave a case from life (read - from production), it was a task for advanced analytics at a petrochemical enterprise. About how it was - under the cut.
The workshop lasted 3 days, it was exactly how much time the teams had to solve our problems and show that the solution they created was something that would actually help the industry, or simply carry a number of useful mechanics that could be applied in the production of digital chemistry in the future.
Task
It was necessary to create a working scenario, within the framework of which the development and implementation of a system of proactive monitoring of technological equipment that we use in production would be carried out.
At the same time, it was important to take into account that it is logical to divide such equipment into several types (according to criticality), therefore the approaches to their management and monitoring should not be the same, and a single script would not work here. It was also necessary to take into account that the company uses the simplest visualization systems for already collected data, which can also be used. Plus, we gave a number of factors to the load - the influence of the condition of the equipment on the product margin; frequency of scheduled repairs; Scenarios for installing additional stands in cases where a basic monitoring system is already in place, and so on.
And we immediately prescribed a number of frameworks and limitations that must be taken into account, otherwise it will turn out that you made a decision, but you won’t be able to apply it, because you forgot about some of these factors. This helps, because such a solution should work in live production, and many different things can happen in the process.
Among these factors were:
- Poor quality of data collected.
- The presence in the team for creating such a monitoring system of specialists with various expertise - programmers, production technologists, people familiar with the equipment, as well as experts in the field of mathematical modeling.
- The unwillingness of staff to use the new system (well, how else).
- A complete lack of data for solving problems (some parameter is not considered, there is no sensor that would take information, etc.).
- If there is any data, there may be difficulties with it - for example, not all of them are digitized (but you need to work with them), they are stored in different formats, some cannot be reached in a couple of clicks, and you need to go through a couple of circles approvals.
Obligatory components of the system: a module that finds anomalies in the equipment (something is warming up, not supposed to, something is hanging out, but it should hold on, and similar behavior), and a forecasting module that can predict a similar situation based on already collected data .
At the output, I wanted to get a detailed description of the solution, which will allow, taking into account all these conditions, to introduce a system of proactive monitoring of equipment. It could include machine learning algorithms, any ready-made solutions and frameworks.
And quite ideally (and this is why there were people from the business as part of the teams) - to note those business processes that will be affected by the introduction of such a system; you may even have to introduce new business processes to ensure that the solution works.
Total
We must pay tribute to the teams - they proved to be excellent. The teams were rather mixed, within the framework of one, both students and programmers with data analysts, and heads of directions, and directors of local companies could work immediately. And such a composition greatly influenced the resulting solutions, we checked and immediately noted that someone had a great emphasis on the architectural part, someone put interaction with users at the forefront, someone decided that the main thing was planning and compliance with KPI. In general, you look at the solution - and immediately imagine who exactly invented it.
Evaluation criteria for us were quite simple. The main thing is the practical applicability of the solution at our enterprises. Almost everyone managed, out of the 6 solutions presented, only 2 did not suit us at all (although, with a sample of 6, this is a third). But the thing was that the guys either did not complete the solution itself without going into details, or the solution was not suitable for the petrochemical industry. Alas, this also happens - and it seems that the solution itself is not bad, it solves problems, maybe it even scales, but specifically, we don’t use it at all, the stack is not the same. At all.
The remaining 4 solutions showed themselves perfectly, we decided that the guys understand exactly what they did and what they will do, so they will now participate in our projects.
Nikolay Ksenzik, Head of the Center for Digital Technologies in Tomsk, SIBUR IT.