что такое промышленное программирование
Промышленное программирование, или Пара слов об АСУ ТП
Есть такая профессия — производство автоматизировать. Аббревиатура АСУ ТП означает «автоматизированная система управления технологическим процессом» — это система, состоящая из персонала и совокупности оборудования с программным обеспечением, использующихся для автоматизации функций этого самого персонала по управлению промышленными объектами: электростанциями, котельными, насосными, водоочистными сооружениями, пищевыми, химическими, металлургическими заводами, нефтегазовыми объектами и т.д. и т.п.
Фактически, каждый человек, живущий не в лесу и пользующийся благами цивилизации, использует результаты труда предприятий, на которых функционируют АСУ ТП.
Иногда на эту тему проскакивают статьи и на хабре. Обычно они не пользуются особой популярностью, но всё же я хочу написать несколько обзорных статей об АСУ ТП в надежде рассказать хабравчанам что-то интересное (а возможно, кому-то даже полезное) и привлечь на хабр больше своих коллег.
Сначала пара слов о себе. Я только начинаю свой жизненный путь в автоматизации, опыт работы без малого два года. За это время побывал на нескольких газовых месторождениях, сейчас работаю на нефтяном.
Поскольку область обширная, несмотря ни на что развивающаяся, местами противоречивая и спорная, буду стараться обобщать не в ущерб достоверности, но не могу избежать перекоса в свою область — то оборудование, софт и сферу, с которыми лично я сталкивался.
Итак, программно-технический комплекс АСУ ТП делится на три уровня: верхний (компьютеры), средний (контроллеры), нижний (полевое оборудование, датчики, исполнительные механизмы). Про нижний уровень рассказывать не буду — слишком уж это далеко от от тематики хабра, да и статья получится слишком большая.
Верхний уровень
Верхний уровень — это серверы и пользовательские ПК (у нас они называются АРМ — автоматизированное рабочее место). Сюда выводится состояние технологического процесса, и отсюда при необходимости оператором подаются команды на изменение его параметров. Для упрощения разработки создано большое количество 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.
Использование R для «промышленной» разработки
Является продолжением предыдущих публикаций. Не секрет, что при упоминании R в числе используемых инструментов вторым по популярности является вопрос о возможности его применения в «промышленной разработке». Пальму первенства в России неизменно держит вопрос «А что такое R?»
Попробуем разобраться в аспектах и возможности применения R в «промышленной» разработке.
Что такое промышленная разработка ПО?
Нисколько не удивляет, что под этим термином каждый понимает что-то свое. Начиная с «только C++» или «только java» и заканчивая «наличием плана продаж и роадмэпом на 10 лет вперед». Но без четкого определения термина дальше двигаться невозможно.
Поскольку однозначно устоявшегося определения нет, для ответа на поставленный вопрос соберем это понятие из совокупности внешних и внутренних присущих артефактов:
По артефактам с точки зрения менеджера все понятно, но они слабо относятся к языку программирования. Внутренних артефактов набирается великое множество, но для многих из них совершенно неважно, на каком языке ведется разработка. В частности, при применении R могут использоваться из числа любимых/привычных
Таким образом, основные претензии можно переформулировать в контексте надежности («ага, интерактивная работа в консоли это вам не 24×7, да и писали все для академических исследований!»). Замечание в целом верное, но по слегка устаревшим данным. По факту в R в настоящее время сформирован набор пакетов и подходов, которые позволяют легко и элегантно делать приложения и в формате 24×7. Поэтому далее сфокусируемся на наиболее интересных моментах в задаче обеспечения надежности разрабатываемого ПО:
Отчасти эти моменты пересекаются с областью «defensive programming».
Также не следует забывать, что R — высокоуровневый язык, ориентированный на решение задач по манипуляции с данными и обладающий широким набором проверенных библиотек (пакетов). Содержательная часть решения даже весьма сложных задач может занимать всего лишь несколько сотен строчек кода. Для более крупных проектов желательно использование механизма пакетирования, позволяющего структурировать код путем формирования собственных библиотек (пакетов).
Поддержка различных парадигм программирования
Существующий набор пакетов, дополняет и расширяет возможности base-R не только в части математических алгоритмов, но и в части парадигм разработки. Вынося за скобки вселенную tidyverse, имеет смысл упомянуть два пакета, расширяющих реализацию ООП и функционального программирования:
Если говорить о функциональном подходе, то реализация отдельного набора элементов такого подхода в пакете purrr в совокупности с pipe оператором %>% позволяет на практике очень сильно упростить и обезопасить обработку данных с существенным сокращением требуемого для этого объема кода. В качестве старта можно ознакомиться с хорошим докладом на эту тему: Happy R Users Purrr – Tutorial
Отладка
В дополнение к классическим инструментам отладки, хорошо описанным в статье «Debugging with RStudio» я бы упомянул следующие небесполезные инструменты:
Статический анализ кода
Тут все достаточно просто. Наиболее популярный инструмент — lintr@CRAN или lintr@github.
Lintr интегрируется с RStudio IDE, чтобы не повторяться, детали можно посмотреть в ветке Lintr integration with RStudio.
Логирование и анализ во время исполнения
Логирование
Логирование процесса исполнения ПО в логически значимых точках хоть и добавляет накладные расходы, но будучи организованным правильным образом существенным образом упрощает задачу обеспечения последующей технической поддержки разработанного ПО. С учетом высокоуровневости R и компактности кода, даже постоянно включенное логирование не является накладным по ресурсам.
Для задачи логирования наиболее удобен пакет futile.logger. Семантика log4j многим известна и не требует изучения нового. Из полезно-удобных дополнений/расширений я бы выделил следующие:
Real-time валидация
В целом, особенно в языках с динамической типизацией, правилом хорошего тона является проверка данных, поступающих на обработку в ту или иную функцию. По-хорошему, проверку следует разделить на два этапа: физическая проверка (данные требуемого типа) и логическая проверка (содержание данных правильного типа также следует установленным требованиям). Время на исполнение логической проверки может быть на порядки больше, нежели на физическую. Элементарный пример — на этапе физической проверки мы смотрим, что на вход пришел вектор чисел с плавающей точкой, а на этапе логической проверки смотрим, что все элементы вектора неотрицательны.
В части логической проверки — тут каждый может выбрать удобный ему способ. Все зависит от того, какие рода данные, идет ли обработка независимо или в конвейере (pipe), что именно нужно проверять.
В зависимости от того, что требуется по логике программы, можно либо делать проверку на соответствие условиям с получением TRUE/FALSE и последующим ветвлением логики, либо генерировать exception (assert).
Обработка исключений
Механизм генерации исключений несомненно полезен при работе с данными, а подробный вывод сопутствующей информации как нельзя кстати при интерактивной работе в консоли. Однако при переходе к потоковому исполнению останов программы при возникновении ошибки совершенно не нужен, а разнообразие в способах формирования диагностических сообщений начинает утомлять при создании обработчиков.
Обработка исключений штатными механизмами tryCatch хорошо описана в книге «Advanced R». Более интересным и полезным применительно к обработке данных в программном режиме является два следующих расширения:
Хорошо и кратко возможности по использованию safely были описаны в блоге RStudio: purrr 0.2.0 by Hadley Wickham + документация.
Функциональное и юнит тестирование
Пакетирование и автоматизированная сборка
Просто констатируем, что есть но не все об этом знают. Сборка, валидация, документирование, проверка и пр., все интегрировано RStudio IDE. Кратко охвачено в статье «Building, Testing, and Distributing Packages». Досконально все описано в отличной книге Hadley Wickham: «R packages». Полезным может оказаться применение хелпер-пакета usethis
Также есть пакет packrat позволяющий сформировать снапшот пакетов, необходимых для работы конкретного приложения. Тем самым обеспечивается независимость среды функционирования ПО от пакетов, установленных в системе.
Система генерации документации
Просто констатируем, что есть для пакетов, но не все об этом знают. Построена на базе roxygen, интегрировано с RStudio IDE.
Досконально все описано в отличной книге Hadley Wickham: «R packages».
Заключение
Сейчас R очень активно развивается. Каждую неделю появляются новые полезные функции, пакеты, подходы или улучшаются существующие. В задачах, связанных с обработкой данных указанный в публикации набор пакетов позволяет писать на R быстрый, стабильный, компактный и прогнозируемый код. Год назад этих пакетов было меньше, что будет в конце 2018 — время покажет.
В такой ситуации делать заключения о возможности или невозможности применения языка и платформы на основании данных двух и более летней давности некорректно. Как минимум, надо ознакомиться с текущим состоянием.
Что касается скорости, то, как всегда, этот вопрос относителен. 2 дня разработки + 10 секунд на исполнение на R много меньше, чем 2 недели разработки + 0.1 секунда на исполнение, например, на Java. О скорости необходимо говорить в контексте. Для функций, требующих быстроты исполнения, есть возможность реализовать ее на C++ не выходя за границы R путем применения пакета Rcpp. С кратким обзором возможностей можно ознакомиться также в одной из статей автора: «Extending R with C++: A Brief Introduction to Rcpp».
Задач по разнообразной обработке данных (от сбора до визуализации) становится все больше. Почему бы не взглянуть в сторону R?
Опыт программирования на дядю за деньги.
Ну то бишь дома хелллоуворлды и курсачи в универе не в счёт.
От твоих программ должен быть токсичный выброс.
относится скорее к вакансии «Системный администратор»
Это «devops» так называемый.
От твоих программ должен быть токсичный выброс.
Токсичный выброс/вброс на LOR?
Нет, не относится.
Правда в том, что действительно хороший разработчик и действительно хороший сисадмин пересекаются в областях компетенции на
Правда в том, что действительно хороший разработчик и действительно хороший сисадмин пересекаются в областях компетенции на
Ну или продолжай быть дилетантом, читать лурку вместо работы это не мешает
Может, если ты сишник-говнокодер.
Иначе непонятно как ты можешь что-нибудь кодить, не зная английского языка и не разбираясь том, под что ты кодишь.
Я не могу представить себе хорошего сетевого сишника, который не знал бы как устроены TCP пакеты. И сетевого сисадмина без этих знаний тоже не могу.
У них нет денег на сисадмина, нанимают специалиста по всему.
В большинстве крупных проектов существует разделение труда и хорошему разработчику администрировать надо максимум свой локалхост (а бывает, что и это не надо). Это не мешает разработчику иметь какие-то знания из других областей, но по сути ему это не нужно, на работе не пригождается, платить за это ему не будут.
Есть и другие проекты, в которых пара человек делают всё, и программируют и базу тюнят и линукс ставят и фаерволы настраивают и жёсткие диски в рейдах перетыкают. Но таких меньше.
А что значит «опыт промышленного программирования»?
Применение навыков разработки программного обеспечения к автоматизации бизнес-процессов какой-либо предметной области (блеванул энтерпрайзом пока писал).
В ОП просто специфическая предметная область и, на мой взгляд, достаточно интересная. Да, больше звучит так, как будто требуется специалист по всему со знанием Python. Но иначе нафиг нужен твой опыт разработки на Python, если не для автоматизации вот таких задач?
И сетевой экран тоже сишник должен уметь настраивать?
Я понял! Ты ПХПист! Ну так бы и писал.
скорее всего безглючная работа под нагрузкой с кучей пользователей.
Где там написано, что из одного?
Безотносительно к самой вакансии. Бедный русский язык, уж лучше бы на английском писали, если кому-то так мучительно больно сформулировать мысли по-русски, не делая кальки с английского. Еще понятно, когда нужных слов нет в русском языке, потому что терминология возникла за рубежом, но например, что это еще за «технические компетенции»? Откуда прет такой бредовый новояз, сказать «Необходимые знания», «квалификация» или просто «требуется» никак уже нельзя.
тогда это объявление будет выглядеть не так солидно и работать на фирму не весть какой честью будет.
И сколько они денег обещают?
А разрабатывает он тоже с прицелом на свой локалхост и ни хостом дальше?
Хочет он этого или нет, но он либо знает как устроен сервер либо он херовый разработчик.
Ну раз все твои познания о сисадминстве заканчиваются тем, что сисадмины настраивают сетевые экраны и брандмауеры, то всё с тобой понятно.
Я питонист последнее время, в прошлом я сисадмин.
Да. Как уже отметили это DevOps. Что-то вроде автоматизации рутинных процессов по администрированию. Как-бы техподдержка для программеров.
Я говорил про хороших разработчиков, а не про обычных
лучше бы русского, чтобы вакансии описывать можно было
что это еще за «технические компетенции»?
Сразу видно человека без опыта промышленного программирования =)
считай, что знание сетей, протоколов и файерволов входит в узконаправленную область 🙂
Если он начинает изучать область все шире и шире он начинает упускать из виду «мелочи» которые его делают «хорошим разработчиком»
да ладно. Какие там мелочи? это как все ищут мастера красить дубовые доски в жёлтый. А если он красил железо в чёрный, то это уже пипец как не в тему.
Понимать как устроен пакет и как это всё работает не то же самое, что и настраивать. И к сожалению, погромистов кто не знает/понимает как работает компьютер большинство, а чо этаж не ваше дело типа.
При чём тут ширина области? Речь была о пересечении областей на
Ты читал вводное сообщение?
Ты знаешь чем занимаются админы?
крутой узкий водитель тачек ни в коем случае не должен даже представлять как работает ДВС и что он вообще есть под капотом
Т.е. это админ должен лезть в говнокод, смотреть что эта кнопачка лезет при полнолунии, туда где заблокировано, а не автор говнокода сказать, что в брендмауере порт закрыт?
Суровая реальность такова, что как раз и приходится достаточно часто читать чужой код.
опенстак на питоне написан, видимо они ищут кодера, который им будет его допиливать
он либо знает как устроен сервер
Но совершенно необязательно умеет настраивать Jenkins, CircleCI, GitHub etc.
И дворник не обязательно умеет мётлы производить, но как они устроены точно должен знать. И при необходимости он может собрать пусть и не самую эффективную в мире метлу, но уж точно полноценную и исправно работающую.
И архитектор мётел в случае чего наверняка сможет подмести мусор.
Но если архитектор и дворник — понаехавшие таджики, не способные даже мануал прочитать — можешь таких специалистов себе нанимать, я без них обойдусь.
И при необходимости он может собрать пусть и не самую эффективную в мире метлу
Ну да, а человек с руками может собрать табуретку. Это не значит, что на любую сидячую работу нужен человек с умением делать табуретки.
А дворник, как раз, уж лучше пусть будет понаехавшим таджиком. Понаехавшие убирают лучше.
для пилотов рефлексы важны, это немного другое
А внимание тест-пилота направлено как раз на то, чтобы исходя из знаний о машине предоставить инженерам как можно больше информации о том, как можно заставить машину ехать лучше и быстрее