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

Предыстория

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

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

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

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

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

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

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

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

Отступление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У нас было:

• 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г сделать из советчика полноценный удаленный автопилот, чтобы люди, приезжающие к вам на завод, выглядели так

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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