Промышленное программирование, или Пара слов об АСУ ТП
Есть такая профессия — производство автоматизировать. Аббревиатура АСУ ТП означает «автоматизированная система управления технологическим процессом» — это система, состоящая из персонала и совокупности оборудования с программным обеспечением, использующихся для автоматизации функций этого самого персонала по управлению промышленными объектами: электростанциями, котельными, насосными, водоочистными сооружениями, пищевыми, химическими, металлургическими заводами, нефтегазовыми объектами и т.д. и т.п.
Фактически, каждый человек, живущий не в лесу и пользующийся благами цивилизации, использует результаты труда предприятий, на которых функционируют АСУ ТП.
Иногда на эту тему проскакивают статьи и на хабре. Обычно они не пользуются особой популярностью, но всё же я хочу написать несколько обзорных статей об АСУ ТП в надежде рассказать хабравчанам что-то интересное (а возможно, кому-то даже полезное) и привлечь на хабр больше своих коллег.
Сначала пара слов о себе. Я только начинаю свой жизненный путь в автоматизации, опыт работы без малого два года. За это время побывал на нескольких газовых месторождениях, сейчас работаю на нефтяном.
Поскольку область обширная, несмотря ни на что развивающаяся, местами противоречивая и спорная, буду стараться обобщать не в ущерб достоверности, но не могу избежать перекоса в свою область — то оборудование, софт и сферу, с которыми лично я сталкивался.
Итак, программно-технический комплекс АСУ ТП делится на три уровня: верхний (компьютеры), средний (контроллеры), нижний (полевое оборудование, датчики, исполнительные механизмы). Про нижний уровень рассказывать не буду — слишком уж это далеко от от тематики хабра, да и статья получится слишком большая.
Верхний уровень
Верхний уровень — это серверы и пользовательские ПК (у нас они называются АРМ — автоматизированное рабочее место). Сюда выводится состояние технологического процесса, и отсюда при необходимости оператором подаются команды на изменение его параметров. Для упрощения разработки создано большое количество 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:
- IL (Instruction List) — низкоуровневый ассемблероподобный язык.
- LD (Ladder Diagram) — графический язык, представляет собой программную реализацию электрических схем на базе электромагнитных реле. Придумано в лохматые года для тех асушников, которые больше электрики, чем программисты.
IL и LD легко конвертируются друг в друга, кажется, всеми средами программирования. Они не очень читабельны, и потому неудобны для разработки, но в ситуациях, когда внутренней памяти контролера немного, приходится писать на них. - ST (Structured Text) — текстовый паскалеподобный язык. По-моему, из всех пяти самый удобный.
- FBD (Function Block Diagram) — своего рода графический язык, «блоксхемоподобный». Программа составляется из функциональных блоков, которые представляют собой подпрограммы, написанные на каком-либо из языков стандарта МЭК61131. У каждого ФБ есть входы и выходы, которые соединяются со входами и выходами других ФБ. Кому-то, возможно, удобнее делать так, чем писать всё на том же ST.
- SFC (Sequential Function Chart) — графический высокоуровневый язык. Создан на базе математического аппарата сетей Петри. Описывает последовательность состояний и условий переходов. Ни разу не встречал и не слышал, чтобы где-то использовался.
Это «по идее». Но, например, Siemens придерживается своего наименования языков, а у B&R есть возможность писать на ANSI C.
Самые используемые контроллеры, безоговорочно, у Siemens и Allen Bradley (последним, к слову, принадлежит Rockwell Automation со своей линейкой SCADA-пакетов RSView). За ними по пятам идут Schneider Electric; ОВЕН; General Electric; AutomationDirect; ICP DAS; Advantech; Mitsubishi Electric; B&R.
Заключение
Пост не претендует на полное справочное описание всего — очень уж разное оборудование, софт и подходы к ним в целом. Самым формально безошибочным рассказом об АСУТП было бы перечисление соответствующих ФЗ, ГОСТов, техстандартов и регламентов. Все возможные расхождения с этими документами считать опечатками 😉 С радостью принимаются комментарии, поправки и, если интересно, пожелания для следующих статей.
Программное обеспечение контроллера
Программное обеспечение системы можно разделить на две группы:
– управляющие программы передающей аппаратуры — контроллера сбора и передачи телемеханической информации;
Программа контроллера ждет сигнала ее вызова с диспетчерского пункта. Пока нет вызовов программа следит за состоянием датчиков пожара, затопления и охранным датчиком. Если от них приходит сигнал, то происходит вызов диспетчерского пункта и сообщается о причине вызова. Как только приходят четыре гудка на модем на пункте учета тепловой энергии, программа отправляет диспетчеру запрос на пароль и следит за состоянием линии связи, чтобы не потерять данные. По приходу пароля его сравнивают с тем, который зашит в ПЗУ данного контроллера и если сравнение прошло успешно, то диспетчер получает доступ к данным на теплосчетчике. Если пароль неверный — модем “кладет трубку” и система возвращается в начальное состояние. Для синхронизации передачи используется асинхронный старт-стоповый режим передачи информации.
Программа компьютера осуществляет прием информационных байтов с пункта учета тепловой энергии и их анализ. По результату анализа данные в удобном для пользователя виде выводятся на экран монитора. Данные также могут быть сохранены в базе данных, в которой хранятся абсолютно все параметры измерений. В программе есть диспетчер регулярного опроса, который по таймеру включается (например: ночью) и автоматически опрашивает все пункты учета тепловой энергии и заносит результаты измерений в базу данных. Существует интерфейсный блок, т.н. монитор данных. Он включает в себя блок статистического анализа, блок мониторинга в режиме реального времени, блок управления модемом, блок формирования отчетов. Блок статистического анализа позволяет производить логические и математические операции над поступившими данными. Блок мониторинга позволяет увидеть в реальном времени поступающие данные и мгновенные их значения. Блок управления модемом позволяет посылать на него различные команды, с помощью которых осуществляется дозвон до пункта учета тепловой энергии и передача данных. В блоке формирования отчетов по заданному образцу создается отчет, который при желании можно вывести на принтер.
4.2. Разработка программного обеспечения
Программа AVR-микроконтроллера — это размещенная в памяти программ последовательность команд, каждая из которых состоит из двоичных кодов операций и двоичных адресов операндов.
Система команд AVR-микроконтроллеров включает команды арифметических и логических операций, команды передачи данных, команды, управляющие последовательностью выполнения программы, и команды операций с битами. Для удобства написания и анализа программ всем операциям из системы команд, кроме двоичного кода, сопоставлены мнемокоды ассемблера (символические обозначения операций), которые используются при создании исходного текста программы.
Специальные программы-трансляторы затем переводят символические обозначения в двоичные коды.
По исходному тексту программы, написанной на языке ассемблера, можно определить время ее исполнения и объем программной памяти, необходимый для ее хранения. Программирование на языке ассемблера является прекрасным средством для того, чтобы прочувствовать архитектуру микроконтроллера и логику его работы. Этому также способствует то обстоятельство, что трансляторы с языка ассемблера распространяются фирмой Атмел бесплатно и доступны всем желающим.
Кроме языка ассемблера, для программирования встраиваемых микропроцессоров широкое распространение получили языки программирования высокого уровня: С и BASIC. Они предоставляют программисту такой же легкий доступ ко всем ресурсам микроконтроллера, как и ассемблер, но, вместе с тем, дают возможность создавать хорошо структурированные программы, снимают с программиста заботу о распределении памяти данных и содержат большой набор библиотечных функций для выполнения стандартных операций.
Важнейшим достоинством системы команд AVR-микроконтроллеров является то, что она была специально оптимизирована для использования языка С.
Вся энергонезависимая память AVR-микроконтроллеров размещается внутри кристалла и состоит из электрически программируемых FLASH-памяти программ и EEPROM-памяти данных.
Так как все команды AVR представляют собой 16-разрядные слова, FLASH- память организована как последовательность 16-разрядных ячеек и имеет емкость от 512 слов до 64K слов в зависимости от типа кристалла.
Во FLASH-память, кроме программы, могут быть записаны постоянные данные, которые не изменяются во время функционирования микропроцессорной системы. Это различные константы, таблицы знакогенераторов, таблицы линеаризации датчиков и т.п.
Достоинством технологии FLASH является высокая степень упаковки, а недостатком то, что она не позволяет стирать отдельные ячейки. Поэтому всегда выполняется полная очистка всей памяти программ. При этом гарантируется, как минимум 1000 циклов перезаписи FLASH-памяти AVR.
EEPROM блок электрически стираемой памяти AVR предназначен для хранения энергонезависимых данных, которые могут изменяться непосредственно на объекте. Это калибровочные коэффициенты, различные установки, конфигурационные параметры системы. EEPROM-память имеет меньшую емкость (от 64 байт до 4К байт), но имеет возможность побайтной перезаписи ячеек, которая может происходить как под управлением внешнего процессора, так и под управлением собственно AVR-микроконтроллера во время его работы по программе.
В энергонезависимой памяти AVR имеется несколько специализированных битов [7].
LOCK-биты (LB1, LB2) предназначены для защиты программной информации, содержащейся во FLASH-памяти. Возможные режимы защиты перечислены в таблице 4.1. Запрограммировав биты защиты, стереть их можно лишь во время очистки FLASH -памяти, которая уничтожает и всю программу.
Режимы защиты программы
| Состояние Lock-бит | |||
| Режим | LB1 | LB2 | Тип защиты |
| 1 | 1 | 1 | Защита отсутствует |
| 2 | 0 | 1 | Запрет программирования Flash |
| 3 | 0 | 0 | Запрет как программирования, так и чтения Flash. |
FUSE-биты позволяют задавать некоторые конфигурационные особенности микроконтроллера (см. таблицу 4.2).
Микроконтроллеры AT90S1200 имеют FUSE-биты SPIEN и RCEN. Все остальные типы classicAVR конфигурируются при помощи FUSE-битов SPIEN и FSTRT. MegaAVR имеют четыре FUSE-бита: SPIEN, SUT0, SUT1 и EESAVE.
Три энергонезависимых Signature-байта служат для идентификации типа кристалла, программируются на фабрике и доступны только для чтения.
| Fuse-бит (значение по умолчанию) | Значение | Режим работы AVR |
| 0 | AVR тактируется внутренним RC-генератором. (работа AVR без каких-либо внешних элементов) | |
| RCEN (1) | 1 | Тактирование при помощи внешнего кварцевого резонатора или генератора. |
| 0 | Разрешение последовательного программирования через SPI интерфейс | |
| SPIEN (0) | 1 | Запрещение последовательного программирования через SPI интерфейс |
| 0 | Задержка старта AVR после сброса ~ 0.25мс | |
| FSTRT (1) | 1 | Задержка старта AVR после сброса ~ 16 мс |
| 00 | Задержка старта AVR после сброса ~ 5 мс | |
| 01 | Задержка старта AVR после сброса ~ 0.5 мс | |
| SUT 0/1 (11) | 10 | Задержка старта AVR после сброса ~ 4.0мс |
| 11 | Задержка старта AVR после сброса ~ 16 мс | |
| 0 | EEPROM не стирается во время цикла очистки энергонезависимой памяти | |
| EESAVE (1) | 1 | EEPROM стирается во время цикла очистки энергонезависимой памяти |
Разнообразные способы программирования AVR-микроконтроллеров обеспечивают простой и удобный доступ к внутренней энергонезависимой памяти во всех возможных ситуациях программирования кристалла.
Для энергонезависимых FLASH и EEPROM блоков AVR предусмотрены параллельный и последовательный способы программирования, которые выполняются под управлением внешнего процессора, а для EEPROM-памяти также возможен способ программной перезаписи под управлением AVR. LOCK-биты могут программироваться как параллельно, так и последовательно. FUSE-биты у младших моделей AVR могут программироваться только последовательно, а у старших — и параллельно, и последовательно.
Параллельное программирование энергонезависимой памяти использует большое число выводов микроконтроллера и выполняется на специальных программаторах. Такое программирование удобно, когда при массовом производстве необходимо «прошивать» большое количество кристаллов.
Последовательное программирование может выполняться прямо в микропроцессорной системе (In System Programming) через последовательный SPI-интерфейс, который использует всего четыре вывода AVR-микроконтроллера. Эта новая возможность является очень важной, так как позволяет обновлять программное обеспечение в уже функционирующей микропроцессорной системе.
Программирование контроллеров зачем нужно
Промышленные объекты в настоящее время автоматизируют деятельность с помощью специализированных программ. В статье расскажем зачем нужно программирование контроллеров и какие преимущества оно дает для деятельности.
Зачем нужно программировать контроллеры?
Для предприятий, осуществляющих работу с монотонными цикличными процессами, встает вопрос автоматизации. Автоматизация позволяет сократить затраты и повысить эффективность производственного процесса. Например, это относиться к инженерным системам – отопление, вентиляция, освещение, канализация.
Контролировать каждый процесс позволяют алгоритмы, записанные на программируемые контроллеры. Настройка очень сложное и ответственное дело, нужно обладать достаточными знаниями, чтобы правильно организовать процесс.
Специализированные компании выполняют программирование контроллеров на заказ и это отличное решение. Разово нанять знающих специалистов и периодический вызов их на техническое обслуживание – намного экономичнее, чем найм сотрудника и ежемесячная выплата заработной платы, социальных взносов.
Как происходит программирование контроллеров?
Для начала нужно подыскать подходящую компанию и уточнить свои потребности. Программы разрабатывают по следующим направлениям, вот список чтобы вам легче было определиться:
- Системы освещения (наружнее, внутреннее),
- Индивидуальный теплопункт,
- Холодильная система,
- Вытяжная установка,
- Пожаропредотвращающие системы (люк или вентилятор удаления дыма; подпор воздуха; клапаны, задерживающие огонь),
- Тепловой завес,
- Насосная станция канализации,
- Вентиляционная система.
Качественно выполняют настройку контроллеров ООО «Приборы и автоматика». Они относительно юная компания, однако их профессионализм не знает границ – уже завершена работа на более 2000 объектов, и появилось более 120 постоянных клиентов. Посмотрите их портфолио на pia.su.
Когда вы определились с выбором фирмы и необходимой услуги, их нужно вызвать на объект. Специалисты сделают технический анализ, дадут свои рекомендации конкретно под ваш случай. После подготовки алгоритма, придет программист, отвечающий за настройку и сделает необходимые манипуляции.
Не забудьте после установки программы, оформить услугу технического обслуживания. Это очень важный пункт, которым не стоит пренебрегать для успеха деятельности.
ПЛК — что это такое?
Доброго времени суток, уважаемые жители Хабра!
Прочитав пост про программирование ПЛК Siemens серии S7, я залез в поиск по Хабру, и был весьма удивлен, что тема промышленной автоматики вообще, и программирования ПЛК в частности, освещена весьма и весьма скудно. Возьму на себя смелость поделиться своим опытом в данной области, описав базовые принципы программирования ПЛК, в частности, производства компании Beckhoff.
Введение
Я занимаюсь автоматизацией зданий. Сложилось так, что в основном мы строим свои системы на базе ПЛК Beckhoff. Такой выбор был сделан прежде всего потому, что эти контроллеры являются свободно-программируемыми в полном смысле этих слов. Что это значит? Возьмите контроллер TAC Xenta, например, и попробуйте на нем реализовать обмен с внешним устройством через RS232 по собственному протоколу, на уровне «байт послал — байт принял». Не получится, эти контроллеры так не умеют — используйте только те протоколы, которые в них заложил разработчик. А Beckhoff умеет. Но прежде чем лезть в такие дебри, давайте посмотрим на среду разработки? На каком, собственно, языке, мы будем писать?
Стандарт МЭК 61131-3
Промышленные ПЛК программируются на языках стандарта МЭК 61131-3. Всего этих языков 5, некоторые производители добавляют свои. Языки друг на друга совсем не похожи, и, наблюдая за коллегами, могу предположить, что выбор того или иного языка связан прежде всего с тем, чем человек занимался до того, как он пришел в эту отрасль.
- IL, instruction list, список инструкций. Похож на ассемблер. Не видел никого, кто его использовал бы, но подозреваю, что олдскульные кодеры, пробивавшие перфокарты по памяти, оценят.
- LD, ladder diagram. Визуальный язык, для тех, кто занимался разработкой схем релейной автоматики.
- ST, structured text. Более всего напоминает «классические» языки программирования, чем-то похож на Паскаль. Оттого ценится теми, кто до ПЛК занимался программированием на других языках и платформах, в частности — мной.
- FBD, functional block diagram. Этакая блок схема, любим прежде всего технологами, решившими податься в программирование, за свою наглядность.
- SFC, sequential function chart. Графический язык, больше ничего не скажу. Ни разу не видел, чтоб его использовали.
Из не всеми поддерживаемых языков стоит отметить язык CFC (continuous flow chart), Beckhoff его поддерживает. Это дальнейшее развитие языка FBD, одним из наиболее существенных отличий, на мой взгляд, является поддержка явной обратной связи в схемах. Зачем это нужно? Например, вот такой генератор коротких импульсов на CFC будет работать, а на FBD – нет.
Блок TON — это стандартный блок, таймер с задержкой включения. Логика работы: выход Q становится TRUE, когда на входе IN сигнал TRUE в течение не менее времени PT.
Самая популярная, наверное, среда разработки под ПЛК — это CoDeSys. Многие производители берут ее за основу, и либо делают к ней библиотеку для работы со своим ПЛК, либо доделывают среду под себя.
Как работает ПЛК?
Программа ПЛК работает циклично. Время цикла может быть от единиц миллисекунд до единиц секунд, в зависимости от задач, которые на этот ПЛК возложены. Большинство ПЛК позволяют задавать время цикла разработчику программы, однако в некоторых моделях такой возможности нет. Многие ПЛК, в частности Beckhoff, позволяют в одной программе создать более одной циклически выполняемой задачи, и задать приоритет для этих задач. Что нам дает эта возможность?
Представим ситуацию: ПЛК управляет вентиляционной установкой, и к нему подключена панель управления через RS232. Температура в помещениях меняется не быстро, и запускать алгоритм управления вентиляцией чаще, чем раз в 50 — 100 мс просто нет смысла. Зато панель оператора опрашивает контроллер постоянно, и задержка ответа ПЛК более 10 мс уже выражается в «притормаживании» интерфейса пользователя, а при задержке 20 мс у нас переполнится аппаратный буфер COM-порта. Наличие нескольких задач позволяет нам решить эту проблему красиво: пусть «быстрая» задача работает с COM-портом, и вызывается каждые 2 мс, а «медленная» реализует логику работы вентиляции, и вызывается каждые 50 мс. Все работает хорошо, панель оператора не тормозит, пользователь доволен.
А что у этих железок внутри?
Тут все очень и очень зависит от производителя. Кто-то делает свою embedded-платформу на RISC-процессоре (например, отечественный «Овен») — этот подход очень популярен. Beckhoff же пошли по другому пути — на их ПЛК установлена Windows CE 5.0 (а если обновить с официального сайта прошивку — то 6.0), или же Windows XP Embedded, а PLC-задача работает как служба. Достаточно интересный контраргумент для любителей рассказывать о нестабильности Windows.
Но это «голова» контроллера, а ведь ему еще нужны входы и выходы, чтобы общаться с внешним миром. Тут есть два подхода:
- Можно сделать «все в одной коробке» — голова, некий набор входов / выходов, несколько вариантов конфигурации — вот тут у нас входов побольше, тут поменьше, тут голова помощнее, тут послабее. Так делают, например, Carel, и много кто еще. На маленьком проекте такой подход себя в чем-то, может быть, и оправдывает.
- Но лично мне кажется, что большую гибкость дает другой подход. Голова отдельно, и к ней по шине подключается наборный «хвост» из модулей ввода-вывода. Мы ставим те модули, которые нам нужны, и в том количестве, которые нам нужно. Так делают Beckhoff и Siemens, например.
Вот так выглядит внешне подход «все в одной коробке». На фото Carel pCO3.
А вот другой вариант — голова Beckhoff серии CX9000 (слева на фото) с набором модулей ввода-вывода.
Помимо всего прочего, на голове еще имеется некая шина, позволяющая объединять ПЛК в сеть, а зачастую еще и менять его программу через эту же сеть. Какая это будет сеть — зависит от ПЛК. Это могут быть и незнакомые тем, кто не сталкивался с промышленными сетями EIA-485, Profibus, CAN, а может быть и вполне привычный Ethernet. Именно через эту сеть, называемую fieldbus, и осуществляется подключение ПЛК к верхнему уровню — к СКАДА-системе, например. На фото выше хорошо видны 2 разъема 8P8C на голове Beckhoff’а — это Ethernet, а у Carel сверху слева видны (плоховато, правда) 2 разъема 6P4C — так они сделали RS-485. У этого интерфейса, к сожалению, нет общепринятого разъема.
Так все же, как под него программы писать-то?
Вообще, это тема не статьи, а целой книги. Но расскажу то, что увидел на личном опыте, и пусть это будет ложкой дегтя.
Для профессиональных программистов освоение ПЛК во многом покажется деградацией. ООП? Их нет у нас, есть только структуры, перечисления, и некое подобие класса, которое называется «функциональный блок». Что такое Private, Public и прочее, тоже можно забыть сразу — не пригодится. Из любого места вашей программы можно получить доступ к любому другому месту.
Динамическое выделение памяти? Их нет у нас совсем. Не уверен, сколько тебе пришлют данных? Выделяй буфер с запасом, и забудь про эту память — освободить ее не получится. Либо проявляй чудеса скорости и обрабатывай данные на лету, если успеешь уложиться в заданное время цикла.
Исключения? Да что вы… видел я одно чудо, которое намертво висло при выполнении конструкции вида:
foo, bar: int; baz: real; foo := 2000; bar := 2000; baz := INT_TO_REAL (foo * bar); Понятно, что переполнение, не влазит foo * bar в 16 бит, но зачем же виснуть-то? Да еще так, что ничего, кроме сброса по питанию не помогает.
Среда разработки? Не у всех CoDeSys, многим хочется пооригинальничать и написать что-нить свое. Одна из таких самописных сред вылетала с runtime error при попытке записать число 86400 в 16-битный INT. А вы говорите, обработка исключений на ПЛК. Ее и в среде разработки-то не всегда нормально могут сделать.
НО! Зато для любителей той тонкой грани, которая отделяет железо от программного обеспечения, софта в просторечии — это очень интересная ветвь ай-ти, правда.
Надеюсь, что этот небольшой обзор будет полезен. Если хабрасообществу будет интересна эта тема, то расскажу про ПЛК подробнее.