To CAN or not to CAN?.

RS485 долгое время был и остается очень популярным в системах безопасности для организации среднего уровня связи. Едва ли не все системы используют его хотя бы частично, хотя бы в одном из исполнений. На нижнем уровне безраздельно правят бал сухие контакты и иногда специализированные адресные шлейфы, на верхнем – Ethernet, а основная рабочая лошадка – RS485.
Да, не все системы полагаются на RS485. Некоторые сразу на младших контроллерах используют Ethernet, некоторые – вообще автономны, но в большинстве систем, если требовалось соединить несколько модулей, чаще всего использовали RS485.
Почему?

Он относительно дешев в реализации, относительно нетребователен к качеству кабельной линии (качеству монтажа), при всем том обеспечивает хорошее быстродействие и дальность передачи. Скажем так, приемлемое быстродействие и достаточную дальность передачи.
Сравнительно с ним Ethernet значительно дороже, для сколько-то разумных расстояний требуется строить инфраструктуру роутеров, коммутаторов и разнотипной разводки (оптика и т. д.) и весьма требователен к качеству кабельной сети. Наконец, Ethernet (в варианте медная витая пара) не может ныне использоваться в системах противопожарной автоматики, ибо недорогие огнестойкие кабели (а по действующему техническому регламенту все кабели в системах пожарной автоматики должны быть огнестойкими) не могут сохранить качество (категорию) в огне. Как правило, огнестойкость достигается за счет наличия тонкой негорючей оплетки из проволоки или пленки, защищающей провода от замыкания в случае выгорания изоляции, – замыкания не будет, но говорить о соблюдении требований Category-5 после выгорания оболочки не приходится.
Так неужели же нет альтернативы и до сих пор ничего лучшего, чем стандарт RS485 образца 1983 г., так и не придумали?
Конечно, придумали альтернативу, и даже не одну. Очень интересным представляется, например, стандарт CAN, разработанный в компании Bosch первоначально для автомобильных применений. После выхода в 1991 г. второй версии спецификации стандарт стал международным и довольно широко распространился за пределами первоначальной отрасли (автомобилестроения).
Лет 10 назад он стал популярным и в отрасли безопасности, появились многочисленные сообщения о разработке аппаратуры систем безопасности, основанной не на RS485, а на CAN. Но почему-то за прошедшее время таких систем в реальном применении появилось не так и много, а большинство первоначально заявленных бесследно исчезли.
Настолько ли уж CAN отличается от RS485? Нет. То, что обычно называют CAN, на самом деле лишь один из физических уровней, определенных в стандарте на CAN, предназначенный для передачи по медной витой паре: ISO 11898-2. И фактически это усложненный (и, соответственно, менее помехозащищенный и менее скоростной) RS485.
Существующие варианты физического уровня CAN (получившие статус международных стандартов помечены).
CAN High-Speed (ISO 11898-2)
CAN Low-Speed (ISO 11519-1)
Fault-Tolerant Transceivers (ISO 11898-3)
Truck/Trailer Transceiver (ISO 11992)
Single-Wire (SAE 2411)
Fiber Optical Transmission
Wire-Less Transmission
Power-Supply Transmission
Следует сказать, что CAN, в отличие от RS485, который определяет только физический уровень (значения напряжений, токов и т. д.), – набор многих уровней спецификации. Как правило, для применения в системе безопасности незачем реализовывать все уровни (механизмы) CAN. Тем более что многие функции – совершенно автомобильные, они просто неуместны в системе безопасности. Например, стандартизация кодов «сигнал левого поворота» или «температура правого заднего тормозного диска». Конечно, есть организация CAN in automation, которая вырабатывает рекомендации, как применять CAN в областях, отличных от первоначальной, но ее рекомендации на самом деле – это весьма сырой набор пожеланий, во многих деталях совершенно бесполезный для систем безопасности (ибо ориентирован на задачи промышленной автоматизации, что ближе к задачам безопасности, но далеко не одно и то же).

Так что же полезного в CAN, чем он лучше RS485 и что из этого можно использовать?
Распространены заблуждения, что CAN может работать дальше и быстрее. Отнюдь. Физика передачи данных по сравнению с RS485 даже ухудшена. То, что обычно называют CAN, – это ISO 11898-2. Это почти RS485, но модифицированный, и вовсе не для увеличения дальности. Модификация – это усложнение протокола, сделанное для возможности голосования одновременно многих устройств. Идея состоит в том, что драйвер сделан похожим на открытый коллектор, так чтобы несколько устройств одновременно могли передавать, не опасаясь спалить друг другу выходы при передаче разных сигналов (в процессе разборок кто кого поборет). Фактически в CAN биты «0» передаются как в 485, а биты «1» вообще не передаются – о них приемники должны сами догадаться по отсутствию сигнала «0». Понятно, что качество передачи (дальность и допустимая скорость) у таких передатчиков, мягко говоря, не лучше, чем у 485.
Дальность 5 км, о которой нередко говорят, – это логическая дальность – вроде как в Ethernet есть понятие «коллизионный домен», размер которого для 10-мегабитной сети составляет 2 км, но ведь это вовсе не значит, что по витой паре категории 3 можно передать Ethernet-сигнал на 2 км. Просто это значит, что ни по какой среде, даже по оптоволокну, нельзя передать больше чем на 2 км в режиме CSMA-CD. Аналогично CAN. 5 км – это максимальное расстояние, реально оно недостижимо (разве что в так и не утвержденном оптоволоконном варианте физического интерфейса CAN). А для физического уровня ISO 11898-2 дальность, как уже говорилось, всегда меньше, чем для RS485 в тех же условиях. Фактически спецификация не рекомендует использовать медные кабельные линии длиннее 200 м. В то время как для RS485 известны условия, в которых можно передать сигнал и на 3 км и на 5 км.
Чем же CAN лучше? Реально – одним. Тем самым механизмом, ради которого «испортили» физические параметры CAN по сравнению с RS485. В CAN заложен механизм «прерываний», когда устройство, имеющее срочную информацию для передачи, может потребовать обслуживание, и если таких устройств несколько, то механизм арбитража шины обеспечит их поочередное обслуживание.
Хорошо? Безусловно. Обработка первого сигнала тревоги может быть сильно ускорена. В плохих системах на базе RS485 это время может достигать 10 секунд. Для систем на базе CAN это время можно сократить до 10–20 миллисекунд. Это действительно хорошо. Правда, «можно сократить» и «сокращено» – две большие разницы. Далеко не всем, заявившим использование CAN, удалось это реализовать. Кроме того, есть способы и на обычном RS485 сократить это время до примерно 200 мс. Такие системы есть, я их знаю (сам делал).
С другой стороны, есть еще один параметр – максимальное количество тревог, которое может обработать система в секунду. Этот параметр у CAN хуже – ведь каждая тревога должна быть не только передана, но и должна сначала поучаствовать в процессе арбитража. Этот параметр менее важен, его всерьез рассматривают только в системах для очень серьезных объектов, когда среди многих рассматривают и такой сценарий развития событий, как массированные ложные тревоги на одном фланге, на фоне которых осуществляется точечный прорыв на другом. Система обязана отработать этот точечный прорыв, невзирая на замусоренность сигналами от сознательно созданных отвлекающих тревог. Сценарий не такой уж невероятный. Дистанционно вызвать ложное срабатывание можно многими способами, начиная от радиопомех и заканчивая, например, обстрелом вибрационного чувствительного элемента из пневматического ружья.
Не будем придираться, возможность асинхронно вызвать обслуживание хороша для систем безопасности.
Чем же еще CAN лучше? Увы, ничем. Дальше начинаются недостатки.
Первый – ограниченный размер кадра, т. е. объем данных, передаваемых за один пакет. В результате передача больших объемов, например конфигурирование контроллера, занимает значительное время и вызывает зубодробительные сложности при программировании. Неудобно – это вполне материальная категория. Неудобно для программиста, значит, в программе будет больше ошибок и меньше удобств для пользователя.
Второй недостаток – непривычная парадигма. Данные в CAN характеризуются в первую очередь не источником и приемником, а передаваемой ими информацией. В автомобильной технике это, наверное, удобно. Количество разных типов данных ограничено, все ситуации наперед известны, зато сразу видно, что происходит. Например, команда «тормозим». И не важно, команда от педали (от водителя) или от радара-датчика дистанции до впереди идущей машины. Да, конечно, можно все перевернуть и исподтишка использовать вместо типов команд привычные адреса устройств. Но это тоже требует насилия над программистом и не повышает качество программы.
Последний (но далеко не самый мелкий) недостаток – цена. Микроконтроллеры, поддерживающие CAN, до сих пор значительно дороже своих атьев, не имеющих на борту поддержки новомодного протокола.
Что же мы видим в результате? Большинство систем, которые появились (или хотя бы были заявлены), когда CAN стал моден, исчезли без следа. Это потому что указанные недостатки (так или иначе сводящиеся к словам «неудобство для программиста») переломили им хребет. Усилия по доводке систем оказались неприемлемо большими, и компании-разработчики предпочли экстенсивно модернизировать свои RS485-системы, а не переходить на новые и совершенно несовместимые (логически несовместимые, по структуре понятий) системы на основе CAN.
В последние годы вновь увеличивается количество систем, использующих CAN. Теперь это уже не мода, теперь его применяют те разработчики, которым он стал привычен в других областях, например, инженеры, пришедшие в безопасность из автомобильной электроники. Им проще и привычней использовать CAN – ну и слава богу. Есть еще ряд инженеров, особенно молодых, которым вообще все равно что использовать, они не имеют опыта ни с тем ни с другим. Однако сейчас несравнимо больше создается оборудования, использующего Ethernet. Стоимость Ethernet на борту микроконтроллеров стремительно падает (фактически сравнялась со стоимостью CAN), а его удобство и стандартность (совместимость, пригодность для передачи системами сторонних производителей) несопоставимо ни с RS485, ни с CAN.
Для сравнения вспомните – каких усилий еще 10 лет назад стоило создать систему видеонаблюдения из 100 видеокамер? А теперь? Вы включаете свой ноутбук (или достаете из кармана смартфон) и, даже не задумываясь о каких-то сложностях интеграции, пользуетесь системой видеонаблюдения из тысяч веб-камер, расставленных по всему миру.
Так что хоть CAN и лучше (теоретически), чем RS485, но системы на его основе вряд ли станут лучше систем на основе RS485, по крайней мере, вряд ли успеют стать лучше, прежде чем и те и другие вымрут под натиском вездесущих интернет-технологий.