Введение: зачем вообще нужен частотник

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

Частотный преобразователь (ЧП, частотник, VFD — Variable Frequency Drive, инвертор) решает эту проблему радикально: он плавно регулирует скорость электродвигателя, меняя частоту и напряжение питания. Насосу нужно меньше давления — он просто крутится медленнее. Результат: экономия электроэнергии 30–70%, меньше износ оборудования, мягкий пуск без ударных нагрузок.

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

Принцип работы: что происходит внутри

Понимание принципа работы — ключ к правильной настройке и диагностике. Внутри любого частотника три основных блока:

1. Выпрямитель (Rectifier)

Входное переменное напряжение (380В/50Гц) выпрямляется в постоянное. Используется трёхфазный диодный мост. На выходе получаем ~540В постоянного тока (380 × √2 ≈ 537В).

2. Звено постоянного тока (DC Bus)

Электролитические конденсаторы большой ёмкости сглаживают пульсации выпрямленного напряжения. Именно здесь хранится энергия рекуперации при торможении. Важно: после отключения питания конденсаторы остаются заряженными до 540В в течение нескольких минут. Всегда ждите разряда перед обслуживанием!

3. Инвертор (Inverter)

IGBT-транзисторы переключаются по алгоритму ШИМ (широтно-импульсная модуляция) с частотой 2–16 кГц, формируя синусоидальный ток нужной частоты и амплитуды. Именно здесь и происходит "магия" — создание переменного тока с произвольными параметрами.

Сеть 380В/50Гц → [Выпрямитель] → 540В DC → [Инвертор ШИМ] → Переменный ток 0-400Гц / 0-380В → Двигатель

Типы управления: скалярное vs векторное

Это первое принципиальное решение при настройке. Выбор не правильный — получите либо плохую динамику, либо нестабильную работу.

Скалярное управление (V/f = const)

Самый простой алгоритм: соотношение напряжения к частоте держится постоянным. Поднимаем частоту с 50Гц до 25Гц — напряжение тоже снижается вдвое (с 380В до 190В). Магнитный поток ротора остаётся примерно постоянным.

Когда использовать:

• Насосы и вентиляторы (вентиляторная нагрузка)

• Момент не нужен на малых скоростях

• Несколько двигателей на одном частотнике

• Простые конвейеры без точного позиционирования

Ограничения: При малых скоростях момент проседает. Нет контроля скорости под нагрузкой — при увеличении нагрузки двигатель чуть замедляется.

Векторное управление (Vector Control)

Алгоритм управляет не просто частотой и напряжением, а непосредственно вектором магнитного потока и моментом. Два варианта:

Без датчика скорости (Sensorless Vector): Математическая модель двигателя внутри частотника оценивает скорость ротора и момент. Требует настройки параметров двигателя (автотюнинг). Точность: ±0.5–2% от номинала.

С датчиком скорости (Closed Loop Vector): Энкодер на валу двигателя даёт точную информацию о скорости. Точность: ±0.01–0.1%. Используется в станках, намоточных машинах, лифтах.

Когда использовать векторное:

• Нужен полный момент при нулевой скорости (краны, экструдеры)

• Точное поддержание скорости под переменной нагрузкой

• Быстрая динамика разгона/торможения

• Один двигатель — один частотник

Выбор частотника: критерии и расчёт

Мощность

Главное правило: мощность частотника ≥ мощности двигателя. Для большинства применений выбирают одноступенчатое превышение по каталогу. Например, двигатель 11 кВт — берём частотник 11 кВт или 15 кВт.

Поправочные коэффициенты:

Ток

Номинальный ток частотника должен быть не меньше номинального тока двигателя с учётом пиковых нагрузок. Многие приводы имеют режим перегрузки 150% на 60 секунд или 200% на 3 секунды.

Серии популярных производителей

Бюджетный сегмент (учёба, простые задачи):

• Delta VFD-E, VFD-M — отличное соотношение цена/качество

• Hyundai N700E — популярны в России

• Веспер Е5 — отечественный производитель

Средний сегмент (промышленность):

• ABB ACS310, ACS550 — надёжные, хорошая документация

• Danfoss FC-051, FC-102 — особенно хороши для насосов

• Schneider Electric Altivar 312, 320

Высокий сегмент (серводрайвы, точное позиционирование):

• Siemens SINAMICS G120, S120

• ABB ACS880 — промышленный стандарт

• Yaskawa A1000, GA700

Подключение: схема и важные нюансы

Силовая часть

Сеть 3ф 380В
    |
[Автоматический выключатель] ← Защита от КЗ, НЕ защита от перегрузки!
    |
[Сетевой реактор] ← ОБЯЗАТЕЛЬНО при искажённой сети или мощности >15кВт
    |
[Частотник]
L1 L2 L3 — вход питания
PE      — заземление (обязательно!)
U V W   — выход на двигатель
    |
[Моторный дроссель] ← при кабеле >20м, защита от перенапряжений
    |
[Двигатель]

Критические ошибки подключения:

1. Никогда не подключайте выход ЧП к сети! U,V,W — только на двигатель.

2. Никогда не ставьте контактор между ЧП и двигателем без специальной схемы — IGBT умирает мгновенно.

3. Заземление обязательно — без него ЧП работает через паразитные ёмкости и сгорит от статики или помех.

4. Разделяйте силовые и сигнальные кабели — минимум 20–30 см между ними.

Управляющая часть

Типовое подключение аналогового задания скорости (0–10В):

ПЛК/потенциометр → AVI (Analog Voltage Input) — задание частоты
ПЛК/кнопка       → DI1 (Digital Input 1)     — команда ПУСК
ПЛК/кнопка       → DI2 (Digital Input 2)     — команда СТОП
ЧП → DO1 (Digital Output 1) → ПЛК            — сигнал "работает"
ЧП → DO2 (Digital Output 2) → ПЛК/лампа      — сигнал "авария"

Токовое задание (4–20мА) более помехоустойчиво для длинных кабелей. При 4мА = 0 об/мин, при 20мА = максимальные обороты. Потеря сигнала (обрыв кабеля) → 0мА → частотник видит это как аварию.

Основные параметры настройки

Каждый производитель имеет свои номера параметров, но логика везде одинакова. Покажем на примере логики настройки:

Группа 1: Параметры двигателя

Это самые важные параметры — частотник должен "знать" двигатель:

P_мощность   = 7.5 кВт    (с шильдика двигателя)
P_напряжение = 380 В
P_ток        = 15.5 А
P_частота    = 50 Гц
P_скорость   = 1440 об/мин (или 1450, 1460 — смотреть шильдик)
P_cos_phi    = 0.86

После ввода этих данных — обязательно запустите автотюнинг (Auto-tuning). Частотник сам измерит активное сопротивление обмоток, индуктивность и другие параметры. Занимает 30–120 секунд. Двигатель при этом либо неподвижен (статический тюнинг), либо вращается (динамический — точнее).

Группа 2: Ограничения

Мин. частота = 5–10 Гц    (ниже нельзя — перегрев двигателя)
Макс. частота = 50–60 Гц  (можно выше, но нужен расчёт подшипников)
Макс. ток     = 110–120% от номинала двигателя

Группа 3: Разгон и торможение

Время разгона  = 5–30 с    (чем тяжелее механизм — тем больше)
Время торможения = 5–30 с
Тип кривой    = S-образная (плавнее для конвейеров, насосов)

Слишком короткое время торможения → ошибка OV (перенапряжение в звене DC) → нужен тормозной резистор или увеличить время.

Группа 4: Источник задания и управление

Источник задания частоты: аналог 0–10В / 4–20мА / цифровые входы / Modbus
Источник команды пуск/стоп: цифровые входы / пульт / Modbus
Режим управления: скалярный / векторный без датчика / с датчиком

ПИД-регулятор в частотнике

Большинство современных ЧП имеют встроенный ПИД-регулятор. Это позволяет строить замкнутую систему управления без внешнего контроллера.

Типичный пример: насос с поддержанием давления

Датчик давления (4–20мА) → Вход обратной связи ЧП
Уставка давления         → Задание (аналог или цифровое значение)
Выход ПИД               → Управляет частотой насоса

Настройка ПИД (упрощённый метод Циглера-Николса):

1. Установить I=0, D=0, поднимать P до возникновения устойчивых колебаний

2. Записать критический коэффициент Kc и период колебаний Tc

3. P = 0.6×Kc, I = 2×Tc, D = Tc/8

Для насосов и вентиляторов (инерционная нагрузка) типичные значения:

• P (пропорциональная составляющая): 20–50%

• I (интегральная): 2–10 секунд

• D (дифференциальная): 0–1 секунда (часто не нужна)

Важно: Включите функцию Sleep/Wake — при малом потреблении (ночное время) насос останавливается, при снижении давления — запускается. Экономия 15–30% электроэнергии.

Защитные функции и их настройка

Современный частотник — это не просто регулятор, это полноценная система защиты двигателя и механизма.

Тепловая защита двигателя (Motor Thermal Protection)

Электронный тепловой реле внутри ЧП моделирует нагрев двигателя на основе тока и времени. Задаётся номинальный ток двигателя (I_nom) и тепловая постоянная времени (обычно 30–600 секунд). Гораздо точнее биметаллических реле — учитывает режим работы.

Защита от перенапряжения (OV — Over Voltage)

Срабатывает когда напряжение в звене DC превышает порог (~800В для 380В-сетей). Причины: резкое торможение (обратная ЭДС двигателя), выброс в сети. Решения: увеличить время торможения, поставить тормозной резистор, включить функцию "регулирование торможения по напряжению DC".

Защита от перегрузки (OC — Over Current)

Ток превысил допустимый предел. Причины: механическое заклинивание, слишком короткое время разгона, неправильно введены параметры двигателя. Никогда не повышайте порог защиты бездумно — это приведёт к перегреву или сгоранию двигателя.

Потеря фазы (Input/Output Phase Loss)

Отсутствует одна из фаз входного питания или обрыв в кабеле до двигателя. Критически важная защита — трёхфазный двигатель на двух фазах перегревается за секунды.

Коммуникация: Modbus RTU на практике

Почти все промышленные частотники поддерживают Modbus RTU через RS-485. Это позволяет управлять приводом с ПЛК или SCADA без аналоговых сигналов.

Типичные Modbus-регистры (адреса условные, смотрите документацию вашего ЧП):

Пример управления через Python (для тестирования и прототипирования):

import minimalmodbus
import time

# Настройка соединения
vfd = minimalmodbus.Instrument('/dev/ttyUSB0', 1)  # COM-порт, адрес устройства = 1
vfd.serial.baudrate = 9600
vfd.serial.bytesize = 8
vfd.serial.parity   = 'N'
vfd.serial.stopbits = 1
vfd.serial.timeout  = 0.5
vfd.mode = minimalmodbus.MODE_RTU

def vfd_start():
    """Команда ПУСК вперёд"""
    vfd.write_register(0x2000, 0x0002, functioncode=6)  # Control word: Run Forward

def vfd_stop():
    """Команда СТОП (свободный выбег)"""
    vfd.write_register(0x2000, 0x0001, functioncode=6)  # Control word: Stop

def vfd_set_freq(freq_hz: float):
    """Задать частоту в Гц (0.0 - 50.0)"""
    value = int(freq_hz * 100)  # Например 50.0 Гц → 5000
    vfd.write_register(0x2001, value, functioncode=6)

def vfd_get_status() -> dict:
    """Считать текущее состояние"""
    status_word = vfd.read_register(0x2100, functioncode=3)
    freq        = vfd.read_register(0x2101, functioncode=3) / 100.0
    current     = vfd.read_register(0x2102, functioncode=3) / 10.0
    voltage_dc  = vfd.read_register(0x2103, functioncode=3)
    
    return {
        'running':   bool(status_word & 0x0001),
        'fault':     bool(status_word & 0x0008),
        'frequency': freq,
        'current':   current,
        'dc_voltage': voltage_dc
    }

# Пример использования
try:
    print("Запуск двигателя...")
    vfd_set_freq(30.0)  # Задаём 30 Гц
    vfd_start()
    
    for i in range(10):
        time.sleep(2)
        status = vfd_get_status()
        print(f"Частота: {status['frequency']} Гц, Ток: {status['current']} А")
        
        if status['fault']:
            print("АВАРИЯ! Проверьте частотник.")
            break
    
    print("Остановка...")
    vfd_stop()

except Exception as e:
    print(f"Ошибка связи: {e}")

Типичные аварии и их устранение

F001 / OC — Сверхток при пуске

Симптомы: Ошибка возникает сразу при подаче команды пуск или в первые секунды разгона.

Причины и решения:

• Слишком короткое время разгона → Увеличить в 2–3 раза

• Механическое заклинивание → Проверить механику, проворачивается ли вал вручную

• КЗ в кабеле или обмотках → Мегомметром проверить изоляцию кабеля (500В) и двигателя

• Неверные параметры двигателя → Перепроверить ток, мощность, cos_phi

• Включён режим векторного управления без автотюнинга → Запустить автотюнинг

F002 / OV — Перенапряжение в DC-шине

Симптомы: Ошибка при торможении или при резком снижении нагрузки.

Причины и решения:

• Слишком короткое время торможения → Увеличить время

• Нет тормозного резистора при большом маховике → Установить резистор

• Высокое напряжение сети (>415В) → Проверить сеть, возможно нужен трансформатор

• Включить функцию "Voltage regulation during deceleration" — ЧП сам замедляет торможение

F003 / OH — Перегрев

Симптомы: После длительной работы или в жаркую погоду.

Причины и решения:

• Загрязнён радиатор → Очистить сжатым воздухом (не водой!)

• Сломан вентилятор охлаждения → Заменить

• Недостаточно места для вентиляции → Минимум 10 см сверху и снизу

• Температура в шкафу >40°C → Добавить принудительную вентиляцию шкафа

• Слишком высокая частота ШИМ → Снизить с 8кГц до 4кГц (будет чуть громче, но прохладнее)

F004 / LV — Пониженное напряжение

Симптомы: При просадке сети или при запуске мощного оборудования рядом.

Решения:

• Проверить напряжение сети мультиметром под нагрузкой

• Установить сетевой реактор — сглаживает просадки

• Настроить время повторного пуска после восстановления питания (Auto-restart)

Энергосбережение: реальные цифры

Закон куба: мощность вентилятора/насоса пропорциональна кубу скорости. Снизили скорость на 20% → потребление упало на 49%!

P2/P1 = (n2/n1)³

При n1 = 50 Гц, n2 = 40 Гц (снижение на 20%):
P2/P1 = (40/50)³ = 0.512 → экономия 48.8%!

Реальный пример из практики: вентилятор системы вентиляции цеха, 55 кВт, работал 24/7 на 50 Гц. После установки частотника с датчиком CO2 и ПИД-регулятором:

• Среднесуточная частота работы: 35–40 Гц

• Фактическое потребление: снизилось с 55 кВт до 22–28 кВт

• Годовая экономия: ~250 000 кВт·ч

• При тарифе 6 руб/кВт·ч: 1 500 000 руб/год

• Стоимость частотника 55 кВт: ~180 000 руб

• Срок окупаемости: 6 недель

Чек-лист при вводе в эксплуатацию

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

□ Напряжение питания соответствует номиналу ЧП (380В ±10%)
□ Заземление подключено и проверено (<4 Ом)
□ Кабели L1-L2-L3 и U-V-W не перепутаны местами
□ Нет КЗ между фазами и на землю (мегомметром)
□ Введены параметры двигателя (шильдик)
□ Проведён автотюнинг
□ Настроены ограничения: мин/макс частота, макс ток
□ Настроены времена разгона/торможения
□ Проверена правильность направления вращения (на малой скорости 5–10 Гц)
□ Настроены аварийные выходы и тестирована их реакция
□ Записаны все изменённые параметры в документацию

Заключение

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

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

Изучите документацию на ваш конкретный привод — производители вкладывают в неё годы опыта тысяч инсталляций. Это лучший источник правильных решений для конкретного устройства.

Что такое ПЛК и почему это не просто "мощный Arduino"

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

Когда на производстве нужно, чтобы насос включился строго через 50 мс после срабатывания датчика — это ПЛК. Когда допустима задержка в секунду — можно обойтись более дешёвыми решениями. Когда вопрос в надёжности и работе в условиях вибраций, пыли, температур от -40 до +70°C — снова ПЛК.

Другие ключевые отличия:

• Цикличность: программа выполняется повторяющимися циклами (обычно 1–100 мс). Каждый цикл: считать все входы → выполнить программу → записать все выходы

• Гальваническая развязка входов/выходов: промышленные сигналы (24В DC, 220В AC) изолированы от внутренней логики

• Горячая замена модулей: во многих системах можно менять I/O-модули без остановки контроллера

• Встроенная диагностика: ПЛК сам следит за собственным здоровьем

Архитектура ПЛК: как это устроено

Центральный процессорный модуль (CPU)

Выполняет программу, управляет обменом данных, содержит основную память. В S7-1200 CPU также имеет встроенные входы/выходы, Ethernet порт и возможность расширения.

Модули ввода-вывода (I/O Modules)

Дискретные входы (DI): Воспринимают сигналы "есть напряжение / нет напряжения". Обычно 24В DC или 220В AC. Примеры источников: кнопки, концевые выключатели, датчики приближения (индуктивные, ёмкостные), фотодатчики, реле.

Дискретные выходы (DO): Управляют исполнительными устройствами. Бывают транзисторные (24В DC, быстрые) и релейные (любое напряжение до 250В AC, медленные, но универсальные).

Аналоговые входы (AI): Принимают непрерывные сигналы: 4–20мА, 0–10В, термопары (тип K, J, T...), термосопротивления (Pt100, Pt1000). Преобразуют в число (обычно 0–27648 для диапазона 0–100%).

Аналоговые выходы (AO): Выдают аналоговые сигналы для управления частотниками, регулирующими клапанами, позиционерами.

Память ПЛК (на примере Siemens)

Стандарт МЭК 61131-3: пять языков программирования

Международный стандарт определяет пять языков для ПЛК. Хороший инженер знает минимум два-три.

1. Ladder Diagram (LD) — Релейно-контактная схема

Исторически первый язык — имитация схем из физических реле. Читается слева направо, как электрическая цепь. Левая шина — "фаза", правая — "ноль". Ток "течёт" если путь замкнут.

         I0.0        I0.1        Q0.0
Пуск     Стоп (НЗ)   Выход насос
 ──┤ ├────┤/├──────────( )──
   
   Q0.0    (самоподхват)
 ──┤ ├──

Эта схема — классика: кнопка ПУСК (I0.0) запускает насос (Q0.0), контакт самоподхвата удерживает его включённым, кнопка СТОП (I0.1, нормально-закрытый) его отключает.

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

Недостатки: Громоздкий для сложных вычислений и работы с данными.

2. Function Block Diagram (FBD) — Диаграмма функциональных блоков

Программа строится из готовых блоков (AND, OR, NOT, таймеры, счётчики, ПИД-регуляторы), соединённых сигнальными линиями. Хорошо подходит для управления потоками сигналов.

I0.0 ──┐
       ├──[AND]──── Q0.0
I0.1 ──┘

3. Structured Text (ST) — Структурированный текст

Язык высокого уровня, похожий на Pascal/Ada. Самый мощный для математических вычислений, работы с массивами, строками.

(* Программа управления насосом с ПИД *)
IF Start AND NOT Stop THEN
    Running := TRUE;
END_IF;

IF Stop THEN
    Running := FALSE;
END_IF;

(* Расчёт ПИД *)
IF Running THEN
    Error    := Setpoint - Feedback;
    Integral := Integral + Error * CycleTime;
    Integral := LIMIT(-100.0, Integral, 100.0); (* Ограничение интеграла *)
    
    Output := Kp * Error + Ki * Integral + Kd * (Error - PrevError) / CycleTime;
    Output := LIMIT(0.0, Output, 100.0);
    
    PrevError := Error;
ELSE
    Output   := 0.0;
    Integral := 0.0;
END_IF;

4. Instruction List (IL) — Список инструкций

Ассемблер для ПЛК. Устаревший язык, в новом стандарте МЭК 61131-3 третьей редакции официально deprecated. Знать необязательно.

5. Sequential Function Chart (SFC) — Диаграмма последовательных функций

Похоже на блок-схему или граф состояний. Идеален для описания технологических последовательностей: шаг 1 → условие перехода → шаг 2 → условие → шаг 3...

Реальный проект: управление насосной станцией

Разберём полноценный пример — система управления двумя насосами с чередованием и защитами.

Техническое задание:

• 2 насоса, работают поочерёдно для равномерного износа

• Автоматическое включение второго при отказе первого

• Защита от сухого хода (датчик уровня)

• Защита от давления (реле давления)

• Ручной/автоматический режим

• Счётчик моточасов каждого насоса

Распределение входов/выходов:

ВХОДЫ:
I0.0 — Кнопка ПУСК (автоматический режим)
I0.1 — Кнопка СТОП
I0.2 — Переключатель Авт/Ручной
I0.3 — Датчик уровня (нижний предел — сухой ход)
I0.4 — Датчик уровня (верхний предел — бак полон)
I0.5 — Реле давления насос 1 (авария — нет давления)
I0.6 — Реле давления насос 2
I0.7 — Тепловое реле насос 1 (перегрев)
I1.0 — Тепловое реле насос 2
I1.1 — Ручное управление насос 1 (в ручном режиме)
I1.2 — Ручное управление насос 2

ВЫХОДЫ:
Q0.0 — Контактор насос 1
Q0.1 — Контактор насос 2
Q0.2 — Лампа "Работа авто"
Q0.3 — Лампа "Авария"
Q0.4 — Сирена (авария критическая)

Программа на Structured Text (ST):

PROGRAM PumpStation

(* ===== ПЕРЕМЕННЫЕ ===== *)
VAR
    // Входы
    btnStart         AT %I0.0 : BOOL;
    btnStop          AT %I0.1 : BOOL;
    swAutoManual     AT %I0.2 : BOOL;  // TRUE = авто
    snsLevelLow      AT %I0.3 : BOOL;  // TRUE = уровень низкий (авария)
    snsLevelHigh     AT %I0.4 : BOOL;  // TRUE = бак полон
    relPressure1     AT %I0.5 : BOOL;  // FALSE = нет давления (авария)
    relPressure2     AT %I0.6 : BOOL;
    thmRelay1        AT %I0.7 : BOOL;  // TRUE = перегрев (авария)
    thmRelay2        AT %I1.0 : BOOL;
    btnPump1Manual   AT %I1.1 : BOOL;
    btnPump2Manual   AT %I1.2 : BOOL;
    
    // Выходы
    outPump1         AT %Q0.0 : BOOL;
    outPump2         AT %Q0.1 : BOOL;
    lampAutoRun      AT %Q0.2 : BOOL;
    lampFault        AT %Q0.3 : BOOL;
    siren            AT %Q0.4 : BOOL;
    
    // Внутренние переменные
    SystemRun        : BOOL := FALSE;
    ActivePump       : INT  := 1;      // Какой насос сейчас основной
    Fault            : BOOL := FALSE;
    FaultCode        : INT  := 0;
    Pump1Fault       : BOOL := FALSE;
    Pump2Fault       : BOOL := FALSE;
    
    // Таймеры
    TimerPumpStart   : TON;            // Задержка пуска насоса
    TimerRotation    : TON;            // Таймер чередования (8 часов)
    TimerAlarmDelay  : TON;            // Задержка подтверждения аварии
    
    // Счётчики моточасов
    Hours_Pump1      : DINT := 0;
    Hours_Pump2      : DINT := 0;
    TimerH_Pump1     : TON;
    TimerH_Pump2     : TON;
END_VAR

(* ===== ЛОГИКА АВАРИЙ ===== *)
// Авария сухого хода — критическая, немедленная остановка
IF snsLevelLow THEN
    Fault     := TRUE;
    FaultCode := 1;  // Сухой ход
    SystemRun := FALSE;
END_IF;

// Задержанные аварии давления (3 секунды для исключения ложных срабатываний)
TimerAlarmDelay(IN := (outPump1 AND NOT relPressure1) OR
                       (outPump2 AND NOT relPressure2),
                PT := T#3S);

IF TimerAlarmDelay.Q THEN
    IF outPump1 AND NOT relPressure1 THEN
        Pump1Fault := TRUE;
        FaultCode  := 2;  // Нет давления насос 1
    END_IF;
    IF outPump2 AND NOT relPressure2 THEN
        Pump2Fault := TRUE;
        FaultCode  := 3;  // Нет давления насос 2
    END_IF;
END_IF;

// Тепловая защита
IF thmRelay1 THEN
    Pump1Fault := TRUE;
    FaultCode  := 4;  // Перегрев насос 1
END_IF;
IF thmRelay2 THEN
    Pump2Fault := TRUE;
    FaultCode  := 5;  // Перегрев насос 2
END_IF;

// Оба насоса в аварии
IF Pump1Fault AND Pump2Fault THEN
    Fault     := TRUE;
    SystemRun := FALSE;
END_IF;

(* ===== КОМАНДЫ ПУСК/СТОП ===== *)
IF btnStart AND NOT Fault THEN
    SystemRun := TRUE;
END_IF;

IF btnStop OR snsLevelHigh THEN  // Стоп или бак полон
    SystemRun := FALSE;
END_IF;

// Квитирование аварии (нажать СТОП для сброса)
IF btnStop THEN
    Fault      := FALSE;
    FaultCode  := 0;
    Pump1Fault := FALSE;
    Pump2Fault := FALSE;
END_IF;

(* ===== АВТОМАТИЧЕСКИЙ РЕЖИМ ===== *)
IF swAutoManual AND SystemRun THEN
    
    // Чередование каждые 8 часов
    TimerRotation(IN := SystemRun, PT := T#28800S);  // 8 часов = 28800 секунд
    IF TimerRotation.Q THEN
        IF ActivePump = 1 THEN
            ActivePump := 2;
        ELSE
            ActivePump := 1;
        END_IF;
        TimerRotation(IN := FALSE);  // Сброс таймера
        TimerRotation(IN := TRUE);
    END_IF;
    
    // При аварии основного насоса — переключаемся на резервный
    IF ActivePump = 1 AND Pump1Fault AND NOT Pump2Fault THEN
        ActivePump := 2;
    ELSIF ActivePump = 2 AND Pump2Fault AND NOT Pump1Fault THEN
        ActivePump := 1;
    END_IF;
    
    // Задержка пуска 1 секунда (защита от дребезга)
    TimerPumpStart(IN := SystemRun, PT := T#1S);
    
    outPump1 := TimerPumpStart.Q AND (ActivePump = 1) AND NOT Pump1Fault;
    outPump2 := TimerPumpStart.Q AND (ActivePump = 2) AND NOT Pump2Fault;

(* ===== РУЧНОЙ РЕЖИМ ===== *)
ELSIF NOT swAutoManual THEN
    outPump1 := btnPump1Manual AND NOT Pump1Fault;
    outPump2 := btnPump2Manual AND NOT Pump2Fault;
    
ELSE
    outPump1 := FALSE;
    outPump2 := FALSE;
END_IF;

(* ===== СЧЁТЧИКИ МОТОЧАСОВ ===== *)
TimerH_Pump1(IN := outPump1, PT := T#1S);
IF TimerH_Pump1.Q THEN
    Hours_Pump1 := Hours_Pump1 + 1;
    TimerH_Pump1(IN := FALSE);
    TimerH_Pump1(IN := TRUE);
END_IF;

TimerH_Pump2(IN := outPump2, PT := T#1S);
IF TimerH_Pump2.Q THEN
    Hours_Pump2 := Hours_Pump2 + 1;
END_IF;

(* ===== ИНДИКАЦИЯ ===== *)
lampAutoRun := SystemRun AND swAutoManual;
lampFault   := Fault OR Pump1Fault OR Pump2Fault;
siren       := Fault;  // Сирена только при критической аварии

END_PROGRAM

Таймеры и счётчики: подробно

Таймеры и счётчики — основа любой программы ПЛК. В стандарте МЭК 61131-3 они реализованы как функциональные блоки.

Типы таймеров

TON (Timer On Delay) — таймер с задержкой включения:

TimerFan(IN := MotorRun, PT := T#5S);
// Q становится TRUE через 5 секунд после включения MotorRun
FanStart := TimerFan.Q;

TOF (Timer Off Delay) — таймер с задержкой выключения:

TimerFan(IN := MotorRun, PT := T#30S);
// Q остаётся TRUE ещё 30 секунд после выключения MotorRun
// Используется для дополнительного охлаждения после остановки
FanRun := TimerFan.Q;

TP (Timer Pulse) — таймер импульса:

TimerBuzzer(IN := AlarmNew, PT := T#2S);
// При фронте AlarmNew генерирует импульс 2 секунды
// Независимо от того, сколько ещё держится AlarmNew
Buzzer := TimerBuzzer.Q;

Счётчики

CTU (Count Up) — счётчик вперёд:

CounterBottles(CU := BottleSensor, R := ResetButton, PV := 100);
// Считает бутылки, при достижении 100 — Q=TRUE
BatchComplete := CounterBottles.Q;
CurrentCount  := CounterBottles.CV;  // Текущее значение

CTD (Count Down) — счётчик назад:

CounterProducts(CD := ProductSensor, LD := LoadButton,
                PV := OrderQty);  // PV загружается при LD=TRUE
OrderComplete := CounterProducts.Q;  // Q=TRUE когда CV=0

Работа с аналоговыми сигналами

Масштабирование аналогового входа

Аналоговый модуль S7-1200 возвращает значение 0–27648 для диапазона 0–100% входного сигнала (4–20мА или 0–10В). Для получения реального значения нужно масштабирование:

FUNCTION_BLOCK ScaleAnalog
VAR_INPUT
    RawValue    : INT;    // Сырое значение от АЦП (0..27648)
    RawMin      : INT;    // Мин значение АЦП (обычно 0 или 5530 для 4мА)
    RawMax      : INT;    // Макс значение АЦП (обычно 27648)
    PhysMin     : REAL;   // Физический минимум (например, 0.0 бар)
    PhysMax     : REAL;   // Физический максимум (например, 16.0 бар)
END_VAR
VAR_OUTPUT
    PhysValue   : REAL;   // Результат в физических единицах
    Broken      : BOOL;   // Обрыв линии (значение ниже 4мА)
END_VAR

// Проверка обрыва линии (для 4-20мА: ниже ~5% = обрыв)
Broken := (RawValue < (RawMin - 1000));

IF NOT Broken THEN
    // Линейное масштабирование
    PhysValue := PhysMin + (REAL(RawValue - RawMin) / REAL(RawMax - RawMin))
                           * (PhysMax - PhysMin);
    // Ограничение выхода
    PhysValue := MAX(PhysMin, MIN(PhysMax, PhysValue));
ELSE
    PhysValue := PhysMin;  // При обрыве — безопасное значение
END_IF;

END_FUNCTION_BLOCK

Использование:

// Датчик давления 4-20мА, диапазон 0-16 бар
PressureSensor(
    RawValue := %IW64,      // Адрес аналогового входа
    RawMin   := 5530,       // 4мА соответствует 5530
    RawMax   := 27648,      // 20мА соответствует 27648
    PhysMin  := 0.0,
    PhysMax  := 16.0
);

Pressure       := PressureSensor.PhysValue;  // Давление в барах
PressureAlarm  := PressureSensor.Broken;     // Авария обрыва линии

IF Pressure > 12.0 THEN
    HighPressureAlarm := TRUE;
END_IF;

Организационные блоки и структура программы

Профессиональная программа ПЛК разделена на функциональные блоки:

Организация в TIA Portal (Siemens):

OB1 (Main) — Главный цикл
├── FC10: ReadInputs         — Чтение и нормализация входов
├── FC20: SafetyLogic        — Приоритетные защиты (всегда первыми!)
├── FB30: PumpControl [DB30] — Управление насосами (с памятью)
├── FB40: PIDControl [DB40]  — ПИД-регулятор
├── FC50: WriteOutputs       — Запись выходов
└── FC60: Diagnostics        — Диагностика и коммуникации

OB35 (Cyclic Interrupt, 10ms) — Быстрые задачи
└── FB35: FastCounter        — Высокоскоростной счётчик

OB82 (I/O Error) — Обработка ошибок I/O-модулей

OB121 (Programming Error) — Обработка ошибок программы

Принцип: защиты и аварии — всегда в начале главного цикла. Они должны отработать независимо от состояния остальной программы.

Отладка и диагностика программы

Онлайн-мониторинг

В TIA Portal при подключении к ПЛК все блоки отображают реальные значения переменных. В Ladder Diagram активные цепи подсвечиваются зелёным — мгновенно видно что работает.

Форсирование переменных (Force)

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

Трассировка

Запись значений переменных в реальном времени с временной меткой. Незаменима для поиска редко возникающих ошибок — включаете запись и ждёте появления проблемы.

Типичные ошибки начинающих:

1. Использование выходных катушек несколько раз в Ladder

НЕПРАВИЛЬНО:
Цепь 1: I0.0 → Q0.0 (катушка)
Цепь 2: I0.1 → Q0.0 (катушка снова!)

Вторая катушка перезаписывает первую. Результат Q0.0 определяется только второй цепью.

ПРАВИЛЬНО:
Цепь 1: I0.0 ──┐
               ├── Q0.0
Цепь 2: I0.1 ──┘

2. Гонка состояний при SET/RESET

// ОПАСНО: порядок операций важен
IF Condition1 THEN  SET(Coil);    END_IF;
IF Condition2 THEN  RESET(Coil);  END_IF;
// Если оба условия TRUE — RESET побеждает (последний)
// Убедитесь, что это желаемое поведение!

3. Деление на ноль

// ВСЕГДА проверяйте делитель
IF Denominator <> 0.0 THEN
    Result := Numerator / Denominator;
ELSE
    Result := 0.0;  // Безопасное значение
END_IF;

Коммуникация ПЛК с внешним миром

Modbus TCP (через Ethernet)

Большинство современных ПЛК поддерживают Modbus TCP "из коробки". Это самый распространённый протокол для связи с SCADA, HMI и частотниками.

В S7-1200 для Modbus TCP используются системные функциональные блоки:

• MB_CLIENT — ПЛК как Modbus-мастер (опрашивает устройства)

• MB_SERVER — ПЛК как Modbus-сервер (отвечает на запросы SCADA)

OPC UA

Современный открытый протокол для промышленной коммуникации. Поддерживает семантику данных, безопасность, публикацию/подписку. Все серьёзные ПЛК последних поколений имеют встроенный OPC UA сервер.

PROFINET/EtherCAT

Промышленные реальном-временные сети. PROFINET — стандарт Siemens и Profibus International. EtherCAT — от Beckhoff, исключительно быстрый (цикл 250 мкс). Используются для связи с распределёнными I/O-модулями, сервоприводами, vision-системами.

Советы по надёжности программы

1. Всегда инициализируйте переменные — не полагайтесь на "нулевое" начальное значение

2. Используйте watchdog-таймер — если программа "зависла", таймер переводит выходы в безопасное состояние

3. Документируйте каждую переменную — через полгода вы забудете что значит переменная b47

4. Разделяйте задачи по функциональным блокам — один блок = одна задача

5. Тестируйте на симуляторе перед загрузкой в реальный ПЛК

6. Делайте резервные копии программы перед каждым изменением — версионирование спасало многих

7. Стандартизируйте именование: btnStart — кнопка, snsLevel — датчик, outPump — выход, tmrDelay — таймер

Заключение

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

Начните с Ladder Diagram — он прозрачен и хорошо отлаживается онлайн. Освойте Structured Text для сложных вычислений. Используйте SFC для технологических последовательностей. И всегда: сначала безопасность, потом функциональность.

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

Почему Modbus жив и актуален спустя 45 лет

Modbus был разработан компанией Modicon в 1979 году для связи ПЛК по последовательной шине. Прошло почти полвека — а протокол по-прежнему является самым распространённым в промышленной автоматизации. По различным оценкам, более 30 миллионов устройств в мире используют Modbus.

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

Сегодня существуют три основные реализации:

• Modbus RTU — по последовательной шине (RS-232, RS-485)

• Modbus ASCII — текстовое представление, устарело

• Modbus TCP — поверх TCP/IP Ethernet

Архитектура: мастер и слейвы

Modbus — строго мастер-слейв (Master-Slave) протокол:

• Мастер (Master): Инициирует все запросы. Только один мастер в сети. Обычно это ПЛК, SCADA-сервер, промышленный компьютер.

• Слейв (Slave): Отвечает на запросы мастера. В сети RS-485 может быть до 247 слейвов с адресами 1–247. Адрес 0 — широковещательный (слейвы не отвечают).

Важно: Слейв никогда не инициирует передачу! Он только отвечает.

Мастер                    Слейв 1    Слейв 2   Слейв 3
  |                          |          |          |
  |── Request → Addr=1 ─────>|          |          |
  |<── Response ────────────|          |          |
  |                          |          |          |
  |── Request → Addr=2 ──────────────>|           |
  |<── Response ──────────────────────|           |

Типы данных (регистры)

Modbus оперирует четырьмя типами данных:

1. Coils (Coil Status) — Дискретные выходы

• Размер: 1 бит

• Доступ: Чтение и запись мастером

• Функциональные коды: FC01 (читать), FC05 (записать один), FC15 (записать несколько)

• Адреса: 00001–09999 (в Modbus-нотации), 0x0000–0xFFFF (в PDU)

• Применение: Состояния реле, клапанов, двигателей

2. Discrete Inputs (Input Status) — Дискретные входы

• Размер: 1 бит

• Доступ: Только чтение мастером (данные поступают от физических входов)

• Функциональные коды: FC02 (читать)

• Адреса: 10001–19999

• Применение: Состояния кнопок, датчиков, концевиков

3. Holding Registers — Регистры хранения

• Размер: 16 бит (2 байта), беззнаковое целое 0–65535

• Доступ: Чтение и запись мастером

• Функциональные коды: FC03 (читать), FC06 (записать один), FC16 (записать несколько)

• Адреса: 40001–49999

• Применение: Уставки, параметры настройки, команды управления

4. Input Registers — Входные регистры

• Размер: 16 бит

• Доступ: Только чтение мастером

• Функциональные коды: FC04 (читать)

• Адреса: 30001–39999

• Применение: Измеренные значения датчиков, счётчики

Хранение чисел с плавающей точкой

16 бит для float недостаточно. Для передачи float используют два последовательных регистра (32 бит = IEEE 754):

Регистр 40001 (HIGH word): первые 16 бит float
Регистр 40002 (LOW word):  вторые 16 бит float

Значение 3.14159:
IEEE 754: 0x40490FDB
HIGH: 0x4049
LOW:  0x0FDB

Важная ловушка: порядок байт и слов (endianness) различается у разных производителей! Четыре варианта: Big-Endian, Little-Endian, Big-Endian Byte Swap, Little-Endian Byte Swap. Смотрите документацию устройства.

Modbus RTU: структура фрейма

RTU (Remote Terminal Unit) — бинарный формат, максимально компактный.

┌─────────┬──────────────┬──────┬────────────────────┬───────┐
│ Address │ Function Code│ Data │        Data        │  CRC  │
│  1 байт │    1 байт    │  ... │        ...         │ 2 байт│
└─────────┴──────────────┴──────┴────────────────────┴───────┘

Пример запроса FC03 (читать Holding Registers):

Запрос: "Слейв №1, дай мне 2 регистра начиная с адреса 0x0064 (100)"

01 03 00 64 00 02 85 D5

01    — Адрес слейва
03    — Код функции (читать Holding Registers)
00 64 — Начальный адрес (0x0064 = 100)
00 02 — Количество регистров (2)
85 D5 — CRC16 (контрольная сумма)

Ответ слейва:

01 03 04 01 F4 00 0A 2B 11

01    — Адрес слейва
03    — Код функции
04    — Количество байт данных (2 регистра × 2 байта = 4)
01 F4 — Значение регистра 100 (0x01F4 = 500)
00 0A — Значение регистра 101 (0x000A = 10)
2B 11 — CRC16

Ответ при ошибке (Exception Response):

01 83 02 C0 F1

01    — Адрес слейва
83    — Код функции + 0x80 (признак ошибки)
02    — Код исключения (02 = Illegal Data Address)
C0 F1 — CRC16

Коды исключений:

Расчёт CRC16

CRC16 (Cyclic Redundancy Check) — контрольная сумма для обнаружения ошибок передачи. Алгоритм несложный, но важный:

uint16_t ModbusCRC16(uint8_t *buffer, uint16_t length)
{
    uint16_t crc = 0xFFFF;
    
    for (uint16_t i = 0; i < length; i++) {
        crc ^= (uint16_t)buffer[i];
        
        for (uint8_t j = 0; j < 8; j++) {
            if (crc & 0x0001) {
                crc >>= 1;
                crc ^= 0xA001;  // Полином Modbus
            } else {
                crc >>= 1;
            }
        }
    }
    
    return crc;  // Младший байт первый в фрейме!
}

// Использование:
uint8_t frame[] = {0x01, 0x03, 0x00, 0x64, 0x00, 0x02};
uint16_t crc = ModbusCRC16(frame, 6);
// Добавить в конец фрейма: (crc & 0xFF), (crc >> 8)

Важно: В Modbus RTU CRC передаётся младшим байтом вперёд (Little-Endian)!

RS-485: физический уровень

Modbus RTU работает поверх RS-485 — дифференциальной последовательной шины.

Параметры сети:

• Длина: до 1200 м (при скорости 9600 бод), до 100 м (при 115200 бод)

• Устройств: до 32 без репитеров, до 247 с репитерами

• Скорости: 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 бод

• Линия: витая пара, лучше экранированная (STP)

• Терминаторы: 120 Ом на каждом конце шины

Топология — только шина!

Мастер ──────┬──────────┬──────────┬──────── Терминатор 120Ом
    120Ом ───┘  Слейв1   Слейв2    Слейв3

НЕЛЬЗЯ делать "звезду" — отражения сигнала разрушат связь.

Типичные проблемы RS-485:

Проблема 1: Нет терминирующих резисторов Симптомы: связь работает на малой скорости, не работает на высокой. Или работает с одним устройством, не работает с несколькими. Решение: 120 Ом строго на двух концах шины — и только там.

Проблема 2: Земля не подключена RS-485 — дифференциальный сигнал (A-B), не требует общего провода теоретически. Практически — без общей земли при большой разнице потенциалов (грозозащита, разные здания) трансиверы сгорают. Третий провод "GND" обязателен.

Проблема 3: Смешаны A и B Сигнальные линии перепутаны местами. Ошибка типичная при ручном монтаже. Симптом: нет ответа вообще или постоянные ошибки CRC.

Проблема 4: Нет pull-up/pull-down резисторов на линии Когда все устройства молчат (пауза между транзакциями), линия "висит в воздухе". Нужны подтягивающие резисторы: A через ~560 Ом на +5В, B через ~560 Ом на GND. Многие USB-RS485 адаптеры имеют их встроенными.

Modbus TCP: Ethernet-версия

Modbus TCP — это Modbus RTU без адреса устройства и без CRC, завёрнутый в TCP/IP пакет.

Структура Modbus TCP фрейма:

┌─────────────┬──────────────────────────────────────────────┐
│  MBAP Header (7 байт)  │    PDU (Protocol Data Unit)       │
├──────┬───────┬──────────┬───────┬──────────────────────────┤
│TrID  │ Proto │  Length  │ UnitID│ FC  │      Data          │
│2 байт│ 2 байт│  2 байта │ 1 байт│1 байт│    N байт         │
└──────┴───────┴──────────┴───────┴──────┴──────────────────┘

TrID   — Transaction Identifier (любое число, повторяется в ответе)
Proto  — 0x0000 (всегда)
Length — длина оставшейся части (Unit ID + FC + Data)
UnitID — адрес устройства (для RTU-TCP шлюзов)

Порт: 502 (стандартный, зарезервирован IANA)

TCP обеспечивает надёжную доставку — CRC не нужен. Но помните: TCP не обеспечивает реальное время. Задержки могут варьироваться от единиц миллисекунд до нескольких секунд при перегрузке сети.

Практика: Modbus на Python

Библиотека pymodbus (полноценная реализация)

# Установка: pip install pymodbus

from pymodbus.client import ModbusTcpClient, ModbusSerialClient
import struct
import time

# ========== MODBUS TCP ==========

def read_vfd_status_tcp(host: str, port: int = 502, unit_id: int = 1) -> dict:
    """
    Читаем параметры частотника по Modbus TCP.
    Пример для ABB ACS550.
    """
    client = ModbusTcpClient(host=host, port=port, timeout=3)
    
    if not client.connect():
        raise ConnectionError(f"Не удалось подключиться к {host}:{port}")
    
    try:
        # Читаем Input Registers 30001-30006 (адрес 0-5)
        result = client.read_input_registers(
            address=0,      # Начальный адрес (0 = регистр 30001)
            count=6,        # Количество регистров
            slave=unit_id
        )
        
        if result.isError():
            raise Exception(f"Ошибка Modbus: {result}")
        
        regs = result.registers
        
        return {
            'status_word':   regs[0],           # Слово состояния
            'speed_rpm':     regs[1],           # Скорость об/мин
            'frequency_hz':  regs[2] / 100.0,  # Частота (0.01 Гц)
            'current_a':     regs[3] / 10.0,   # Ток (0.1 А)
            'voltage_v':     regs[4],           # Напряжение
            'power_kw':      regs[5] / 10.0,   # Мощность (0.1 кВт)
            'running':       bool(regs[0] & 0x0001),
            'fault':         bool(regs[0] & 0x0008),
        }
        
    finally:
        client.close()


def write_vfd_command_tcp(host: str, freq_hz: float, run: bool, unit_id: int = 1):
    """Управление частотником через Modbus TCP"""
    client = ModbusTcpClient(host=host, port=502, timeout=3)
    
    if not client.connect():
        raise ConnectionError(f"Не удалось подключиться")
    
    try:
        # Задаём частоту (Holding Register 40002, адрес 1)
        freq_raw = int(freq_hz * 100)  # 50.00 Гц → 5000
        client.write_register(address=1, value=freq_raw, slave=unit_id)
        
        # Команда пуск/стоп (Holding Register 40001, адрес 0)
        control_word = 0x0002 if run else 0x0001  # 2=Run, 1=Stop
        client.write_register(address=0, value=control_word, slave=unit_id)
        
        print(f"VFD: {'Пуск' if run else 'Стоп'}, частота {freq_hz} Гц")
        
    finally:
        client.close()


# ========== MODBUS RTU ==========

def create_rtu_client(port: str, baudrate: int = 9600) -> ModbusSerialClient:
    """Создаём RTU клиент для RS-485"""
    return ModbusSerialClient(
        port=port,            # '/dev/ttyUSB0' или 'COM3'
        baudrate=baudrate,
        bytesize=8,
        parity='N',           # N=None, E=Even, O=Odd
        stopbits=1,
        timeout=1.0
    )


def scan_modbus_rtu_network(port: str, baudrate: int = 9600) -> list:
    """
    Сканирование Modbus RTU сети — ищем все активные устройства.
    Возвращает список адресов ответивших устройств.
    """
    client = create_rtu_client(port, baudrate)
    client.connect()
    
    found_devices = []
    
    print(f"Сканирование Modbus RTU на {port}, {baudrate} бод...")
    
    for address in range(1, 248):
        try:
            # Пробуем прочитать 1 регистр — если устройство есть, оно ответит
            result = client.read_holding_registers(0, 1, slave=address)
            
            if not result.isError():
                found_devices.append(address)
                print(f"  

✅ Найдено устройство: адрес {address}")

except Exception: pass # Таймаут — устройства нет

time.sleep(0.05) # Пауза между запросами

client.close() print(f"Найдено устройств: {len(found_devices)}")

return found_devices # ========== РАБОТА С FLOAT ========== def registers_to_float(high_reg: int, low_reg: int, byte_order: str = 'big') -> float: """ Конвертация двух Modbus-регистров в float IEEE 754. byte_order: 'big' (ABCD), 'little' (DCBA), 'big_swap' (BADC), 'little_swap' (CDAB) """ if byte_order == 'big': raw = struct.pack('>HH', high_reg, low_reg) elif byte_order == 'little': raw = struct.pack('<HH', low_reg, high_reg) elif byte_order == 'big_swap': raw = struct.pack('>HH', ((high_reg & 0xFF) << 8) | (high_reg >> 8), ((low_reg & 0xFF) << 8) | (low_reg >> 8)) else: raw = struct.pack('>HH', high_reg, low_reg) return struct.unpack('>f', raw)[0] def float_to_registers(value: float, byte_order: str = 'big') -> tuple: """Конвертация float в два Modbus-регистра""" raw = struct.pack('>f', value) high_reg, low_reg = struct.unpack('>HH', raw) if byte_order == 'big': return high_reg, low_reg elif byte_order == 'little': return low_reg, high_reg return high_reg, low_reg # ========== ПРИМЕР OPROS SCADA ========== class ModbusDataCollector: """ Циклический опрос Modbus-устройств для SCADA/мониторинга. """ def __init__(self, host: str): self.client = ModbusTcpClient(host=host, port=502, timeout=5) self.data = {} def poll_all_devices(self) -> dict: """Опросить все устройства и вернуть данные""" if not self.client.connect(): return {'error': 'connection_failed'} try: results = {} # Насос 1 (Unit ID = 1) pump1 = self.client.read_input_registers(0, 4, slave=1) if not pump1.isError(): r = pump1.registers results['pump1'] = { 'running': bool(r[0] & 1), 'fault': bool(r[0] & 8), 'freq_hz': r[1] / 100.0, 'current_a': r[2] / 10.0, 'power_kw': r[3] / 10.0, } # Датчик давления (Unit ID = 5, счётчик давления) pressure = self.client.read_input_registers(0, 2, slave=5) if not pressure.isError(): r = pressure.registers results['pressure_bar'] = registers_to_float(r[0], r[1]) # Расходомер (Unit ID = 6) flow = self.client.read_input_registers(0, 4, slave=6) if not flow.isError(): r = flow.registers results['flow'] = { 'instant_m3h': registers_to_float(r[0], r[1]), 'total_m3': registers_to_float(r[2], r[3]), } return results finally: self.client.close() # ========== ЗАПУСК ========== if __name__ == "__main__": # Пример использования collector = ModbusDataCollector('192.168.1.100') while True: data = collector.poll_all_devices() print(f"Давление: {data.get('pressure_bar', 0):.2f} бар") print(f"Насос 1: {'Работает' if data.get('pump1', {}).get('running') else 'Стоит'}, " f"{data.get('pump1', {}).get('freq_hz', 0):.1f} Гц") time.sleep(1)

Реализация Modbus Slave на микроконтроллере (C)

Иногда нужно сделать собственное устройство с Modbus-интерфейсом. Вот минимальная реализация для STM32/Arduino:

#include <stdint.h>
#include <string.h>

#define MODBUS_ADDRESS    1      // Адрес нашего устройства
#define HOLDING_REG_COUNT 20     // Количество Holding Registers
#define INPUT_REG_COUNT   10     // Количество Input Registers

// Данные регистров
static uint16_t holding_regs[HOLDING_REG_COUNT] = {0};
static uint16_t input_regs[INPUT_REG_COUNT]     = {0};

// Расчёт CRC16
static uint16_t crc16(uint8_t *buf, uint16_t len)
{
    uint16_t crc = 0xFFFF;
    for (uint16_t i = 0; i < len; i++) {
        crc ^= buf[i];
        for (uint8_t j = 0; j < 8; j++) {
            if (crc & 1) { crc = (crc >> 1) ^ 0xA001; }
            else           { crc >>= 1; }
        }
    }
    return crc;
}

// Отправка ответа (реализуйте под вашу платформу)
extern void uart_send(uint8_t *data, uint16_t len);

// Обработка Modbus запроса
void modbus_process_request(uint8_t *request, uint16_t req_len)
{
    uint8_t response[256];
    uint16_t resp_len = 0;
    
    // Проверяем адрес
    if (request[0] != MODBUS_ADDRESS) return;
    
    // Проверяем CRC
    uint16_t received_crc = (request[req_len-1] << 8) | request[req_len-2];
    uint16_t calculated_crc = crc16(request, req_len - 2);
    if (received_crc != calculated_crc) return;  // CRC ошибка — игнорируем
    
    uint8_t fc    = request[1];
    uint16_t addr = (request[2] << 8) | request[3];
    uint16_t count = (request[4] << 8) | request[5];
    
    response[resp_len++] = MODBUS_ADDRESS;
    response[resp_len++] = fc;
    
    switch (fc)
    {
        case 0x03:  // Читать Holding Registers
        {
            if (addr + count > HOLDING_REG_COUNT) {
                // Исключение: неверный адрес
                response[1] = fc | 0x80;
                response[resp_len++] = 0x02;
                break;
            }
            
            response[resp_len++] = count * 2;  // Количество байт
            
            for (uint16_t i = 0; i < count; i++) {
                response[resp_len++] = holding_regs[addr + i] >> 8;
                response[resp_len++] = holding_regs[addr + i] & 0xFF;
            }
            break;
        }
        
        case 0x04:  // Читать Input Registers
        {
            if (addr + count > INPUT_REG_COUNT) {
                response[1] = fc | 0x80;
                response[resp_len++] = 0x02;
                break;
            }
            
            response[resp_len++] = count * 2;
            
            for (uint16_t i = 0; i < count; i++) {
                response[resp_len++] = input_regs[addr + i] >> 8;
                response[resp_len++] = input_regs[addr + i] & 0xFF;
            }
            break;
        }
        
        case 0x06:  // Записать один Holding Register
        {
            if (addr >= HOLDING_REG_COUNT) {
                response[1] = fc | 0x80;
                response[resp_len++] = 0x02;
                break;
            }
            
            holding_regs[addr] = (request[4] << 8) | request[5];
            
            // Эхо запроса как ответ
            memcpy(response + 2, request + 2, 4);
            resp_len += 4;
            break;
        }
        
        case 0x10:  // Записать несколько Holding Registers
        {
            if (addr + count > HOLDING_REG_COUNT) {
                response[1] = fc | 0x80;
                response[resp_len++] = 0x02;
                break;
            }
            
            uint8_t byte_count = request[6];
            for (uint16_t i = 0; i < count; i++) {
                holding_regs[addr + i] = (request[7 + i*2] << 8) | request[8 + i*2];
            }
            
            // Ответ: адрес и количество записанных регистров
            response[resp_len++] = request[2];
            response[resp_len++] = request[3];
            response[resp_len++] = request[4];
            response[resp_len++] = request[5];
            break;
        }
        
        default:
        {
            // Неизвестная функция
            response[1] = fc | 0x80;
            response[resp_len++] = 0x01;  // Illegal Function
            break;
        }
    }
    
    // Добавляем CRC
    uint16_t resp_crc = crc16(response, resp_len);
    response[resp_len++] = resp_crc & 0xFF;
    response[resp_len++] = resp_crc >> 8;
    
    // Отправляем ответ
    uart_send(response, resp_len);
}

// Обновление Input Registers из реальных данных
void modbus_update_inputs(uint16_t temp_x10, uint16_t pressure_x100,
                          uint16_t status_bits)
{
    input_regs[0] = temp_x10;       // Температура × 10 (250 = 25.0°C)
    input_regs[1] = pressure_x100;  // Давление × 100 (1013 = 10.13 бар)
    input_regs[2] = status_bits;    // Биты состояния
}

Диагностика сети Modbus: практические инструменты

Wireshark для Modbus TCP

Wireshark понимает Modbus TCP "из коробки". Фильтр для захвата:

modbus.func_code  — фильтр по функциональному коду
tcp.port == 502   — весь Modbus TCP трафик
modbus.exception_code  — только ошибки

ModRSsim2 / Diagslave — эмуляторы слейва

Незаменимы при разработке — тестируете мастер без реального оборудования.

Свой анализатор на Python:

import socket
import struct

def modbus_tcp_sniffer(host: str, port: int = 502):
    """Простой анализатор Modbus TCP запросов"""
    
    FC_NAMES = {
        1: 'Read Coils',
        2: 'Read Discrete Inputs',
        3: 'Read Holding Registers',
        4: 'Read Input Registers',
        5: 'Write Single Coil',
        6: 'Write Single Register',
        15: 'Write Multiple Coils',
        16: 'Write Multiple Registers',
    }
    
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((host, port))
    
    while True:
        # Читаем MBAP-заголовок (7 байт)
        header = sock.recv(7)
        if len(header) < 7:
            break
        
        transaction_id = struct.unpack('>H', header[0:2])[0]
        protocol_id    = struct.unpack('>H', header[2:4])[0]
        length         = struct.unpack('>H', header[4:6])[0]
        unit_id        = header[6]
        
        # Читаем PDU
        pdu = sock.recv(length - 1)
        fc  = pdu[0]
        
        fc_name = FC_NAMES.get(fc, f'Unknown FC {fc}')
        
        if fc < 0x80:  # Запрос или нормальный ответ
            if len(pdu) >= 5:
                addr  = struct.unpack('>H', pdu[1:3])[0]
                count = struct.unpack('>H', pdu[3:5])[0]
                print(f"[{transaction_id}] Unit={unit_id} | {fc_name} | "
                      f"Addr={addr} Count={count}")
        else:  # Ошибка
            exc_code = pdu[1]
            print(f"[{transaction_id}] EXCEPTION: FC={fc & 0x7F} Code={exc_code}")

Типичные проблемы и решения

"Устройство не отвечает"

Алгоритм диагностики:

1. Проверьте физику: контакты, полярность A/B, терминаторы

2. Проверьте параметры порта: baudrate, parity, stopbits — должны совпадать с устройством

3. Проверьте адрес — он правильно задан в устройстве? Не все устройства имеют адрес "1" по умолчанию

4. Используйте осциллограф или логический анализатор — видны ли данные на линии?

5. Попробуйте другой кабель

"Иногда не отвечает, CRC-ошибки"

• Слишком длинная линия без репитера

• Отсутствуют или не там стоят терминаторы

• Несколько устройств с одинаковым адресом

• Помехи от силового оборудования — проложите кабель отдельно

"Данные неверные"

• Неправильный порядок байт (endianness) для float

• Смещение адреса: в документации адреса часто указываются с 1 (40001), а в запросе нужно с 0 (0x0000)

• Неправильный масштабный коэффициент (×10, ×100, ×0.01...)

Заключение

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

Для новых проектов, где нет ограничений совместимости, стоит рассматривать OPC UA или MQTT как более современные альтернативы. Но если перед вами стоит задача интегрировать любое промышленное оборудование — с вероятностью 90% оно имеет Modbus, и знание этого протокола решит задачу быстро и надёжно.

IIoT: не просто модное слово

Промышленный IoT (IIoT — Industrial Internet of Things) — это не умный чайник и не фитнес-браслет. Это системы, которые собирают данные с реального производственного оборудования, анализируют их и помогают принимать решения.

Реальный кейс: завод по производству подшипников. Раньше плановое ТО каждые 3 месяца — меняли подшипники в редукторах "по графику". После внедрения IIoT (вибродатчики на каждом редукторе + MQTT + аналитика): 30% редукторов работали нормально и менялись зря, 5% уже имели износ и могли выйти из строя раньше графика. Экономия на расходниках — 28%, аварийных остановок из-за поломки — минус 4 в год.

Это и есть предиктивное обслуживание. И начинается оно с правильного сбора данных.

Архитектура IIoT-системы

Уровень 0 — Полевые устройства:
    Датчики (температура, вибрация, давление, ток)
    Исполнительные механизмы

Уровень 1 — Агрегаторы / Граничные узлы (Edge):
    ESP32, Raspberry Pi, промышленные шлюзы
    Протоколы: Modbus, 1-Wire, I2C, SPI, 4-20мА

Уровень 2 — Брокер сообщений:
    MQTT Broker (Mosquitto, EMQX, HiveMQ)
    Нормализация данных, маршрутизация

Уровень 3 — Обработка и хранение:
    Node-RED / Python — логика, алармы
    InfluxDB / TimescaleDB — временные ряды
    PostgreSQL — конфигурация, справочники

Уровень 4 — Визуализация и аналитика:
    Grafana — дашборды, алерты
    Jupyter Notebook — анализ данных
    ML модели — предиктивная аналитика

MQTT: почему именно он

MQTT (Message Queuing Telemetry Transport) — лёгкий протокол публикации/подписки, разработанный IBM в 1999 году для телеметрии нефтепроводов через спутник. Идеален для IoT:

• Лёгкий: заголовок всего 2 байта, работает при 2G-соединении

• Асинхронный: устройства не опрашиваются, а сами публикуют данные

• QoS (Quality of Service): три уровня надёжности доставки

• Retain: брокер хранит последнее значение, новые подписчики сразу его получают

• Last Will: автоматическое сообщение при потере связи с устройством

Уровни QoS:

• QoS 0 (At most once): Отправил и забыл. Быстро, но сообщение может потеряться. Для частых нечувствительных данных (телеметрия каждую секунду).

• QoS 1 (At least once): Гарантированная доставка, но возможны дубликаты. Для алармов и важных событий.

• QoS 2 (Exactly once): Ровно один раз. Медленнее, для критичных команд управления.

Структура топиков (best practices):

factory/                        ← Завод
  ├── line1/                    ← Производственная линия 1
  │   ├── conveyor1/            ← Конвейер 1
  │   │   ├── telemetry         ← Данные датчиков (JSON, часто)
  │   │   ├── status            ← Состояние (работает/стоит)
  │   │   ├── alarms            ← Аварии
  │   │   └── commands          ← Команды управления
  │   └── robot1/
  │       └── telemetry
  └── utilities/
      ├── compressor1/
      │   └── telemetry
      └── hvac/
          └── telemetry

Примеры топиков:
factory/line1/conveyor1/telemetry
factory/line1/robot1/status
factory/+/+/alarms              ← Подписка на все аварии всей линии 1
factory/#                       ← Подписка на ВСЁ (осторожно!)

Установка и настройка Mosquitto

# Ubuntu/Debian
sudo apt update
sudo apt install mosquitto mosquitto-clients

# Конфигурация /etc/mosquitto/mosquitto.conf:
listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd

# TLS (обязательно для производства!):
listener 8883
cafile /etc/ssl/certs/ca-certificates.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
require_certificate false

# WebSocket для Node-RED и браузерных клиентов:
listener 9001
protocol websockets

# Логирование:
log_dest file /var/log/mosquitto/mosquitto.log
log_type all

# Создание пользователя:
sudo mosquitto_passwd -c /etc/mosquitto/passwd username

sudo systemctl enable mosquitto
sudo systemctl start mosquitto

# Тест:
mosquitto_sub -h localhost -u user -P pass -t "factory/#" -v &
mosquitto_pub -h localhost -u user -P pass -t "factory/test" -m "hello"

ESP32: узел сбора данных

ESP32 — идеальный Edge-узел: WiFi/BT, 240 МГц, 520 КБ RAM, куча периферии, цена $3–5.

#include <WiFi.h>
#include <PubSubClient.h>
#include <ArduinoJson.h>
#include <Wire.h>
#include "Adafruit_BME280.h"

// ===== КОНФИГУРАЦИЯ =====
const char* WIFI_SSID     = "Factory_WiFi";
const char* WIFI_PASSWORD = "secretpass";
const char* MQTT_SERVER   = "192.168.1.100";
const int   MQTT_PORT     = 1883;
const char* MQTT_USER     = "esp32_node1";
const char* MQTT_PASS     = "nodepass";
const char* DEVICE_ID     = "conveyor1";

// Топики
const char* TOPIC_TELEMETRY = "factory/line1/conveyor1/telemetry";
const char* TOPIC_STATUS    = "factory/line1/conveyor1/status";
const char* TOPIC_ALARMS    = "factory/line1/conveyor1/alarms";
const char* TOPIC_COMMANDS  = "factory/line1/conveyor1/commands";
const char* TOPIC_WILL      = "factory/line1/conveyor1/status";

WiFiClient   espClient;
PubSubClient mqtt(espClient);
Adafruit_BME280 bme;

// Состояние
bool motorRunning   = false;
float setpoint      = 50.0f;
uint32_t lastPublish = 0;
uint32_t uptime_sec  = 0;

// ===== ПОДКЛЮЧЕНИЕ =====
void connectWiFi() {
    WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
    Serial.print("WiFi...");
    while (WiFi.status() != WL_CONNECTED) {
        delay(500);
        Serial.print(".");
    }
    Serial.println(" OK");
    Serial.println(WiFi.localIP());
}

void connectMQTT() {
    while (!mqtt.connected()) {
        Serial.print("MQTT...");
        
        // Last Will & Testament — сообщение при потере связи
        const char* willMsg = "{\"online\":false}";
        
        if (mqtt.connect(DEVICE_ID, MQTT_USER, MQTT_PASS,
                         TOPIC_WILL, 1, true, willMsg)) {
            Serial.println(" OK");
            
            // Сообщение о подключении
            mqtt.publish(TOPIC_STATUS, "{\"online\":true}", true);
            
            // Подписываемся на команды
            mqtt.subscribe(TOPIC_COMMANDS, 1);  // QoS 1
            
        } else {
            Serial.printf(" Ошибка: %d\n", mqtt.state());
            delay(5000);
        }
    }
}

// ===== ОБРАБОТКА КОМАНД =====
void mqttCallback(char* topic, byte* payload, unsigned int length) {
    // Парсим JSON команду
    StaticJsonDocument<256> doc;
    DeserializationError error = deserializeJson(doc, payload, length);
    
    if (error) {
        Serial.println("JSON error");
        return;
    }
    
    String topicStr = String(topic);
    
    if (topicStr == TOPIC_COMMANDS) {
        // Команда пуск/стоп
        if (doc.containsKey("run")) {
            motorRunning = doc["run"].as<bool>();
            Serial.printf("Команда: %s\n", motorRunning ? "ПУСК" : "СТОП");
        }
        
        // Изменение уставки
        if (doc.containsKey("setpoint")) {
            setpoint = doc["setpoint"].as<float>();
            Serial.printf("Уставка: %.1f\n", setpoint);
        }
        
        // Сброс аварии
        if (doc["reset_alarm"].as<bool>()) {
            Serial.println("Сброс аварии");
        }
    }
}

// ===== ПУБЛИКАЦИЯ ДАННЫХ =====
void publishTelemetry() {
    // Читаем датчики
    float temperature = bme.readTemperature();
    float humidity    = bme.readHumidity();
    float pressure    = bme.readPressure() / 100.0f;
    int   current_raw = analogRead(34);  // 4-20мА через ACS712
    float current_a   = current_raw * 25.0f / 4095.0f;  // 0-25А
    
    // Формируем JSON
    StaticJsonDocument<512> doc;
    doc["device_id"]   = DEVICE_ID;
    doc["timestamp"]   = millis() / 1000;
    doc["uptime"]      = uptime_sec;
    doc["running"]     = motorRunning;
    doc["setpoint"]    = setpoint;
    
    JsonObject sensors = doc.createNestedObject("sensors");
    sensors["temperature"] = round(temperature * 10) / 10.0;
    sensors["humidity"]    = round(humidity * 10) / 10.0;
    sensors["pressure"]    = round(pressure * 10) / 10.0;
    sensors["current"]     = round(current_a * 100) / 100.0;
    
    // Диагностика устройства
    JsonObject diag = doc.createNestedObject("diagnostics");
    diag["wifi_rssi"]   = WiFi.RSSI();
    diag["free_heap"]   = ESP.getFreeHeap();
    diag["cpu_freq"]    = ESP.getCpuFreqMHz();
    
    // Сериализация и публикация
    char payload[512];
    serializeJson(doc, payload);
    
    mqtt.publish(TOPIC_TELEMETRY, payload, false);  // QoS 0, не retain
    
    // Проверка алармов
    if (temperature > 80.0f) {
        StaticJsonDocument<128> alarm;
        alarm["type"]    = "high_temperature";
        alarm["value"]   = temperature;
        alarm["limit"]   = 80.0f;
        alarm["message"] = "Превышена температура двигателя!";
        
        char alarmPayload[128];
        serializeJson(alarm, alarmPayload);
        mqtt.publish(TOPIC_ALARMS, alarmPayload, true);  // retain = true
    }
}

// ===== SETUP / LOOP =====
void setup() {
    Serial.begin(115200);
    
    Wire.begin(21, 22);
    if (!bme.begin(0x76)) {
        Serial.println("BME280 не найден!");
    }
    
    connectWiFi();
    mqtt.setServer(MQTT_SERVER, MQTT_PORT);
    mqtt.setCallback(mqttCallback);
    mqtt.setBufferSize(1024);  // Увеличиваем буфер для больших сообщений
    
    connectMQTT();
}

void loop() {
    // Переподключение при потере связи
    if (!mqtt.connected()) {
        if (WiFi.status() != WL_CONNECTED) {
            connectWiFi();
        }
        connectMQTT();
    }
    
    mqtt.loop();
    
    // Публикация каждые 5 секунд
    if (millis() - lastPublish >= 5000) {
        lastPublish = millis();
        uptime_sec += 5;
        publishTelemetry();
    }
}

Python: обработка и алармы

import paho.mqtt.client as mqtt
import json
import time
from datetime import datetime
from influxdb_client import InfluxDBClient, Point
from influxdb_client.client.write_api import SYNCHRONOUS

# ===== КОНФИГУРАЦИЯ =====
MQTT_BROKER   = "192.168.1.100"
MQTT_PORT     = 1883
MQTT_USER     = "backend"
MQTT_PASS     = "backendpass"

INFLUX_URL    = "http://localhost:8086"
INFLUX_TOKEN  = "your-influx-token"
INFLUX_ORG    = "factory"
INFLUX_BUCKET = "telemetry"

# ===== ИНИЦИАЛИЗАЦИЯ =====
influx_client = InfluxDBClient(url=INFLUX_URL, token=INFLUX_TOKEN, org=INFLUX_ORG)
write_api = influx_client.write_api(write_options=SYNCHRONOUS)

# Состояние алармов (дедупликация)
active_alarms = {}

def on_message(client, userdata, msg):
    topic = msg.topic
    
    try:
        data = json.loads(msg.payload.decode())
    except json.JSONDecodeError:
        print(f"Ошибка JSON в топике {topic}")
        return
    
    # Маршрутизация по топику
    if "/telemetry" in topic:
        handle_telemetry(topic, data)
    elif "/alarms" in topic:
        handle_alarm(topic, data)
    elif "/status" in topic:
        handle_status(topic, data)


def handle_telemetry(topic: str, data: dict):
    """Запись телеметрии в InfluxDB"""
    
    # Извлекаем путь устройства из топика
    # factory/line1/conveyor1/telemetry → ['factory', 'line1', 'conveyor1', 'telemetry']
    parts = topic.split('/')
    if len(parts) < 4:
        return
    
    location = parts[1]   # line1
    device   = parts[2]   # conveyor1
    
    sensors = data.get('sensors', {})
    
    # Формируем точку данных для InfluxDB
    point = (
        Point("telemetry")
        .tag("location", location)
        .tag("device", device)
        .tag("device_id", data.get('device_id', device))
        .field("temperature", float(sensors.get('temperature', 0)))
        .field("humidity",    float(sensors.get('humidity', 0)))
        .field("pressure",    float(sensors.get('pressure', 0)))
        .field("current",     float(sensors.get('current', 0)))
        .field("running",     int(data.get('running', False)))
        .field("wifi_rssi",   int(data.get('diagnostics', {}).get('wifi_rssi', 0)))
    )
    
    try:
        write_api.write(bucket=INFLUX_BUCKET, record=point)
    except Exception as e:
        print(f"InfluxDB ошибка: {e}")
    
    # Проверка пороговых значений
    temp = sensors.get('temperature', 0)
    if temp > 85.0:
        send_alert(device, "critical", f"Критическая температура: {temp}°C")
    elif temp > 75.0:
        send_alert(device, "warning", f"Высокая температура: {temp}°C")


def handle_alarm(topic: str, data: dict):
    """Обработка аларм-сообщений от устройства"""
    parts = topic.split('/')
    device = parts[2] if len(parts) >= 3 else "unknown"
    
    alarm_type = data.get('type', 'unknown')
    alarm_key  = f"{device}_{alarm_type}"
    
    # Дедупликация: не спамим одинаковые алармы
    now = time.time()
    if alarm_key in active_alarms:
        if now - active_alarms[alarm_key] < 300:  # 5 минут
            return
    
    active_alarms[alarm_key] = now
    
    print(f"

🚨

АВАРИЯ [{device}]: {data.get('message', alarm_type)}") # Здесь можно добавить отправку в Telegram, email, SMS send_notification( f"⚠️ Авария на {device}\n" f"Тип: {alarm_type}\n" f"Значение: {data.get('value', 'N/A')}\n" f"Время: {datetime.now().strftime('%H:%M:%S')}" ) def handle_status(topic: str, data: dict): """Отслеживание онлайн/офлайн устройств""" parts = topic.split('/') device = parts[2] if len(parts) >= 3 else "unknown" online = data.get('online', False) print(f"{'🟢' if online else '🔴'} {device}: {'онлайн' if online else 'офлайн'}") if not online: send_alert(device, "critical", f"Устройство {device} потеряло связь!") def send_alert(device: str, level: str, message: str): """Отправка алерта (пример — в лог)""" timestamp = datetime.now().strftime("%Y-%m-%d %H:%M:%S") print(f"[{timestamp}] {level.upper()} [{device}]: {message}") def send_notification(text: str): """Здесь интеграция с Telegram Bot API""" # import requests # requests.post(f"https://api.telegram.org/bot{TOKEN}/sendMessage", # json={"chat_id": CHAT_ID, "text": text}) print(f"NOTIFICATION: {text}") # ===== ЗАПУСК ===== client = mqtt.Client(client_id="backend_processor") client.username_pw_set(MQTT_USER, MQTT_PASS) client.on_message = on_message client.connect(MQTT_BROKER, MQTT_PORT, 60) client.subscribe("factory/#", qos=1) # Подписка на всё print("Backend запущен, ожидаем данные...") client.loop_forever()

InfluxDB + Grafana: красивые дашборды

Установка через Docker Compose:

# docker-compose.yml
version: '3.8'

services:
  mosquitto:
    image: eclipse-mosquitto:2
    ports:
      - "1883:1883"
      - "9001:9001"
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - mosquitto_data:/mosquitto/data

  influxdb:
    image: influxdb:2.7
    ports:
      - "8086:8086"
    environment:
      DOCKER_INFLUXDB_INIT_MODE: setup
      DOCKER_INFLUXDB_INIT_USERNAME: admin
      DOCKER_INFLUXDB_INIT_PASSWORD: secretpassword
      DOCKER_INFLUXDB_INIT_ORG: factory
      DOCKER_INFLUXDB_INIT_BUCKET: telemetry
      DOCKER_INFLUXDB_INIT_RETENTION: 30d  # Хранение 30 дней
    volumes:
      - influxdb_data:/var/lib/influxdb2

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: grafanapass
      GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS: "yesoreyeram-infinity-datasource"
    volumes:
      - grafana_data:/var/lib/grafana
    depends_on:
      - influxdb

  node-red:
    image: nodered/node-red:latest
    ports:
      - "1880:1880"
    volumes:
      - nodered_data:/data

volumes:
  mosquitto_data:
  influxdb_data:
  grafana_data:
  nodered_data:

Flux-запрос в Grafana (температура за последний час):

from(bucket: "telemetry")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "telemetry")
  |> filter(fn: (r) => r._field == "temperature")
  |> filter(fn: (r) => r.device == "conveyor1")
  |> aggregateWindow(every: 1m, fn: mean, createEmpty: false)
  |> yield(name: "mean_temperature")

Предиктивная аналитика: пример с вибрацией

import numpy as np
from scipy.fft import fft, fftfreq
from scipy.stats import zscore

def analyze_vibration(samples: list, sample_rate: int = 1000) -> dict:
    """
    Анализ вибрации для обнаружения износа подшипников.
    samples: список отсчётов акселерометра
    sample_rate: частота дискретизации, Гц
    """
    data = np.array(samples, dtype=float)
    n = len(data)
    
    # Временные характеристики
    rms   = np.sqrt(np.mean(data**2))      # Эффективное значение (RMS)
    peak  = np.max(np.abs(data))           # Пиковое значение
    crest = peak / rms if rms > 0 else 0  # Пик-фактор (norma: 1.4–2.5, износ: >4)
    kurtosis = float(np.mean((data - np.mean(data))**4) / (np.std(data)**4 + 1e-10))
    
    # Спектральный анализ (FFT)
    spectrum = np.abs(fft(data))[:n//2]
    freqs    = fftfreq(n, 1.0 / sample_rate)[:n//2]
    
    # Поиск доминирующих частот
    top_indices = np.argsort(spectrum)[-5:][::-1]
    dominant_freqs = [(float(freqs[i]), float(spectrum[i])) for i in top_indices]
    
    # Оценка состояния
    # Crest Factor: <2.5 — норма, 2.5–4 — внимание, >4 — износ
    # Kurtosis: <3 — норма (гауссов шум), >6 — дефект (удары)
    
    if crest > 4.0 or kurtosis > 6.0:
        status = "FAULT"
        recommendation = "Замените подшипник в течение 48 часов"
    elif crest > 2.5 or kurtosis > 4.5:
        status = "WARNING"
        recommendation = "Запланируйте замену при следующем ТО"
    else:
        status = "OK"
        recommendation = "Оборудование в норме"
    
    return {
        'rms':             round(rms, 4),
        'peak':            round(peak, 4),
        'crest_factor':    round(crest, 2),
        'kurtosis':        round(kurtosis, 2),
        'dominant_freqs':  dominant_freqs[:3],
        'status':          status,
        'recommendation':  recommendation,
    }

# Пример использования с MQTT:
def on_vibration_data(client, userdata, msg):
    data = json.loads(msg.payload)
    samples = data['samples']
    device  = data['device_id']
    
    analysis = analyze_vibration(samples, sample_rate=data.get('sample_rate', 1000))
    
    # Публикуем результат анализа
    result_topic = f"factory/analytics/{device}/bearing_health"
    client.publish(result_topic, json.dumps(analysis), retain=True)
    
    if analysis['status'] != 'OK':
        print(f"

⚠️

{device}: {analysis['recommendation']}") # Отправить уведомление...

Безопасность IIoT

Это не опционально. Промышленные системы с интернет-подключением — лакомая цель для атак.

Минимальный стандарт:

1. TLS везде — Mosquitto с сертификатами, никакого plaintext

2. Аутентификация — уникальный логин/пароль для каждого устройства, или X.509 сертификаты

3. Авторизация по ACL — устройство conveyor1 пишет только в factory/line1/conveyor1/#, не может читать чужие команды

4. Сегментация сети — IoT-устройства в отдельном VLAN, без прямого доступа в интернет

5. OTA-обновления — возможность удалённого обновления прошивки при обнаружении уязвимостей

6. Мониторинг аномалий — необычное количество сообщений, соединения с нестандартных IP

# Mosquitto ACL файл /etc/mosquitto/acl:
# Устройство conveyor1 — пишет только в свои топики
user esp32_conveyor1
topic write factory/line1/conveyor1/+
topic read  factory/line1/conveyor1/commands

# Backend — читает всё, пишет команды
user backend
topic readwrite factory/#

Заключение

IIoT с MQTT — это доступная и проверенная технология, которую можно внедрить даже на небольшом предприятии с минимальными затратами. ESP32 + Mosquitto + InfluxDB + Grafana — весь стек работает на одном Raspberry Pi 4 или бюджетном сервере.

Главные принципы: данные должны быть точными (правильная калибровка датчиков), надёжными (QoS, переподключение, buffering), безопасными (TLS, ACL) и полезными (не просто собирать, а анализировать и действовать).

Начните с малого: один датчик температуры, один MQTT-брокер, один Grafana-дашборд. После первого успешного графика желание расширять систему появится само.

Почему RS-485, а не что-то современное

Каждый год появляются новые промышленные протоколы: EtherCAT, PROFINET, IO-Link, TSN. Но RS-485 не умирает. По данным IHS Markit, ежегодно продаётся более 1 миллиарда чипов RS-485. Новые установки продолжают использовать этот интерфейс.

Причины живучести просты:

• Дешевизна: кабель — витая пара $0.1/м, трансивер MAX485 — $0.3

• Надёжность: дифференциальный сигнал устойчив к помехам, работает на расстояниях до 1200 м

• Простота: понять и реализовать RS-485 можно за один день

• Совместимость: поддерживается абсолютно всеми промышленными устройствами

Modbus RTU, BACnet MS/TP, DMX512, DALI — всё это работает поверх RS-485. Если вы занимаетесь промышленной автоматизацией, знание RS-485 обязательно.

Сравнение: RS-232 vs RS-485

Физический уровень: как работает дифференциальный сигнал

RS-485 использует дифференциальную пару проводников A и B:

Состояние MARK (логическая 1, рецессивное):
  A > B: разность (A-B) = +200мВ...+5В

Состояние SPACE (логическая 0, доминантное):
  B > A: разность (B-A) = +200мВ...+5В, то есть (A-B) = -200мВ...-5В

Типичное напряжение при передаче:
  A ≈ +3.5В, B ≈ -3.5В → разность = +7В (гарантированная "1")
  A ≈ -3.5В, B ≈ +3.5В → разность = -7В (гарантированная "0")

Устойчивость к синфазным помехам:
  Помеха +5В добавляется на ОБА провода:
  A = +3.5 + 5 = +8.5В, B = -3.5 + 5 = +1.5В
  Разность = +8.5 - 1.5 = +7В — сигнал не изменился!

Пороги приёмника: если разность (A-B) > +200мВ — принимает "1"; если (A-B) < -200мВ — принимает "0". Диапазон ±200мВ — мёртвая зона (неопределённость).

Выбор трансивера RS-485

Бюджетные (для начала):

MAX485 / MAX485E (Maxim)

• Самый популярный, $0.3–0.5

• Полудуплекс, 2.5 Мбит/с

• Нет защиты от ESD (добавьте TVS-диоды!)

• Нет защиты от перегрева

• Питание 5В

SP3485 (Sipex/Exar)

• Клон MAX485, питание 3.3В

• Совместимость с STM32, ESP32 напрямую (5В-tolerant входы)

Профессиональные (для промышленности):

MAX3485 / MAX3488

• Расширенный диапазон ESD: ±15 кВ (HBM)

• Работает от 3.3В

SN65HVD1780 (Texas Instruments)

• Встроенная защита от отказа шины (failsafe)

• ESD: ±16 кВ IEC 61000-4-2

• Для жёстких промышленных условий

ADM2587E (Analog Devices)

• Встроенная гальваническая изоляция 2500 VRMS

• Изолированный DC-DC для питания изолированной стороны

• Для применений с разным заземлением узлов

Схема подключения: правильно и неправильно

Минимальная схема (Arduino + MAX485):

Arduino         MAX485          RS-485 шина
  TX ─────────── DI
  RX ─────────── RO
  D2 ────┬────── DE            A ──── Шина A
         └────── RE_           B ──── Шина B
  GND ─────────── GND          GND ── Общий провод (обязательно!)
  5V ──────────── Vcc

Резисторы на шине:
  A ──[120 Ом]── B   ← Терминатор на каждом конце шины
  
  Pullup/Pulldown для определённого состояния в паузах:
  +5В ──[560 Ом]── A   ← Pull-up
  B ──[560 Ом]── GND   ← Pull-down

Ключевые правила:

✅ ПРАВИЛЬНО: [Устройство A]──────[Устройство B]──────[Устройство C] [Term 120Ом] [Term 120Ом] Строго линейная шина, терминаторы только на концах

❌ НЕПРАВИЛЬНО — "звезда": [Устройство A] │ [Уст.B]──[Hub]──[Уст.C] │ [Устройство D] Отражения на каждом разветвлении разрушат сигнал!

❌ НЕПРАВИЛЬНО — терминаторы не там: [Term]──[Уст.A]──[Уст.B]──[Term]──[Уст.C] Терминатор посередине создаёт проблемы!

Допустимые ответвления (stub):

Короткие отводы от основной шины допустимы при условии:

• Длина stub < λ/10, где λ — длина волны на рабочей скорости

• При 9600 бод: λ ≈ 12 км → stub до 1200 м (практически неограничен)

• При 115200 бод: stub не более 1 м

• При 1 Мбит/с: stub не более 15 см!

Управление направлением передачи

RS-485 в полудуплексном режиме требует переключения между передачей и приёмом через сигнал DE/RE:

// Arduino: управление направлением через GPIO

#define RS485_DE_RE_PIN 2
#define RS485_BAUDRATE  9600

void rs485_init() {
    Serial.begin(RS485_BAUDRATE);
    pinMode(RS485_DE_RE_PIN, OUTPUT);
    rs485_receive_mode();  // По умолчанию — приём
}

void rs485_receive_mode() {
    digitalWrite(RS485_DE_RE_PIN, LOW);  // DE=0, RE=0 → приём
}

void rs485_transmit_mode() {
    digitalWrite(RS485_DE_RE_PIN, HIGH);  // DE=1, RE=1 → передача
}

void rs485_send(uint8_t *data, uint8_t len) {
    rs485_transmit_mode();
    
    Serial.write(data, len);
    Serial.flush();  // ЖДЁМ пока все байты уйдут в UART TX буфер!
    
    // После flush() данные ещё в UART, нужно дождаться физической передачи
    // Расчёт времени: N_байт × 10_бит / baudrate
    uint32_t delay_us = (uint32_t)len * 10 * 1000000UL / RS485_BAUDRATE + 100;
    delayMicroseconds(delay_us);
    
    rs485_receive_mode();
}

Аппаратное управление DE/RE (лучше!):

На STM32 USART имеет аппаратный сигнал DE для RS-485. Переключение происходит автоматически — с точностью до такта, без программных задержек:

// STM32 HAL: аппаратное управление DE через USART
// В CubeMX: USART → Mode = Asynchronous, Hardware Flow Control = RS-485 Driver Enable

// CubeMX настроит:
// huart2.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_DE_INIT;
// huart2.AdvancedInit.DEPolarity = UART_DE_POLARITY_HIGH;
// huart2.AdvancedInit.DEAssertionTime = 16;  // тактов предвключения
// huart2.AdvancedInit.DEDeassertionTime = 16; // тактов послевыключения

// После этого просто передаём — DE управляется автоматически!
HAL_UART_Transmit(&huart2, data, len, 100);
// STM32 сам поднял DE перед передачей и снял после!

Расчёт нагрузки на шину

RS-485 трансивер создаёт нагрузку на шину. Стандарт RS-485 определяет "единицу нагрузки" (Unit Load, UL) = 12 кОм.

Драйвер должен обеспечить минимум 32 UL. Это значит: максимум 32 "классических" устройства на шине.

Современные трансиверы с низким потреблением имеют 1/8 UL или 1/4 UL:

Также нагрузку создают терминирующие резисторы:

• 2 × 120 Ом = 60 Ом = 200 UL (!) — это доминирующая нагрузка

• Учитывайте это при расчёте суммарной нагрузки

Кабель: выбор и прокладка

Требования к кабелю RS-485:

Обязательно:

• Витая пара (не просто два провода!)

• Волновое сопротивление 120 Ом (терминируется парными резисторами 120 Ом)

Рекомендуемые типы кабелей:

• КВВГЭ 1×2×0.75 — отечественный, экранированная витая пара

• Belden 9842 — американский стандарт, 120 Ом, двойной экран

• LiYCY 2×0.5 мм² — гибкий, для подвижных установок

• Cat5e / Cat6 — работает! (120 Ом, но без промышленной изоляции)

Сечение проводника:

Падение напряжения на кабеле:
ΔU = 2 × R_кабеля × I_нагрузка

R = ρ × L / S = 0.0175 (Ом·мм²/м) × 1000 м / 0.5 мм² = 35 Ом

При токе утечки 100 мА:
ΔU = 2 × 35 × 0.1 = 7В — это уже критично!

Для длинных линий выбирайте кабель 1.0 мм² и более.

Экранирование:

Правила заземления экрана:

✅ Заземлять в ОДНОЙ точке — предотвращает контурные токи Обычно: на стороне мастера/ПЛК

❌ Заземлять с ОБОИХ концов — контурный ток протекает по экрану! При разных потенциалах земли создаёт синфазные помехи. Исключение: при частотах > 100 кГц экран заземляют с обоих концов (через конденсатор 10 нФ с одной стороны).

Практика: полный пример Modbus RTU на Python

import serial
import struct
import time
from typing import Optional

class RS485Master:
    """
    Мастер RS-485 с ручным управлением DE/RE через GPIO (для Raspberry Pi).
    Или с автоматическим через RTS (для USB-RS485 адаптеров).
    """
    
    def __init__(self, port: str, baudrate: int = 9600,
                 use_rts: bool = True, rts_level: bool = True):
        """
        port: '/dev/ttyUSB0', 'COM3' и т.д.
        use_rts: использовать RTS для управления DE/RE (USB-адаптеры)
        rts_level: уровень RTS при передаче (True = HIGH)
        """
        self.ser = serial.Serial(
            port     = port,
            baudrate = baudrate,
            bytesize = serial.EIGHTBITS,
            parity   = serial.PARITY_NONE,
            stopbits = serial.STOPBITS_ONE,
            timeout  = 0.1
        )
        
        if use_rts:
            self.ser.rts = not rts_level  # Начальное состояние — приём
        
        self.use_rts   = use_rts
        self.rts_level = rts_level
        
        # Время передачи одного символа (для задержки после отправки)
        self.char_time = 10.0 / baudrate  # 10 бит на символ
    
    def _tx_enable(self):
        if self.use_rts:
            self.ser.rts = self.rts_level
            time.sleep(0.0001)  # 100 мкс предвключение
    
    def _rx_enable(self):
        if self.use_rts:
            # Ждём физической передачи последнего байта
            time.sleep(self.char_time)
            self.ser.rts = not self.rts_level
    
    def _crc16(self, data: bytes) -> int:
        crc = 0xFFFF
        for byte in data:
            crc ^= byte
            for _ in range(8):
                crc = (crc >> 1) ^ 0xA001 if crc & 1 else crc >> 1
        return crc
    
    def send_raw(self, data: bytes):
        """Отправка сырых данных"""
        self.ser.reset_input_buffer()  # Очищаем входной буфер перед отправкой
        self._tx_enable()
        self.ser.write(data)
        self.ser.flush()
        self._rx_enable()
    
    def recv_raw(self, expected_len: int, timeout: float = 0.5) -> Optional[bytes]:
        """Приём данных с таймаутом"""
        deadline = time.time() + timeout
        buf = b''
        
        while time.time() < deadline:
            chunk = self.ser.read(expected_len - len(buf))
            buf += chunk
            if len(buf) >= expected_len:
                break
            time.sleep(0.001)
        
        return buf if len(buf) == expected_len else None
    
    def modbus_read_registers(self, slave: int, func: int,
                               start_addr: int, count: int) -> Optional[list]:
        """
        Чтение Holding (FC=3) или Input (FC=4) регистров.
        Возвращает список значений или None при ошибке.
        """
        # Формируем запрос
        request = struct.pack('>BBHH', slave, func, start_addr, count)
        crc = self._crc16(request)
        request += struct.pack('<H', crc)  # CRC little-endian!
        
        self.send_raw(request)
        
        # Ожидаемый размер ответа: addr(1)+fc(1)+byte_count(1)+data(count×2)+crc(2)
        expected = 5 + count * 2
        response = self.recv_raw(expected)
        
        if response is None:
            return None  # Таймаут
        
        # Проверка CRC
        recv_crc = struct.unpack('<H', response[-2:])[0]
        calc_crc = self._crc16(response[:-2])
        if recv_crc != calc_crc:
            return None  # CRC ошибка
        
        # Проверка Exception
        if response[1] & 0x80:
            exc_code = response[2]
            print(f"Modbus Exception: slave={slave}, code={exc_code}")
            return None
        
        # Распаковываем данные
        byte_count = response[2]
        values = list(struct.unpack(f'>{count}H', response[3:3+byte_count]))
        return values
    
    def modbus_write_register(self, slave: int, addr: int, value: int) -> bool:
        """Запись одного Holding регистра (FC=6)"""
        request = struct.pack('>BBHH', slave, 6, addr, value)
        crc = self._crc16(request)
        request += struct.pack('<H', crc)
        
        self.send_raw(request)
        
        # Ответ = эхо запроса (8 байт)
        response = self.recv_raw(8)
        if response is None:
            return False
        
        recv_crc = struct.unpack('<H', response[-2:])[0]
        return recv_crc == self._crc16(response[:-2])
    
    def close(self):
        self.ser.close()


# ===== ПРИМЕР ИСПОЛЬЗОВАНИЯ =====

def demo_poll_vfd():
    """Опрос частотника по Modbus RTU через RS-485"""
    
    master = RS485Master('/dev/ttyUSB0', baudrate=9600, use_rts=True)
    
    try:
        print("Опрос частотника (адрес 1)...")
        
        while True:
            # Читаем 6 Input регистров: статус, частота, ток, напряжение, мощность, fault
            regs = master.modbus_read_registers(slave=1, func=4,
                                                 start_addr=0, count=6)
            
            if regs is None:
                print("Нет ответа от устройства")
            else:
                status   = regs[0]
                freq_hz  = regs[1] / 100.0
                curr_a   = regs[2] / 10.0
                volts    = regs[3]
                power_kw = regs[4] / 10.0
                fault    = regs[5]
                
                running = bool(status & 0x0001)
                faulted = bool(status & 0x0008)
                
                print(f"{'

▶

' if running else '⏹'} " f"f={freq_hz:.1f}Гц " f"I={curr_a:.1f}А " f"U={volts}В " f"P={power_kw:.1f}кВт " f"{'🔴АВАРИЯ' if faulted else ''}") if faulted: print(f"Код аварии: {fault}") time.sleep(1.0) except KeyboardInterrupt: print("Остановлено") finally: master.close() demo_poll_vfd()

Диагностика: осциллограф и мультиметр

Измерения мультиметром:

Линия A-B без сигнала (все устройства молчат):
  Должно быть: A > B на 200мВ+ (если есть pull-up/down)
  Плохо:       A = B (неопределённое состояние — нужны резисторы смещения)

Во время передачи:
  Осциллограф: чёткие уровни ±3..4В, без выбросов
  Плохо: размытые фронты → слишком длинная линия или нет терминаторов
  Плохо: выбросы >±7В → нет снаббера или плохое заземление
  
Измерение дифференциального сигнала:
  Щуп A → канал 1, Щуп B → канал 2
  Включить Math: CH1 - CH2
  Должен быть чёткий прямоугольник ±(3..5)В

Типичные осциллограммы проблем:

Нет терминаторов:

    ┌──────┐
    │      │  ← Нормальный фронт
    │      │╲  ← Отражение (заброс)
────┘      └─╲──────
                └──  ← Повторное отражение

Слишком длинный stub:

    ┌──────┐
    │      ╲___/  ← Паразитное колебание после фронта
────┘            ────

Хорошая линия:

    ┌──────────┐
────┘          └────  ← Чёткие фронты без выбросов

Гальваническая развязка: когда обязательна

В промышленных установках "земля" в разных точках может иметь разный потенциал — десятки и даже сотни вольт. Без развязки:

• Контурный ток по GND-проводу шины RS-485 разрушает трансиверы

• Помехи от силового оборудования проникают в логику

• Один неисправный узел выводит из строя всю сеть

Когда нужна обязательно:

• Устройства питаются от разных источников

• Расстояние между устройствами > 50 м

• Рядом с шиной есть мощные электродвигатели или сварочное оборудование

• Разные здания или разные распределительные щиты

Варианты реализации:

Вариант 1: Изолированный трансивер (ADM2587E, ISO3082)
  UART ──[Изолированный трансивер]── RS-485 шина
  Встроенная изоляция 2500 VRMS, нет внешних компонентов

Вариант 2: Оптопара + отдельный трансивер
  UART_TX ──[HCPL2630]── MAX485 ── RS-485 шина
  UART_RX ──[HCPL2630]──┘
  Дешевле, но нужен изолированный DC-DC конвертер питания

Вариант 3: Цифровой изолятор + трансивер
  UART ──[ISO7720]── MAX485 ── RS-485 шина
  ISO7720: 5 кВ изоляция, 100 Мбит/с, без светодиодов (долговечнее оптопар)

Число устройств больше 32: репитеры и конвертеры

Если нужно более 32 устройств или протяжённость линии превышает допустимую:

Репитер RS-485:
[Сегмент 1: 32 уст., 600 м]──[Репитер]──[Сегмент 2: 32 уст., 600 м]

Репитер переусиливает и переформирует сигнал.
Каждый сегмент — отдельная нагрузка.

Популярные репитеры:
- ADAM-4510 (Advantech): изолированный, DIN-рейка
- Moxa MB-9000: с диагностикой
- Homemade: MAX487 + MAX487 с DE/RE управлением

Защита от грозовых разрядов и ESD

При длинных линиях между зданиями — молниезащита обязательна:

Схема защиты RS-485 линии:
                                         RS-485
Шина ──[Предохранитель]──[GDT или MOV]──[TVS-диод]──[Трансивер]
 A                                        P6KE6.8CA

Уровни защиты:
1. GDT (газоразрядник) или MOV: ограничивают до 100..500В за наносекунды
2. TVS-диод P6KE6.8CA: ограничивает до ±6.8В, рассеивает 600 Вт импульсно
3. Последовательный резистор 10..22 Ом: ограничивает ток через TVS

Готовые модули молниезащиты RS-485:
- MTL5000: промышленный барьер
- Phoenix Contact TRABTECH: DIN-рейка
- УЗИП-485 (отечественный): Microsemi/аналоги

Частые вопросы и ответы

Q: Можно ли использовать обычный кабель UTP Cat5e вместо специального? A: Можно, и это работает на практике. Cat5e имеет волновое сопротивление 100 Ом (термinator нужен 100 Ом), паразитные ёмкости немного хуже. До 300м/115200 бод — без проблем. Но в промышленной среде с помехами — лучше экранированный кабель.

Q: Нужен ли третий провод GND? A: Для корректной работы трансивера входная синфазная помеха не должна выходить за пределы -7В...+12В (Vcm). При длинных линиях и разных заземлениях это нарушается. GND-провод удерживает синфазное напряжение в пределах допустимого. Включайте GND во все промышленные установки.

Q: У устройства нет RS-485, только UART. Как подключить? A: Добавить внешний трансивер MAX485/SP3485 + резистор 300 Ом на DE/RE от GPIO.

Q: Что делать если устройства разных производителей не видят друг друга? A: Проверить: 1) Скорость/parity/stopbits совпадают. 2) Полярность A/B (иногда производители маркируют наоборот). 3) Адреса устройств уникальны. 4) Нет конфликта адресов.

Заключение

RS-485 — это не устаревший протокол, а надёжный, проверенный инструмент для промышленных приложений. Правильная линейная топология с терминаторами, экранированная витая пара, правильное управление DE/RE и гальваническая развязка там, где нужно — всё это обеспечит годы надёжной работы.

Вложите время в понимание физического уровня: осциллограф + хорошая книга по физике передачи сигналов. Большинство проблем RS-485 решаются на физическом уровне, а не в программе.

Правильный датчик — половина успеха автоматизации

Самый умный ПЛК и лучший алгоритм управления ничего не стоят, если датчик даёт неверные данные. Выбор, монтаж и калибровка датчиков — часто недооцениваемая область, которая определяет качество всей системы.

Промышленный датчик — не просто "измерительное устройство". Это прибор, который должен работать 24/7 годами в условиях вибраций, агрессивных сред, перепадов температур и электромагнитных помех. И при этом давать достоверные показания.

Классификация выходных сигналов

Прежде чем выбирать датчик — определитесь с типом сигнала:

Аналоговые сигналы

4–20 мА (токовая петля):

• Самый распространённый промышленный стандарт

• 4 мА = 0% диапазона, 20 мА = 100%

• Устойчив к помехам (ток, не напряжение)

• Обнаружение обрыва кабеля: < 3.8 мА = авария

• Длина линии до нескольких км (ограничено напряжением питания)

• Двухпроводная схема: датчик питается от той же петли!

0–10 В:

• Проще в подключении, но чувствителен к помехам

• Нет встроенного обнаружения обрыва

• Ограничение длины кабеля (~50 м)

• Используется в HVAC, Building Automation

0–5 В / ±10 В:

• Распространён для ускорений, давлений в автомотиве

Дискретные сигналы

NPN / PNP:

• NPN: выход тянет к GND при активации (сигнал = LOW)

• PNP: выход тянет к питанию (сигнал = HIGH)

• Подключение к ПЛК: важно соответствие типа входного модуля!

NO / NC (нормально открытый / нормально закрытый):

• NO: контакт разомкнут в норме, замыкается при срабатывании

• NC: контакт замкнут в норме, размыкается при срабатывании

• Для безопасности: NC предпочтительнее (обрыв провода = срабатывание защиты)

Цифровые/протокольные

IO-Link, HART, Profibus PA, Foundation Fieldbus, EtherCAT — для умных датчиков с диагностикой и конфигурированием по линии.

Температура: термопары и PT100

Термопары (Thermocouple)

Принцип: эффект Зеебека — два разных металла, соединённых в двух точках, генерируют ЭДС при разнице температур.

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

• Генерируют малую ЭДС (0–80 мВ) — нужен прецизионный усилитель

• Требуют компенсации холодного спая (CJC — Cold Junction Compensation)

• Длинные термопарные кабели из компенсационных проводов (дороже!)

• Нелинейная характеристика (полиномиальная аппроксимация по ГОСТ)

Подключение к микроконтроллеру через MAX31855/MAX6675:

#include <Adafruit_MAX31855.h>
#include <SPI.h>

// MAX31855: усилитель термопары типа K с SPI интерфейсом
Adafruit_MAX31855 thermocouple(D5, D6, D7);  // CLK, CS, DO

void setup() {
    Serial.begin(115200);
    if (!thermocouple.begin()) {
        Serial.println("MAX31855 не найден!");
        while (1);
    }
}

void loop() {
    double hot_temp  = thermocouple.readCelsius();  // Температура термопары
    double cold_temp = thermocouple.readInternal();  // Температура холодного спая (чип)
    
    if (isnan(hot_temp)) {
        uint8_t fault = thermocouple.readError();
        Serial.print("Ошибка: ");
        if (fault & MAX31855_FAULT_OPEN)   Serial.println("обрыв термопары");
        if (fault & MAX31855_FAULT_SHORT_GND) Serial.println("КЗ на GND");
        if (fault & MAX31855_FAULT_SHORT_VCC) Serial.println("КЗ на VCC");
    } else {
        Serial.printf("T = %.2f°C (холодный спай: %.2f°C)\n", hot_temp, cold_temp);
    }
    
    delay(1000);
}

Термосопротивления PT100/PT1000

Принцип: сопротивление платинового проводника линейно растёт с температурой.

• PT100: 100 Ом при 0°C, α = 0.00385 Ом/(Ом·°C)

• PT1000: 1000 Ом при 0°C (лучше для длинных кабелей)

R(T) = R0 × [1 + A×T + B×T² + C×T³ × (T-100)]
R0 = 100 Ом
A = 3.9083×10⁻³
B = -5.775×10⁻⁷
C = -4.183×10⁻¹² (только при T < 0°C)

Упрощённо для -50..+200°C:
R(T) ≈ 100 × (1 + 0.00385 × T)
T ≈ (R - 100) / 0.385

Схемы подключения:

2-проводная (дёшево, но ошибка от сопротивления кабеля):
  [ПЛК]──R_кабель──[PT100]──R_кабель──[ПЛК]
  Ошибка: ΔR_кабель = 2 × ρ × L / S
  При 10 м, 0.5 мм²: ΔR ≈ 0.7 Ом ≈ 1.8°C погрешность!

3-проводная (стандарт):
  [ПЛК]──R1──[PT100]──R2──[ПЛК]
              │
              R3──────────[ПЛК]
  Измерительная схема компенсирует сопротивление одного провода

4-проводная (эталонная точность):
  [ПЛК]──I+──[PT100]──I-──[ПЛК]  (ток через PT100)
  [ПЛК]──U+──[PT100]──U-──[ПЛК]  (измерение напряжения)
  Сопротивление провода не влияет на точность

Датчики давления: 4–20 мА в промышленности

Основные типы:

Пьезорезистивные: мембрана с тензодатчиками, сигнал 4–20 мА. Самые распространённые.

Пьезоэлектрические: для динамических давлений (удары, взрывы). Заряд пропорционален давлению.

Ёмкостные: высокая точность (0.01%), дорогие. Для точных технологических процессов.

Подключение датчика 4–20 мА:

Двухпроводная схема (+питание, -сигнал):

24В ──────────┬──────── Датчик (+)
              │
           R_shunt (250 Ом)
              │
GND ──────────┴──────── Датчик (-)
              │
           Измеряем U на R_shunt
           4мА → 1.000В
           20мА → 5.000В

В ПЛК: аналоговый вход 1–5В или через преобразователь ток→напряжение

def current_to_pressure(current_ma: float,
                          pressure_min: float,
                          pressure_max: float) -> float:
    """
    Преобразование тока 4-20мА в давление.
    
    Args:
        current_ma: ток в мА (4.0..20.0)
        pressure_min: давление при 4мА (нижний предел датчика)
        pressure_max: давление при 20мА (верхний предел)
    
    Returns:
        давление в единицах pressure_min/max
    """
    # Проверка обрыва линии
    if current_ma < 3.8:
        raise ValueError(f"Обрыв линии или ошибка датчика: {current_ma} мА")
    
    # Проверка превышения
    if current_ma > 20.5:
        raise ValueError(f"Превышение тока: {current_ma} мА")
    
    # Линейное масштабирование
    # 4мА = 0%, 20мА = 100%
    pct = (current_ma - 4.0) / 16.0
    return pressure_min + pct * (pressure_max - pressure_min)

# ADC напряжение → ток → давление
def adc_voltage_to_pressure(voltage_v: float, shunt_ohm: float = 250.0,
                             p_min: float = 0.0, p_max: float = 16.0) -> float:
    current_ma = voltage_v / shunt_ohm * 1000.0
    return current_to_pressure(current_ma, p_min, p_max)

# Пример:
voltage = 2.5   # Вольт на шунте 250 Ом
current = 2.5 / 250 * 1000  # = 10 мА
pressure = current_to_pressure(current, 0, 16)  # = 7.5 бар (середина диапазона)

Индуктивные датчики: металл без контакта

Индуктивный датчик (Inductive Proximity Sensor) обнаруживает металлические объекты без физического контакта.

Принцип: высокочастотное электромагнитное поле. При попадании металла в зону — меняется амплитуда генератора → срабатывание.

Дальность обнаружения зависит от металла:

• Сталь (St37): номинальная дальность × 1.0

• Нержавейка (304): × 0.7–0.85

• Алюминий: × 0.4–0.5

• Медь, латунь: × 0.35–0.45

Типичные параметры:

• Диаметр: M8, M12, M18, M30 (стандартные серии)

• Дальность: 2–50 мм

• Выход: NPN или PNP, NO или NC

• Питание: 10–30В DC

• Частота переключения: до 3000–5000 Гц

Пример выбора:

• Считать металлические детали на конвейере: M12, PNP NO, Sn=4 мм

• Контроль положения поршня цилиндра: M8 встраиваемый, PNP NO

Подключение PNP к ПЛК с входом 24В:
+24В ──────── Коричневый провод датчика (питание)
Синий провод ────────────────────────── GND (0В)
Чёрный провод ── DI вход ПЛК ─── 

↗ 24В при срабатывании

NPN подключение к ПЛК: +24В ────────────────────────────── DI

вход ПЛК Чёрный провод ─── DI вход ПЛК ──

↘ 0В при срабатывании

Ёмкостные датчики: любые материалы

Ёмкостной датчик (Capacitive) обнаруживает металлы, пластики, жидкости, порошки, дерево.

Принцип: электрод датчика образует конденсатор с объектом. Приближение объекта → рост ёмкости → срабатывание.

Применения:

• Контроль уровня сыпучих материалов (зерно, цемент, порошки) сквозь стенку ёмкости

• Обнаружение прозрачных объектов (стекло, пластик) — там, где оптика не работает

• Контроль присутствия жидкости в трубе (сквозь пластик)

• Счётчик таблеток/ампул на фармацевтическом конвейере

Особенность: требует настройки чувствительности под конкретный материал и расстояние (потенциометр или IO-Link).

Ультразвуковые датчики уровня

Принцип: излучают ультразвуковой импульс → принимают эхо → время до эха = расстояние.

Расстояние = v_звука × t_эхо / 2
v_звука ≈ 343 м/с при 20°C

Поправка на температуру:
v(T) = 331.5 + 0.606 × T(°C)

При T=40°C: v = 331.5 + 0.606×40 = 355.7 м/с
Ошибка без коррекции при 5м дальности: Δd = 5 × (355.7-343)/343 = 0.185 м = 18.5 см!

Пример: SR-04 (HC-SR04) на Arduino:

// HC-SR04: бюджетный датчик для прототипов (не промышленный!)
// Промышленные: Pepperl+Fuchs, Microsonic, ifm, Banner

const int TRIG_PIN = 9;
const int ECHO_PIN = 10;

void setup() {
    Serial.begin(115200);
    pinMode(TRIG_PIN, OUTPUT);
    pinMode(ECHO_PIN, INPUT);
}

float measure_distance_cm(float temp_celsius = 20.0) {
    // Отправляем импульс 10 мкс
    digitalWrite(TRIG_PIN, LOW);
    delayMicroseconds(2);
    digitalWrite(TRIG_PIN, HIGH);
    delayMicroseconds(10);
    digitalWrite(TRIG_PIN, LOW);
    
    // Измеряем длительность эхо
    unsigned long duration_us = pulseIn(ECHO_PIN, HIGH, 30000);  // таймаут 30 мс
    
    if (duration_us == 0) {
        return -1;  // Объект не найден или слишком далеко
    }
    
    // Расчёт расстояния с коррекцией температуры
    float speed_cms = (331.5 + 0.606 * temp_celsius) * 100.0 / 1000000.0; // см/мкс
    float distance = duration_us * speed_cms / 2.0;
    
    return distance;
}

// Уровень в резервуаре:
float measure_tank_level(float tank_height_cm) {
    float distance = measure_distance_cm(25.0);
    if (distance < 0 || distance > tank_height_cm) return -1;
    
    float level_pct = (1.0 - distance / tank_height_cm) * 100.0;
    return max(0.0f, min(100.0f, level_pct));
}

Мёртвая зона: HC-SR04 не измеряет до 2 см. Промышленные: от 1–3 мм. Проблемы: пена на поверхности жидкости, пыль, ветер, наклонные поверхности, температурные градиенты.

Расходомеры: измерение потока

Электромагнитный (Flowmeter/Магнитный):

• Только электропроводящие жидкости (вода, кислоты, суспензии)

• Нет движущихся частей → долговечность

• Нет потерь давления

• Погрешность: 0.5–1%

• Сигнал: 4–20 мА + импульсный выход (число импульсов = объём)

Вихревой (Vortex):

• Жидкости и газы

• Измеряет частоту вихрей (пропорциональна скорости)

• Минимальный расход: ограничен (при малом расходе не работает)

Ультразвуковой (накладной / inline):

• Накладной: крепится снаружи трубы без врезки!

• Подходит для ретрофита существующих трубопроводов

• Для чистых жидкостей (пузыри искажают сигнал)

Coriolis:

• Измеряет массовый расход напрямую (не объём!)

• Самый точный (0.1%), самый дорогой

• Работает с любыми жидкостями, суспензиями, вязкими средами

Датчики вибрации: предиктивное обслуживание

import numpy as np
from scipy.fft import rfft, rfftfreq
from scipy.signal import find_peaks

class VibrationAnalyzer:
    """
    Анализ вибрации для диагностики подшипников и валов.
    Акселерометр: ADXL345 (I2C) или промышленный 4-20мА.
    """
    
    def __init__(self, sample_rate: int = 1000):
        self.sample_rate = sample_rate
    
    def analyze(self, samples: np.ndarray, machine_rpm: float) -> dict:
        """
        Полный анализ вибрационного сигнала.
        
        machine_rpm: скорость вращения (об/мин) для идентификации гармоник
        """
        n = len(samples)
        
        # === ВРЕМЕННЫЕ ПОКАЗАТЕЛИ ===
        rms   = np.sqrt(np.mean(samples**2))
        peak  = np.max(np.abs(samples))
        crest = peak / rms if rms > 0 else 0
        
        # Эксцесс (Kurtosis): для обнаружения ударных дефектов
        mean = np.mean(samples)
        std  = np.std(samples)
        kurtosis = np.mean(((samples - mean) / std)**4) if std > 0 else 0
        
        # === СПЕКТРАЛЬНЫЙ АНАЛИЗ ===
        # Оконная функция для уменьшения утечек
        window   = np.hanning(n)
        spectrum = np.abs(rfft(samples * window)) * 2 / n
        freqs    = rfftfreq(n, 1.0 / self.sample_rate)
        
        # Основная частота вращения
        f_rotation = machine_rpm / 60.0
        
        # Поиск пиков в спектре
        peaks_idx, peak_props = find_peaks(
            spectrum, height=0.01 * np.max(spectrum), distance=5
        )
        
        peaks = [(float(freqs[i]), float(spectrum[i])) for i in peaks_idx]
        peaks.sort(key=lambda x: -x[1])  # По убыванию амплитуды
        
        # Идентификация характерных частот
        identified = {}
        for freq, amp in peaks[:10]:
            # Гармоники вращения
            for harmonic in range(1, 8):
                if abs(freq - harmonic * f_rotation) < 2.0:
                    identified[f"{harmonic}x_rotation"] = (freq, amp)
        
        # === ДИАГНОСТИКА ===
        # ISO 10816-3: нормы вибрации для промышленных машин
        # Класс 1 (малые): OK<2.3, WARN<4.5, CRIT<7.1 мм/с RMS
        # Класс 2 (средние): OK<4.5, WARN<7.1, CRIT<11.0
        
        rms_velocity_mms = rms / (2 * np.pi * f_rotation) * 1000 if f_rotation > 0 else 0
        
        if rms_velocity_mms < 2.3:
            iso_status = "Зона A (Хорошо)"
        elif rms_velocity_mms < 4.5:
            iso_status = "Зона B (Допустимо)"
        elif rms_velocity_mms < 7.1:
            iso_status = "Зона C (Внимание!)"
        else:
            iso_status = "Зона D (Опасно!)"
        
        # Диагностика по Kurtosis
        if kurtosis > 6:
            bearing_diagnosis = "Дефект подшипника (ударные нагрузки)"
        elif kurtosis > 4:
            bearing_diagnosis = "Начальный износ подшипника"
        else:
            bearing_diagnosis = "Норма"
        
        return {
            'rms_g':           round(rms, 4),
            'peak_g':          round(peak, 4),
            'crest_factor':    round(crest, 2),
            'kurtosis':        round(kurtosis, 2),
            'rms_velocity_mms': round(rms_velocity_mms, 2),
            'iso_status':      iso_status,
            'bearing_status':  bearing_diagnosis,
            'top_frequencies': peaks[:5],
            'identified_harmonics': identified,
        }

Калибровка: без неё данные не достоверны

Каждый датчик имеет погрешности: смещение (offset), нелинейность, дрейф со временем и температурой. Калибровка — сравнение с эталоном и коррекция.

def two_point_calibration(raw_low: float, ref_low: float,
                           raw_high: float, ref_high: float,
                           raw_measured: float) -> float:
    """
    Двухточечная линейная калибровка.
    
    raw_low, raw_high:  показания датчика в нижней и верхней точках
    ref_low, ref_high:  эталонные значения в этих точках
    raw_measured:       текущее показание датчика
    
    Пример: PT100 показывает 99.2 Ом при 0°C (вместо 100) и 138.9 при 100°C (вместо 138.5)
    calibrated = two_point_calibration(99.2, 100.0, 138.9, 138.5, current_reading)
    """
    if raw_high == raw_low:
        return ref_low
    
    # Линейная интерполяция
    slope  = (ref_high - ref_low) / (raw_high - raw_low)
    offset = ref_low - slope * raw_low
    
    return slope * raw_measured + offset

Периодичность калибровки:

• Термопары: ежегодно или при замене

• PT100: 1–2 раза в год (дрейф незначителен)

• Датчики давления: раз в год или при смене диапазона

• Расходомеры: согласно паспорту (обычно 1 раз в год)

Монтаж: правила, которые нельзя игнорировать

Температурные датчики:

✅ Погружение на 1/2–2/3 диаметра трубы

✅ Против потока (для лучшего теплообмена)

✅ Защитный карман (гильза) из нержавейки

❌ На наружной поверхности трубы (ошибка до 50°C!)

❌ В зоне завихрений (после колен, до 10D от колена)

Датчики давления:

✅ Импульсные линии: уклон для самодренажа (для газа — вверх, для жидкости — вниз)

✅ Манометрический вентиль для обслуживания без остановки

❌ Прямое подключение к горячим/агрессивным средам без разделительного сосуда

Индуктивные датчики:

✅ Расстояние > 2× диаметра от соседних металлических поверхностей

✅ Осевая нагрузка — только через крепёжную гайку, не на корпус

❌ Монтаж в металлический кронштейн вплотную (ложные срабатывания)

Заключение

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

Всегда изучайте datasheet: реальный диапазон рабочих температур, степень защиты IP, материал контактной части. И никогда не экономьте на монтаже — половина проблем с датчиками — это неправильный монтаж, а не неисправность прибора.

Почему функциональная безопасность — не формальность

Техасский Сити, 2005 год. Взрыв на нефтеперерабатывающем заводе BP. 15 погибших, 180 раненых, $1.5 млрд ущерба. Причина: переполнение ректификационной колонны — датчик уровня дал неверные показания, система безопасности не сработала.

Бхопал, 1984 год. Утечка метилизоцианата. 3 787 погибших (официально), десятки тысяч раненых. Системы безопасности были отключены для экономии.

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

Базовые концепции

Опасность, риск, допустимый риск

Опасность (Hazard): потенциальный источник вреда (горючий газ, высокое давление, токсичное вещество).

Риск (Risk): комбинация вероятности события и его последствий:

Риск = Вероятность × Тяжесть последствий

Допустимый риск (Tolerable Risk): уровень риска, который общество считает приемлемым. Для промышленных объектов — обычно ≤10⁻⁵/год (один раз в 100 000 лет) для смертельного события.

Независимые защитные слои (IPL — Independent Protection Layer)

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

Слой 1: Базовая система управления (BPCS) — ПЛК основной автоматики
  ↓ не сработала
Слой 2: SIS (Safety Instrumented System) — независимая система безопасности
  ↓ не сработала  
Слой 3: Механические защиты — предохранительный клапан, разрывной диск
  ↓ не сработала
Слой 4: Физические барьеры — обвалование, газоулавливающая система
  ↓
Катастрофа

Каждый слой снижает риск в 10–1000 раз.
Задача: снизить суммарный риск до допустимого уровня.

Стандарты: IEC 61508 и его отраслевые производные

IEC 61508 — базовый стандарт функциональной безопасности для электрических/электронных/программируемых систем безопасности. 7 частей, охватывает весь жизненный цикл.

Отраслевые стандарты (выводятся из 61508):

• IEC 61511 — нефтехимия, газ, химия (процессные установки)

• IEC 62061 — машиностроение

• EN 50128 / EN 50129 — железнодорожный транспорт

• IEC 60601 — медицинское оборудование

• DO-178C — авиационное ПО

Уровни полноты безопасности (SIL)

SIL (Safety Integrity Level) — дискретная мера целостности функции безопасности. Определяется вероятностью отказа при выполнении функции по требованию:

PFDavg — средняя вероятность отказа в режиме ожидания (датчик не сработал когда нужно).

PFH — частота опасных отказов в час (для непрерывных защит).

Расчёт SIL: упрощённый подход

Определение требуемого SIL — через LOPA (Layer of Protection Analysis):

Пример: высокое давление в реакторе может привести к взрыву

Частота инициирующего события: 0.1 /год (раз в 10 лет, типично для BPCS)
Вероятность последствий без защит: 1.0 (взрыв неизбежен)
Тяжесть: катастрофическая (несколько погибших)
Допустимый риск: 10⁻⁵ /год

Требуемое снижение риска:
RRF = Частота × Вероятность / Допустимый риск
RRF = 0.1 × 1.0 / 10⁻⁵ = 10 000

LOPA уже учитывает другие IPL (предохранительный клапан, оператор):
- Предохранительный клапан: снижение в 100 раз (PFD = 0.01)
- Независимый алярм оператора: снижение в 10 раз

Оставшийся RRF для SIS: 10 000 / (100 × 10) = 10
PFD_SIS = 1/10 = 0.1 → SIL 1 (10⁻² ... 10⁻¹)

Если предохранительного клапана нет: PFD_SIS = 0.001 → SIL 2

Архитектура Safety Instrumented System

Типовая SIS архитектура для SIL 2:

  Датчики (1oo2 или 2oo3)
       │
  [Логический решатель — Safety PLC]
       │
  Исполнительные устройства (финальные элементы)
  
1oo1: один из одного — нет резервирования (SIL 1)
1oo2: один из двух — высокая готовность, ложные срабатывания
2oo2: два из двух — низкая доступность к опасности, ложные отказы
2oo3: два из трёх — оптимальный баланс (SIL 2-3)

Для SIL 2 часто используют:
- Датчики: 1oo2D (один из двух с диагностикой) или 2oo3
- Logic Solver: 1oo1D (один с диагностикой) или 1oo2
- Финальные элементы: 1oo1 (один клапан) или 1oo2 (два параллельных)

Safety PLC: ключевые отличия от обычных ПЛК

Safety PLC (FS-PLC — Fail-Safe PLC) — это не просто обычный ПЛК с "безопасным" лейблом. Конструктивные отличия:

Аппаратные:

• Двойное/тройное резервирование процессора

• Непрерывная взаимная проверка процессоров (cross-checking)

• Ошибка → переход в безопасное состояние (обычно: все выходы = 0)

• Диагностика: обнаружение > 99% опасных отказов (DC — Diagnostic Coverage)

• Специальные I/O модули с самодиагностикой

Программные:

• Память программы верифицирована (CRC/хэш)

• Данные хранятся дважды или с кодом исправления ошибок

• Принцип fail-safe: при любой неопределённости → безопасное состояние

• Ограниченный набор инструкций (только сертифицированные блоки)

Популярные Safety PLC:

• Siemens SIMATIC S7-300F / S7-400F / S7-1500F

• Rockwell Allen-Bradley GuardLogix 5580

• Schneider Modicon M580 Safety

• ABB AC500-S

• Pilz PSS 4000

Программирование Safety PLC: особенности

На примере Siemens S7-1500F + TIA Portal Safety:

Ключевые принципы программирования Safety:

1. Fail-safe блоки (FB) vs Standard блоки
   - Безопасный код должен использовать ТОЛЬКО сертифицированные F-блоки
   - Смешивание: Standard → F OK; F → Standard НЕЛЬЗЯ без копирования

2. F-Signature: каждый F-блок имеет уникальную подпись
   - Изменение любого бита → другая подпись → требует повторной верификации

3. Consistent data transfer:
   - При передаче данных между F и Standard зонами — специальная процедура
   - Данные защищены от случайного изменения

4. Passivation: при ошибке датчика — F-код устанавливает безопасное значение (0 или FALSE)
   - Программа должна обрабатывать пассивацию явно!

(* Пример F-программы на Structured Text (S7-1500F / TIA Portal) *)
(* Функция безопасности: аварийная остановка при высоком давлении *)

FUNCTION_BLOCK FB_PressureShutdown
VAR_INPUT
    PressureHigh_1 : BOOL;     // Датчик высокого давления 1 (активен = HIGH)
    PressureHigh_2 : BOOL;     // Датчик высокого давления 2 (резервный)
    EStop_1        : BOOL;     // Кнопка аварийной остановки 1
    EStop_2        : BOOL;     // Кнопка аварийной остановки 2
    Reset          : BOOL;     // Сброс защиты (после устранения причины)
    
    // Каналы датчиков (после F_DI блока)
    CH_Pressure_1  : BOOL;     // TRUE = канал исправен
    CH_Pressure_2  : BOOL;
    CH_EStop_1     : BOOL;
    CH_EStop_2     : BOOL;
END_VAR

VAR_OUTPUT
    ShutdownCommand : BOOL;    // TRUE = закрыть клапан, остановить насосы
    AlarmActive     : BOOL;    // TRUE = авария активна
    AlarmCode       : INT;     // Код аварии
    ReadyToReset    : BOOL;    // Можно сбросить (причина устранена)
END_VAR

VAR
    Trip_Pressure   : BOOL;
    Trip_EStop      : BOOL;
    Trip_ChannelFault : BOOL;
    TripLatch       : SR;      // SR-триггер (Set-Reset)
END_VAR

(* Анализ датчиков давления (1oo2 логика) *)
(* Срабатывание при ЛЮБОМ из двух датчиков *)
Trip_Pressure := (PressureHigh_1 AND CH_Pressure_1) OR
                 (PressureHigh_2 AND CH_Pressure_2);

(* Кнопка аварийной остановки (2oo2 логика для предотвращения ложных срабатываний) *)
(* Исправный канал при нажатой кнопке EStop: NC контакт → LOW *)
Trip_EStop := (NOT EStop_1 AND CH_EStop_1) OR
              (NOT EStop_2 AND CH_EStop_2);

(* Отказ канала датчика = безопасное состояние (принцип fail-safe) *)
Trip_ChannelFault := NOT CH_Pressure_1 OR NOT CH_Pressure_2 OR
                     NOT CH_EStop_1   OR NOT CH_EStop_2;

(* Защёлка аварии: Set при любой причине, Reset только при явном сбросе *)
TripLatch(
    SET1 := Trip_Pressure OR Trip_EStop OR Trip_ChannelFault,
    RESET := Reset AND NOT (Trip_Pressure OR Trip_EStop OR Trip_ChannelFault)
    (* Нельзя сбросить пока причина активна! *)
);

ShutdownCommand := TripLatch.Q1;
AlarmActive     := ShutdownCommand;

(* Определяем код аварии *)
IF Trip_ChannelFault THEN
    AlarmCode := 3;  (* Наивысший приоритет: отказ диагностики *)
ELSIF Trip_EStop THEN
    AlarmCode := 2;
ELSIF Trip_Pressure THEN
    AlarmCode := 1;
ELSE
    AlarmCode := 0;
END_IF;

(* Условие готовности к сбросу *)
ReadyToReset := AlarmActive AND
                NOT Trip_Pressure AND NOT Trip_EStop AND NOT Trip_ChannelFault;

END_FUNCTION_BLOCK

Финальные элементы: клапаны и их диагностика

Финальный элемент (обычно отсечной клапан) — самое слабое место SIS. Клапан может "прикипеть" в открытом положении — и не закроется по команде.

Диагностика финальных элементов:

Частичное хождение клапана (Partial Valve Stroke Test, PVST):
- Раз в 3-6 месяцев в рабочем режиме
- Клапан закрывается на 10-15% от полного хода
- Проверяется отклик (позиционер, время отклика)
- Полное закрытие не происходит → нет нарушения производства
- Сокращает интервал плановой проверки → снижает PFD

Полная проверка (Full Stroke Test):
- При плановом останове (раз в год или реже)
- Полное закрытие, замер времени
- Проверка концевых выключателей

def calculate_pfd_valve_with_pvst(
    pfd_full_stroke: float,    # PFD без диагностики
    pvst_coverage:   float,    # Покрытие диагностикой PVST (обычно 0.6-0.8)
    pvst_interval_months: int, # Интервал PVST
    full_test_interval_years: int  # Интервал полной проверки
) -> dict:
    """
    Расчёт PFD финального элемента с учётом PVST.
    
    Упрощённая модель (для точного расчёта — IEC 61511-1 Annex K).
    """
    
    # Частота опасных отказов (из datasheet производителя или OREDA)
    # Например, для шарового клапана DN100: lambda_D ≈ 1e-6 /час
    lambda_d = pfd_full_stroke / (full_test_interval_years * 8760 / 2)
    
    # PFD без PVST (только полная проверка раз в год)
    pfd_no_pvst = lambda_d * full_test_interval_years * 8760 / 2
    
    # PFD с PVST: диагностика снижает эффективный интервал
    # PFD_pvst ≈ PFD_full × (1 - DC_pvst) + PFD_full × DC_pvst × (Ti_pvst/Ti_full)
    pvst_interval_years = pvst_interval_months / 12
    
    pfd_with_pvst = (pfd_no_pvst * (1 - pvst_coverage) +
                     pfd_no_pvst * pvst_coverage * 
                     (pvst_interval_years / full_test_interval_years))
    
    reduction_factor = pfd_no_pvst / pfd_with_pvst if pfd_with_pvst > 0 else 1
    
    return {
        'pfd_without_pvst':  round(pfd_no_pvst, 6),
        'pfd_with_pvst':     round(pfd_with_pvst, 6),
        'reduction_factor':  round(reduction_factor, 1),
        'sil_without_pvst':  1 if pfd_no_pvst >= 1e-2 else 2 if pfd_no_pvst >= 1e-3 else 3,
        'sil_with_pvst':     1 if pfd_with_pvst >= 1e-2 else 2 if pfd_with_pvst >= 1e-3 else 3,
    }

# Пример расчёта:
result = calculate_pfd_valve_with_pvst(
    pfd_full_stroke      = 0.01,   # PFD при ежегодном тестировании = SIL 1
    pvst_coverage        = 0.7,    # PVST выявляет 70% опасных отказов
    pvst_interval_months = 3,      # PVST раз в квартал
    full_test_interval_years = 1
)
print(f"PFD без PVST: {result['pfd_without_pvst']} (SIL {result['sil_without_pvst']})")
print(f"PFD с PVST:   {result['pfd_with_pvst']} (SIL {result['sil_with_pvst']})")
print(f"Снижение PFD: в {result['reduction_factor']} раз")

Жизненный цикл SIS: от концепции до вывода из эксплуатации

По IEC 61511, жизненный цикл SIS включает 16 фаз:

Фаза 1-4: Анализ
  1. Анализ опасностей (HAZOP)
  2. Оценка рисков (SIL Determination / LOPA)
  3. Концепция безопасности
  4. Требования к SIS (SRS — Safety Requirements Specification)

Фаза 5-9: Проектирование
  5. Архитектура SIS
  6. Выбор оборудования
  7. Проектирование F-программы
  8. Factory Acceptance Test (FAT)
  9. Site Acceptance Test (SAT)

Фаза 10-13: Эксплуатация
  10. Ввод в эксплуатацию
  11. Плановое техническое обслуживание
  12. Периодическое функциональное тестирование (Proof Test)
  13. Управление изменениями (MOC — Management of Change)

Фаза 14-16: Завершение
  14. Вывод из эксплуатации
  15. Оценка соответствия (SIL Verification)
  16. Функциональная оценка (Functional Safety Assessment)

HAZOP: анализ опасностей и работоспособности

HAZOP (Hazard and Operability Study) — методология анализа, где команда экспертов применяет "направляющие слова" к каждому параметру процесса:

Направляющие слова × Параметры → Отклонения → Последствия → Защиты

Параметры: расход, температура, давление, уровень, состав, время
Направляющие слова: Нет, Больше, Меньше, Другое, Обратное, Часть

Примеры:
"Нет расхода" → охладитель не подаётся → перегрев реактора → взрыв
  Защита: датчик расхода + BPCS блокировка; SIS ESD; предохранительный клапан

"Больше давления" → разрыв оборудования → утечка газа → взрыв/пожар
  Защита: HS датчик давления + SIS; предохранительный клапан на 120% рабочего

"Обратный поток" → смешение несовместимых реагентов
  Защита: обратный клапан; двойная задвижка с блоком (Double Block & Bleed)

Практические советы по SIS-проектам

1. Независимость — не просто разные ПЛК Датчики SIS и BPCS должны быть на РАЗНЫХ отборах давления/температуры, разных кабелях, разных шинах питания. Один кабельный канал для обоих = нет независимости.

2. Воздействие оператора — только через стандартный HMI Обход (bypass) защиты — только физический (байпасный выключатель), с аудитом и процедурой. Никакого программного обхода через меню!

3. Документируйте каждое изменение через MOC Изменение уставки датчика, замена компонента, изменение программы — всё через официальную процедуру управления изменениями. Иначе следующий HAZOP или audit найдёт несоответствие.

4. Proof Test — проводите регулярно и документируйте PFD рассчитан на конкретный интервал тестирования. Пропустили proof test — ваш SIL больше не действителен формально (и реально выше PFD).

Заключение

Функциональная безопасность — это та область, где нет места импровизации. Стандарты IEC 61508/61511 написаны на основе реальных промышленных катастроф и содержат выверенные методологии.

Для старта: изучите IEC 61511 (он ориентирован на процессные установки и более практичный, чем базовый 61508). Пройдите курс TÜV Rheinland или TÜV SÜD по Functional Safety Engineer — они дают систематическое понимание и признаваемый сертификат.

И помните: в функциональной безопасности "достаточно хорошо" и "почти правильно" не существует. Либо соответствует SIL, либо нет. Промежуточных значений нет.