Что можно и чего нельзя.
Стандартизация – основа автоматизации?
Доброго дня, уважаемое сообщество. Наша компания много лет занимается разными системами автоматизации, разработкой ПО, проектированием и внедрением систем. У инженеров руки чешутся автоматизировать все, на что глаз падает. В том числе и собственный труд. Можно ли автоматизировать процесс проектирования в эпоху «после САПР»? Что интересного можно предложить проектировщику, у которого есть NanoCAD, Компас, EPLAN или, не к ночи будь помянут, AutoCAD?
Занимаясь практической деятельностью, мы совершили такое количество ошибок при использовании разных инструментальных средств, что, балансируя между ленью и перфекционизмом, нашли точку приложения усилий.
В нашей среде есть поговорка: если вы можете объяснить, что вы делаете – мы сможем это автоматизировать! А еще у нас безусловная любовь к разным инструментам, ничем не слабее тяги к новым игрушкам.
Мы придумали классный инструмент для облегчения некоторых скучных операций проектирования систем автоматизации.
Количество систем автоматизации увеличивается, но за проектирование (особенно такого «вспомогательного» раздела как АСУД) Заказчик платит менее охотно, чем за оборудование, а квалифицированных инженеров сильно не хватает – напрашивается идея передать проектирование самых массовых решений машине. Так у инженеров родилась идея MasterCAD.
Учитывая опыт проектирования, в первую очередь хотелось автоматизировать самое нудное – заполнение штампов и титульных листов. Не мы первые, не мы последние. Многие начинали с этого. При росте числа спроектированных систем появились блоки, блоки с атрибутами, динамические блоки, шаблоны. Очень быстро мы поняли, что нам мало лишь автоматического заполнения, очень хочется переиспользовать однажды сделанное, но это упирается в сложность хранения и навигации по библиотекам. И здесь мы тоже не первые и не последние.
В больших проектных компаниях и институтах это решается специализированными инструментами. Но мы – небольшая компания (на тот момент) и проектирование – не основная наша деятельность. Зато мы знаем, что необходимо на практике на каждом объекте, например, в подсистеме вентиляции. И знаем, что такая подсистема есть практически везде. Вот с нее и начнем – амбициозно постановили.
На самом деле вентиляция – самая сложная из инженерных подсистем здания. Мы определили более 600 000 вариантов возможных конфигураций.
Под лозунгом «если можно описать – можно автоматизировать» мы придумали, как описать установку общеобменной вентиляции. Как инженеры, мы установили необходимые ограничения, выделили общие признаки и таким образом свели возможные варианты к 21 типу.
Самые существенные ограничения оказались количественные:
-
1 контроллер может обслуживать одну установку, если это ПВУ или ПУ
-
1 контроллер может обслуживать не более 5 установок ВУ
-
Мощность двигателя (вентилятора) может быть не более 15кВт.
В среде САПР нам удалось создать команду, которая по конфигурационному слову из 30 ноликов и единичек построила ФСА вентиляции.
После этого идея была признана реализуемой! Так родился backend.
Повторное использование наработок.
Любите ли вы регламенты так, как любим их мы? Готовы ли вы пунктуально выполнять придуманные регламенты?
У нас инженеры очень любят придумывать. Поэтому либо у них получаются нерегламентированные наименования папок, либо возникает новый прием в процедуре создания блока или упорядочения атрибутов. В итоге придуманная, стройная и понятная система расплывается. Опять не найдешь нужный образец шаблона проекта, неизвестно, кто и когда делал, и вообще, делал ли проект такой установки. Переиспользовать однажды сделанное, есть и внутренняя потребность (третье повторение – скучно) и коммерческая выгода (быстрее).
Это значит, что наработки надо хранить не в виде шаблонов и файлов, а в формализованном виде.
Так родилась база данных. На рисунке приведен фрагмент первой версии формализации используемых в процессе проектирования понятий.
Что делать SCADA инженеру в проектировании.
Сначала мы строили чертеж с помощью набора команд в среде AutoCAD, потом сделали плагин, но все это в инструменте проектировщика. Чтобы двигаться дальше – надо дать инженеру понятный ему интерфейс (в терминах технологического объекта). Для вентиляционной установки это вентиляторы, частотные преобразователи, фильтры, датчики, рекуперация, рециркуляция, нагреватели и охладители.
Для максимального удовольствия в процесс конфигурирования состава установки добавлены проверки. Самое очевидное – внешний вид окна конфигурирования зависит от типа установки. Вы не сможете выбрать рекуперацию для приточки, например.
Так родился frontend и необходимость разработки дизайна. Зато теперь получить ФСА может инженер-технолог, а система сама сделает все по ГОСТ.
Делаем спецификацию автоматизированной.
После ФСА логично было сформировать перечень сигналов. Ведь, по ГОСТ 34, мы должны формировать таблицу сигналов на схеме C1. Сегодня вы можете использовать формируемый документ В1 «Перечень сигналов», но мы продолжаем над ним работать.
Самое срочное, с чем мы сталкивались, когда выполняли функцию интегратора – настойчивое желание Заказчика сделать бюджетную оценку предполагаемых затрат до окончания проектирования и даже до принятия технических решений.
И опять не мы первые и не мы последние придумывали набор условий и опросников для хотя бы оценки масштаба стоимости. Мы встречали даже оценку затрат на автоматизацию от площади здания (сооружения). Наиболее часто встречается правило – некоторый процент от стоимости основного технологического оборудования – это затраты на его автоматизацию. Это слабо устраивает Заказчика и не очень устраивало нас. Поэтому спецификацию очень хочется получать как можно раньше.
В итоге оказалось, что сам факт наличия спецификации, особенно, если в нее встроены расчеты (например, количество необходимого числа модулей ввода/вывода) позволяет уменьшить необходимое число итераций при проектировании.
Для создания спецификации кроме состава установки (те самые рекуперация/рециркуляция), надо выбрать оборудование.
Можно ли эту часть описать? Как к этому процессу подходят обычно?
Чаще всего проектировщик имеет на входе собственный опыт (много раз проектировал такую подсистему на такой модели контроллера и проект лежит в такой-то папке). Поскольку любой Заказчик предпочитает работать с постоянным проектировщиком из-за гарантированного качества результата, кажется логичным просто рассчитать необходимое количество модулей ввода/вывода разных типов в зависимости от состава установки.
Этот процесс поддается описанию.
Но в условиях, когда такие пары (заказчик – проектировщик) не сложились, или привычное оборудование исчезло с рынка (устарело, попало под санкции) - проектировщик либо должен сам сделать выбор нового, либо получает набор конкретных моделей из вендор-листа Заказчика. Обращаем ваше внимание на то, что у проектировщика всегда есть некоторый ограниченный набор используемого им оборудования. Даже если он очень творческий человек и внутренне обожает поиск нового – время на разработку проекта и творческий поиск ограничено.
Мы также ограничили набор возможного к использованию оборудования, во-первых, потому что разрабатывали систему для себя и у нас тоже есть предпочтения. Причем они усиливаются тем, что каждую систему мы доводим до полноценной автоматизированной системы управления и диспетчеризации. У нас «на горизонте» всегда стоит цель: как будет работать система в целом под управлением MasterSCADA.
Вторая причина: процесс загрузки и актуализации каталогов оборудования должен быть автоматизирован. Двигаться сразу в нескольких направлениях не получается.
Сегодня в сервисе можно выбрать оборудование для шкафа автоматизации из ограниченного числа типов. При этом проверяется наличие такого оборудования в линейке. Например, соответствие Производитель – Серия – Диагональ для панели оператора. Обращаю внимание на то, что достаточно выбрать производителя и серию для, например, блоков питания – система подберет в спецификацию необходимые номиналы или выдаст сообщение, что в выбранной линейке нет блока питания с необходимыми под целевую задачу характеристиками.
Спецификация строится для каждого шкафа автоматизации установки и входит в состав документа «чертеж внешнего вида» (ВО). Мы собираем в один документ сводную спецификацию на все шкафы автоматизации, это позволит вам быстро отдать ее в оценку.
Другие чертежи.
Так интересен был факт, что оборудование подобрано и чертежи «рисуются сами собой», что следующим шагом стали чертежи внешнего вида шкафа.
Так родилась «не планируемая» функциональность.
Нам есть, куда идти.
Какие преимущества получили мы и теперь готовы делиться с вами:
-
Автоматизация некоторых рутинных операций;
-
Автоматизированное построение документов, схем и чертежей (В1, С3, ВО, С0);
-
Проверка условий при автоматизированном подборе оборудования;
-
Соблюдение ГОСТ 34;
-
Хранение и переиспользование формализованных данных;
-
Быстрое формирование и пересчет спецификаций.
Мы узнали, что можно сделать. Мы много сделали. Но пока не знаем, чего сделать нельзя. Каждый, даже маленький шаг, лишь генерирует новые возможности и позволяет строить новые планы.
Веселуха Галина Леонидовна – заместитель генерального
директора по инжинирингу ООО МПС софт.