Сети промышленных контроллеров

CAN (controller area network) — сеть промышленных контроллеров (иногда ее называют последовательной коммуникационной шиной) служит средством для объединения отдельных контроллеров в единую систему управления, работающую в реальном времени. В основе идеологии CAN лежит семиуровневая модель OSI/ISO. Спецификой CAN является то, что для реализации функций управления эта сеть должна обеспечивать надежный и высокоскоростной (до 1 Мбит/с) внутрисистемный обмен данными между контроллерами, с учетом неблагоприятных условий технологического окружения. CAN по своему определению объединяет ограниченное количество контроллеров, по своей природе она локальна и не выходит за рамки технологического объекта.

В архитектуре этой сети есть определенное очарование, свойственное любой миниатюре. При знакомстве с ней возникает примерно такое же ощущение, как при виде узкоколейной железной дороги или действующих моделей, хотя на самом деле здесь все «по-настоящему», но в ином масштабе, чем в более известных сетях WAN, LAN или SAN. Знакомство с ее устройством может быть полезным не только специалистам.

Впервые идея CAN была предложена в середине 80-х немецкой компанией Robert Bosch, которая задумывала ее в качестве экономичного средства для объединения контроллеров, расположенных внутри автомобиля. Актуальность этой задачи понятна любому, кто хоть раз видел системы-коммуникации в объектах автоматизации, эти километры и километры кабельной проводки, которыми опутаны и промышленные объекты, и энергетические агрегаты, и даже летательные аппараты. Традиционный способ связи распределенных по объекту контроллеров жгутами проводов по своей технической сложности, по ценовым и по весовым параметрам для столь массового изделия, коим является автомобиль, оказался непригоден. Требовалось альтернативное решение, сокращающее количество проводов, поэтому был предложен протокол CAN, для которого достаточно любой проводной пары.

В настоящее время CAN успешно используется. Достижения в этой области, особенно на престижном «мерседесе» класса S (по-русски — «крутой» шестисотый), стимулировали продвижение идеи в другие отрасли. Сейчас CAN можно найти в системах морской навигации, управлении лифтами, сельскохозяйственных машинах, робототехнике, научной и медицинской аппаратуре, офисной технике и даже в сложных игрушках. Общее число сетей CAN в 2000 году превысило 100 млн., а сферы применения перекрывают диапазон от бытовой техники до космических аппаратов. Это вовсе неудивительно: замена кабельных монстров сетями (в простейшем случае телефонной «лапшой», витой экранированной или неэкранированной парой или даже оптоволокном) представляется очень привлекательной.

CAN и семиуровневая модель

Дорога CAN к массовому использованию очень похожа на путь, пройденный другими сетевыми решениями. Он состоит из двух этапов стандартизации: первый — принятие стандартов на нижние уровни модели OSI/ISO, второй — активная борьба за будущие стандарты более высокого прикладного уровня и т. д. Первый этап практически завершен, второй — проходит этап становления.

Стандарты на CAN сформулированы в двух документах: ISO 11898 и ISO 11519. Соответствующее оборудование выпускается целым рядом крупнейших производителей; в их числе Bosch, NEC, Intel, Philips и целый ряд других компаний. Действующие стандарты пока распространяются только на два нижних уровня модели OSI/ISO — физический и канальный. Для физического уровня определена среда передачи, рекомендуемые типы соединений и разъемов, скорости передачи данных (10, 20, 50, 100, 250, 500, 800 кбит/с и 1 Мбит/с). На канальном уровне приняты стандарты Standard CAN и Extended CAN, которые определяют форматы сообщений (Message Frame). Логически они идентичны, но различаются числом разрядов в идентификаторе сообщения. В первом случае их только 11, во втором — 11 или 29. Обеспечивается совместимость сверху вниз. Об идентификаторах, изюминке CAN, мы поговорим чуть позже.

Протоколы верхних уровней модели, называемые HLP (High Level Protocol), стали активно развиваться только в последние годы, в связи с массовым распространением CAN, теперь уже вне традиционных автомобильных приложений. Как обычно бывает в таких случаях, эти протоколы предлагаются и развиваются компаниями-конкурентами. Кроме того, в целях стандартизации создаются картельные коммерческие и некоммерческие организации. Можно насчитать несколько десятков протоколов CAN HLP. Среди них наибольшее распространение получили CAL/CANopen, CAN Kingdom, DeviceNet и SDS (Smart Distributed System). Эти протоколы с исчерпывающей полнотой описаны в [1]. Общим для всех протоколов HLP является сжатие всех верхних уровней в один: для приложений CAN этого вполне достаточно.

Логика работы CAN

Принцип передачи данных в CAN часто, но не всегда, называют CSMA/BA (Collision Sense Multiple Access/Bitwise Arbitration). Из первой части названия следует, что он относится к категории CSMA (Carrier Sense, Multiple Access), где предполагается разделение доступа к носителю путем его прослушивания. Успех Ethernet сделал популярным другой вариант CSMA — с обнаружением коллизий CSMA/CD (Collision Detect). Вторую же часть названия CSMA/BA можно перевести как «побитный арбитраж»; в этом красивом способе разрешения коллизий и заключается специфика CAN.

В любой реализации CSMA носитель интерпретируется как эфир, в котором контроллеры, чаще их называют станциями, работают как приемники и передатчики. (Говорят, толчком к созданию Ethernet стало посещение Робертом Меткалфом Гавайских островов и знакомство с тамошней радиосетью AlohaNet.)

Для разделения доступа к носителю в CAN разработан простой и вместе с тем очень надежный механизм доставки сообщений. Следует выделить несколько основополагающих идей этого механизма.

• Данные предаются квантованными сообщениями стандартного формата (телеграммами), поэтому исключаются все обычные сложности, присущие пакетной передаче с переменной длиной пакетов. Каждое сообщение включает только одно значение некоторого физического параметра, например, скорость вращения вала или температуру жидкости, назовем это типом сообщения, и идентификатор типа.
• Априорно предполагается, что количество станций и количество разных типов сообщений относительно невелики; в конечном счете, они ограничены технологической сложностью объекта управления. При таком допущении можно построить безадресную и абсолютно децентрализованную систему, где ни один передатчик не связан в своей работе с другими. Иными словами, имеет место, на первый взгляд, полная анархия, каждый котроллер пытается передать данные тогда, когда считает это необходимым, заботясь вовсе не о том, кто будет приемником. Его задача — передать. Поэтому все приемники вынуждены принимать все сообщения и отбирать по идентификатору только те, которые соответствуют их функциональной задаче. Скажем, система управления зажиганием принимает сообщения о скорости вращения двигателя и игнорирует данные о работе кондиционера.

Рис. 3. Коллизия трех станций и ее разрешение

Оказывается, что для реализации такой дисциплины обмена достаточно иметь всего четыре разных формата сообщений, называемых в данном случае фреймами. На сайте www.kvser.se можно обнаружить удачные метафоры того, что могли бы сказать контроллеры, обращаясь в сеть.

Data Frame — фрейм передачи данных: «Привет всем, вот данные с идентификатором Х, получите».

Remote Transmission Request Frame или просто Remote Frame — фрейм запроса данных: «Привет всем, а может ли кто-нибудь выслать данные с идентификатором Х?»

Error Frame — служебный фрейм ошибки: «Стоп, начнем все с начала».

Overload Frame — служебный фрейм перегрузки контроллера: «Я очень занят, подождите чуть-чуть».

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

Рис. 4. Архитектуры BCAN и FCAN

Очень важно подчеркнуть, что, начав передачу, станция не прерывает слушание эфира, в частности она отслеживает и контролирует процесс передачи текущей предаваемой телеграммы, посланной ей самой.

На этапе передачи первой части сообщения — идентификатора это необходимо для разрешения коллизий, а затем, когда передается смысловая часть, таким образом проверяется корректность передачи данных. Если на втором этапе обнаруживается ошибка (маски не совпали), передатчик прерывает свою работу и фреймом Error Frame оповещает всех остальных об этом событии.

Но передатчик и сам должен быть как-то уведомлен об успехе или неуспехе своей попытки, получив сообщение от контрагентов. Для этой цели в Data Frame имеется слот ACK (от английского acknowledgment — «подтверждение»), куда любой из контролеров, восприявших данный фрейм как адресованный ему, может занести запись о приеме. Передатчик отслеживает состояние этого слота и, если он не заполнен, будет повторять передачу до победного конца, пока подтверждение о приеме не будет получено.

Двуликий идентификатор

В механизме доставки с сообщений с контекстной адресацией ключевую роль играет идентификатор. Это всего лишь двоичное число, длина которого варьируется в зависимости от версии Standard CAN или Extended CAN, но в любом случае он выполняет две взаимосвязанные функции.

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

Более интересным и, как все миниатюрное, изящным представляется использование идентификаторов в качестве основного инструмента, используемого в процедуре разрешения коллизий. По определению CSMA станция имеет право начинать передачу, если эфир свободен, и при хорошей скорости передачи и небольшом числе станций так чаще всего и бывает. Но неизбежны случаи, называемые коллизиями, когда две или даже большее число станций начинают одновременно работать в эфире. В CAN в качестве основного критерия для разбора коллизий, для принятия решения, кому отдать эфир, используется приоритет сообщений. Каждому типу сообщения приоритет присваивается во время проектирования системы и динамически изменяться не может. Приоритет выражается двоичным значением идентификатора: чем число меньше, тем выше приоритет.

Двоичные значения «нуль» и «единица» наделены двумя качествами, явно заимствованными из генетики: «доминантный» и «рецессивный». Доминантный ген, как известно, подавляет рецессивный, например, ген черных волос подавляет ген светлых, в следствие чего количество натуральных блондинок уменьшается. В сети CAN доминантным считается «нуль», а «единица» — рецессивной. Результатом наложения на шине двух сигналов «нуля» с «единицей» будет «нуль»: если одновременно передаем два числа, то на гипотетическом осциллографе увидим меньшее. Если одновременно несколько станций начали передачу, и при этом произошла коллизия, происходит суперпозиция передаваемых идентификаторов. Идентификаторы последовательно, побитно (bitwise), начиная со старшего, налагаются друг на друга; в их противоборстве выигрывает тот, у кого меньше арифметическое значение идентификатора, а значит, выше приоритет. Доминантный «нуль» подавит единицы и в любом случае к концу передачи поля идентификатора оно станет равно более приоритетному значению.

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

CSMA/BA и другие способы распределения каналов

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

Первая из них — отношение к ресурсу. В свое время аналогичным образом решалась задача разделения доступа к центральному процессору. Любой ресурс (процессора или носителя) можно каким-то образом квантовать по времени, выделяя каждому участнику обмена фиксированный фрагмент (token slot, token passing). С другой стороны его можно выделять по мере необходимости (по запросам) тому участнику обмена, кому в данный момент он нужен (CSMA/CD, Bitwise Arbitration, циклические перестановки).

Вторая дихотомия определяется отношением к сохранности передаваемых данных. Доступ к шине может быть неразрушающим, если шина выделяется по какому-то принципу монопольно на интервал времени одному из претендентов, и он доводит свою передачу до логического конца, сохраняя данные (token slot, token passing, Bitwise Arbitration, циклические перестановки). Напротив, CSMA/CD и Ethernet относятся к разрушающим методам резервирования каналов, при обнаружении в них коллизии прерываются все участвующие в ней передачи.

Во введенной классификации CAN относится к категории неразрушающих методов резервирования, работающих по запросам. Преимущество такого паллиативного метода заключается в том, что в нем нет холостых циклов, а значит, резко сокращаются потери времени канала, но при этом и нет прерванных передач.

Работоспособности

Для обеспечения надежности в CAN предусмотрено несколько децентрализованных механизмов, основанных на способности контроллеров прослушивать свою собственную передачу. Мы уже обсудили, как она используется для разрешения коллизий, теперь несколько слов о том, контролируется ли корректность передачи самого содержания телеграмм. Если при передаче полей, следующих за идентификатором, обнаруживается несоответствие с исходным значением, то контроллером вырабатывается Error Frame, состоящий из шести доминантных бит, которые прерывают текущие действия и не позволяют приемнику получить неверную информацию.

Вторая составляющая механизма контроля — «имплантация бита» (bit stuffing), защищает от зависаний и других «глюков». По условиям в эфир подряд не может проходить более пяти битов одного значения. Если их набирается пять, то между ними вставляется дополнительный, служебный шестой, имеющий противоположное значение, в дальнейшем он просто фильтруется приемником. Но если его нет, то опять вырабатывается Error Frame.

Еще одна составляющая — мониторинг состояния контроллеров. Для контроллера обычным является активное по отношению к ошибкам (error-active) состояние, активное в том смысле, что оно предполагает способность генерировать фрейм Error Frame. Но при этом количество порожденных ошибок постоянно считается самим контроллером и, если оно достигает 96, то вырабатывается предупреждающий сигнал. Если же значение счетчика ошибок превысит 127, то контроллер переходит в пассивное (error-passive) состояние, в котором он продолжает выполнять регулирующую функцию, подсчитывая и дальше число ошибок, но при этом сигнал об ошибках Error Frame видоизменяется и теперь состоит из шести рецессивных бит и ни на что повлиять не в состоянии. Если в процессе работы число ошибок сократится, упадает ниже 128, то контроллер возвращается в активное состояние. Если же число ошибок еще больше возрастет и достигнет 256, то контроллер отключается от сети, переходя в состояние buss-OFF и ожидая обслуживания.

Рис. 5. Передача данных между сетями CAN

Об эффективности этих механизмов можно судить по данным, которые опубликованы в довольно популярном и многократно перепечатанном в Сети документе [2]. В нем оценивается вероятность возникновения ошибок, не обнаруженных описанными методами; их называют residual errors, т.е. остаточные или необъясненные ошибки. Утверждается, что в средней сети, состоящей из пяти — десяти станций, работающей по 8 часов 365 дней в году такая ошибка может возникнуть один раз за тысячу лет.

Базовый и полный

Существует два основных подхода к архитектуре интерфейса контроллеров с сетью. Первый — упрощенный Basic CAN (BCAN), второй — более сложный Full CAN (FCAN). Между ними есть еще промежуточное компромиссное решение Direct storage CAN — DCAN. Два первых различаются между собой механизмами буферизации сообщений. Если учесть, что каждая станция получает весь поток сообщений, циркулирующих в сети, то становится понятно: значительная часть процессорных ресурсов контроллера уходит на обработку сообщений. Возможны два выхода из этой ситуации, первый — снабдить контроллер производительным процессором, который бы справлялся с нагрузкой, а второй — усилить логику вспомогательной части контроллера, осуществляющей буферизацию и обработку сообщений. Чем эффективнее механизм буферизации, тем меньше загрузка процессора. Собственно, эти две полярные идеи развиваются в альтернативных решениях: BCAN — вся нагрузка на процессор, FCAN — минимизация нагрузки.

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

Интеграция сетей CAN

Как только сети CAN стали выходить за пределы таких относительно простых объектов автоматизации, как автомобили, где требуется автоматизировать ограниченное число функций, возникла необходимость интегрировать несколько сетей в одну систему управления [3]. Одна из главных причин — высокая, но, тем не менее, ограниченная пропускная способность шины. И здесь мы опять сталкиваемся со спецификой CAN, для которой пока не существует стандартных интеграционных решений, но известные весьма оригинальны.

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

Поэтому возможным оказывается довольно неожиданное решение, своего рода «виртуальное» разделение сетей. Допустим, есть множество устройств U, которые распределены по нескольким сетям Ni. В привычных сетях множества Ni не пересекаются, их сумма равна U. В сетях CAN множества Ni пересекаются, здесь один и тот же контроллер может входить одновременно больше чем в одну сеть, причем каждый многовходовый контроллер одновременно выполняет функцию шлюза между двумя сетями.

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

Контроллеры со встроенными функциями межсетевого шлюза сегодня выпускают две компании. Из названия контроллера TwinCAN производства Infineon Technologies (английское twin означает «близнец») следует, что он способен подключаться к двум сетям одновременно. FCAN-контроллер ELIZA производства компании NEC включает 7 модулей подключения к сети и шлюзование между ними.

Литература

1. А. Щербаков, Сеть CAN: популярные прикладные протоколы. ChipNews, 1999, № 5
2. Controller Area Network, A Serial Bus System. CAN in Automation.
3. Jens Eltze, Thomas Lee, Integrated Controller Area Network Applications. NEC Electronics.