Протоколы основанные на CAN сети

Сегодня CAN сети активно применяются в самых, казалось бы, неожиданных устройствах и механизмах — от стиральных машин до томографов и ракет: аттракционы, штамповочное, фрезерное и типографское оборудование, морские суда, промышленные роботы. Одно лишь перечисление областей человеческой деятельности, где сегодня успешно трудится Controller Area Network, способно занять целую страницу. Можно припомнить хорошо известные в России телескопы Carl Zeiss, упаковщики TetraPak, томографы Siemens, не говоря уже о множестве марок европейских грузовых и легковых автомобилей: BMW, Mercedes Benz, Renault, Fiat, Volvo, Saab, Audi, в которых CAN сеть является нервной системой, центром управления жизненно важными узлами.

Ряд оригинальных и эффективных технических решений, положенных в основу CAN протокола фирмой Bosch, а также последующие годы «проверки на прочность» CAN сетей в самых разных, как правило, очень не простых условиях эксплуатации — поистине, во всех трех стихиях: на земле, в небесах и на море — обеспечили CAN мировое признание, закрепленное в 1993 году в международном стандарте ISO 11 898. На сегодняшний день стандарт ISO 11 898 наряду с современной спецификацией Bosch CAN 2.0A/B является базовым документом разработчиков CAN устройств — от трансиверов до модулей и сетей. Координацию усилий производителей, разработчиков и пользователей CAN систем и технологий осуществляет международная некоммерческая организация CiA (CAN in Automation), объединяющая более 300 компаний во всем мире. Среди многочисленных достоинств CAN сетей можно выделить следующие.

Невысокая стоимость как самой сети, так и ее разработки. На рынке существует большой выбор CAN контроллеров по цене до $ 10,а простейшие устройства ввода вывода — CAN SLIO (CAN 2.0A) стоят менее доллара. Следует отметить доступность и широкий выбор готовых CAN модулей и недорогих инструментальных средств.

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

Простота конфигурирования и масштабирования сети, отсутствие теоретических ограничений на количество узлов.

Поддержка разнотипных физических сред передачи данных, от витой пары до оптоволокна и радиоканала.

Эффективность реализации режима реального времени, благодаря мультимастерности, широковещанию, побитовому арбитражу и высокой скорости передачи данных (до 1 Мбит/с).

Промышленный стандарт — десятки производителей CAN компонентов и оборудования, включая практически всех электронных гигантов: Intel, Philips, Siemens, Motorola.

Гарантированная доступность элементной базы в течение, как минимум, 10 лет.

Однако действующий стандарт CAN ограничивается спецификацией только двух самых нижних уровней эталонной семиуровневой модели взаимодействия открытых систем OSI/ISO — физического и канального (рисунок 3.10).

Рисунок 3.10 — Соотношение эталонной модели OSI/ISO и CAN-протоколов.

Описываются физические параметры среды передачи данных (только в ISO 11 898), форматы сообщений, процессы передачи данных длиной до 8 байт, механизмы обнаружения ошибок и др. Но за рамками стандарта остаются решения таких важных при разработке вопросов, как адресация узлов, распределение между ними CAN идентификаторов, интерпретация содержимого фрейма данных, передача данных длиной более 8 байтов и др., то есть все то, что обычно рассматривается на более высоких уровнях, вплоть до 7 го прикладного. Разумеется, сервисов двух нижних уровней может оказаться вполне достаточно, когда речь идет о разработке сравнительно простой сети, не планируемой к расширению и вдобавок состоящей из созданных под нее узлов модулей. Или, к примеру, стоит задача создать «закрытую» сеть на основе оригинального протокола. Но в подавляющем большинстве случаев практических CAN разработок двух «стандартных» уровней оказывается явно мало, а изобретение «велосипеда протоколов» для конкретной задачи — слишком дорогое, долгое и, следовательно, малоэффективное занятие. Поэтому с самого начала опубликования CAN-спецификаций и выпуска первых CAN компонентов как независимыми компаниями, так и ассоциациями по промышленной автоматизации непрерывно велась и продолжается до сих пор работа над созданием спецификаций протоколов верхнего уровня — HLP (Higher Level Protocol) для CAN сетей.

Уже разработанные и существующие в настоящее время спецификации протоколов CAN HLP, как правило, имеют жатую трехуровневую архитектуру (рисунок 3.10), включающую в себя два базовых уровня CAN протокола, иногда дополняемых спецификациями физического уровня (соединители, кабели и т. п.), и прикладной уровень.

Сервисные функции промежуточных уровней либо отсутствуют, либо включены в прикладной. Соблюдение полной иерархии уровней эталонной модели OSI/ISO в системах управления не требуется, кроме того, наличие дополнительных изолирующих межуровневых интерфейсов привело бы к потере производительности системы в режиме реального времени и сделало бы существенно менее предсказуемыми задержки прохождения сообщений в сети.

Преимущества использования стандартных HLP при разработке CAN сетей очевидны и немалочисленны. Во первых, в отличие от использования только сервисов ISO 11 898 или Bosch 2.0A/B, вместе с тем или иным HLP разработчик получает в руки уже готовые механизмы передачи данных любой длины, процедуры начальной инициализации, распределения идентификаторов и т. п., а кроме этого, часто в придачу и конкретную спецификацию физической среды: длина и топология шины, скорости передачи, типы кабелей, соединителей и т. п. — для своей области применения (например гидравлика, общественный транспорт), на подготовку и тестирование которой в реальных условиях уже потрачены силы большого числа разработчиков и экспертов. Во вторых, появляется возможность интегрирования модулей сторонних производителей и простого наращивания сети в будущем, применения широкого спектра имеющихся на рынке инструментальных средств для того или иного HLP, что значительно снижает время и стоимость разработки и положительно сказывается на показателях надежности. В третьих, протоколы HLP позволяют максимально эффективно задействовать многие преимущества CAN, особенно при работе в режиме реального времени. И, наконец, немалое число всевозможных групп пользователей и производителей оборудования для тех или иных HLP способны если не решить за разработчика его задачу, то уж, во всяком случае, значительно облегчить ему жизнь.

А многочисленность существующих CAN протоколов прикладного уровня — на сегодня их уже более четырех десятков — наряду с наличием метапротоколов (например CANKingdom) в известной мере снимает проблему, связанную с оборотной стороной любой стандартизации и заключающуюся в ограничении свободы системного разработчика.

Среди многообразия CAN HLP, представленных на современном рынке CAN технологий, особого внимания заслуживают четыре поддерживаемых ассоциацией CiA и получивших наибольшее распространение в последнее время. Это CAL/CANopen, CANKingdom, DeviceNet и SDS (SmartDistributed System).