Как на Excel заработать сотни миллионов? Опыт проекта RTO05.12.2024 22:15

Добрый день, читатели!

Предыстория:

С чего обычно начинаются веселые проекты?

  1. Фазы проработки гипотезы и предпроектной проработки решили не делать

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

  3. «Ядром» для советчика должна была стать технологическая модель от иностранной компании, софт которой не обновлялся несколько десятилетий, а точность была под большим вопросом. Как она выиграла в тендере? Захотели разнообразия.

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

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

  6. На роль руководителя проекта был приглашен ведущий-инженер технолог производства с околонулевым опытом управления командой (ваш покорный слуга).

  7. Предыдущая команда при переходе на следующий этап на защите проекта «немного слукавила», не выполнив половину пунктов, которые обязана была сделать в рамках 1 этапа. Предполагалась работа в режиме советчика — выдача рекомендаций по ведению технологического процесса на интерфейсе пользователя в операторной. Ни созданных тегов для передачи уставок, ни подключенных тегов к модели, ни интерфейса пользователя — не было, как сказал бы Олег Тинькофф, НИ-…-Я 

Мое лицо от осознания, куда я вляпался

Мое лицо от осознания, куда я вляпался

Отступление:

Советую также прочитать предыдущую обзорную статью про RTO и отличную статью моих бывших коллег. Это сейчас с высоты накопленного опыта мы можем похвастать несколькими уникальными в России проектами удаленного интеллектуального автопилота производства, а начинали с ранее описанных вводных и прокладывать эту дорожку к успеху было довольно интересно.

Для тех, кто решил отложить эти статьи на потом, коротко изложу — целью проектов RTO является повышение уровня эффективности и автоматизации производства. При этом, находясь в иерархии между системами планирования производства ERP, управления производственными процессами MES и непосредственного контроля за технологическим процессом, следующей значимой составляющей в данном проекте помимо самой технологической модели является его ИТ-архитектура. О ней сейчас и поговорим.

Особенности IT-архитектуры RTO

Организация инфраструктуры передачи данных имеет ряд особенностей по сравнению с другими «советчиками», ведь если мы говорим не об открытом, а закрытом контуре, то предполагается не просто выдача рекомендаций оператору пульта управления, а непосредственная отправка сигнала от сервера с моделью с распределенную систему управления производства (РСУ).

Важную роль при реализации мер защиты играет сегментация сети передачи данных. Существуют решения, где модель расположена внутри технологической сети передачи данных (ТСПД) и не связаны корпоративной сетью передачи данных (КСПД). Однако, на мой взгляд, целевым решением является именно удаленный автопилот, т.е. размещение модели в корпоративной сети. В противном случае рано или поздно вы поймаете следующие ситуации:

  1. Ой, не можем найти инженера поддержки в наш великолепный город Мухосранск

  2. Ой, единственный инженер поддержки в отпуске, а потенциальные замены не могут оформить срочную командировку из-за своих планов

  3. Ой, товарищи инженеры, решение локальное, поэтому прогрузка новой версии модели каждый раз требует от вас выезда на площадку. А что вам не нравится?

  4. Ой, для прогрузки изменений в модель требуется ожидание в несколько месяцев до остановочного ремонта производства, поскольку вносить изменения «на ходу» запрещено из-за риска «уронить» управление в ходе прогрузки изменений.

Запрещенная практика на промышленных площадках

Запрещенная практика на промышленных площадках

Итого, наилучшим решением будет вынесение модели в КСПД при обеспечении инфраструктуры передачи данных (корректировок) из КСПД в ТСПД и наоборот.

  1. Данное архитектурное решение позволяет обслуживать текущую модель и «выкатывать» в PROD ее новые версии дистанционно, без необходимости разработчикам присутствовать на производственной площадке.

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

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

Перейдем к главному.

a7db447bc62b4ae0b7ce5cda7f02440f.PNG

Для обеспечения безопасной передачи данных между RTO и АСУТП должна быть организована специальная буферная зона ДМЗ ОКИИ (демилитаризованная зона объектов критической информационной инфраструктуры), которая включает в себя систему обеспечения информационной безопасности (СОИБ).

СОИБ включает в себя множество мер защиты и процессов для контроля как периметра АСУТП и передаваемых технологических данных, так и обеспечивает инфраструктурные процессы по обслуживанию системы, включая:

  • систему идентификации и аутентификации

  • систему обновлений ПО

  • антивирусную защиту

  • сервис сбора событий

  • сервис резервного копирования

  • систему сетевого мониторинга

  • эшелонирование и сегментацию

Полный перечень требований к СОИБ ОКИИ можно посмотреть на сайте ФСТЭК приказ №239 от 25.2017. Конкретные протоколы передачи данных, ПО для обеспечения работоспособности этой схемы и удовлетворению СОИБ — это конкретика, которая не разглашается по правилам ИБ, да и сугубо индивидуальная для каждой компании, поэтому я бы и рад рассказать, но смысла мало, а проблем потенциальных — много.

Ближе к делу, Excel — твой выход

У нас было 2 пакетика травы, 75 ампул...

У нас было 2 пакетика травы, 75 ампул…

У нас было:

  • dll модель иностранного вендора формата black-box (направил данные для расчета в Excel — получил результат JSON-файлом)

  • MES c удобной надстройкой Proficy historian для обмена данными с Excel

  • Требования в сжатые сроки сделать простую визуализацию для регулярной демонстрации полученных данных модели пользователям (не забываем, пилотный проект, модель не откалибрована, требуется постоянно показывать результаты расчетов заказчику

Выбран был Excel с самописной моделью обработки данных и оптимизации расчетов на VBA как самый простой и быстрый вариант. Код был написан по всем канонам ООП, а решение было лаконичным и состояло всего лишь из ~3000 строк кода. Теперь пройдемся по оптимизатору. Не думаю, что многие в курсе, но в надстройках экселя можно выбрать «поиск решения» и у вас будет возможность проводить оптимизацию одним из трех солверов (линейный, понижающего градиента, эволюционный).

Окно оптимизатора

Окно оптимизатора

Первое время мы вручную проводили расчеты в excel, пока наш доблестный разработчик осваивал VBA и писал код будущей шайтан-машины. Затем по мере разрастания кода плавно перешли на автоматический расчет каждого модуля, а их в RTO несколько.

  1. Сбор данных. При помощи другой надстройки в Excel обеспечивался коннект к системе MES, откуда собирались данные по тегам для будущего расчета.

  2. Проверка данных. В зависимости от логики, некоторые данные критически важны «сырые», т.е. текущие и без них расчет невозможен. Где-то можно настроить логику замены на среднее за последний успешный период. А часть данных хоть и на первый взгляд нормальные, не Bad’ы какие-нибудь и не нули, но имеют регулярную системную ошибку.

  3. Согласование данных. Как раз таки инструмент, который лечит эти регулярные ошибки. Например, сведение материального баланса. Вошло 500т, а вышло 480. Кто врет? Собираем все расходомеры, составы потоков и путем минимизации суммарной ошибки через опять же оптимизацию сводим мат. баланс и приводим данные к более достоверным.

  4. Расчет текущего режима. Подключаемся к нашей DLL-модели, бросаем в нее данные через call-функцию, написанную Python-скриптом, получаем ответ в виде JSON, парсим обратно в Excel в нужные переменные и ячейки.

  5. Ввод ограничений. Оператор на интерфейсе пользователя вводит значения технологических (давление, температура и т.д.) и производственных (выход продукции, загрузка конкретных линий производства, потребление сырья или энергоресурсов) ограничений, которые нам пригодятся в п.7.

  6. Расчет режимов для оптимизации. От текущего режима делаем шаги вверх/вниз по каждой варьируемой переменной, полученные сценарии пропускаем через модель согласно п.4.

  7. Оптимизация. С помощью выбранного солвера и его настроек подбираем баланс между рассчитанными режимами, в стиле «щепотку Х, половину Y и другую половину Z». На выходе имеем оптимизированный сценарий работы, который уперся минимум в 1 ограничение и имеет максимальную маржу среди остальных сценариев.

  8. Отправка данных. Конфигурация файла для отправки на сервер пользователя с отображением на интерфейсе итогов оптимизации. В каждой из ссылок про RTO в разделе отступление есть пример интерфейса.

Теперь про сам код. 

SolverOk SetCell := Cells(row, column), MaxMinVal := 1, byChange :=

Целевая функция из окна оптимизации, показанной ранее. Какую ячейку оптимизируем, как оптимизируем (мин, макс, целевое значение), какие ячейки изменяем. 

SolverAdd CellRef: = Cells(Row, Column).Address(), Relation := 2, FormulaText := 50

Добавление ограничений: берём значение ограничения для ячейки Cells, устанавливаем для него отношение »<=" (цифра 1), и значение не больше которого она может быть (цифра 50). Realation 3 - "+>», 2 — »=». Чтобы все прелести тут не расписывать, дам ссылку.

Настройки солвера

Настройки солвера

'параметры решателя - ключевое: линейная модель, решаем Симплекс-Методом
SolverOptions MaxTime:=50, 
Iterations:=10, 
precision:=0.1, 
assumeLinear:=True, 
StepThru:=True,                
Estimates:=1, 
Derivatives:=1, 
SearchOption:=1, 
IntTolerance:=3, 
Scaling:=True, 
Convergence:=0.01, 
AssumeNonNeg:=True

Функция SolverSolve вернёт нам некое число. Если это 0, то солвер нашёл решение и мы сохраняем его. Иначе можем не сохранять. Естественно, нюансов впереди вас будет ждать уйма, например еще не успели произвестись одни внутренние калькуляции (на листах, ячейках, переменных), а код пошел шагать дальше и отправил неполный или неточный пакет данных на внешнюю калькуляцию. Лечилось так

Do While Application.CalculationState = xlDone
    Loop

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

TimeExpire = Now + TimeValue("00:30:00")

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

Эпизод IV. Новые проблемы

Трудности начались дальше при попытке в 2022 г сделать из советчика полноценный удаленный автопилот, чтобы люди, приезжающие к вам на завод, выглядели так

05063fad3d0ce6276ba96785d9f26340.jpg

По всем известным причинам многие ключевые поставщики оборудования ушли с российского рынка либо потеряли сертификаты ФСТЭК. Перед руководителями проектов возникли следующие задачи:

  1. поиск и тестирование необходимых аналогов на доступном для России рынке;

  2. доработка оборудования и ПО под требования компаний;

  3. проведение ПМИ/ПСИ для получения согласования и включения в вендор-лист

  4. необходимость пересмотра спецификаций оборудования;

  5. корректировки технорабочих проектов (ТРП).

На смену привычным всем Yokogawa, Asus, Cisco, Siemens, Dell и прочим пришли Huawei, Infowatch, Провенто, Fortigate и другие хорошие ребята. Реализация проектов уехала на 2023 год, а реестры выученных уроков пополнились десятком строчек.

Следующим вызовом стала необходимость перехода на групповую управляемую учетную запись gMSA. Оказалось, что под данной учеткой не работают приложения, запускать можно только службы, к которым Excel с его интерфейсом не относятся. Пришлось переписывать решение на Python и искать в команду Гарри Поттера. Но это уже другая история.

Заключение

Реализация подобных проектов подарит вам

  • возможность гордиться уникальностью данного решения, ведь мало кто осмелится потратить пару лет своей жизни на согласование канала передачи данных в блок ТСПД, поскольку «не хватало нам еще, чтобы какая-то там моделька управляла заводом»©

  • уникальный опыт создания из говна и палок крутого продукта с огромным экономическим эффектом, а ведь умение делать из воздуха деньги — это хорошая заметка в резюме и волки где-то на Уолл-Стрит читая его воскликнут «АУФ» и захотят провернуть с вами пару мутных схем

  • навык превращения waterfall проекта в agile, поскольку сроки для проекта, в котором доля НИОКР составляющая, совершенно непредсказуемые. Пробовали в компании, не знакомой со словом agile, продлить 5 раз сроки?

  • опыт работы в условиях, когда доверие внешнему подрядчику больше, чем своим IT дочкам. Один пример озвучивал, а другой —  ожидание в 6 мес для проведения ПМИ ключевого оборудования для проекта силами другой IT-дочки, которая имитировала работу и ничего не делала по факту ибо «рук нет».

Так что, мой вам совет — делайте как надо. Как не надо — не делайте. Спасибо за внимание!

© Habrahabr.ru