Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
MES (manufacturing execution system) — система управления производственными процессами, которая решает задачи синхронизации, координации, анализа и оптимизации выпуска продукции на производстве. Относится к классу систем управления уровня цеха, но может использоваться и для интегрированного управления производством на предприятии в целом. Мы честно пытались использовать покупную коробочную версию от умудренных опытом автоматизации производства зарубежных коллег. Они даже пробовали переписать ее под нас, но не смогли! И тогда мы расчехлили наш старый Delphi, а наши эксперты превратились в разработчиков и сели его допиливать. Я, Андрей Тимченко, и Ксения Куницкая контролируем процессы управления производством "Северстали" со стороны ИТ, расскажем вам, как все было.
Чтобы понять, какой должна быть наша MES-система, посмотрим, что собой представляет производство «Северстали»
Производство металла на комбинате проходит полный цикл: от обработки каменного угля и железной руды до выплавки готовых изделий из высококлассной стали. Это, например, ванты для мостов, трубы газопроводов, оцинковка для автопроизводства и немало других нужных и полезных изделий. Технология производства состоит из нескольких этапов, которые называют переделами. Сначала из железной руды и коксующегося угля получают чугун. Далее из чугуна, металлического лома и легирующих добавок выплавляют сталь, которую для дальнейшей обработки отливают в слитки-слябы. Сляб — это основной вид продукции сталеплавильного производства. Следующий передел — это листопрокатные цеха (ЛПЦ). В них слябы нагревают, потом раскаленный докрасна кусок металла начинают постепенно плющить, проводя через каскад валков. Зазор между валками уменьшается с каждой парой, в результате чего из толстого и короткого сляба получается тонкий и длинный лист. В конце линии прокатки лист сматывают, и получается рулон горячекатаного металла.
Горячекатаный металл — это востребованный на мировом рынке продукт. Однако металл может стать значительно более востребованным после холодной прокатки. Пройдя различные производственные операции в холодном прокате (например, термообработку, травление), рулон металла становится более прочным, гибким, лучше сопротивляется ударам и разрывам. Именно в цехах холодного проката на металл наносят цинковое или разноцветное полимерное покрытие.
Далее металл может получить необходимые конкретному заказчику свойства. Ведь не всем заказчикам нужен металл в рулонах или листах, зачастую нужны так называемые гнутые профили, то есть порезанные листы металла, которые изогнуты под нужды заказчика. Это делает цех гнутых профилей (ЦГП).
Получается, что при производстве совершается множество сложных операций, в процессе которых требуется отслеживать и учитывать передаваемые параметры полуфабрикатов и готовой продукции. Как весь этот производственный учет автоматизировать? Тут не может быть никаких общих решений по типу 1С:бухгалтерии, потому что они формализованы нормативными актами, а учет металла завязан еще и на складскую логистику, управление запасами, техническое обслуживание и ремонт, требования заказчиков.
А какая была автоматизация до нашей эры?
Не было никакого общего контроля за автоматизацией процесса учета металла в цехах. Ситуация напоминала эпоху феодальной раздробленности в западной Европе: каждый цех был совершенно автономен и решал свои проблемы учета, как мог. У кого-то были свои БД, несколько своих программистов или даже целый информационно-вычислительный центр (ИВЦ). В цехе на рабочих местах стояли ПК, работающие в текстовом режиме. Учетчики заносили информацию в таблицы БД через Oracle Forms по протоколу telnet или делали запросы. Такие цеха считались жутко продвинутыми в части IT, и учетчики других цехов им завидовали. Они-то вели учет металла старым дедовским способом: вносили записи в журналы, а в конце месяца специально обученные люди по этим журналам делали отчет в Excel и клали распечатку таблицы на стол начальнику.
С распространением ОС Windows и доступностью GUI приложения типа Oracle Forms сразу же морально устарели, хотя и продолжали использоваться еще довольно долго. Все цеха перешли на использование БД Oracle, а в качестве клиента в 95% случаев использовалось приложение на Delphi. Но в системе учета каждого цеха по-прежнему было реализовано свое, написанное на коленке, уникальное решение. Никакого единого подхода к отслеживанию продукции не было, не говоря уже про унификацию процессов производства.
Немного облегчила жизнь реализация системы межцеховой передачи металла, которая позволила пользователям одного цеха не вводить заново в систему данные о полуфабрикатах, поступивших из другого цеха. Но в остальном системы учета разных цехов были по-прежнему совершенно непохожи друг на друга, подобно формам жизни, которые развивались на разных планетах.
В общем, нужна была унификации процессов учета и аттестации. И уже на базе этой унификации надо создавать систему для всех производств, основанную на едином подходе, где клиентские интерфейсы были бы одинаковые, цеха отличались бы друг от друга только настройкой справочников, а основой были бы таблицы БД с единообразной структурой.
При этом в ИТ не было таких должностей как «постановщик задачи», «разработчик», «тестировщик». Был просто «программист», и этот чудо-специалист должен был и технологию цеха знать, и пользователя понимать, и код писать, и клиента ORACLE установить, и понять, почему на складе готовой продукции не печатает принтер, и мышку мог почистить, чтобы шустрее ездила.
«Облом из коробки» и переделка системы под первый цех
Задача по унификации учета металла во всех цехах представлялась нам сложной. Для создания системы было рассмотрено множество предложений, в том числе и от иностранных фирм, которые, как мы ожидали, привнесут в нашу компанию передовые технические решения и лучшие мировые практики. Состоялся тендер, и победу в нем одержала зарубежная компания, которая гордилась своим опытом в части автоматизации производства. Но уже совсем скоро оказалось, что подрядчик недооценил масштаб производства «Северстали», количество переделов и видов выпускаемой продукции, сложности технологических процессов. И переоценил возможности своего продукта. Предлагаемое «коробочное» решение не получилось просто настроить под нужный цех, чтобы оно с легкостью заработало. Но отступать было уже поздно — проект был важен для развития предприятия, и надо было добиваться рабочего решения.
Мы ожидали, что заграничные коллеги выполнят fine-tuning своей системы под сталеплавильное производство. Оно ведь достаточно простое вроде бы: взял чугун, лом, да и выплавил сталь. Ну, может быть, нужно еще химических элементов добавить в процессе. Мы провели анализ производства и составили список требований к новой MES-системе. Пришло время нашим зарубежным подрядчикам показать свои лучшие мировые практики! Но ко всеобщему удивлению никакой тонкой настройки не произошло. Вместо этого заморские специалисты достали ноутбуки, запустили на них Delphi XE2, выбрали пункт меню «New project» и… начали писать систему практически с нуля. Естественно, при таком подходе сроки внедрения новой системы стали стремительно перемещаться в весьма отдаленное будущее.
Полученный через какое-то время первый прототип системы представлял собой монстра в виде шести отдельных огромных EXE-файлов, каждый из которых реализовывал функциональность отдельной области: справочники, работа с заказами, производство, качество, склады и отгрузка, отчеты. Такая реализация вобрала в себя вовсе не передовые технические решения, а набор примеров «как делать не надо». Разработчики не стали использовать возможности СУБД ORACLE, а использовали БД просто как хранилище таблиц с данными. Вся бизнес-логика, все операции с данными (добавление, удаление, обновление) и все запросы хранились в клиенте. Использовалось большое количество сторонних компонентов для Delphi, и это превращало настройку компиляции проекта в сущий ад. Размер исходников проектов был настолько велик, что часто попытка компиляции в IDE приводила к системной ошибке нехватки памяти. Пришлось модернизировать парк пользовательских ПК, чтобы система хоть как-то работала на местах. Но в итоге MES все же внедрили в производство.
На очереди маячил следующий цех, куда отправлялось больше всего слябов из сталеплавильного — это листопрокатный цех №2 (ЛПЦ-2). Он уже не такой простой: в нем несколько переделов и много видов продукции. Процесс аттестации продукции в этом цехе уже автоматизирован. Всем было ясно, что если попытаться внедрить новую MES в ЛПЦ-2 точно так же, как это сделали в сталеплавильном, то грядет полный провал и по срокам, и по степени удовлетворенности пользователей.
Как наши консультанты стали программистами
Первые изменения, которые мы внесли:
С самого начала мы стали четко ориентироваться именно на возможности СУБД и её доступные фишки. Вся бизнес-логика и запросы теперь хранились в пакетах на стороне сервера. Приложение стало использовать компоненты прямого доступа к БД.
Поменяли структуру приложения. Теперь EXE-файл был всего один, он представлял собой оболочку для показа интерфейсов. То есть, при подключении нужно было выбрать среду — это либо цеховая система, либо общий модуль типа ведения справочников. Каждая среда имела свое дерево функций (как любая древовидная структура или главное меню). При выборе конкретной функции в этом дереве показывался основной интерфейс выбранной функции. Реализованы эти интерфейсы были в BPL-пакетах, которые подключались по мере необходимости. Больше не было огромных экзешников, а разработку интерфейсов можно было разделять между программистами, каждый из которых правил свой пакет.
Было решено реализовать новый фреймворк, которым должны были пользоваться все подключаемые к системе пакеты. Этот фреймворк был призван обеспечить единообразие в написании интерфейсов не только в отношении кода. Внешний вид интерфейсов тоже должен быть одинаковым. Фреймворк был основан на базовых классах типа frame, в них реализованы элементы интерфейсов, которые могут быть показаны как на основных формах, так и на панели или во всплывающем окне с кнопками «Ок» и «Отмена». При этом от использования классических DB-Aware компонентов Delphi отказались, все данные загружали в память и работали с ними далее как с двумерным массивом типа variant.
И тут наши подрядчики поняли, что сами они в обозначенные сроки никак не справятся. Поэтому IT-специалисты «Северстали», которые были приглашены исключительно для консультаций, оказались партнерами по разработке. Теперь они должны были сами писать систему, которая была куплена как коробочный продукт, причем самостоятельно прорабатывая новую архитектуру БД и принимая активное участие в основной разработке. «Подвиньтесь-ка!» — сказали ребята и увлеченно заклацали по клавиатурам, вглядываясь в экран из-под нахмуренных от мыслительного процесса бровей. Этого никто не ожидал.
Что ж, нашу новую MES-систему для ЛПЦ-2 мы исполнили в четыре руки, как говорят пианисты, то есть, сообща. Для организации совместной работы использовали MS TFS (Team Foundation Server), где создавали задачи и отслеживали их выполнение, а также применяли его в качестве общего репозитория для хранения кода. И хотя впоследствии оказалось, что TFS — не лучший выбор на роль сервера совместной разработки, это все равно было огромным шагом вперед по сравнению с предыдущей организацией работы. Раньше задачи либо вообще явно не отслеживались, либо их пытались отслеживать в каких-то написанных по заказу системах учета. С хранением исходников был полный хаос: часто они хранились на ПК разработчика, иногда их даже теряли. Совместная работа над кодом в таких условиях была просто невозможна, и всё решалось тем, что отдельные приложения целиком отдавались разработчику — он сам писал в их коде то, что хотел, и сам выгружал все изменения.
Теперь технология разработки стала намного более четкой и прозрачной, появилось разделение зон ответственности.
Делаем так:
Сначала функциональный менеджер выясняет у пользователя, что нужно сделать, а пожелания оформляет в виде задач TFS.
Задачи попадают к начальнику отдела разработки, он распределяет их по разработчикам.
Разработчик берет себе в работу задачи из плана на неделю и в процессе их реализации меняет код в общем репозитории. После того как реализация завершена, разработчик переводит задачу в тестирование.
Изменения выставляются на тест не самим разработчиком, а отдельной группой деплоя. После успешной проверки изменения выставляются в рабочую среду также деплоем. В дальнейшем мы разработали собственную систему автодеплоя.
На очереди — производство холодного проката (ПХП, но не то, к которому вы привыкли).
Внедрение MES в ПХП: подрядчики только “мешают”
При распространении системы ЛПЦ-2 на ПХП никакого готового решения не получилось, пришлось много чего дописывать. Слишком сильно отличается производство в одном цехе от другого, у каждого своя специфика. Но зато была получена система, которая использует единые базовые структуры БД и однотипные принципы работы с учетными единицами. В клиентской части — единое представление сред и их функций, почти все интерфейсы используют единый фреймворк, в результате чего у них одинаковая структура кода и внешний вид.
Еще оказалось, что теперь наши зарубежные подрядчики приносят нам больше проблем, чем пользы. Никаких передовых технических решений мы от них не дождались, а единственная польза была в создании общего фреймворка. Работать с ними становилось все труднее, сроки выполнения оставляли желать лучшего. Было решено после внедрения в ПХП сократить процент участия подрядчика и большинство работ вести своими силами.
Тираж системы: другие цеха — другие сложности
Постепенно мы внедрили систему в ЛПЦ-1, потом в ЛПЦ-3 (это уже в Колпино) и далее по всем остальным производственным цехам Череповецкой и Колпинской площадок.
В сортопрокатном производстве мы столкнулись с новой проблемой. Там идет штучный учет достаточно мелкой продукции в пачках, что приводило к зависаниям системы, так как она не была готова обрабатывать тысячи записей по операциям за секунды. Но благодаря слаженной работе команда устранила все недостатки заранее, так что на стадии внедрения пользователи не почувствовали нашу боль.
При переходе к системам так называемого первого передела (коксоаглодоменное производство) столкнулись с ситуацией массового учета, а не штучного, под который была заточена наша MES-система. Системе намного проще идентифицировать рулон на складе, чем работать с массовым объёмом кокса, руды, известняка или агломерата. Взяли себя в руки (не впервой!) и внесли правки в архитектуру БД. На базе единого фреймворка разработали интерфейсы под первый передел и начали один за одним завоевывать производства сыпучих материалов. Да так успешно, что внедрили систему в Яковлевском ГОКе (Белгородская область).
Что получилось в итоге, как разросся код и немного размышлений про Delphi
Сейчас все цеха, и первого передела, и производственные работают в единой MES-системе. Но все же мы не получили того, чего хотели изначально — универсальный коробочный продукт, который при его внедрении в других цехах требует минимальных изменений в коде. Зато получили огромный опыт, упорядочили процесс разработки и все-таки получили единую на всех систему. Она вышла большая. Ниже на диаграмме можно проследить, как со временем разрастался код. Причин тому было несколько:
Были моменты, не учтенные на начальных этапах, не укладывающиеся в общие алгоритмы. В некоторых местах появлялось нагромождение условий под определённый цех или случай. Также мы постоянно наращивали функциональность, расширяли возможности системы, автоматизировали то, что раньше вводилось и контролировалось вручную, реализовывали специфичные для конкретного производства интерфейсы. Большой вклад в новый код вносила интеграция с другими системами. Здесь в разных системах и в разных цехах могло отличаться абсолютно всё. И, несмотря на попытки привести всё к единому формату обмена, каждая интеграция осталась уникальной.
Наша единая MES-система создавалась в течение восьми лет. За это время в IT-сфере многое поменялось. К сожалению, сейчас, внедрив систему во многих цехах «Северстали», мы получили ещё не старую, но уже не современную (хотя и вполне работоспособную) MES в архитектуре клиент-сервер.
Основная проблема в том, что в современном мире десктопные приложения и IDE для их создания стремительно сдают позиции, а студенты в своих институтах больше не изучают Pascal или Delphi. Теперь в тренде кроссплатформенность и такие языки, как Java, Python или C#. Если сегодня кто-то собирается реализовать свой проект в архитектуре клиент-сервер (которая по-прежнему неплоха, если речь идет о локальной системе), то он выберет не Delphi, а MS Visual Studio, а писать своего клиента будет на C# с использованием библиотеки Windows Forms. Порассуждаем о Delphi.
Современная MS Visual Studio показывает, как могла бы выглядеть Delphi, если бы ее хотели развивать. Тем более, что компонентную модель в MS VS делала та же команда, которая в свое время создала Delphi и его компилятор. Сейчас Delphi по большей части используется как IDE для поддержания старых, давно написанных систем, а новые проекты на Delphi не создаются. Со временем все труднее будет находить специалистов, которые хорошо знают Delphi и согласны работать на поддержке систем. Перспективные и бурно развивающиеся WEB-приложения на Python/Java/PHP/C# намного предпочтительнее старых приложений на Delphi в модели “клиент-сервер”.
Ситуация усугубляется тем, что нет никакого способа более-менее автоматической конвертации приложения для десктопа в WEB-приложение. Это совсем разные концепции, приложение придется полностью переписать — а это долго и дорого. Поэтому велика вероятность, что большие системы на Delphi еще долго будут работать. До тех пор, пока специалистов по Delphi еще можно будет найти, или пока системы окончательно не устареют. Это растянется не на один десяток лет, а затем клиенты на Delphi будут смотреться также, как раньше смотрелись клиенты на Oracle Forms — да, технология старая и специалистов по ней почти не осталось, но ведь работает!
Надеемся, вам было интересно узнать, что среди задач IT в «Северстали» есть и такие. И приглашаем подискутировать в комментарии о Delphi.
