Нижний уровень автоматизации

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

Однако существует общий принцип построения систем промышленной автоматики, согласно которому АСУ ТП строится по иерархической схеме, включающей 3 уровня – от нижнего к верхнему.

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

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

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

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

Принципы автоматизации

Существуют единые принципы автоматизации, которые относятся ко всем видам автоматизированных процессов.

Контроллерный уровень

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

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

Полевой уровень

Полевой уровень АСУ ТП является самым нижним в иерархии. По англоязычной классификации это ступень «Input/Output», иначе говоря, уровень входов-выходов. Здесь располагаются следующие компоненты автоматических систем:

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

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

Как работают современные промышленные шины и протоколы

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

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

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

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

Как разработчики выбирают протокол для своего проекта? Все современные протоколы обмена обеспечивают довольно высокое быстродействие, поэтому зачастую выбор того или иного производителя обусловлен не скоростью обмена по этой самой промышленной шине. Не так важна и реализация самого протокола, потому что, с точки зрения разработчика системы, это все равно будет черный ящик, который обеспечивает некую внутреннюю структуру обмена и не рассчитан на вмешательство извне. Чаще всего обращают внимание на практические характеристики: производительность вычислителя, удобство применения концепции производителя к поставленной задаче, наличие нужных типов модулей ввода-вывода, возможность горячей замены модулей без разрыва шины и т.д.

Популярные поставщики оборудования предлагают собственные реализации промышленных протоколов: например, всем известная компания Siemens разрабатывает свою серию протоколов Profinet и Profibus, компании B&R — протокол Powerlink, Rockwell Automation — протокол EtherNet/IP. Отечественное решение в этом списке примеров: версия протокола FBUS от российской компании Fastwel.

Есть и более универсальные решения, которые не привязаны к конкретному производителю, такие как EtherCAT и CAN. Мы подробно разберем эти протоколы в продолжении статьи и разберемся, какие из них лучше подходят для конкретных применений: автомобильной и аэрокосмической промышленности, производства электроники, систем позиционирования и робототехники. Оставайтесь на связи!

Виды автоматизируемых процессов

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

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

Вторая группа предприятий, это предприятия, выполняющие переработку природного сырья. Они изготавливают продукцию из сырья, добытого или произведенного
предприятиями первой группы. К таким предприятиям относятся, например, предприятия автомобильной промышленности, сталелитейные предприятия, предприятия
электронной промышленности, электростанции и т.п.

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

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

К таким процессам относятся:

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

Пример Технических заданий на автоматизацию некоторых подсистем предприятия можно посмотреть и приобрести в интренет
магазине “Менеджмент качества”.

ТЗ на подсистему “Склады” представляет собой пример Технического задания на автоматизацию управления складами предприятия.

Данный документ является примером реального Технического задания, на основании которого была выбрана и внедрена система автоматизации
складским хозяйством промышленного предприятия.

Документ включает в себя 26 страниц. Формат документа – Microsoft Word 2002. Совместим со всеми версиями MS Word. Документ допускает
редактирование и внесение изменений.

ТЗ на подсистему “Документооборот” представляет собой пример Технического задания на автоматизацию управления процессом документооборота.

Данный документ является примером реального Технического задания, на основании которого была выбрана и внедрена система автоматизации
документооборота промышленного предприятия.

Документ включает в себя 17 страниц. Формат документа – Microsoft Word 2002. Совместим со всеми версиями MS Word. Документ допускает
редактирование и внесение изменений.

ТЗ на подсистему “Закупки” представляет собой пример Технического задания на автоматизацию процессов закупок и управления поставщиками.

Данный документ является примером реального Технического задания, на основании которого была выбрана и внедрена система автоматизации
закупками и управления поставщиками промышленного предприятия.

Документ включает в себя 23 страницы. Формат документа – Microsoft Word 2002. Совместим со всеми версиями MS Word. Документ допускает
редактирование и внесение изменений.

Виды автоматизированных процессов

Для предприятий из любой отрасли экономики характерны общие группы автоматизируемых процессов.

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

От гирлянды до целой рабочей станции

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

Если оператору повезло больше, то в качестве верхнего уровня ему достанется панель оператора — некий плоскопанельный компьютер, который тем или иным образом получает данные для отображения от контроллера и выводит их на экран. Такая панель обычно монтируется на сам шкаф автоматики, поэтому взаимодействовать с ней приходится, как правило, стоя, что вызывает неудобства, плюс качество и размер изображения — если это малоформатная панелm — оставляет желать лучшего.

Ну и, наконец, аттракцион невиданной щедрости — рабочая станция (а то и несколько дублирующих), представляющая собой обычный персональный компьютер.

Для наглядного отображения информации на рабочих станциях и плоскопанельных компьютерах используют специализированное программное обеспечение — SCADA-системы. На человеческий язык SCADA переводится как система диспетчерского управления и сбора данных. Она включает в себя множество компонентов, таких как человеко-машинный интерфейс, визуализирующий технологические процессы, систему управления этими процессами, систему архивирования параметров и ведение журнала событий, систему управления тревогами и т.д. Всё это дает оператору полноценную картину происходящих на производстве процессов, а также возможность ими управлять и оперативно реагировать на отклонения от технологического процесса.

Оборудование верхнего уровня обязано взаимодействовать неким образом с контроллером (иначе зачем оно нужно?). Для такого взаимодействия используются протоколы верхнего уровня и некая технология передачи, например, Ethernet или UART. В случае с «ёлкой» таких изощрений, конечно, не нужно, лампочки зажигаются с использованием обычных физических линий, никаких мудреных интерфейсов и протоколов там нет.

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

Диспетчерский уровень

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

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

Промышленное программирование, или Пара слов об АСУ ТП

Время на прочтение

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

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

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

Сначала пара слов о себе. Я только начинаю свой жизненный путь в автоматизации, опыт работы без малого два года. За это время побывал на нескольких газовых месторождениях, сейчас работаю на нефтяном.

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

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

Верхний уровень

Верхний уровень — это серверы и пользовательские ПК (у нас они называются АРМ — автоматизированное рабочее место). Сюда выводится состояние технологического процесса, и отсюда при необходимости оператором подаются команды на изменение его параметров. Для упрощения разработки создано большое количество 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,

, 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.

Заключение

Автоматизация процессов представляет собой сложную и трудоемкую задачу. Для успешного решения этой задачи необходимо придерживаться определенной
стратегии автоматизации. Она позволяет улучшить процессы и получить от автоматизации ряд существенных преимуществ.

Кратко, стратегию можно сформулировать следующим образом:

Второе поколение протоколов или не совсем промышленные шины ISA, PCI(e) и VME

На смену протоколам Modbus и HART пришли не совсем промышленные шины, такие как ISA (MicroPC, PC/104) или PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), а также VME.

Настала эра вычислителей, имеющих в своем распоряжении универсальную шину передачи данных, куда можно подключать различные платы (модули) для обработки некоего унифицированного сигнала. Как правило, в этом случае процессорный модуль (вычислитель) вставляется в так называемый каркас, который обеспечивает взаимодействие по шине с другими устройствами. Каркас, или, как его любят называть трушные автоматизаторы, «крейт», дополняется необходимыми платами ввода-вывода: аналоговыми, дискретными, интерфейсными и т.д., либо все это слепливается в виде бутерброда без каркаса — одна плата над другой. После чего это многообразие на шине (ISA, PCI, etc.) обменивается данными с процессорным модулем, который таким образом получает информацию с датчиков и реализовывает некую логику.

Все бы ничего с этими шинами ISA, PCI(e) и VME, особенно для тех времен: и скорость обмена не огорчает, и расположены компоненты системы в едином каркасе, компактно и удобно, горячей замены плат ввода-вывода может и не быть, но пока еще и не очень хочется.

Но есть ложка дегтя, и не одна. Распределенную систему довольно сложно построить в такой конфигурации, шина обмена локальная, нужно что-то придумывать для обмена данными с другими подчиненными или равноправными узлами, тот же Modbus поверх TCP/IP или какой другой протокол, в общем, удобств маловато. Ну и вторая не очень приятная штука: платы ввода-вывода обычно ждут на вход какой-то унифицированный сигнал, и гальванической развязки с полевым оборудованием у них нет, поэтому нужно городить огород из различных модулей преобразования и промежуточной схемотехники, что сильно усложняет элементную базу.

«А что с протоколом обмена по промышленной шине?» — спросите вы. А ничего. Нет его в такой реализации. По кабельным линиям сигнал попадает с датчиков на преобразователи сигналов, преобразователи выдают напряжение на дискретную или аналоговую плату ввода-вывода, а данные с платы уже читаются через порты ввода/вывода, средствами ОС. И никаких специализированных протоколов.

Нужна ли бизнесу автоматизация процессов

Причины ввести автоматизацию на предприятии следующие:

Несмотря на очевидные плюсы автоматизации, из-за специфики некоторых производств отказ от ручного труда не всегда выгоден. Следующие особенности производства препятствуют вводу автоматизации:

Уровни автоматизации процессов

Уровни автоматизации процессов совпадают с уровнями управления компанией, на котором происходит автоматизация.

В схеме представлен схематический взгляд на структуру менеджмента компании. Уровни автоматизации соответствуют уровням управления в компании.

Шины и протоколы в промышленной автоматике

Наверняка многие и вас знают или даже видели, каким образом управляются большие автоматизированные объекты, например, атомная станция или завод со множеством технологических линий: основное действо часто происходит в большой комнате, с кучей экранов, лампочек и пультов. Это комплекс управления обычно называется ГЩУ — главный щит управления для контроля за производственным объектом.

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

Принципы автоматизации процессов

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

Основными принципами автоматизации процессов являются:

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

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

Массовая автоматизация процессов затронула все сферы экономики. Ручной труд заменяется механизированным. Заметить это можно, приобретая продукты в супермаркете, жетон в метро, заказав доставку с почты или купив билеты в театр.

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

Преимущества автоматизации процессов

Автоматизация процессов позволяет существенно повысить качество управления и качество продукта. При внедрении СМК
автоматизация дает существенный эффект и дает возможность организации значительно улучшить свою работу. Однако, прежде чем принимать решение об
автоматизации процессов, необходимо оценить преимущества выполнения процессов в автоматическом режиме.

Как правило, автоматизация процессов дает следующие преимущества:

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

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

Системы автоматизации процессов

Автоматизированию производственных процессов помогают системы, призванные облегчить отмену ручного выполнения программ. Например, CRM-системы (каналы общения с клиентами), ERP-системы (управление складом и производством на предприятии), OLAP-системы (обработка данных и аналитика).

Пример автоматизированной CRM-системы: OkoCRM.

Системы автоматизации делятся на следующие (могут быть комбинированными): неизменяемые, программируемые и самонастраиваемые.

«Древние» протоколы передачи данных

Мало кто знает, но на седьмой день создания мира Бог не отдыхал, а создавал Modbus. Наравне с HART-протоколом, Modbus, пожалуй, самый старый промышленный протокол передачи данных, он появился аж в 1979 году.

В качестве среды для передачи изначально использовался последовательный интерфейс, затем Modbus реализовали поверх TCP/IP. Это синхронный протокол по схеме «мастер-слейв» (главный-подчиненный), в котором используется принцип «запрос-ответ». Протокол довольно тяжеловесный и медленный, скорость обмена зависит от характеристик приемника и передатчика, но обычно счет идет чуть ли не на сотни миллисекунд, особенно в реализации через последовательный интерфейс.

Более того, регистр передачи данных Modbus является 16-битным, что сразу же накладывает ограничения на передачу типов real и double. Они передаются либо по частям, либо с потерей точности. Хотя Modbus до сих пор повсеместно используется в случаях, когда не нужна высокая скорость обмена и потеря передаваемых данных не критична. Многие производители различных устройств любят расширять протокол Modbus своим исключительным и очень оригинальным образом, добавляя нестандартные функции. Поэтому данный протокол имеет множество мутаций и отклонений от нормы, но все же до сих пор успешно живет в современном мире.
Протокол HART тоже существует с восьмидесятых годов, это промышленный протокол обмена поверх двухпроводной линии токовой петли, в которую напрямую включаются датчики 4-20 мА и другие приборы с поддержкой протокола HART.

Для коммутации линий HART используются специальные устройства, так называемые HART-модемы. Также существуют преобразователи, которые на выходе предоставляют пользователю уже, допустим, протокол Modbus.

Примечателен HART, пожалуй, тем, что помимо аналоговых сигналов датчиков 4-20 мА в цепи передается и цифровой сигнал самого протокола, это позволяет соединить цифровую и аналоговую часть в одной кабельной линии. Современные HART-модемы могут подключаться в USB-порт контроллера, соединяться по Bluetooth, либо же старинным способом через последовательный порт. Десяток лет назад по аналогии с Wi-Fi появился и беспроводной стандарт WirelessHART, работающий в диапазоне ISM.

Автоматизация процессов необходима для поддержки управления на всех уровнях иерархии компании. В связи с этим уровни автоматизации определяются в
зависимости от уровня управления, на котором выполняется автоматизация процессов.

Уровни управления принято разделять на оперативный, тактический и стратегический.

В соответствии с этими уровнями выделяют и уровни автоматизации:

Автоматизация процессов на каждом из указанных уровней обеспечивается за счет применения различных систем автоматизации(CRM
системы, ERP системы, OLAP системы и пр.). Все системы автоматизации можно разделить на
три базовых типа.

Типы систем автоматизации включают в себя:

Эти типы систем могут применяться на всех уровнях автоматизации процессов по отдельности или в составе комбинированной системы.