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

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

В настоящей заметке речь идет про массовую выгрузку / загрузку настроек точек данных.

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

И, вроде бы все так, да не всегда. Критично ли наличие ошибок в программах? Странный вопрос - конечно, критично. Но, тем не менее, найдутся и те, кто скажет – не беда. И даст этому свое объяснение. Здесь, правда,  можно вспомнить, как фирма Intel объясняла несущественность ошибки деления с плавающей точкой в процессоре Pentium (подробнее см. [1]). Но общественность и пользователи объяснили Intel, что она не права. И, понеся большие репутационные и финансовые потери,  ей пришлось с этим согласиться и исправить положение.

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

Итак. Выберем для экспериментов три среды: две известные – это MATLAB, SimInTech и одну, известную больше по статьям вашего покорного слуги, - среду параллельного автоматного программирования ВКПа. Для первых двух можно скачать ограниченные версии.  Их возможностей вполне будет достаточно для наших примеров. Ну, а в отношении третьей - придется довериться автору.

«Можно вечно смотреть на три вещи: как горит огонь, как течет вода и как несколько бездельников Senior dev собеседуют Junior».

Как их проводить, как понять, что компания не подходит, с кем соглашаться работать, а с кем нет?

Собеседования и в целом рынок IT вакансий одни из самых частых тем мемов в комьюнити, особенно среди людей с небольшим опытом.

Недавно на работе столкнулись с интересной ситуацией, о которой захотелось написать тут, потому что случай довольно интересный, хотя как и оказалось простой. На одном из агрегатов, управляемым контроллером от Allen Bradley Compact Logix L33ER, в контроллере постоянно сыпались предупреждения, а точнее даже минорный ошибки (Minor Faults) - которые на функциональность никак не влияют, но раздражают своим присутствием. В секунду по нескольку десятков таких ошибок без перерыва: Type 04 Program fault (Code 04) Arithmetic overflow. Result of an arithmetic instruction out of range, что переводится примерно как "Арифметическое переполнение. Результат арифметической инструкции вышел за предел."

Сразу к сути: есть склад, где все бизнес-процессы уже отлажены и в целом всех всё устраивает. Ничего, что даст рост в 30%, сделать уже невозможно, но хочется. Поставлена цель: оптимизировать маршрут, по которому идёт сборщик товаров, чтобы товар собирался быстрее. Результат 2-3% роста вполне устроит. Ограничения:

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

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

Для прочтения знать сам алгоритм k-ближайших соседей не требуется — он очень простой и станет ясен ещё в ходе прочтения. Он чем-то похож на теорему Пифагора, только на стероидах.

Часто в РФ приходится слышать мнение, что в Embedded разработке якобы в принципе не может быть никакого модульного тестирования. Инженеры за 40 в (7 случаях из 10) даже никогда не слышали термина unit testing. В России бытует даже расхожее мнение

Не нужны никакие тесты. Если программист хороший, то и код он пишет без ошибок.

Попробуем разобраться какие есть плюсы и минусы в модульном тестировании и понять надо это или нет.

На habr достаточно много статей про информационную безопасность АСУТП и объектов критической информационной инфраструктуры. По некоторым статьям идет бурное обсуждение между специалистами по ИБ и инженерами АСУТП, и у сообщества инженеров АСУТП есть свое мнение по вопросам ИБ)). В любом случае, если на производстве есть инженер АСУТП, то вопросы информационной безопасности производственной ЛВС он как-то решает.

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

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

Организация аварийных и технологических защит на примере технологической печи

В статье приведен пример организации защит для технологической печи. Данный подход к построению защит был неоднократно реализован на объектах нефтепереработки и нефтехимии с применением различных ПЛК.

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

Предложенный подход основан на личном опыте автора, автор не претендует на истинность.

SCADA (Supervisory Control And Data Acquisition) – вариант человеко-машинного интерфейса (ЧМИ), если перевести почти дословно – диспетчеризация, управление и обработка данных.

История развития ЧМИ.

Обзор решений SCADA.

Варианты реализации функций модификации прикладной программы без отключения контроллера (сохранения состояния выходов) и останова технологического процесса (в большинстве вариантов это не on-line модификация, как это заявляет изготовитель ПЛК):

Программируемый Логический Контроллер (ПЛК) для технологических процессов – разнообразие форм и размеров.

Из прошлой статьи:

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

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

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

Основные понятия РСУ (DSC), PLC (ПЛК), ESD (ПАЗ) и различие между ними.

Когда «молодой специалист» сталкивается с современной терминологией систем промышленной автоматизации, то такие термины как DCS, РСУ, PLC (ПЛК), ESD, SCADA, СБиПАЗ вызывают некоторое недоумение, так как объективно существует несоответствие между термином и оборудованием. А если послушать объяснение менеджеров-продавцов систем автоматизации или их компонентов, почитать форумы, путаницы становится еще больше.

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

Активно изучаем различные алгоритмы? Читаем про поиск k-ближайших соседей, задачу о рюкзаке, всякие алгоритмы сортировки, поиска и т. п.? А часто читаем примеры их практического внедрения на каком-нибудь предприятии? Такие истории встречаются реже, чем даже обзоры книг по этим же алгоритмам.

Предлагаю всем вместе начать исправлять эту ситуацию и приглашаю почитать о том, как на промышленном складе применяли — внезапно! — алгоритм Левенштейна (способ нечёткого сравнения строк).

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

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

Итак в вашем репозитории накопилось количество сборок превысившее число 1. Настало время задуматься о DevOps(е). Как же уследить за всеми этими сборками?

Классическое решение это запустить сервер сборки. Есть готовая технология, называется Jenkins.

Идея проста. Сервер сборки это инфраструктурный прикладной процесс, который периодически запускает скрипты построения конкретных программных проектов и затем сохраняет *.bin(ари) в конкретную папку или архив. Обычно сервер сборки работает автономно 24/7 и собирает артефакты из репозитория с кодом.

В этом тексте я написал инструкцию-методичку для разворачивания Jenkins на Windows компьютере.

Времена нынче суровые. Откуда «прилетит» непонятно, но то, что «прилетит», сомневаться уже не приходится. Вот оно и … «прилетело». В связи с определенными обстоятельствами (возможно, вы даже догадываетесь какими) предложено рассмотреть  переход с ПЛК фирмы Delta на ПЛК от Haiwell. Мы, как говорится, и не такое  переживали, а потому качаем среду проектирования HaiwellHappy и пытаемся ее освоить. Самих ПЛК, хотя они уже заказаны (?!),  пока нет, но есть симулятор. Но для начала этого вполне достаточно…   

Путь проторенный. А потому в целях обучения и одновременно внедрения технологии автоматного программирования создаем – что? - правильно, модель RS-триггера. Почему? – см. статью [1]. Но, если кратко, то триггер - это фактически мизерный проект, от которого пользы – ну, просто туча. В этом и предстоит далее убедиться.

Однако, смотрим, на что же позарились наши менеджеры?… Цена ПЛК – хорошая! Ну, то есть – относительно небольшая. Для нормального менеджера этого, видимо, уже достаточно. Но работать-то – программистам!  Ставим среду и создаем наш первый проект. Это, как уже было сказано, модель реального RS-триггера.

Оставим в стороне всякие мелочные придирки к среде проектирования (обсудим их по ходу), а приведем сразу код проекта. Благо он, как уже было тоже сказано, мизерный. Его внешний вид приведен на рис. 1.

Соловей!.. Ведь, слушайте, ведь вот пичуга! Ну, смотреть не на что!.. Ну, мелочь пузатая!.. А ведь как, подлец, природу украшал!.. Что делал, мерза­вец!.. Э-тю-тю-тю-тю-тю-тю, тю-тю-тю!..

Райкин А. Люди и манекены

Рассмотрим алгоритм, который заимствован из несложного проекта системы управления прессом. В сам проект вникать не будем, а рассмотрим лишь его небольшую и, пожалуй, самую простую часть – управление валками. На пульте управления есть кнопка «Валки» (на рис. 1 сигнал X6), при нажатии на которую посылается сигнал, который то прижимает, то отпускает валки. Преобразуем алгоритм управления валками в автоматную форму и посмотрим, что из этого получится.

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

Продолжаем расширять мой базовый курс работы с системой WinCC OA. На этот раз речь пойдет о драйвере Modbus TCP.

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

1. Автоматное программирование: определение, модель, реализация.

2. Вот, как просто! Автоматы в деле. Для ПЛК фирмы DELTA.

3. Автоматы в деле. Штабелер. Засады ПЛК.

Задание на проектирование программы

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

После нажатия кнопки «Сброс» (прокат останавливается, переходя в режим паузы) штабелер должен войти в режим паузы. Повторное нажатие кнопки выполняет реальный сброс системы управления. Продолжить прокат, находясь в ситуации паузы,  можно с помощью кнопки «Прокат». Штабелер, находясь в режиме «Автомат», может входить в тот же режим паузы, но после формирования текущего листа.   Работа штабелера в режиме системы «Полуавтомат» несколько отличается от работы в режиме «Автомат». В первом случае он останавливается после выполнения проката и ожидает срабатывания гильотины (в режиме «Полуавтомат» она запускается вручную). Дождавшись, он сбрасывает лист и перемещается в заключительную позицию. Из нее нажатием кнопки Штабелер «крыло» возвращается в исходное состояние. В режиме «Автомат» перемещение в заключительную позицию происходит только после выполнения задания.