Автоматические системы управления специальность что это
Профессия Инженер АСУ ТП в России
Аббревиатура АСУ ТП означает «автоматизированная система управления технологическим процессом» — это система, состоящая из персонала и совокупности оборудования с программным обеспечением, использующихся для автоматизации функций этого самого персонала по управлению промышленными объектами: электростанциями, котельными, насосными, водоочистными сооружениями, пищевыми, химическими, металлургическими заводами, нефтегазовыми объектами и т.д. Инженер занимается настройкой и конфигурированием программного обеспечения входящих в АСУ ТП технических комплексов под определенные направления автоматизации, выполняет пусконаладку систем АСУ ТП, разрабатывает схемотехнические решения и подбирает необходимое оборудование.
О профессии Инженера АСУ ТП
Зарплаты: сколько получает Инженер АСУ ТП *
Начинающий: 20000 в месяц
Опытный: 40000 в месяц
Профессионал: 56000 в месяц
Востребованность профессии
Рынок труда нуждается в квалифицированных инженерах. У специалиста не возникнет сложностей с трудоустройством.
Для кого подходит профессия
Профессия, связанная с техникой и механизмами, требует крайне ответственного отношения к труду. Здесь важна высокая точность выполнения всех действий. Ответственность, стрессоустойчивость и внимательность специалиста помогут ему не допустить ошибок в работе.
Карьера
Инженер по автоматизации систем управления технологическим процессом имеет три категории, которые определяются наличием высшего образования и стажем работы. Квалифицированный специалист с опытом всегда будет востребован на рынке труда. Начав с рядового инженера, может дорасти до руководителя отдела или предприятия.
Обязанности
Чтобы улучшить качество продукции, сделать труд рабочих на производстве безопасным и высокопроизводительным, необходимо автоматизировать системы управления технологическим процессом. Инженер осуществляет следующие действия:
Изучает спектр необходимых работ и проводит исследования.
Составляет планы автоматизации и механизации производственных процессов, подъёмно-транспортных, погрузочно-разгрузочных и складских операций.
Получает на рассмотрение эскизы и технические проекты, чертежи.
Участвует в монтажных работах, наладке и сдаче в эксплуатацию средств автоматизации и механизации.
Контролирует их обслуживание и следит, чтобы работа соответствовала критериям надёжности и качества.
Результаты проделанной работы инженер описывает в отчёте.
Автоматические системы управления специальность что это
Инженер-программист АСУ ТП: чем занимается и что нужно знать
Главный эксперт по автоматизации производства,
Когда употребляют аббревиатуру АСУ ТП, под технологическим процессом очень часто подразумевают такие сложные процессы, как нефте- и газопереработку, электрические станции, переработку полезных ископаемых. Приходят также на ум предприятия химической и пищевой промышленности. Для автоматизации такого сорта процессов используются сложные распределенные системы управления. Как бы ни назывались эти системы и какие бы вендоры их ни производили, их надо сконфигурировать в единую АСУ ТП.
Программист обычно всегда участвует в этом процессе. Естественно, в этот процесс входит установка программного обеспечения на соответствующие компьютеры и проверка его функционирования. Здесь не требуется знаний программирования как такового, но требуется понимание архитектуры АСУ ТП. В программе нашего курса есть соответствующие блоки, которые расширят ваше понимание и позволят чувствовать себя более комфортно в этом процессе.
Чтобы АСУ ТП выполняло свои функции в соответствие с ТЗ и требованиями к системам, нужно прикладное ПО. Написание ПО и является основной задачей программиста. Даже в достаточно сложных техпроцессах есть две составляющие, которые практически есть везде и которые составляют большую часть прикладного ПО.
Первая – это логика функционирования процесса, включающая в себя последовательность старта и останова, различного рода блокировки, поведение при аварийных ситуациях, а также различные режимы работы, например, автоматический и дистанционный. Вторая составляющая ориентирована на регулирование параметров техпроцесса, таких как давление, температура, расход компонентов и т. п. Как правило, большинство вычислений производится в ПЛК (программируемые логические контроллеры), и их программирование регулируется стандартом МЭК 61131-3, включающим 5 языков программирования: LD, FBD, SFC, ST, IL:
LD — Язык релейных схем
FBD — Язык функциональных блоков
SFC — Язык диаграмм состояний
ST — Паскале-подобный язык
Как видно даже из этого краткого описания, LD и SFC очень подходят для программирования логики процессов, а FBD – для функций регулирования. Эти языки графические, и первые два из них очень интуитивные и в почёте у людей, не имеющих большого опыта в программировании. IL, как и следовало ожидать, очень эффективен и поэтому хорош для быстрых процессов. Однако программисты должны обладать определенным опытом для его эффективного использования – язык низкого уровня всегда такой.
В современных системах управления технологическими процессами всё большую роль играют SCADA. Она не просто выполняет роль человеко-машинного интерфейса HMI, а также хранения и переработки данных, но и множество других функций. Мы не будем подробно освещать функционал SCADA, это отдельная тема. Нам важно, что здесь программисту есть где разгуляться. Помимо конфигурации и стыковки с ПЛК, возможно выполнение различных сложных функций управления и контроля. Для комфортной работы желательно хотя бы базовые знания VBA, C, C++, MS SQL Server, MS Access. Такие популярные SCADA как InTouch и Citect имеют свои языки/скрипты, позволяющие реализовать сложный функционал.
» data-img-src=»https://fs-thb02.getcourse.ru/fileservice/file/thumbnail/h/6568965974facbade679a3c4addb35d1.jpg/s/s1200x/a/163679/sc/304″ > 
Пример SCADA
Промышленное программирование, или Пара слов об АСУ ТП
Есть такая профессия — производство автоматизировать. Аббревиатура АСУ ТП означает «автоматизированная система управления технологическим процессом» — это система, состоящая из персонала и совокупности оборудования с программным обеспечением, использующихся для автоматизации функций этого самого персонала по управлению промышленными объектами: электростанциями, котельными, насосными, водоочистными сооружениями, пищевыми, химическими, металлургическими заводами, нефтегазовыми объектами и т.д. и т.п.
Фактически, каждый человек, живущий не в лесу и пользующийся благами цивилизации, использует результаты труда предприятий, на которых функционируют АСУ ТП.
Иногда на эту тему проскакивают статьи и на хабре. Обычно они не пользуются особой популярностью, но всё же я хочу написать несколько обзорных статей об АСУ ТП в надежде рассказать хабравчанам что-то интересное (а возможно, кому-то даже полезное) и привлечь на хабр больше своих коллег.
Сначала пара слов о себе. Я только начинаю свой жизненный путь в автоматизации, опыт работы без малого два года. За это время побывал на нескольких газовых месторождениях, сейчас работаю на нефтяном.
Поскольку область обширная, несмотря ни на что развивающаяся, местами противоречивая и спорная, буду стараться обобщать не в ущерб достоверности, но не могу избежать перекоса в свою область — то оборудование, софт и сферу, с которыми лично я сталкивался.
Итак, программно-технический комплекс АСУ ТП делится на три уровня: верхний (компьютеры), средний (контроллеры), нижний (полевое оборудование, датчики, исполнительные механизмы). Про нижний уровень рассказывать не буду — слишком уж это далеко от от тематики хабра, да и статья получится слишком большая.
Верхний уровень
Верхний уровень — это серверы и пользовательские ПК (у нас они называются АРМ — автоматизированное рабочее место). Сюда выводится состояние технологического процесса, и отсюда при необходимости оператором подаются команды на изменение его параметров. Для упрощения разработки создано большое количество SCADA-систем (от англ. supervisory control and data acquisition — диспетчерское управление и сбор данных). Это в некотором роде расширенный аналог IDE, в котором скомпилированная «программа» и выполняется.
Системы SCADA
Вообще, если отбросить академизм, то на предприятии для всех кроме асушников скада выглядит вот так: 
А если совсем не повезёт, то вот так: 
Подразумеваются два режима функционирования: режим разработки и режим выполнения (runtime). Не обязательно эти режимы взаимоисключающи: можно редактировать проект на одном АРМе, инженерном, заливать его, он обновится на пользовательских. Это очень важно — изменять проект без простоев и отключений, потому что технологический процесс прерывать нельзя, и операторы всегда должны иметь возможность его контролировать. В скаде создаются графические интерфейсы, настраиваются источники данных с полевых устройств, она отвечает за взаимодействие пользователя (оператора, диспетчера, технолога) с происходящим на производстве, а также за архивирование всех нужных данных в БД.
Архивирование — одна из обязательных функций, очень важно иметь возможность «вернуться назад во времени» для разбора полётов в случае чего-то непредвиденного либо для глобального анализа при медленных, длительных процессах. Например, недавно геологи попросили меня выгрузить табличкой данные по давлению нефти на скважинах за последний год.
Периодически скада складывает все собранные данные в БД. Их потом можно посмотреть в виде графиков (называем их трендами), а при необходимости, если оговорено в ТЗ на АСУТП, реализуется выгрузка в виде отчётов в эксель или ещё как-нибудь. Архивация сделана по-разному: в MS SQL; MS Access; в ту же MS SQL, но по своему хитрому алгоритму с дополнительной архивацией; а у кого-то вообще в свою собственную бинарную БД.
Особым пунктом в скадах идёт информирование оператора: текущие сообщения и аварийные. Они тоже обязательно архивируются. В общем виде сообщения делятся на текущие и важные (аварийные). Текущие прячут подальше, но журнал аварийных всегда выводится на экране оператора. К текстовым аварийным сообщениям привязываются звуковые, чтобы кто-нибудь не проспал ЧП 🙂
Рынок SCADA
Самыми распространёнными, по-моему, считаются скады производства Invensys Wonderware, Iconics, Siemens, Indusoft, AdAstra, Emerson, Rockwell Automation.
Я лично работал с виндовыми: Invensys Wonderware InTouch и более мощной System Platform, с Iconics Genesis32 — и с (пока ещё?) малоизвестной B&R APROL под SLES (формально, это не совсем скада, а покруче — из-под апрола программируются и сами контроллеры).
По поисковым запросам, например, SCADA, HMI можно посмотреть примеры интерфейсов и мнемосхем.
Внешний вид и юзабилити по приоритету, увы, находятся на последнем месте. Причём, это касается не только рантайма, но и разработки. Для разработки в каждой скаде существуют как минимум дефолтные библиотеки символов — от кнопок и прочих контролов до графических изображений насосов, труб, задвижек, ёмкостей. Здесь-то и могли бы умные разработчики SCADA-пакетов (не путать с нами, асушниками — разработчиками проектов в этих пакетах) добиться принципиального преимущества над конкурентами, сделав продуманные библиотеки, из которых бы даже самый далёкий от дизайна и юзабилити инженер при всём нежелании делал бы гуманные интерфейсы и мнемосхемы. К сожалению, сейчас эта сфера идёт по пути экстенсивного развития, по которому развивалась IT до недавнего времени — наращивание функционала, добавление плюшек, больше, выше, сильнее, harder, better, stronger, и о пользователях пока думают мало.
Средний уровень
Средний уровень — ПЛК, программируемые логические контроллеры. Здесь всё достаточно просто, чаще всего физически ПЛК состоят из отдельных модулей. Для программирования у каждого ПЛК есть своя среда разработки, иногда она объединена со средой для создания SCADA.
Состав ПЛК
Контроллер B&R серии X20
Зачем нужен блок питания — понятно. БП сделан отдельным именно модулем, а не устройством, чтобы гарантировать совместимость с данной линейкой ПЛК. Чаще всего входное напряжение у БП 220 В переменного тока, выходное — 24 В постоянного тока.
Процессорный модуль — это голова ПЛК. Внутри у него, само собой, ЦПУ, ОЗУ и ПЗУ, сервисный порт для прошивки и, возможно, коммуникационный порт (ethernet, RS232/422/485, Profibus, etc). Иногда коммуникационный порт используется и как сервисный. Иногда на модуле есть переключатель (у Allen Bradley ещё круче — там натуральный ключ с замочной скважиной) для перевода ПЛК в различные режимы работы. Отдельной кнопки включения/выключения нет, в лучшем случае — тот переключатель, иначе, если есть питание — ПЛК запускается, а выключается и перезагружается «по-варварски» отключением питания.
Контроллер Allen Bradley серии CompactLogix
Дискретные и аналоговые модули обрабатывают соответствующие сигналы. Входные модули принимают эти сигналы с поля, выходные — формируют их.
Дискретный сигнал — это обычно напряжение цепи 24 вольта. Есть 24 — это «1», нет — «0». Бывают модули на 220В, есть модули с проверкой целостности цепи. Дискретные сигналы, приходящие с поля, могут информировать, например, о состоянии насоса включен/выключен. Управляющие дискретные сигналы могут запускать либо останавливать этот насос. Оптимизация здесь не оправдана, поэтому на запуск будет отдельная цепь, на останов — отдельная.
Модули I/O одного типа могут быть объединены: например, один модуль с 16 дискретными входами и 16 дискретными выходами.
Аналоговые входные сигналы — это приходят показания с датчиков. Здесь чаще всего используется токовая петля 4-20 мА, в соотетствие которой ставятся пределы измерения датчика. Начинается от 4 мА для диагностирования обрыва цепи (если меньше 4 мА, значит где-то что-то не в порядке с проводкой).
Рассмотрим на примере уровня жидкости в резервуаре. Стоит уровнемер, он измеряет уровень от 0 до 2 метров. Тогда: уровень 0 метров — это 4 мА, уровень 2 метра — это 20 мА. Промежуточные значения калибруются по ситуации, не всегда 1 метр соответствует 4+(20-4)/2=12 мА, может быть небольшая погрешность, уровень в 1 метр может быть какие-нибудь 12,7553 мА.
Аналоговые выходные — то же, только на управление. Не встречал чтобы использовалось, т.к. всегда существуют наводки. В измерении это допустимая погрешность, в управлении — нет. Да и неудобно это. Вместо них используется цифровая передача данных по различным протоколам через коммуникационные модули.
Температурные модули замеряют сопротивление в цепи либо термо-ЭДС. Если на них подключаются термометры сопротивления — при нагревании металла его сопротивление, по законам физики, повышается, соответственно определяется температура. Если подключается термопара (два спаянных проводника из разных металлов, при нагревании стыка возникает разность потенциалов между другими концами), замеряется напряжение.
Интерфейсные (или коммуникационные) модули предоставляют нам порты под RJ45, DB9, DB15, просто клеммники или что ещё бог производителю на душу положит. Помимо реализации непосредственно интерфейса (физического разъёма под коннектор, физического уровня модели OSI) они также реализуют протокол обмена через этот разъём.
Протоколы и интерфейсы
Протоколов напридумывали и используют кучу: ModBus (RTU, TCP, ASCII), Profibus, Profinet, CAN, HART, DF1, DH485 и т.д. Некоторые особо хитрые производители реализуют свои протоколы поверх общепринятых.
Я достаточно тесно знаком с интерфейсами RS232/485 и протоколами Modbus. RS232 это всем знакомый COM-порт, с тремя основными линиями: Tx (transmit, передача), Rx (recieve, получение) и GND (ground, земля). RS485 это асинхронный полудуплексный последовательный интерфейс по 2 проводам (совмещённые Tx/Rx+ и Tx/Rx-) или 4 проводам (отдельно Tx+, Tx-, Rx+, Rx-) с разностью потенциалов на каждой паре от 2 до 10 вольт.
А модбас это в общем-то нехитрая штука, с проверкой целостности пакета по чексумме, подтверждением доставки и корректности запроса — или ответом, почему запрос неверен. В сети модбас есть два вида устройств: master — инициирует обмен; slave — выполняет запросы мастера. Пакет от мастера расходится ко всем слейвам, которые сравнивают адрес назначения со своим, если сходится, то смотрят следующие два байта — это команда работы с регистрами памяти — чтение/запись (за исключением нескольких редко используемых служебных команд), потом байты адреса и непосредственно данных, в конце чексумма. Достаточно подробно и понятно расписано на википедии.
Программная начинка
Первое, что нужно сказать, программа в ПЛК выполняется циклически с определённой частотой. Возможности зависят от контроллера, обычно это где-то 20, 50, 250 мс, 1, 2, 3, 4, 5 с. Естественно, это не гарантирует выполнение кода именно за такой промежуток времени, нельзя большие программы пихать в цикл 20 мс, к началу следующего цикла предыдущий должен быть завершён.
Второе, это языки программирования. По идее программируются ПЛК на языках, определённых стандартом МЭК61131:
Это «по идее». Но, например, Siemens придерживается своего наименования языков, а у B&R есть возможность писать на ANSI C.
Самые используемые контроллеры, безоговорочно, у Siemens и Allen Bradley (последним, к слову, принадлежит Rockwell Automation со своей линейкой SCADA-пакетов RSView). За ними по пятам идут Schneider Electric; ОВЕН; General Electric; AutomationDirect; ICP DAS; Advantech; Mitsubishi Electric; B&R.
Профессия техник автоматизированных систем управления и обработки информации.
1. Как называется ваша профессия (должность)?
Техник автоматизированных систем управления и обработки.
2. В чем заключается Ваша работа и какие у Вас обязанности?
Обслуживание отраслевой компьютерной техники, создание программ и приложений. При этом создание программ профильное.
В основном это идёт обслуживание железнодорожных систем автоматики, телемеханики и связи. Вся система прорабатывается для автоматического контроля.
3. Какое образование необходимо, чтобы получить Вашу должность?
4. Опишите свой рабочий день.
Начинается как у всех обычно в 8 часов утра и заканчивается в 17 часов. Необходимо проверить компьютерную технику, проводить профилактику и в случае необходимости производить ремонт. Каждый техник имеет определённый участок работ. За ним закреплено несколько компьютеров и автоматических устройств. Перед тем как приступить проверяется состояние, в случае наличия ошибки исправляется и дорабатывается.
5. Насколько комфортны условия Вашего труда (целый день на улице, или в офисе с чашечкой кофе)?
Преимущественно в офисе, либо в пределах площади компании. Возможные и командировки.
6. Что Вам больше всего нравится в своем деле?
Сложные задачи и их решение.
7. Что Вам больше всего не нравится в своем деле?
Проведение долго времени за ЭВМ.
8. Если не секрет, Ваш уровень зарплаты (достаточно написать устраивает или нет)?
Пятнадцать тысяч в месяц, хотело бы конечно побольше.
9. Опишите Ваш коллектив, какие люди работают вместе с Вами?
Один бригадир и несколько подчинённых.
10. Какие человеческие качества по Вашему мнению наиболее важны в вашем деле?
Быстрая обучаемость и понимание задачи.
11. Работа дает мне дополнительные возможности(тут все что дает вам работа кроме денег, от самовыражения и общения с интересными людьми до возможности побывать в различных странах).
Возможность командировок по городам нашей страны.
12. У Вас есть возможность оценить по пятибалльной шкале свою работу, какую оценку Вы бы поставили?
13. Почему Вы выбрали такую работу?
Интерес к компьютерным технологиям.
14. Какие существуют возможности для вашего карьерного роста?
Старший техник, руководитель отдела.
15. Что по Вашему мы не включили в план и чем бы Вы еще хотели с нами поделиться?
Данная работа — это работа будущего, так как компьютерная индустрия стремительно развивается.
16. Ваша страничка в соц сетях.
я в вконтакте
Мой путь в пром. автоматизацию. Инженер-программист АСУТП
Опишу вкратце саму специальность, обязанности и как я к этому пришел. Будет много текста.
В общем выполнение работ по автоматизации проходит следующие стадии (упрощенно, на самом деле все немного сложнее):
1. Если участвуют несколько отделов в реализации проекта, то, когда приходит запрос из отдела продаж, каждый отдел предоставляет часы, которые потратит специалист на реализацию своей части. Далее это все суммируется и возвращается в отдел продаж. Они офигевают и ообычно на этом этапе уменьшаются часы, заложенные различными заинтересованными отделами, ибо дорого, и нужно продать. Ненавижу за это «продажников», хотя и понимаю, что это бизнес. Чтобы было понятно, в компании, где было больше 200 сотрудников были: департамент проектирования, департамент разработки ПО, департамент пуско-наладочных работ. И каждое подразделения выдавало кол-во часов на этот проект, необходимое для выполнения их части работ. И как итог выиграли тендер (если повезло, не будем говорить про остальные схемы).
2. На этом этапе обычно пишется ТЗ (технологическое задание) программистом на автоматизацию, хотя должно быть наоборот, заказчик должен предоставить описание того, что он хочет получить. Но у меня было так, как описываю. Дальше это ТЗ долго и нудно согласовывается с заказчиком, вносятся правки, ставятся подписи. Хотя это совсем не гарантия того, что ТЗ останется неизменным. Правки могут прийти, когда до начала пуско-наладочных осталось совсем немного времени, но почти всегда фирма-исполнитель прогибается под заказчика и программист потом в панике вносит изменения, что приводит к тому, что ПО будет не протестировано до конца, что приводит к задержкам при вводе в эксплуатацию и т.д. Но никого это обычно не волнует, хоть спи на объекте, но оно должно работать.
4. Тестирование программы на стенде или в симуляторах. Отлично работающая программа в симуляторе не равно иногда даже работающей на «живом объекте».
5. И самый интересный момент — это пуско-наладка (ПН). Об этом напишу подробнее.
Итак, что должен делать инженер во время ПН. Для удобства разделю на этапы.
1. I/O check проверка правильности подключения всех входов/выходов ПЛК (программируемый логический контроллер). И если что-то неправильно – то исправление. На данном этапе никакого ручного управления, не говоря уже про автоматизацию нет. Просто в контроллере можно жестко активировать выход и посмотреть, тот ли механизм включился. С входами проще, бегаешь вокруг механизма и тыкаешь кнопки, замыкаешь вручную концевые выключатели и смотришь, соответствует ли это тому, что ты заложил в программу. Для тех, кто не в теме, каждый контроллер имеет входа и выхода. Входа используются для сбора данных с механизма (всякого рода датчики, кнопки и т.д.). Выхода же нужны для управления устройством, например включить двигатель, закрыть задвижку и т.д. Это если очень упрощенно и не вдаваясь в подробности.
2. Если предыдущий этап закончился успешно и все собрано правильно (на более-менее больших объектах с первого раза никогда все правильно собрано не будет) – то приступаем к проверке в ручном режиме. Для этого либо со SCADA либо HMI включаем/выключаем узел агрегата и смотрим все ли правильно работает и все ли правильно отображается. Часто бывают ошибки (если используется визуализация) в привязках переменных к объекту на визуализации. Например, запустили один механизм, а на панели/скаде отображается, что включился другой, хотя работает правильный ну и т.д. Эти ошибки сразу же исправляются и процесс проверки продолжается.
3. Когда закончили ручное тестирование – переходим к самому сложному и интересному (вот тут симулятор, если тестировалась программа на нем, и дает прикурить иногда). Автоматический режим. Ну с ним все ясно, перевели все механизмы в автомат и запустили объект.
С этим режимом всегда могут быть проблемы. И когда вы пишете программу нужно учитывать максимально возможные варианты. Например, на двигателе перестал работать датчик температуры и из-за этого запускать этот узел в автоматическом режиме нельзя (ведь датчик не просто так там установлен), но если этот узел нельзя запустить в автомате, то и остальные по идее тоже нельзя, так как в автоматическом режиме реализовываются блокировки, которые отключат механизм при неисправности. Неисправность одного узла не дает запустить другой от него зависящий ну и т.д. И теперь нужно ждать пока починят неисправность, а производство в это время стоит. И владелец кричит какие в обще все, хм, хорошие люди. Но обычно так не делается. Почти всегда есть возможность запустить все в автомате, даже если какой-то из узлов агрегата не может работать в автомате. Часто дается возможность отключить контроль какого-то сигнала, например, тот же датчик. Активируем эту функцию и все у нас работает в автомате, так как сигнал от датчика не учитывается и в дальнейшем это может привести к проблемам, но это уже ответственность заказчика. Все эти режимы описываются в инструкции и с большими предупреждающими знаками. При использовании систем визуализации часто делают так называемый лог событий сюда входят аварии (это всегда делается) и действия оператора (имя оператора, что нажал, какой режим выбрал, что изменил и т.д.). И если возникает поломка механизма по вине заказчика, так как отключили какой-то элемент контроля – то это уже не гарантийный случай и фирма, что делала автоматизацию не попала на деньги. Так как любой гарантийный ремонт делается за счет изготовителя, а в этом случае они сами виноваты.
На этом пока хочу закончить. И так уже вышел далеко за рамки того объема, который хотел написать. Возможно получилось как-то не слишком структурировано, но я старался))) Будет кому-то интересно возможно продолжу еще что-то по теме автоматизации писать.