Новости с полей цифровизации производства за ноябрь.

• Группа НЛМК (https://habr.com/ru/company/nlmk/profile/)

• Сибур (https://habr.com/ru/company/sibur_official/profile/)

• Первая грузовая компания (https://habr.com/ru/company/pgk/profile/)

• Северсталь (https://habr.com/ru/company/severstal/profile/)

• Евраз (https://habr.com/ru/company/evraz/profile/)

Публикации за ноябрь

НЛМК

Как мы узнали, что одна из бригад оцинковщиков работала быстрее других и что было дальше

Все бригады работают по одинаковым техническим инструкциям и примерно с одинаковыми сортаментными группами: толщиной и шириной проката, маркой стали и т.д. Но производительность у бригад немного отличается.

Сравнение статистики распределения скорости полосы при работе бригад на одинаковом сортаменте показало, что все работают на близких скоростях, но, тем не менее, их медианная скорость отличается. На глаз, находясь в цехе, разницу заметить достаточно сложно, нужно видеть серии результатов.

Технологи предложили создать сервис, который подсказывал бы максимальную допустимую скорость при переходах на новый сортамент. Точнее, говорил бы «можно быстрее» или «а вот сейчас лучше медленнее».

Анализируя данные с датчиков для каждой бригады, мы построили график оптимальной и фактических скоростей и на основании этого разработали советчик, который включается при переходах по сортаменту и рекомендует скорость, учитывая толщину/ширину и марку стали. Так мы помогли тем, кто работал по принципу «тише едешь – дальше будешь», приблизится к результатам бригад, которые предпочитают работать «на острие».

Рекомендательный сервис состоит из двух компонентов. Одна часть – теоретическое значение оптимальной скорости. Технологическая инструкция регламентирует диапазон возможных скоростей для конкретного сортамента. Рекомендуемые параметры перевели в формулы и настроили сервис таким образом, что он выдаёт конкретное значения скорости, тогда как раньше в инструкции был указан широкий диапазон значений.

Вторая часть – на основании исторических данных, таких как, например, скорость обработки рулонов, мы разделили данные на группы по сортаменту (марка стали, толщина, ширина) и в каждой группе нашли максимальное значение скорости. База постоянно обновляется, добавляются новые значения, и мы всегда знаем актуальное значение максимальной скорости по группе. Теперь зная расчётное значение скорости и максимальное историческое значение скорости, мы находим их максимум и выдаем результат с небольшим повышающим коэффициентом 1,05%, но не больше допустимого значения по технологической инструкции.

Кроме того, мы выводим статистику топ-5 лучших скоростей на таком же сортаменте по всем бригадам. Каждый оператор может полагаться не только на предлагаемое значение скорости, но и на лучшие практики других бригад.

Над сервисом в течение трех месяцев работала продуктовая команда: сотрудники цеха, бизнес-транслятор и разработчики. Мы взяли не все параметры, по-хорошему можно отслеживать, например, ремонты. Сервис предполагает развитие, но даже сейчас при такой первичной оптимизации уже приносит экономический технический и эффект.

Сибур

Как мы оцифровали обходы. Часть 1: пилот и чек-листы

Отслеживать обход было невозможно, а соответственно и знать наверняка, что его совершили вовремя и в полной мере. Так появилась потребность в оцифровке процесса, и мы разработали продукт «Мобильные обходы». Он позволяет убедиться, действительно ли обходчик в нужное время был возле нужного оборудования, на самом ли деле он провел требуемые проверки, и все ли выявленные отклонения он зафиксировал.

Наш MVP состоял из web-интерфейса и мобильного приложения. Он предоставлял полную информацию о количестве и качестве обходов. И вот, как:

Первые данные мы запрашивали от предприятий в формате Excel, а потом руками загружали в систему, чтобы у пользователей в web-интерфейсе была информация для работы.

Там же можно было создавать маршруты, назначать их периодичность и наполнять теми единицами оборудования, которые следовало осмотреть. В мобильное приложение уже приходили маршруты-задания для исполнения.

Но как проверить, что обходчик на самом деле был на точке?

Мы решили добавить чекины по NFC-метке – заранее подготовили инфраструктуру, развесили метки и прошили их с записью единиц оборудования, которые требовали осмотра.

Так выглядит чекин

Куда именно вешать метки, какие включать единицы оборудования, и какие маршруты формировать, нам подсказывали коллеги с завода. Они лучше знают правила по эксплуатации оборудования, плюс у них богатый личный опыт и экспертиза.

На момент MVP мы хотели в первую очередь проверить гипотезу, что продукт приживётся, работники смогут с ним работать, а мы – собирать через него информацию. В итоге мы стали накапливать данные и наглядно видеть весь процесс совершения обходов. Мы сделали процесс прозрачным, и так появилась возможность более качественно управлять осмотрами оборудования.

Чек-листы

В процессе обхода, разумеется, важно не только зачекиниться, но и зафиксировать отклонения и дефекты. Чем раньше мы найдем дефект и устраним его, тем лучше и безопаснее будет работать производство. Поэтому мы внедрили чек-листы для осмотра оборудования.

Для каждой группы оборудования есть рекомендации, на что особенно важно обратить внимание. Не просто осмотреть в духе «Ну выглядит норм», а проверить уровень масла, снять показания датчика давления и проверить рукой температуру на предмет перегрева корпуса (кстати, сейчас это делают наши датчики интернета вещей), и др. Для удобства обходчиков мы показываем список сразу в момент чекина, чтобы вся нужная информация была под рукой и в быстром доступе. Это заметно повышает качество осмотра.

Дефекты на производстве выявляли и без нашего продукта, но картина была далеко не полной. По многим причинам. Вот пара примеров:

• Неудобно переписывать на бумагу, когда стоишь на открытой установке на высоте двухэтажного дома. В минус сорок. И ночью;

• Пока шёл до операторной, отвлекли, и забыл вовремя передать инфу;

• Увидел пустяковый дефект и устранил его сам. И решил никому не говорить;

• Или проблему устранила ремонтная служба, но информацию всё равно нигде не отразили – «а зачем, всё же работает».

Так, конечно, не пойдёт.

Когда мы делали функционал фиксации дефектов, мы в первую очередь шли от проблемы дискомфорта: чтобы люди пользовались продуктом, важно учитывать контекст обхода и условия работы обходчика. От внешних погодных условий до экипировки – в сибирскую зиму, например, перчатки лучше не снимать.

Когда мы проектировали эти возможности, упор делали на простоту и удобство работы, чтобы количество обращений к интерфейсу было минимальным. При этом мы не забывали о минимальном наборе данных, который требуется для фиксации дефекта – здесь количество кликов или тапов может быть прямо-таки жизненно важным.

В итоге мы выстроили взаимодействие с интерфейсом так, чтобы с ним можно было работать не только с помощью тапов, но и при помощи боковых кнопок или голосового набора. Всё ради того, чтобы руки работников оставались в тепле!

Когда мы выкатили эту фичу, она и правда хорошо и быстро прижилась. И к нам полился огромный поток данных. На некоторых предприятиях объём зафиксированных дефектов увеличился до 400%, но вовсе не потому, что внезапно все стало ломаться – просто мы достигли той самой прозрачности, когда фиксируется любое, даже мельчайшее отклонение.

Чтобы визуализировать такой объём информации мы обратились к коллегам из управления корпоративными данными. Они собрали аналитические дашборды, на которые можно было взглянуть и понять, что делать и как управлять данными дальше.

После того, как мы стали фиксировать дефекты и выводить информацию на дашборды, у нас, помимо производства, появился еще один внутренний заказчик. Это служба управления надежностью, которая как раз отвечает за стратегии техобслуживания. Сейчас мы с ними прорабатываем новые процессы и возможности развития продукта. Впереди интересный вызов – как не только получать и анализировать данные, но и быстро корректировать стратегию. И исполнять её, сокращая при этом внеплановые поломки и издержки на ремонт.

Как мы оцифровали обходы. Часть 1: пилот и чек-листы

Как мы оцифровали обходы. Часть 2: журналы и ремонты

На производствах есть обязательные для ведения документы, «Сменные журналы». По сути, это логи производства. В них фиксируются все события, произошедшие за смену — кто сегодня в составе, когда смена началась и закончилась, что происходило, как менялся технологический режим, что отдали в ремонт, что вывели из ремонта, где переключили резерв, и др. В общем, максимально подробно.

Так как с «Мобильными обходами» мы начали оцифровывать процессы сразу по нескольким ролям – оператора, диспетчера и начальника смены – то решили не останавливаться на обходах и дефектах. Ведь журналы смен ведут те же самые люди.

Первую версию электронного журнала мы сделали одинаковой для всех предприятий. За что оперативно словили волну оправданного негатива от коллег.

Задача оказалась гораздо сложнее: внутри каждого завода, производства и даже каждой установки работают по разным технологиям и режимам. У каждого свой особенный конечный продукт. А ещё у всех 20 с лишним предприятий, на которых работает наш продукт, есть своя иерархия и количество участников, которые вносят записи в журнал. Плюс разные структуры и верификация этих записей.

Оправданный негатив сопровождался требованием вносить данные в один журнал сразу несколькими пользователями и соблюдать преемственность при приёме и передаче от смены к смене.

Мы сделали конструктор, который можно приспособить непосредственно под свои нужды: выстраивать необходимые иерархии и вести записи в табличном или текстовом виде. Или и в том, и другом. Также мы прикрутили к компонентам редакторы для удобства работы, возможность переноса данных от смены к смене, настроили автоматическое предзаполнение информации из систем и добавили электронную подпись. Благо, теперь законодательство это позволяет.

Всё это помогло нам уйти от тонн бумаг (а бумаги на самом деле копилось МНОГО), наладить интеграции этого журнала с различными источниками данных и сократить трудозатраты на ведении бумажных аналогов.

Распоряжения

Следующий процесс, который мы решили оптимизировать – выдача распоряжений. Это своего рода таски на производстве. Задания могут быть как для ознакомления (к примеру, информирование о правилах ношения СИЗ), так и для исполнения. К примеру, те же самые отклонения, которые обнаруживают обходчики. Если это возможно устранить своими силами, то начальник смены может создать такое распоряжение на того же обходчика. Выглядеть это будет так:

1.    Обходчик проводит осмотр;

2.    Фиксирует в приложении найденные дефекты;

3.    Начальник смены в режиме реального времени видит дефект в интерфейсе;

4.    Принимает решение и ставит обходчику дополнительную задачу;

5.    Обходчику приходит push-уведомление о том, что можно здесь и сейчас сделать своими силами;

6.    Обходчик выполняет задачу и отмечает это в приложении;

7.    Начальник смены видит актуальный статус распоряжения;

8.    Готово, все справились!

Ведение такого документа регламентируется, и оно обязательно по требованию надзорных органов. Поэтому мы также прикрутили электронную подпись, чтобы соблюсти форму документа и контролировать ответственность по его исполнению.

Мобильные ремонты

Итак, мы получили картину по обходам в реальном времени, с огромным потоком данных по дефектам, добились их фиксации и отражения. А что насчёт устранения дефектов?

Осмотры и ремонты тесно связаны, и в целом это части одного процесса под названием ТОиР —Технологическое обслуживание и Ремонт. Процесс всегда огромный и капиталоёмкий, причём на любом производственном предприятии.

Поэтому мы решили с помощью продукта «Мобильные ремонты» сделать прозрачными вообще все действия: от фиксации дефекта на оборудовании до его устранения, чтобы качественно управлять всем циклом процесса. И если фиксировать дефекты мы научились, то в части ремонта мы решили начать с получения фактической картины: как ремонты проводятся сейчас.

У нас в компании при планировании ремонта используются нормативы, в которых прописаны: какие нужны материалы, сколько потребуется человек, какие им необходимо выполнять операции, даже сколько времени потребуется на каждую операцию – всё это складывается в затраты. При планировании ремонтных работ ориентируются как раз на затраты из этих нормативов.

Чтобы подтвердить и, если нужно, скорректировать такие нормативы мы начали с инструмента для измерения фактических трудозатрат. Пошли короткими итерациями: сначала мы попросили коллег указывать фактическое время начала и окончания по каждой операции и количеству исполнителей. Почти как в плеере с кнопками «старт/стоп», но только на операциях. Дальше, перед тем как менять процессы и поставлять новые, нам потребовалось поменять организационный дизайн, и мы ввели новые роли. К примеру, у нас появилась роль супервайзера с отдельным KPI.

Запустив процесс, мы начали через дашборды внимательно анализировать, что происходит. Когда мы собрали информацию о реальных трудозатратах, мы увидели потенциал, где можно сократить нормативы и затраты компании, а где наоборот стоит планировать на ремонты больше времени или ресурсов. Но в целом, корректировка нормативов – процесс небыстрый, так как он требует большого количества исторических данных по ремонтам и их последующей аналитики.

Кстати, важно отметить: «Мобильные ремонты» –  это не только инструмент контроля за исполнением ремонта, но и полезный помощник, который может показать планы на неделю вперёд, чтобы сотрудник мог лучше провести подготовку к ремонту, а во время самого ремонта – загрузить нужные чертежи и отобразить всю историю: что было раньше с оборудованием, какие детали и когда меняли, и др.

Оснащение сотрудников всеми необходимыми инструментами и информацией довольно сильно влияет на качество ремонта, а чем оно выше, тем дольше мы не будем делать ремонт повторно. И тем самым сэкономим деньги.

Собственно, это и есть текущая фаза развития продукта. Дальше – больше! Мы принципиально против подхода, когда все работает «из коробки», ведь практически каждое изменение продукта подразумевает под собой тонны изменений в процессе и наоборот. Без оттачивания этих изменений никакой цифровой продукт не даст никакой дополнительной ценности. Так что мы продолжим усердно работать и рассказывать вам об этом :)

Команда и процессы

И для обходов, и для ремонтов мы используем один стек и микросервисную архитектуру. Сейчас в продуктовой команде 12 человек:

●      2 бэкендера;

●      2 фронтендера;

●      2 тестировщика;

●      2 Android-разработчика;

●      1 аналитик;

●      1 дизайнер;

●      1 скрам-мастер;

●      1 владелец продукта;

Но кроме команды разработки на наших предприятиях работает распределённая команда по внедрению цифровых продуктов. Эта команда максимально приближена к технологиям на самом производстве – она отвечает за обучение конечных пользователей, внедрение цифрового продукта и его приживаемость (совокупность метрик использования).

Отдельная фишка — это тираж нашего продукта. Мы разворачивали обходы и ремонты постепенно, начиная с установки на одном заводе. Сейчас мы работаем уже на более 20 предприятиях. Чтобы всякий раз не отвлекать команду разработки на тираж, мы спроектировали и разработали Self-Service: когда к системе подключается новый завод, команда внедрения с помощью раздела администрирования может самостоятельно прописать все необходимые маршруты, добавить пользователей и выдать им нужные роли, не привлекая ни одного разработчика.

Это позволяет нам двигаться в развитие функционала и не тратить ресурсы на тираж. А ещё у нас есть выделенная линия поддержки, которая отдельно занимается вопросами и проблемами цифровых продуктов.

Обратная связь и планы

Дизайнеров и разработчиков впереди ждёт особый вызов: большая часть наших пользователей – это производственный персонал, который трудится «в полях». Им не нужно навороченное приложение с прикольными фичами, хотя иногда, конечно, нам самим хочется добавить красоты. Но гораздо большее внимание нужно уделять проектированию взаимодействия и изучению контекста использования.

Мы, например, можем пожертвовать размером кнопок в угоду эстетике, но очень скрупулёзно будем рассматривать сценарий с дополнительным кликом или тапом. Ведь с нашими цифровыми продуктами работают, в том числе, и в опасных производственных условиях, так что это всё имеет действительно важное значение.

Все макеты, которые мы берём в разработку, обязательно проходят через серию юзабилити-тестов с пользователями. Да и вообще, выезды в «поля» очень помогают учитывать контекст – как, где и кто использует твой продукт в реальной жизни.

С момента запуска MVP «Мобильных обходов» прошло уже полтора года, а количество наших активных пользователей выросло до 7 000+ в месяц. Нагрузка на сервисы, конечно, тоже возросла, как и наши требования к качеству кода. Так как при растущей нагрузке стабильность сервиса может проседать, мы стали уделять больше внимания написанию автотестов и дополнительным мониторингам.

А ещё радует, что в процессе развития продуктов мы начинаем предоставлять их не только СИБУРу и нашим же заводам, но и совместным предприятиям с другими крупными компаниями. В общем, нам есть куда расти :)

https://habr.com/ru/company/sibur_official/blog/592473/

ПГК

Подводные камни в работе с данными в проектах Data Science

Меня зовут Павел Куницын, я работаю главным специалистом по анализу данных и машинному обучению в ПГК. На нашем примере расскажу, с какими трудностями мы сталкивались при внедрении ML-инициатив и как их преодолевали.

Первая статья, которую вы сейчас читаете, — о препятствиях, которые могут возникнуть при работе с данными.

Загрузка данных

Как известно, модели строят свои оценки на основании закономерностей в данных, выявленных в процессе обучения. Поэтому ML-конвейер всегда начинается с получения необходимого массива. К частым сложностям, с которыми может столкнуться data scientist на этой стадии, можно отнести:

1. Неожиданные изменения данных в источниках

2. Отсутствие документации

3. Большие объемы данных

4. Большое количество источников

5. Ошибки в ETL-процессах

Подготовка данных

Сырые данные практически никогда не пригодны для моделирования, и именно эта стадия является самой трудоемкой. Здесь часто приходится тратить много сил на аналитику, процесс подготовки данных может отнять большую часть времени проекта. К основным преградам на пути к формированию чистых данных можно отнести следующие проблемы:

1. Низкое качество данных

2. Сложности в разметке данных

3. Нехватка данных

4. Отсутствие бизнес-экспертизы

Применение Materialized Views в организации ETL-процессов

Приветствую! Меня зовут Жумабаев Султан, и в ПГК я работаю инженером данных на проекте «Цифровой вагон». Могу уверенно сказать, Oracle сегодня — одно из самых популярных и надежных хранилищ, хотя рынок и предлагает множество новых современных разработок. В этой статье я расскажу про использование Materialized Views для организации ETL-процессов в рамках проекта.

Существует два основных способа использования материализованных представлений:

1. Репликация данных в отдельные базы данных для снижения нагрузки запросов.

2. Повышение производительности запросов за счет периодического вычисления и хранения результатов сложных агрегаций данных, что позволяет пользователям запрашивать результаты сложных запросов на определенный момент времени.

Цифровой вагон

Система «Цифровой вагон» помогает собирать и анализировать большое количество данных о состоянии вагона, принимать своевременные решения о его ремонте и, таким образом, оптимизировать затраты ПГК. Проект стартовал с модуля, который позволяет отслеживать технические показатели колесных пар с датчиков, массово расположенных на сети РЖД — ИС КТИ (контрольно-технические измерения). Благодаря этой информации мы можем осуществлять их предиктивный, то есть предупредительный ремонт. Подробнее здесь.

Data Science для «неайтишных» компаний. Как организовать работу направления с «нуля»?

Сегодня большинство компаний идут по пути цифровой трансформации, внедряют новые методы работы и организации процессов. Частью этой трансформации обычно становится Data Science, ведь сложно себе представить «цифру» без предиктивной аналитики и возможностей, которые она дает. Меня зовут Надежда Костякова, я руковожу управлением анализа данных и машинного обучения в Первой грузовой компании (ПГК). Я расскажу о том, как мы начинали работать с направлением Data Science. Надеюсь, этот опыт будет полезен и специалистам, и компаниям, которые, как и мы, находятся в начале пути.

Data Science для «неайтишных» компаний. Как организовать работу направления с «нуля»?

Северсталь

«Хотим дашборд» — что на самом деле это значит и как создавать дашборды, которыми реально будут пользоваться

Гибкая аналитическая отчетность — звучит интересно, выглядит как светлое будущее и интригует бизнес-пользователей. Но когда они сталкиваются с реальными гибкими инструментами, то понимают, что работать с ними не так-то уж просто. И что они скорее предпочли бы статичную, но грамотно созданную визуализацию.

Я, Табулина Светлана, старший консультант по управлению данными в компании «Северсталь». Я расскажу, как мы используем SAP Analytics Cloud для создания дашбордов, как выясняем настоящие потребности бизнеса и как научились создавать аналитику, которой реально пользуются.

«Хотим дашборд» — что на самом деле это значит и как создавать дашборды, которыми реально будут пользоваться

Евраз

Техномагия для гиганта: как IT двигает ЕВРАЗ, а ЕВРАЗ качает IT

Лонгрид о этапах внедрения IT-проектов на производстве

Металлургический хакатон ЕВРАЗа по Data Science: результаты, проекты и победители

Технологии помогают повышать эффективность работы, поддерживать высокий уровень безопасности на производстве, соответствовать требованиям рынка — сегодня, например, растет спрос на высококачественные марки стали. Устойчивое развитие также невозможно представить без диджитализации.

Металлургии необходимы инновации, и для участников EVRAZ AI Challenge мы подготовили задачи, соответствующие реальным запросам бизнеса. О том, что из этого получилось — под катом.

Подробности о хакатоне

EVRAZ AI Challenge прошел в онлайне с 29 по 31 октября. Основными инструментами для общения стали Zoom и Telegram, а зарегистрироваться, собрать команду и сделать сабмиты участникам помогла специальная онлайн-платформа. Организовать и провести хак нам помогла команда Phystech.Genesis. Хакатон длился 48 часов. Участвовать могли как индивидуальные разработчики, так и команды до 5 человек. Мы приглашали архитекторов баз данных, дата-инженеров, аналитиков данных, специалистов по машинному обучению.

Рассказываем о двух треках EVRAZ AI Challenge.

Трек 1: Продувка металла через Data Science. Командам нужно было разработать модель, прогнозирующую содержание углерода и температуру чугуна во время и по завершению процесса продувки металла на кислородном конвертере.

Подробнее о задаче. При производстве стали чугун «продувается», т.е. насыщается кислородом. Этот процесс идет в среднем 15-25 минут при температуре около 1600 градусов. За процессом следит машинист дистрибьютора: на основе своего опыта и знаний он решает, когда продувку нужно остановить. Если «передуть» чугун, сгорит больше полезной части расплава — на выходе получится меньше стали, и компания потеряет часть прибыли. А если «не додуть», то марка стали не будет соответствовать заданным критериям качества. Процесс продувки придется запустить повторно, и это снизит производительность цеха. Соответственно, участникам нужно было разработать алгоритм прогнозирования параметров чугуна для помощи машинистам и повышения экономической эффективности производства ЕВРАЗа. Но обеспечить качественное предсказание — только половина дела. Важно понимать ограничения прогнозной модели и то, каким образом ее можно задействовать в оптимизации производственного процесса.

СУЭК/Еврохим

Просто новости

«УМНАЯ» КАСКА СТАЛА ЕЩЕ УМНЕЕ

В «Татнефти» продолжается тестирование интеллектуальных инструментов для повышения эффективности производственной деятельности. Обновленный образец «умной» каски проходит испытания на электроэнергетических объектах Компании. Совместный проект Центра промышленной и экологической безопасности и дочернего предприятия «Татнефть-Энергосбыт» предполагает не только экономическую выгоду, но и решает задачи по обеспечению безопасных условий труда и снижению рисков ошибочных действий персонала.

«Умная» каска стала еще умнее

НА КНААЗ ВЕДЕТСЯ ШТРИХКОДИРОВАНИЕ ИНСТРУМЕНТА

Ее значимой составной частью является проект «Инвентаризация и учет инструмента, оснастки с применением системы штрихкодирования». Проект рассчитан на восемь лет — это уникальный случай в практике совершенствования производственной системы Сухого, обычно горизонт планирования составляет максимум три года. Но в данном случае сделано исключение, с тем чтобы тиражировать проект на все подразделения предприятия.

Ежегодный экономический эффект от внедрения проекта составит 59,5 млн. рублей.

На КнААЗ ведется штрихкодирование инструмента

КАК ЭТО РАБОТАЕТ: СИСТЕМА «УМНЫЕ КАСКИ»

На Березовской ГРЭС успешно внедрена и работает новая интегрированная система сбора обработки и анализа данных с целью мониторинга за соблюдением правил техники безопасности «Умные каски». Новая система позволяет в онлайн-режиме получать информацию о местонахождении сотрудника, который вошел в производственную зону, контролировать параметры его жизнедеятельности и быстро найти человека в том случае, если он потерял сознание или получил травму на территории электростанции.

Система является дополнением к «Мобильному обходчику» для обеспечения качества обходов и осмотра оборудования.

Как это работает: система «Умные каски»

VR ДЛЯ БЕЗОПАСНОСТИ: РЕАЛЬНЫЕ НАВЫКИ ИЗ ВИРТУАЛЬНОЙ РЕАЛЬНОСТИ

АО "ПО "Электрохимический завод"

Приобретенный программно-аппаратный комплекс виртуальной реальности (ПАК VR) состоит из пяти автоматизированных рабочих мест на базе персональных компьютеров, соединенных в локальную сеть. Четыре «персоналки» оснащены шлемами виртуальной реальности и манипуляторами, с помощью которых тренируемый может выполнять в «виртуале» работу «руками». Пятый компьютер – для управления процессом обучения и проверки навыков.

Ряд преимуществ ухода в виртуальную реальность налицо: в виртуальном пространстве можно «разместить» не только ячейки КРУ, а все оборудование и интерьеры целой подстанции, причем реальной, той, в которой завтра персоналу придется непосредственно работать. Более того, софт ПАК VR позволяет моделировать различные задачи и ситуации, связанные с обслуживанием энергообъекта, что расширяет возможности процесса обучения.

VR для безопасности: реальные навыки из виртуальной реальности

ПОБЕГ ИЗ EXCEL-ТАБЛИЦ: ЦИФРОВИЗАЦИЯ ПРОИЗВОДСТВА В АЛРОСА

Один из ключевых проектов автоматизации на производстве — MES-система (Manufacturing Execution System, система управления производством).

Есть ощущение, что мы немного отстали от других предприятий горной добычи в России и мире по уровню цифровизации. Такие базовые вещи, как, например, системы диспетчеризации производства, системы планирования горных работ, единые информационные пространства, у других компаний существуют достаточно давно. Где-то уже внедрены более продвинутые технологии, элементы искусственного интеллекта или больших данных. Нельзя сказать, что в других компаниях продвинутые технологии «красивые» и выглядят как в книгах по цифровизации, но их элементы уже у многих присутствуют и, так или иначе, тестируются, эксплуатируются и приносят пользу компаниям. В таком срезе мы догоняющие. Но, думаю, если мы сделаем программу цифровизации производства так, как задумали, имеем все шансы выйти в лидеры.

Побег из Excel-таблиц: цифровизация производства в АЛРОСА

Картиночки (Де? Мотивирующие)

«ЕВРОЦЕМЕНТ ГРУП» СОВЕРШЕНСТВУЕТ СИСТЕМУ МОБИЛЬНОГО МОНИТОРИНГА ОБОРУДОВАНИЯ

«МОБИЛЬНЫЙ ОБХОДЧИК»: КАК ИДЕТ ВНЕДРЕНИЕ В «ТЕПЛОЭНЕРГО»

«ОДК-САТУРН» ВНЕДРЯЕТ ЦИФРОВЫЕ РЕШЕНИЯ В ДЕЯТЕЛЬНОСТЬ МЕТРОЛОГОВ