Первые шаги в программирование

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

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

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

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

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

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

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

Проектирование - это процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части. Результатом проектирования является проект - целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы (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


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

Подробнее...

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


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

Подробнее...

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


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

Подробнее...

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


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

Подробнее...

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

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



Инфо-МАСТЕР ®
Все права защищены ©
e-mail: mail@info-master.su