Что такое «протокол»?

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

Так что же такое протокол?

Обычно, говоря о протоколе – имеется в виду протокол передачи данных. Рассмотрим на примере для чего он нужен: датчик движения срабатывает и должен отправить данные о том, что он сработал исполнительному устройству, затем, получив данные, исполнительное устройство включается и отправляет данные о том, что оно включилось в контроллер, который отправит эту информацию на панели управления и в интерфейс смартфона. Для того чтобы это сработало описанным образом – задействуется протокол передачи данных, к примеру KNX, между устройствами и протокол передачи данных по TCP/IP и Wi-Fi для того, чтобы отправить информацию о включении на смартфон.

Любой протокол делится на несколько уровней:

Физический – по какому физическому интерфейсу будут передаваться данные.

Если говорить о системах автоматизации, то, как правило, используются либо проводные (шина KNX, шина Dali, RS-485, RS-232, CAN-bus, Ethernet и т.д.) либо радио (Bluetooth Low Energy (BLE), Z-wave, ZigBee, 433 МГц, Wi-Fi 2,4 МГц и 5 МГц, KNX RF и т.д.).

Для проводных систем необходимо определить, как соединять устройства друг с другом в системе (какая топология – дерево, звезда, параллельное подключение, последовательное и т.п.), какой тип интерфейса (подключения проводов к устройствам) использовать и какие требования к проводам (линии передачи данных).

Для систем, с передачей данных радиоволнам необходимо определиться с используемой частотой радиоволны и уровнем сигнала, чтобы устройство могло передавать сигнал на выбранное расстояние.

Далее нужно определить то, как будет передаваться 0, а как 1. К примеру, в шине KNX сигнал передаётся с помощью модулирования напряжения на шине (проводах), причём 0 — это импульс в 6 Вольт, а 1 – это отсутствие импульса. Данные передаются по двум проводам вместе с питанием. Есть протоколы, где линии питания и линии сигнала разделены. В некоторых из них 1 – это +3 Вольта, 0 – это -3 Вольта или наоборот. Напряжение тоже может быть разным. Под линией имеются ввиду провода, соединяющие устройства, к примеру для протокола Modbus RTU, подключённого по шине RS-485: линия питания (для  подключённого устройства идёт отдельно от шины RS-485, и может быть как 220 Вольт переменного тока, так и рассчитанной для постоянного тока) – двужильный провод (фаза и нейтраль или, в случае с постоянным током «+» и «-»), и линия данных, представляющая из себя двужильный провод (часто используют две жилы кабеля типа витая пара) с обозначениями либо А и В, либо + и -, в зависимости от производителя.

Так как на одной линии шины (проводов) как правило находится несколько устройств, то необходимо определить, как будет определяться именно то устройство, которому предназначается та или иная команда. В большинстве случаев каждое устройство получает свой уникальный адрес в рамках системы. Иногда это происходит автоматически, иногда необходимо назначать адрес вручную.

После этого необходимо определить какие данные помимо адреса будут входить в пакет данных, который одно устройство будет отправлять другому. Под «пакетом» понимается одна передача от одного устройства другому, к примеру, датчик движения передаёт исполнительному устройству данные что он сработал.

Определившись с тем, что будет входить в пакет данных, необходимо определиться с тем, будет ли как-то фиксироваться информация о том, что пакет данных дошёл до адресата в целости и сохранности. В данном случае идеальным примером будет разница протоколов TCP и UDP, которые применяются в передаче данных по локальной сети Ethernet и по сети Интернет. Если вы, к примеру, заходите на сайт, то как правило применяются пакеты TCP, которые требуют обязательной проверки на целостность и отправки отчёта о получении. Если с информацией в пакете что-то произошло, то сервер, отправивший вам этот пакет, получив отчёт о неполном или повреждённом пакете, отправит вам его снова. Таким образом сайт загрузится целиком в любом случае, но из-за того, что некоторые пакеты данных придётся отправлять по несколько раз, то могут быть задержки. А если вы совершаете аудио или видео звонок через какой-либо мессенджер, то используются пакеты UDP, которые не требуют такой проверки на целостность. Сервер не будет приостанавливать передачу остальных пакетов данных, пока вы не получите целый и невредимый каждый пакет данных. При некачественном соединении с сервером в случае с проверкой мы получили бы ощутимые задержки и даже простой разговор превратился в муку для каждого собеседника. Но так как проверки на целостность нет, то в итоге мы не имеем ощутимых задержек, но иногда получаем так называемый робо-голос со стороны собеседника, видео «гличи» и т.д., как раз из-за повреждённых пакетов, а иногда связь прерывается из-за того, что пакеты просто недошли.

После этого возникает вопрос: а что будет, если два датчика начнут передачу информации в одно время? Для некоторых протоколов этот вопрос не актуален, к примеру Modbus RTU, так как там сам по себе датчик не отправляет данные. В данном протоколе устройства делятся на Master и Slave. На одной шине может быть только одно Master устройство, остальные должны быть Slave. Master устройство постоянно опрашивает все Slave устройства, обновляет и хранит их состояние у себя в памяти. Именно поэтому два устройства одновременно никак не могут начать отправку пакетов. Но для многих других протоколов были придуманы специальные правила очерёдности и проверки линии на то, что в данный момент никто не отправляет данные.

Напоследок возникает вопрос с точки зрения безопасности: а как будет защищена передача информации? То есть:

1. Сможет ли кто-то физически подключиться к линии передачи?
2. Сможет ли он что-то увидеть?
3. Сможет ли он что-то отправить?

Если рассматривать протокол Z-wave, то есть специальные устройства, которые позволяют посмотреть так называемый радиоэфир. Но оно просто покажет, что одно устройство отправило какие-то данные другому устройству. Разобраться что это за устройства и, соответственно, что именно передавалось (температура, освещённость, уровень яркости и пр.) не получится, а тем более отправить какую-либо команду, так как необходимо знать id устройства, id z-wave сети и какую именно команду этому устройству нужно отправить.

Для того чтобы совсем защититься от «подглядываний» создали несколько версий шифрования данных. Для Z-wave это S0, S2.

Основные принципы при создании протокола обмена данными мы разобрали.

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

К примеру, почему для умных домов на радиочастоте были созданы протоколы Z-wave, Zigbee, Bluetooth low energy, а не использовали тот же Wi-Fi? Ответ прост: для того, чтобы сделать систему умного дома простой для установки обычным обывателем, а также сделать её мобильной и плюс к этому сделать так, чтобы для её установки не приходилось делать ремонт в помещении, нужно было создать некоторые устройства с питанием от батареек или встроенного аккумулятора. Протокол Wi-Fi сам по себе достаточно «тяжёлый», так как пакеты полезных данных сначала упаковываются в пакеты TCP, UDP и пр., со своими правилами, а потом уже упаковываются поверх в пакет для передачи по Wi-Fi. И такой способ передачи очень энергозатратный, поэтому батарейки долго работать не смогут. Классический Bluetooth тоже обладает рядом недостатков, которые являются критическими для этой задачи. Протокол, 433 (работающий на частоте 433 МГц) не обладает функцией подтверждения получения пакета данных с проверкой на целостность, поэтому является ненадёжным решением в данном случае. Поэтому несколько компаний разработали свои протоколы передачи данных, которые были бы оптимальными для данных задач.

Но как же поступить, когда есть освещение, управляющееся по протоколу Dali, котёл, управляющийся по протоколу OpenTherm, вентиляция, управляющаяся по протоколу Modbus, терморегуляторы на батареях отопления, работающие по протоколу KNX, а логику включения, выключения и работы нужно использовать общую и в одном интерфейсе? В данном случае необходимо использовать шлюзы. Это оборудование, которое способно понимать два протокола, к примеру Modbus переводит в KNX и наоборот. Такими шлюзами мы собираем все данные из разных протоколов в один, который будет основным, на котором будет прописана логика работы всего оборудования, включая оборудование из разных протоколов. В таком случае, мы получаем систему, собранную из устройств, работающих на различных интерфейсах и протоколах, которые работают согласовано друг с другом.

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