Почему мы решили обновить протокол MODBUS RTU, которому исполнилось 40 лет и как появился его потомок – idiBus
Мы хотели сократить время разработки, чтобы снизить для клиентов стоимость автоматизации их устройств. Как это связано со снижением цен на цифровую электронику за последние 40 лет. Ниже описаны наши мотивы, страдания и их результат.
Мы — это команда разработчиков, которая производит разнообразную электронику для автоматизации. Очень разную. Это и профессиональные холодильники, и бассейны и мини химзаводы и разные другие устройства АСУ ТП, которые выпускаются малыми сериями. Автоматизация обычно идет двумя путями. Первый — это создание одного специализированного набора управляющей электроники, который заказчик будет устанавливать в свое устройство. Заказчик дает ТЗ, по которому и производится разработка. Устройство получается уникальным и при большом тираже дешевым потому, что никаких лишних функций оно не содержит, ничего кроме управляющего контроллера и нужной периферии. Второй путь — это использование свободно программируемых контроллеров, которые через шину работают с периферийными устройствами.
Если устройство будет выпускаться большим тиражом, то путь выпуска специализированной платы выгоден. Стоимость разработки в этом случае высока, но сами устройства получаются дешевыми.
Ну, а если заказчик не знает какой будет тираж? Или до конца не уверен во всех функциях своего изделия? Ответ давно известен — применение свободно программируемых контроллеров разных производителей. OMRON, Schneider Electric, HITACHI и множество других фирм выпускают контроллеры, а другие фирмы выпускают датчики, управляющие устройства и другую периферию. Наиболее популярный в мире протокол для связи контроллеров и периферии на сегодня это MODBUS RTU. Википедия утверждает, что стандарт этого протокола был утвержден в 1979 году. В том далеком году цифровая техника стоила крайне дорого и существенных денег стоил каждый бит памяти. А вот аналоговые устройства были дешевы.
Для чего был придуман протокол MODBUS? Для обмена данными между устройствами, обеспечивающими автоматизацию технологических процессов. 40 лет назад речь не шла даже о мегабайтах памяти. Первый IBM PC с гибкими дискетами на 300 кБ появился только через пару лет. И вот как результат тогдашних цен на память и появился этот и поныне самый популярный в мире протокол. Его еще именуют полевой шиной, так как эта шина как бы связывает устройства, находящиеся «в поле» с главным устройством управления.
Мы, как команда разработчиков с опытом в десятки лет, конечно всегда стремимся идти по наиболее технически и экономически выгодному варианту. Нету никакого пафоса и гордости в том, что бы вместо применения комбинации готовых устройств, доступных на рынке с некоторой долей программирования взять и начать собственную разработку. Отладку аппаратной части и написание своих собственных программ. Заказчику же важно соотношение цена/качество или цена/время. У него нет желания потренировать наше знание схемотехники.
Ну и конечно мы неоднократно пробовали вместо собственной разработки использовать готовые свободно программируемые контроллеры. И каждый раз оказывалось, что все не так просто и быстро, как хотелось бы. Сами контроллеры устроены достаточно просто. Но уже первая с ними проблема — отсутствие единой среды программирования и вообще само их программирование на уровне соединения реле, катушек и контактов. Вот например OMRON программируется на языке LD. Или ST. А Schneider Electric имеет свою среду программирования EcoStruxure Machine Expert. Carel тоже имеет свой 1tool.
Каждый производитель стремиться максимально затруднить переход проектировщиков и разработчиков с его оборудования на любое другое. Но поскольку выпустить все, что может понадобиться из периферийных устройств, не может пока ни один производитель, то все они вынуждены все же иметь способы подключения сторонних устройств. Это как я уже писал — протокол MODBUS в его версии MODBUS RTU. Существуют и другие протоколы и полевые шины, такие как CAN, FIELDBUS, PROFIBUS, которые бывают или открытые или частные.
Но даже если отбросить несовместимость сред программирования, все эти протоколы обмена объединяет одно — необходимость работать с битами и регистрами. Причина тому проста — старость протокола. В те годы, когда самый популярный протокол MODBUS RTU был разработан, нормой было работать с битами и регистрами.
Представьте себе, что в 2020 году вам предложили начать программировать в кодах. Даже не в ассемблере, а прямо в кодах и регистрах. Нет никаких библиотек высокого уровня. Нет никакого объектного программирования. Вы не можете программировать на С++ и вообще ни на чем кроме переключателя регистров.
Давайте представим простую систему.
На шине стоит контроллер. К ней подключен термометр в помещении с адресом 01 и к ней же подключен мотор управления форточкой на адресе 02.
Вам надо узнавать какая температура и, если жарко, открывать форточку.
Пример №1
Используем библиотечную функцию от термометра GetTemperature (int Addr) и такую же библиотечную функцию от привода открывания окна OpenWindow(int Addr, int Percent);
if (GetTemperature(01)>24) {OpenWindow(02,20);};
if (GetTemperature(01)>30) {OpenWindow(02,40);};
Мы в программе можем просто запросить у устройства на адресе #01 температуру и потом дать команду другому устройству на адресе #02 на сколько процентов открыть окно.
Пример №2
Те же термометр и привод открывания окна. Но оба устройства «совместимы с MODBUS RTU»
Вы читаете документацию к термометру и приводу и проделываете примерно следующее:
Если вы хотите прочитать значение аналогового вывода, то надо послать команду 0×03. К вам придет PDU. Протокол Дата Юнит. А далее надо вынуть нужную вам информацию.
Что бы ее получить надо как-то понять вот этот текст, который взят со страницы
https://ipc2u.ru/articles/prostye-resheniya/modbus-rtu/#read_analog_out:
Данные в модуле хранятся в 4 таблицах. Две таблицы доступны только для чтения и две для чтения-записи. В каждой таблице помещается 9999 значений. В сообщении Modbus используется адрес регистра.Например, первый регистр AO Holding Register, имеет номер 40001, но его адрес равен 0000. Разница между этими двумя величинами есть смещение offset. Каждая таблица имеет свое смещение, соответственно: 1, 10001, 30001 и 40001. Ниже приведен пример запроса Modbus RTU для получения значения аналогового выхода (holding registers) из регистров от #40108 до 40110 с адресом устройства 17.
Расшифровка PDU MODBUS RTU
Помните чуть выше в примере №1 было как-то все сильно проще? Библиотечная функция просто сразу возвращала физическую величину из устройства, которое имеет свой адрес на шине.
Откуда же такая разница? Корень этой разницы лежит в разницы цены на 1 бит информации в 1970 году и в 2020. Сегодня биты и такты микропроцессоров подешевели в тысячи раз. В 1970 году они стоили настолько дорого, что вся обработка данных от цифровых датчиков и происходила на стороне центрального контроллера. Или даже центрального процессора. Аналоговые устройства на шине не могли обрабатывать данные потому, что это было слишком дорого. Вся обработка данных происходила на стороне Master. Поскольку он обладал наиболее мощной для тех времен вычислительной способностью.
Аналоговые устройства стоили относительно цифровых в 1970 году радикально дешевле. Но в 2020 году ситуация стала абсолютно обратной. 32-х разрядный чип с кучей периферии, с АЦП и таймерами, 4 UART, SPI и прочими интерфейсами стоит всего 200 рублей.
Что нам дает такое переворачивание пропорций цен на «цифру» и «аналог»? Теперь мы можем практически не увеличив цену датчиков и исполнительных устройств поручить им еще и перевод своих внутренних данных в понятные человеку физические величины и вообще перейти от работы с регистрами к работе с данными в нужном нам формате.
Хотите данные с часов реального времени? Ну так ясно же, что самый удобный и быстрый вариант получения его это библиотечная функция GetTime(int Addr), из библиотеки, которая вам выдается при покупке этих часов. Вам надо узнать частоту вращения вала двигателя от цифрового датчика? GetMotorSpeed(int Addr).
Снижение цен на микроконтроллеры дало возможность перенести цифровую обработку на сторону самого устройства на шине. Оно на сегодня без удорожания может обслуживать самые сложные протоколы.
Надо было дать имя наследнику MODBUS RTU.
Intellectual Digital Bus — idiBus
Это шина типа Master-Slave, как и ее предок — MODBUS RTU
Физический уровень сохранился и это RS-485. Но на современном уровне развития электроники скорость этого соединения уже может быть 10 МБ/с.
Какие еще возможности появились в связи с новым соотношением цен digital/analog?
Шифрование. В эпоху, когда злонамеренные лица могут пытаться нарушить работу предприятий, систем или оборудования уже неприлично передавать по шине нешифрованные данные.
Обновление прошивок по шине. Аналоговые устройства не обновлялись. Как можно обновить термопару? Но сегодня разработчики уже произведенных устройств могут увеличивать их точность, добавлять сервисные функции и они хотели бы иметь возможность загружать в свои устройства обновления, не отключая их от шины и не демонтируя. idiBus дает такую возможность.
Одновременное считывание показаний и одновременное включение устройств. На шине idiBusопрашивание устройств последовательное. Но если нужно в разных местах одновременно произвести замер неких величин, то можно объединить устройства в общую логическую группу и затем дать всей группе команду на считывание. Точно также можно давать команду на исполнение. Ну например открыть одновременно все ворота на ипподроме.
Внеочередное обращение к Master. В протоколе имеется временное окно, в которое может обратится Slaveк Мaster, сообщив об экстренной ситуации. Каждое из устройств на шине может прервать последовательность опроса и обратить внимание на себя.
Спящий и безопасный режим. Экономия энергии может достигаться отключением аналоговой части устройств на шине и сохранения только функций обмена. На сегодня экономия энергии это популярный тренд.
Обратная совместимость с MODBUS RTU. Устройства idiBus могут находиться на одной физической шине с устройствами MODBUS RTU и Master idiBus может к ним обращаться.
Стандартная обработка ошибок передачи данных. Существенно более продвинутая, чем в древних протоколах.
Задачей создания новой шины и нового протокола была экономия средств на разработку. В России к нашему общему сожалению не производятся сверх массовые простые устройства. Технологический уровень страны более приспособлен к выпуску не больших партий более дорогих устройств, чем простая микроволновка или стиральная машина. Малые тиражи выпуска техники требуют от разработчиков их систем управления максимального снижения цены и сроков именно разработки. Больше половины стоимости разработки станка/бетономешалки/крана/лифта составляют затраты на программирование.
То есть на программистов. Политика крупных вендоров на предотвращение стандартизации и унификации привела к тому, что программисты, имеющие опыт работы с конкретными средствами разработки конкретных вендоров стоят дорого. И их мало. Поэтому и стоят они дорого.
Наша подход заключается в том, что надо дать возможность программирования на универсальных языках программирования. Прежде всего на С++, так как этому языку обучают сегодня во всех школах и ВУЗах. Это наиболее популярный язык и он имеет самый широкий круг программистов. И этот фактор определяет их цену и доступность — самую лучшую на сегодняшнем рынке программирования.
Набор стандартных библиотек для устройств шины idiBus для C++ обеспечивает еще одно важное качество — отсутствие необходимости программисту иметь знания и опыт работы с микроконтроллерами. Он просто работает с библиотеками от конечных устройств. С физическими величинами. Достаточно указать адрес на шине и установить этот адрес на самом устройстве.
Для еще большего расширения возможного круга программистов мы даже обеспечили совместимость с ARDUINO. А это означает, что любой школьник после кружка робототехники уже может приступать к профессиональной деятельности в качестве разработчика системы АСУТП.
После нескольких лет изысканий наследник MODBUS RTU был разработан и испытан прямо на себе. На устройствах шины idiBus мы разработали установку для производства дезинфекционного состава за 4 недели. Конечно никакая индивидуальная разработка за такое время сделана быть не может. Следующим устройством был профессиональный шкаф акустической заморозки. Время разработки до серийного внедрения — 2 недели.
Добавим еще факт, что разработчиками выступали студенты старших курсов МИЭТ. Откуда такие скорости разработки? Готовые отлаженные библиотеки вообще не требуют знания о периферийном устройстве. Никаких чтений мануалов. Никаких изучений регистров и портов. Просто #inclule и GetData (int Addr).
У самой шины есть и другие плюсы, которые обусловлены тем, что 2022 год это не 1970. В отличие от одной линии MODBUS RTU, idiBus имеет на шине две одинаковые линии RS-485. Каждая из которых может работать с разной скоростью. При скорости 115200 Бит/с дальность связи составит 1,2 км. А при скорости 10 МБит/с — 10 метров. Таким образом скоростной вариант можно использовать для работы внутри устройства или установки, а более медленный для работы в масштабе предприятия.
Приглашаем разработчиков к соучастию
Разработав новую современную версию MODBUS мы обнаружили еще один интересный момент в жизни автоматизаторов и разработчиков АСУ ТП. Это все больший отрыв крупных игроков — производителей свободно программируемых контроллеров и всяких устройств автоматизации от тенденций в развитии языков программирования.
Россия как член МЭК — международной энергетической комиссии ввела стандарт МЭК 61784–1:2014 «Промышленные сети. Профили. Часть 1. Профили полевых шин» (IEC 61784–1:2014 «Industrial communication networks — Profiles — Part 1: Fieldbus profiles», IDT).
Как вы думаете, как много компаний в России, кто в курсе, что это за такой стандарт на полевые шины? И есть второй не менее интересный вопрос. А что там с языком программирования устройств для этих полевых шин?
А вот что. Стандарт описывает этот самый язык. Который у нас никому не ведом. И в Иране. И в Африке и в Китае и вообще много где.
Вот что говорят про эти языки: «Языки программирования стандарта МЭК 6–1131/3 включают в себя 3 визуальных языка (FBD, SFC, LD), ориентированных на инженеров и бизнес‑аналитиков и 2 текстовых (ST, IL), ориентированных на программистов. С помощью языков IEC 61 131–3 одинаково комфортно программируются и контроллеры, и алгоритмы человеко‑машинного интерфейса (HMI) и задачи EAM и MES.»
Вот цитата из описания »Techno IL это простейший язык мнемонических инструкций, внешне напоминающий ассемблер. Этот язык был включен в стандарт для программирования контроллеров, обладающих низкой вычислительной мощностью.»
Кажется странным, что для каких-то таких задач включить выключить свет и газ требуется один язык программирования, а что бы решить задачу автоматизации мобильного телефона или научных расчетов требуется другой. А в школе и ВУЗе все изучают третий и четвертый.
По нашему убеждению, все большее усложнение языков для АСУ ТП просто приводит их постепенно к некоему подобию старых добрых универсальных языков программирования.
А тем временем уже невозможно найти микроконтроллер, у которого настолько низкая вычислительная мощность, что он не может провернуть программу на С++. Разве что кто-то выпустит микроконтроллер только с двумя ножками — питание и земля.
Сначала в языках АСУ ТП стандарта МЭК не было процедур. Они появились.
Не было объектов и наследования. Вот оно уже на пороге.
Еще немного и все эти недоязыки достигнут уровня C++, Rust или Python и перестанут выглядеть как «простейший язык мнемонических инструкций, внешне напоминающий ассемблер».
Есть еще один важный вопрос, который стоит перед разработчиком нового протокола — это его надежность. Насколько долго может работать протокол без перезагрузки и как он реагирует на появление на шине дефектных устройств.
За 2 года применения idiBus в двух видах установок не было случаев критических сбоев именно по причине дефектов логики протокола. При том, что эти установки работали в разных странах и возможности загрузить новые прошивки мы не имели.
Заключительные слова коллегам — разработчикам устройств автоматизации. О чем мы думаем глядя в будущее.
У нас было два пути, а теперь появился третий. Россия не является производителем и экспортером именно устройств автоматизации. Дисплеев, контроллеров, датчиков, двигателей и наши производители и производства всегда ориентировались на импорт. Россию просто оккупировали Омроны и Шнайдеры. И нам нечего было им противопоставить ввиду существенной раздробленности наших рядов.
Но их старая парадигма и старые протоколы с массой уже выпущеных на рынок устройств могут сыграть нам на руку. Мы можем от их почти аналоговых и почти ассемблерных контроллеров сразу перейти в цифровую эпоху и к цифровому протоколу, радикально упрощающему и удешевляющему время разработки.
Физическая среда протокола idiBus
Новые провода и разъемы мы не изобретали, а взяли максимально доступные на рынке. Это кабель Cat5 и разъемы RJ-45 от кабельной системы Ethernet. Кроме дешевизны есть и еще одно преимущество у этого решения — наличие большого ассортимента patch проводов, которые очень удобно использовать для межплатного соединения.
Спецификация распайки перед вами. Питание передается сразу по линии и 24 вольта взяты для того, что бы по мере удаления от источника питания можно было получить на больших расстояниях стандартные 12 вольт путем установки понижающего DC/DC.
Спецификация кабельной системы idiBus
Парные провода питания и земли дают снижение сопротивления на линии питания. Линии 4 и 5 это буквально физическая совместимость с предшественником MODBUS RTU на тех устройствах, на которых стоят разъемы RJ-45. Это наиболее популярный в мире вариант распайки. Скорости указаны условно. Но они не могут быть любыми. Для idiBus выбрали фиксированный набор скоростей, которые могут быть получены применением популярных частот кварцевых резонаторов.
На каждом устройстве предусматривается выбор скорости. Тройным переключателем S2-S1-S0. Великое многообразие вариантов как мы сегодня знаем вообще не требуется. Обычно всем нужен простой набор. В нашем варианте всего 8 скоростей.
Набор скоростей idiBus
Еще один вид стандартизации — размеры плат и расположения монтажных отверстий
Разработчики протоколов ранее не утруждали себя спецификациями геометрии устройств. Каждый крупный производитель имел свой собственный геометрический формат и собственные межплатные разъемы и их расположение. Мы предполагаем, что для общего удобства необходимо дать варианты спецификаций, придерживаясь которых возможно совмещать устройства разных производителей, не имея нужды гадать при разработке своего устройства, будет ли оно совместимо при установке в корпуса приборов и установок или не будет.
Мировая практика показывает, что обычно для АСУ ТП используются три размерны формата. Компактный формат в собственном корпусе для установки на DIN рейку, крупные собственные корпуса для установки вне корпусов установок и третий формат без корпусной. Его стараются избегать.
Глядя на все это и на условия существования наших электронщиков мы решили начать с бескорпусного стандартного формата. Причины этому две. Первая — цена. Плата без корпуса дешевле и когда оборудование устанавливается в корпус устройства или установки, то в сущности корпуса это лишний элемент. Вторая причина это цена корпусов, Увы, Россия это не Китай. При том, что технологически мы уже все можем выпускать печатные платы нужных размеров, мы не можем дешево заказать корпуса. Это всеобщая проблема России — отсутствие индустриальной среды. Наши мелкосерийные производства не могут себе позволить заказать пластиковый корпус, потому что одна пресс форма стоит не менее 500 тыс рублей. И рассчитана она на 100 тысяч копий. А зачем нам 100 тысяч копий? Никто даже не мечтает от таких тиражах устройств AСУ ТП.
Именно поэтому мы выбрали для старта спецификацию без корпусов. Независимые платы привязаны к сетке размера 12×12 см. На основной материнской плате, которая является Master в качестве мезонина устанавливается плата с основным микроконтроллером. И еще есть платы расширения, которые обеспечивают связь, и на которые можно устанавливать платы расширения тоже в качестве мезонинов. На этих платах расширения не нужно ставить микросхемы для работы с RS-485. Интерфейс и выбор скорости обеспечивает плата расширения.
Вот пример нашей «материнской платы» и платы с управляющим чипом:
Материнская плата обеспечивает выдачу на линию питания 24В
Плата расширения, с модулями расширения.
Плата с основным чипом и интерфейсами для программирования и загрузки прошивки
Размерный ряд плат предусматривают монтаж в виде послойного пирога. Для этого стандартизированы монтажные отверстия. Межплатные соединения используют самые дешевые на рынке разъемы, а фиксацию от вибрации сделали лавсановыми стойками.
Стандартные типоразмеры плат idiBus
Натягивание одеяла на себя или возможность для многих?
Предлагаем всем соучастие и создание национальной системы цифровой автоматизации на базе нашей разработки idiBus, спецификация которого будет бесплатна для всех желающих. Мы пока не думаем о idiBus foundation, но российский рынок не на столько велик, что бы мы могли позволить себе не объединяться на российской открытой платформе.
Дмитрий Балаболин,
Сергей Слепнев
Радиоинженеры,
разработчики электроники
