Как составить проект автоматизации

Промышленная автоматизация — беремся за проектирование

Проектирование — это только поначалу страшно..

С чего начинается проект автоматизации и системы управления?

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

После тендера мы уже знаем сумму средств, которые выделены на наш фронт работ. Сами работы и их описание получаем в виде ТЗ. А что касается технологии — то в основном мы от заказчика получаем технологический рисунок плюс описание желаемых/предполагаемых алгоритмов работы тех процесса страниц так на 100-200. Многие вещи, что касаются сварочных работ, гидравлики или капитального строительства нас не касаются. Однако хорошо иметь на руках планы всех предполагаемых работ и примерные чертежи зданий, объектов и коммуникаций. Это необходимо как раз на стадии проектирования, для планирования прокладки кабельных трасс, размещения шкафов локального управления и т.д. Во многих случаях бывает оправдано сотрудничать с другими фирмами, чтобы, к примеру, совместно делать прокол под существующими дорогами или укладывать заземление после того, как закончен фундамент зданий, но ещё не начато строительство стен. Большинство трасс с сигнальными кабелями к датчикам давления, температуры, расхода воды, густоты и многим другим, идут вдоль основных технологических труб. Если в планах модернизации есть укладка новых трубопроводов, то мы стараемся договориться с генеральным исполнителем и уложить наши кабельные линии в существующие траншеи.

Так может выглядеть примерный план будущего объекта.

На нем проектным бюро предварительно расположены здания, кабельные трассы, трубопроводы и многое другое. Исходя из него уже можно понять примерную протяжённость кабельных линий, возможное расположение и количество шкафов управления. Также какие-то простые вещи, вроде уличного освещения или расположения/количества камер наружного наблюдения можно быстро разместить на нем же и отправить на согласование. Из этого же плана можно выделить объекты нуждающихся в заземлении по периметру. Здания административные и технологические изначально строятся с заземлением в фундаментах, а остальные объекты должны быть заземлены по периметру с обязательным выведением контрольно-измерительных участков с последующим подключением к общему заземляющему контуру. Ещё в нескольких местах необходимо предусмотреть выводы обычного заземления (мы используем, в основном полосу заземления FeZn 30×4) недалеко от основных трубопроводов. Так, как в последнее время они делаются исключительно из нержавеющей стали и нам нужно перейти с заземления оцинкованного, с помощью медного кабеля сечением 10-16мм², на заземление трубопровода. Для подключения заземления раньше вваривали болты М6 или М8, пока не купили специальный контактный сварочный аппарат, что за секунду «стреляет» шпильки М6-М8. Получается таких мест, где нужны выводы с резьбой для болтового соединения — довольно много. Каждое механическое соединение и ответвление труб должно быть заземлено последовательно. Исходя из стандартов механическое соединение (болтовое или на шпильках) не может быть признано электрическим, кроме редких случаев.

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

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

• В каких местах должны быть технологические измерения (давление, расход, pH, температура, уровень кислорода, плотности/вязкости и прочие)
• Где необходимо вести контрольный замер по нескольким параметрам.
• Где будут расположены исполняющие устройства, их количество и мощность.
• Можно понять тип устройств — в некоторых случаях достаточно управляемых задвижек или клапанов с принципом работы 1/0 — открыто/закрыто. Тогда, скорее всего, будут использоваться более простые устройства с управлением бинарными сигналами и с обратной связью по ним же — состояние, авария, конечные положения. Или же необходимо использовать устройства с плавной регулировкой положения и тогда управление и обратная связь должны уже идти по каким-то протоколам промышленной связи (profibus, modbus и т.д.).
• То же самое касается и двигателей насосов, компрессоров. Либо достаточно устройств плавного пуска, либо все же необходимо использовать частотные преобразователи

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

Самое простое с чего можно начать — это структурные схемы (упрощенные однолинейные принципиальные схемы) с посчитанными мощностями исполняющих устройств — будь то помпы, вентиляторы, компрессоры. К ним, исходя из номинальных значений токов и расстояний, подбираются соответствующие сечение кабелей. Если кабели будут иметь подземные участки, то сразу выбирается соответствующее исполнение, к примеру, в помещениях для маломощной однофазной нагрузки используются кабели типа YDY 3×2,5 (возможный аналог — ПВС), а устройства снаружи будут использоваться минимум YKY 3×2,5 (возможный аналог — ВВГ). Согласно параметрам исполняющих устройств подбираются дифференциальные автоматы (если необходимо).

Пример структурой схемы с указанием возможного типа кабеля и потребляемой мощности.

Указывается тип питания — однофазный или трехфазный и параметры автоматических выключателей. Указываем параметры УЗО – номинальный ток, количество фаз, ток утечки и тип самого аппарата. Как и комментарии в коде, здесь важно постараться описать всех потребителей. Это потом пригодится для составления протоколов измерений параметров электрической сети. Если есть такой «скелет» с типами кабелей и защитных аппаратов, мы сделали практически половину работы, что понадобится при контрольных измерениях и составлении протоколов. Не стоит забывать и о монтажниках, что впоследствии и будут изготавливать шкафы. Имея максимум информации на скелетной схеме – они легко могут подобрать количество и тип клемм (по сечению жил), быстро понять иерархию соединения между собой аппаратов защиты и найти названия потребителей. Скелетная схема может занимать 10-15 страниц. А полная проектная электрическая документация с внесенными всеми зависимостями – может содержать 200-300 страниц.

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

Здесь самый простой электрический шкаф и потому расположение элементов имеет мало значения. В шкафах же управления придётся учитывать множество факторов — тот же температурный режим, особенно, если будут расположены блоки питания 230/24В, частотные преобразователи, контроллеры, панели к ним – тогда необходимо предусмотреть вентиляционные решетки, принудительную вентиляцию включать через термостат. Или же учитывать электромагнитное излучение — от тех же частотных преобразователей. Необходимо заранее предусмотреть место на крепление экранов силовых кабелей от двигателей.

Структурная схема части объекта — очень условная, так как здесь только питающие цепи.

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

Структурная схема коммуникации. Разные цвета — разные протоколы

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

Отдельно пару слов об иерархии контроллеров. Если система очень сложная, имеет множество технологических объектов с обилием аналоговых измерений и устройств, с которыми нужно «общаться» или управлять, то мы разбиваем её на несколько шкафов управления. Один из шкафов условно назначаем главным. В нем будет главный контроллер. Он обслуживает свою часть техпроцесса и отвечает за коммуникацию со SCADA. Остальные контроллеры независимы и выполняют свой объем локальных задач, синхронизируя с главным контроллером только некоторые переменные. Те же панели управления HMI — всегда slave. Будут ли они работать или нет — не влияет на работу контроллеров и как следствие — техпроцесса. Панели управления, расположены на дверях шкафов управления и служат исключительно для локального мониторинга или проверки работы оборудования сервисными службами. Наши же программисты оставляют себе backdoor в виде GSM модемов с туннелем в шкафах с контролерами. И тогда к контроллеру в аварийной ситуации можно подключиться удалённо, даже если все панели и компьютер со SCADA выйдет из строя.

Структурная схема компьютерных сетей, к ним относятся и сети к камерам наблюдения, особенно после того, как они все стали использовать протокол POE

Дело в том, что многие предварительные документы на постройку каких-то объектов могут лежать годами. Порой они долго ждут финансирования и успевают устареть. К примеру, часто встречается требование укладки отдельных кабелей питания к камерам. Что-то, вроде кабеля 3х1,5. Плюс витая пара 5 или 6 категории к каждой камере. Если на этапе согласования не удается избавиться от таких «ляпов», то они остаются физически. То есть эти кабеля укладываются, хоть никогда и ни к чему не подключаются. А само подключение и питание камер идет по POE

После скелета проекта и этапов согласования начинается проектирование полноценной документации. Об этом и нюансах проектирования – в следующей части

Вместо вывода:

Начиная с нуля, довольно трудно спроектировать автоматизацию какого-то крупного объекта. Однако все начинали с чего-то небольшого. И пусть это был шутливый проект по охране цветка от кота с помощью Arduino или самодельная ambilight подсветка по документации от Lightpack, это было всего лишь начало. В любом из проектов накапливается опыт. Берутся все более крупные заказы. Да, мы живем в неидеальном мире и постоянно приходится оглядываться на себестоимость проектирования, изготовления, запуска и гарантии. Всегда есть рамки, в которые надо поместиться, будь то время или средства. Но в конце концов, не ошибается только тот, кто ничего не делает. Много интересных вещей мы видели на Хабре, многому научились. Может кому-нибудь поможет наш опыт в области промышленной электроники. Задавайте вопросы в комментариях, делитесь своим опытом, будет интересное узнать другое мнение.

p/s предыдущий пост, начало этой темы Автоматизация и промышленная электроника – когда одним Arduino сыт не будешь

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

В очередной раз, размышляя над тем, что же можно/нужно сделать лучше, я углубился в тему подготовки описания проекта (устава проекта). Документ важный с разных сторон, т.к. на основании Устава проекта одни участники формируют свои ожидания от проекта, а другие определяют для себя приоритеты в работах.

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

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

---

Правильно формулируйте цель

(как бы банально это не звучало)

---

// Есть очень хорошая цитата на эту тему — «Скорость важнее силы, но точность важнее скорости».

Какое правило описания цели сформулировал для себя я:

• во-первых, нужно определить проблему/задачу, которую мы хотим решить (как правило если нет проблемы, то нет смысла что-то изменять)
• во-вторых, нужно понять ожидаемый эффект от решения проблемы и оценить – насколько он значителен, чтобы затевать перемены

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

Причем целесообразно разложить цель на более локальные задачи. Приведу пример:

1. Выделяем проблему: низкий уровень клиентского сервиса при исполнении заказов покупателей (92%)
2. Формулируем ожидаемый эффект: повышение уровня клиентского сервиса до 96%
3. Определяем возможные варианты решения проблемы, выбираем наиболее актуальный и формулируем на его основании цель.

В данном примере у нас может быть как минимум 2 варианта решения проблемы:

• увеличение складских остатков готовой продукции для повышения вероятности обеспеченности принимаемых заказов готовой продукцией
• развитие системы прогнозирования принимаемых заказов для формирования заявки на производство под ожидаемые заказы

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

Выбираем второй вариант, и тогда наша цель будет выглядеть таким образом:

«Оптимизация и автоматизация алгоритмов формирования заявки на производство на основании прогнозирования спроса»

       4. Чтобы цель была более ясной, выделим в ней задачи (крупные «камни», определяющие результат):

• Организация учета в ИТ-системе проводимых трейд маркетинговых мероприятий (плановые и фактические приросты объёмов продаж)
• Автоматизация алгоритма прогнозирования отгрузок на основании истории, сезонности, влияния акций и динамики развития
• Формирование заявки на производство на основании остатков и прогноза отгрузок
• Проверка ограничений по рабочим центрам (по узким горлышкам)

---

Договаривайтесь о правилах игры

---

После определения целей проекта нам необходимо составить план работ. Однако для этого нужно договориться – какие правила организации работ будет соблюдать проектная команда.

Одно из самых понятных противоречий, которые возникают при этом, — это процент времени, выделяемый участниками на проект. Зачастую функциональные заказчики, участвующие в проекте, не освобождаются от своей текущей работы (т.е. для них проект- это факультативная задача). Соответственно, если загрузка до проекта у них уже была 120% (а это нередкость, цифра может быть и выше), то назначение их на проект приведёт к растягиванию сроков работ до бесконечности.

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

---

Формализуйте критерии завершённости

---

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

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

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

«В ИТ-системе создано не менее 3-х трейд-маркетинговых мероприятий, по ним рассчитана плановая эффективность акции на основании определенных аналитиком плановых приростов.

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

План-фактный анализ эффективности акций сформирован в ИТ-системе автоматически».

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

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

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

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

Соседние файлы в папке Лекции

• #
• #
• #
• #
• #
• #

  22.02.2016464.38 Кб9402.2 Методика разработки алгоритма управления.ppt

• #

Проектирование АСУ ТП

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

Основные темы раздела будут такими:

• Проектирование. Способы проектирования систем автоматизации.
• Документация. ГОСТы. Руководства. Законодательство.
• Средства разработки. SCADA. CAD-системы. Средства разработки ПО ПЛК и т.п.
• Программирование. Особенности программирования приборов АСУ.
• Примеры проектов. Здесь будем рассматривать примеры учебных и действующих проектов.

Но по мере своих скромных сил я буду расширять этот список. А теперь немного подробнее об основных принципах разработки АСУ.

Чем проектирование отличается от разработки

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

Проектирование – это процесс определения архитектуры, компонентов, интерфейсов и
других характеристик системы или её части. Результатом проектирования является проект – целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы (ISO 24765).

Разработка – это процесс проектирования и создания изделия (системы). Результатом разработки является изделие (система).

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

А разрабатывая АСУ, мы выдаём заказчику готовую систему “под ключ”.

Таким образом проектирование – это лишь часть (этап) разработки. Поэтому, если будете когда-нибудь работать с юридически подкованным заказчиком, то ни в коем случае не пишите в договоре “я обязуюсь разработать АСУ”, если вы не собираетесь выполнять её монтаж и пуско-наладку.

Этапы проектирования АСУ

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

• Получение технических условий (требуется не всегда).
• Обследование объекта и предварительное формирование требований к АСУ.
• Проведение научно-исследовательских работ (очень редко, в большинстве случаев не выполняется).
• Разработка технического задания (ТЗ). В случае, когда выполняются только проектные работы, это может называться заданием на проектирование.
• Эскизный проект. Это некие наброски будущей АСУ: архитектура, структура, предварительный выбор
  ТСА. Предварительное определение списка документов проекта.
• Технический проект (техническая документация). Проектные решения по АСУ и/или её частям.
• Рабочий проект (рабочая документация). Сюда же входит разработка программного обеспечения и его отладка.

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

• Ввод в эксплуатацию (в действие, в работу). Пуско-наладка, обучение персонала, испытания, пробная эксплуатация…
• Сопровождение. Выполнение работ по гарантийным обязательствам.

Это, так сказать, список шагов по разработке АСУ, приближённый к ГОСТовскому. Но у меня по итогам моей практической деятельности сложился свой список шагов. Он похож на этот, но всё-же немного отличается. И я об этом обязательно расскажу, но в другой раз. Так что подписывайтесь на новости, чтобы ничего не пропустить (кнопка вверху страницы справа).

Программирование АСУ

В отличие от НЕ автоматизированных инженерных систем, разработка современных АСУ ТП практически всегда включает в себя программирование.

Виды программирования я бы разделил так:

• Программирование приборов. Это даже не столько программирование, сколько конфигурирование (настройка). Обычно вы просто устанавливаете какие-то параметры, например, для таймеров, терморегуляторов, частотных преобразователей и т.п.
• Программирование панелей оператора, программируемых реле. В большинстве случаев это тоже не программирование, а конфигурирование. Хотя некоторые панели оператора позволяют писать макросы на каком-либо языке программирования. Если панель позволяет создавать полноценные программы, то это уже не панель, а панельный ПЛК (программируемый логический контроллер).
• Программирование ПЛК. Вот это уже настоящее программирование, хотя и специфическое. ПЛК – это основа современной АСУ. Соответственно, большая часть времени программиста будет потрачена на разработку ПО ПЛК.
• Программирование SCADA-систем. Это тоже программирование. Точнее, SCADA-системы позволяют писать программы на
  каком-либо языке программирования (обычно на простом, таком как Паскаль или VBScript). Однако в простых случаях это может и не понадобиться, потому что можно будет обойтись конфигурированием. SCADA-системы – это отдельная большая тема, которой я буду посвящать отдельные статьи.

Сколько времени занимает проектирование

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

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

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

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

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

Ниже приведу некоторые цифры, основанные на моём опыте. Быть может, кому-то это поможет оценить трудозатраты.

• Обследование объекта. Обычно занимает 1-2 рабочих дня (с учётом поездок в пределах города и близлежащих населённых пунктов).
• Разработка ТЗ – примерно 1…2 страницы в час. ТЗ для системы средней сложности обычно содержит 20…30 страниц.
• Эскизный проект. Обычно 1…2 рабочих дня, если не углубляться в подробности (в эскизном проекте этого и не надо).
• Технический и рабочий проект:
• Чертёж формата А4 – примерно 1 час
• А3 – 1,5…2 часа
• А2 – 3..4 часа
• А1 – 7…8 часов
• А0 – 12…16 часов
• Расчётно-пояснительная записка (РПЗ) – 1…3 страницы в час. РПЗ для проекта средней сложности обычно 30…50 страниц. Ну и не все это делают, надо сказать.
• Разработка ПО. Здесь определить трудозатраты практически невозможно. Потому что это очень индивидуально и зависит от требований заказчика и от вашего опыта (или опыта вашего программиста). Поэтому здесь надо всегда брать время с запасом. Например, если вы предполагаете, что разработка ПО ПЛК займёт 40 часов, то в себестоимость надо включать не менее 60 часов, а лучше 80. То есть вашу предварительную оценку надо умножить на 1,5…2, тогда получите что-то более-менее близкое к действительности.

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

Средства разработки АСУ ТП

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

• CAD-системы,
  такие как КОМПАС или
  AutoCAD. Эти системы применяются для разработки схем, чертежей, 3D-моделей и т.п.
• Средства разработки ПО ПЛК. Например, CoDeSys. С помощью этих средств разрабатываются и отлаживаются программы для ПЛК. Загрузка программ в ПЛК выполняется этими же средствами.
• SCADA-системы. С помощью этих систем создаются программы для компьютеров. Эти программы необходимы для взаимодействия с оператором, для хранения данных АСУ, для формирования отчётов и т.п.
• Конфигураторы. Используются для настроек разных приборов, таких как терморегуляторы, панели оператора, преобразователи интерфейсов, программируемые реле и т.п.
• Программы для расчётов и составления смет. Здесь есть куча всяких маленьких и больших программ,
  которые помогают делать инженерные расчёты, составлять сметы и т.п. Примеры: Гранд-СМЕТА, разные калькуляторы.
• Математические программы и симуляторы. Это используется реже, в основном для каких-то достаточно узких направлений. Но всё же иногда может быть полезно. Примеры: MathCAD, Maple, Multisim.
• Средства разработки ПО для микроконтроллеров и Ардуино. Вообще на микроконтроллерах АСУ не делают. Но есть любители, которые этим занимаются. Во всяком случае на просторах Интернета вы можете найти их проекты. Иногда довольно сложные.

Как видите, практически все средства разработки – это программы. В цифровой век живём, товарищи…

Особенности проектирования АСУ ТП

Ну в общем-то в каждом инженерном направлении есть свои особенности. Есть они и в проектировании систем автоматизации. Я бы назвал следующие:

• Довольно сложный выбор из огромного разнообразия датчиков, приборов, ПЛК и другого оборудования. Здесь надо много чего знать и иметь практический опыт использования. Иначе можно просто приобрести, например, датчики, которые не будут работать в ваших условиях.
• Множество средств разработки, каждое из которых надо изучить и знать в совершенстве, чтобы снизить трудозатраты на проектирование.
• Сложности общения с заказчиками, которые в большинстве случаев просто не знают, чего хотят, потому что, например, в строительстве почти все заказчики хоть как-то разбираются, а в автоматике – вообще никто.
• Много программирования на разных уровнях и в разных направлениях. Требуются соответствующие специалисты, которых на рынке труда большой дефицит.

Документация для разработчиков АСУ

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

1. Документы, которыми руководствуются при проектировании. Это ГОСТы, Правила, законы, технические условия, руководства и т.п.
2. Документы, которые создаются при проектировании. Ну а это уже непосредственно проектная и рабочая документация, которая появляется в ходе выполнения проектных работ. Если кратко, то всё, что было рассмотрено ранее, надо описать и задокументировать.

Но если говорить именно о документации ДЛЯ разработчиков, то это, конечно, документы из первой части.

Например, если вы разрабатываете электрические схемы для систем автоматизации, то вы должны “как отче наш” знать
ПУЭ (Правила Устройства Электроустановок).

Если вы создаёте АСУ для взрывоопасного объекта, то вы обязаны знать соответствующие ГОСТы и законодательство, определяющее правила проектирования для таких объектов.

Ну и так далее. Как видите, жизнь простого инженера-автоматизатора не легка…

Стоимость проектирования систем автоматизации

Лично для меня это самый больной вопрос (как и в случае с трудозатратами – это связанные вопросы). Потому что, в отличие от других вопросов, он почти неразрешим.

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

Но кроме трудозатрат есть ещё и стоимость инструмента, оборудования и материалов. И здесь тоже немало подводных камней. Особенно в нашей стране, где в течение года стройматериалы могут подорожать в три раза, а электрические кабели и провода – в 2…2,5.

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

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

Конечно, в крупных проектных компаниях этим занимаются экономисты. Но, как правило, и они ничего толком не могут рассчитать с нужной точностью.

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

Я упорно пытал экономистов, но конкретного ответа так и не получил. Точнее, получил такой ответ: все расчеты очень приблизительны. То есть по сути цифры берутся “с потолка”.

Но если всё-таки попытаться определить себестоимость, то, в первую очередь, конечно, надо исходить из трудозатрат. По крайней мере для меня, как для фрилансера, время – это единственная точка отсчёта.

И я стараюсь договариваться с заказчиками на почасовую оплату. Это, кстати, более выгодно и для заказчика. И те, кто это понимает, соглашаются.

Ну а те, кто не понимает, переплачивают. Потому что в таком случае я не могу заранее с нужной точностью сказать, сколько времени потребует разработка. Поэтому, например, если предварительно я оцениваю трудозатраты 50 часов, то я закладываю 100. На всякий случай. И, как правило, реальность получается где-то посередине. То есть 70…80 часов (с учётом мелких доработок и исправления ошибок).

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

Советы начинающим проектировщикам

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

1. Не бойтесь делать. Это главное. “Глаза боятся, а руки делают” – народная мудрость. Или “не боги горшки обжигают”. Да, это сложно. Но разобраться можно во всём. Невыполнимых задач не существует.
2. Не бойтесь ошибаться. Вроде бы это входит в первый пункт, но на самом деле нет. Это всё-таки другое. Многие боятся совершить ошибку, “облажаться”. Напрасно. Открою вам тайну – ошибаются все. Даже самые матёрые профессионалы. Иначе бы самолёты не падали. И так уж человек устроен, что лучше всего он учится именно НА СВОИХ ошибках.
3. Не бойтесь показаться глупым. Не бойтесь спрашивать. Отбросьте все комплексы – все мы когда-то пИсали в штаны. И если вас кто-то гнобит за ваши незнания, не обращайте внимания. Так поступают только люди с комплексами неполноценности – им надо самоутверждаться за счёт других. Настоящий же мастер всегда поможет разобраться со сложным вопросом, потому что он помнит, что когда-то и он был таким.
4. Изучайте законы, ПУЭ, ГОСТы и другие официальные документы, касающиеся вашей отрасли.
5. Изучайте средства разработки – это поможет вам повысить эффективность использования рабочего времени (снизить трудозатраты). Особенно это вам пригодится, если вы будете фрилансером. Потому что вы сможете делать больше за то же время, что позволит вам больше зарабатывать и получать больше клиентов.
6. Как можно больше практики на этапе входа в профессию. Делайте любые проекты. Даже если вам за это не платят или платят мало. Платить хорошо будут, когда вы наберётесь опыта. Но этого опыта вы никогда не наберётесь, если будете отказываться от работы.

Что вас ждёт дальше на пути проектировщика АСУ ТП

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

Не талант. Не связи. Не образование. А именно настойчивость.

Почему простой деревенский мужик Ломоносов стал всемирно известным учёным? Ведь у него не было ничего: ни связей, ни денег, ни образования. Талант, возможно, был. Но он так и остался бы в глухой деревне, если бы Ломоносов не был НАСТОЙЧИВЫМ и не пошёл бы пешком в столицу.

Путь автоматизатора также сложен и долог. Поэтому настойчивость – это то, что поможет вам достичь успеха на этом пути.

И можете считать это ещё одним – главным советом начинающему проектировщику – будьте настойчивы, не сдавайтесь.

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

Что почитать о проектировании АСУ ТП

Справочник инженера по АСУТП: Проектирование и разработка. Том 1

---

Несмотря на то, что книга называется “Справочник”, в ней довольно много и достаточно подробно описаны основные определения и требования, выполнение которых желательно (а иногда и обязательно) учитывать при проектировании АСУТП. В книге рассматривается состав и пошаговое распределение работ по созданию АСУТП, устанавливается состав и содержание проектной документации. В общем, серьёзное учебное пособие, которое будет полезно не только начинающим. 449 страниц, год издания 2016. Подробнее…

Справочник инженера по АСУТП: Проектирование и разработка. Том 2

---

Второй том рассмотренного выше двухтомника. Продолжает рассказывать о проектировании АСУТП. Достоинством книги является её практическая направленность. Описаны процедуры выполнения работ по проектированию и разработке АСУТП, даны советы по учету особенностей проектирования систем защиты технологических процессов, что поможет всем, кто связан с этими задачами – от разработчиков систем, до руководителей предприятий. Представленная в книге методология создания АСУТП является шагом к разработке современных отечественных стандартов промышленной автоматизации, согласованных с международным опытом. 485 страниц, год издания 2016. Подробнее…

Порядок создания, модернизации и сопровождения АСУТП

---

Книга от того же автора, что и предыдущая. Но более старое издание и несколько о другом. В книге рассказывается о способах проектирования и разработки систем управления и защиты на основе достижений отечественной прикладной школы, и, в то же время, согласованных с положительным международным опытом. Представлен полный текст Стандарта предприятия на порядок создания, модернизации, внедрения и сопровождения АСУТП, разработанного автором книги. 569 страниц, 2011 год. Подробнее…

Библия электрика: ПУЭ, ПОТЭЭ, ПТЭЭП

---

Некоторые автоматчики с пренебрежениям относятся к электрике. Совершенно напрасно. Потому что при проектировании АСУТП мы никак не сможем обойтись без знаний требований Правил Устройства Электроустановок и прочих электрических заморочек. Поэтому эту книгу должен иметь каждый разработчик, который создаёт системы, хоть как-то связанные с электрикой: АСУ, видео, сигнализация, связь и т.п. Подробнее…

Я не прощаюсь…

Статья получилась достаточно большой. Но я не сказал даже сотой части того, чего мог бы сказать. Поэтому данный раздел будет постоянно обновляться. И по всем подразделам мы будем продвигаться углублённо. Так что “не переключайтесь”. Подписывайтесь на новости и ждите новых статей…