Автоматизированная система управления очистки городских сточных вод

Ко всем контроллерам семейства (от S7212 до S7 216) могут подключаться два модуля типа Master интерфейса AS (Aktuator Sensor Interface). Эта возможность обеспечивается благодаря использованию специального коммуникационного процессора, который имеет структуру модуля расширения и подключается к шине AS интерфейса через два его разъема. Таким образом, при необходимости можно превратить микроконтроллер в своего рода коммуникатор - он одновременного работает как Master (по интерфейсу PPI с соответствующими компонентами системы) и как Slave (по отношению к контроллерам более высокого уровня иерархии, к которым он подключен по шине PROFIBUS DP или через интерфейс PPI).

И последний, но немаловажный факт: контроллер S7 215 может работать со стандартной информационной шиной промышленного применения PROFIBUS DP. Для этого CPU 215, помимо интерфейса PPI, дополнительно оборудован интерфейсом PROFIBUSDP. Это не только позволяет использовать интеллектуальные функции периферии в реальном масштабе времени, но и открывает разнообразные и гибкие возможности при модульном построении децентрализованных систем управления. Область применения этого дополнительного свойства контроллера S7 215 действительно исключительно широка, так как на его основе возможно создание систем автоматизированного управления со сложной конфигурацией при минимальных денежных затратах: для работы таких систем нужно только одно устройство координатор, в то время как собственно задачи управления технологическим процессом будут выполнятся несколькими контроллерами S7 200, объединенными информационной шиной PROFIBUS DP (к информационной шине PROFIBUS DP могут быть подключены до 127 устройств). Таким образом, предоставляются практически неограниченные коммуникационные возможности, для использования которых не нужно никакое дополнительное программное или аппаратное обеспечение, кроме соединительного кабеля.

Семейство S7 200 состоит из пяти базовых контроллеров: S7 210, S7 212, S7 214, S7 215 и S7 216. Мощность CPU этих контроллеров оптимальным образом рассчитана на емкость подключаемой периферии входов/выходов.

Среди прочего предоставляется:

возможность подключения к информационной шине PROFIBUS DP, шине интерфейса AS и большому количеству других устройств (например, к приводам с регулировкой скорости вращения);

простое в использовании программное обеспечение STEP7 Micro/WIN и STEP7 Micro/DOS;

готовое пользовательское программное обеспечение, написанное с учетом нашего большого практического опыта;

подробная документация (в том числе краткое руководство для начинающих).

Каждое из CPU может оперировать с 4 26 входами и 4 16 выходами. Контроллер S7-216 может быть расширен до 128 входов/выходов (а через интерфейс AS даже до400 входов/выходов). В спектре семейства контроллеров S7 200 предлагаются разнообразные наборы программного обеспечения, CPU и блоков расширения с входами/выходами разных стандартов (реле, транзисторы и т.д.). В настоящий момент семейство S7 200 представляет собой самый полный набор средств автоматизации подобного класса на рынке. Электропитание датчиков интегрировано в CPU. Это позволяет подключать датчики и сенсоры непосредственно к микроконтроллеру с большой экономией монтажной площади и денежных затрат.

В максимальной конфигурации контроллер S7 200 может состоять из 7 блоков расширения.

3 Обзор сетевых протоколов для построения сетей промышленной автоматизации

3.1 CAN протокол

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

конфигурационная гибкость,

получение сообщений всеми узлами с синхронизацией по времени, неразрушающий арбитраж доступа к шине,

режим мультимастер,

обнаружение ошибок и передача сигналов об ошибках,

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

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

работает по витой паре на расстоянии до 1 км.

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

объектный уровень обеспечивает фильтрацию сообщений и обработку сообщений и состояний;

транспортный уровень представляет собой ядро CAN протокола, он отвечает за синхронизацию, арбитраж, доступ к шине, разделение посылок на фреймы, определение и передачу ошибок и минимизацию неисправностей;

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

Физический уровень

Физический уровень определяется стандартом ISO 11898 и характеризуется следующими возможностями. Дифференциальное включение приемопередатчиков обеспечивает подавление синфазной помехи, при этом уровень сигналов составляет 1/3 от значения напряжения питания, причем само напряжение питания не определяется жестко. Например, типичные значения при напряжении питания +5 В приведены на рисунке 3.1, причем доминирующим уровнем является нижний уровень, а рецессивным, соответственно, верхний.

Рисунок 3.1 - Сигнальные уровни на CAN - шине

Характеристики сети:

максимальное расстояние между узлами - до 1 км;

скорость обмена до 1 Мбит/с при длине линии 60 м;

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



Рисунок 3.2 - Два типа гальванической развязки

В CAN протоколе определены следующие типы фреймов:

фрейм данных перемещает данные с передатчика на приемник (приемники);

удаленный фрейм запрашивает передачу фрейма данных, связанного с определенным идентификатором;

фрейм ошибки выражает, какой узел обнаружил ошибку шины/сети;

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

Рассмотрим подробнее фрейм данных (рисунок 3.3). Он состоит из стартового поля SOF, поля арбитража Arbitration Field, управляющего поля Control Field,поля данных Data Field, поля контрольной суммы СRC, поля подтверждения ACKField, поля конца фрейма EOF.

Поле SOF (Start of Frame) находится в начале фрейма данных и удаленного фрейма и содержит один доминирующий бит.

Поле арбитража Arbitration Field содержит 11 битовый идентификатор и RTR бит, показывающий, является данный фрейм фреймом данных или удаленным фреймом. Идентификатор предназначен для адресации сообщений и используется механизмом арбитража.



Рисунок 3.3 - Фрейм данных

Управляющее поле Control Field (рисунок 3.4) содержит 6 битов, из которых 4 бита (DLC0 DLC4)составляют поле Data Length Code, показывающее количество байтов данных, которое будет передаваться в поле данных; два других бита зарезервированы для следующих редакций протокола.

Рисунок 3.4 - Управляющее поле фрейма данных

Поле данных Data Field содержит передаваемые данные, причем количество передаваемых байтов указывается в поле Control Field и не может превышать 8.

Поле СRC обеспечивает механизм избыточного контроля по четности передаваемых данных.

Поле подтверждения ACK Field (рисунок 3.5)содержит участки ACK Slot и ACK Delimiter и выполняет следующую функцию: передающий узел посылает по одному рецессивному биту на каждом из участков, а приемник, если он принял сообщение без сбоев, устанавливает на линии доминирующий бит в поле ACK Slot. При наложении рецессивного и доминирующего уровней на линии устанавливается доминирующий, и это событие сигнализирует передающему узлу о том, что передача прошла нормально и повтор не требуется.

Рисунок 3.5 - Поле подтверждения фрейма данных

Поле конца фрейма EOF содержится в фрейме данных и удаленном фрейме и состоит из семи рецессивных битов.

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

Передающий узел в CAN протоколе слышат ВСЕ другие узлы в сети и подтверждают это. Всякий раз, когда шина свободна от передачи, узел может начинать передавать. Если узел передает, эта передача должна быть завершена прежде, чем другой узел может пытаться передавать. Если два или больше узла начинают передавать в одно и то же время, конфликт решается при помощи неразрушающего (non-destructive) поразрядного алгоритма арбитража, использующего поле арбитража. Поле арбитража, включенное во все фреймы данных, состоит из:

11-битового поля идентификатора;

RTR-бита.

RTR-бит указывает, является ли фрейм фреймом данных или удаленным фреймом.

11-битовое поле идентификатора передается от старшего к младшему значащему биту. Доминирующий уровень - логический 0. Одновременная передача бита с доминирующим уровнем (логический 0) и бита с рецессивным уровнем (логическая 1) дает в результате уровень логического 0.

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

Если значения равны, узел способен заем продолжить передачу. Если бит с пассивным уровнем (логическая 1) был передан, а активный бит (логический 0) обнаружен на шине, то данный узел теряет право передачи и должен прекратить передачу последующих данных (рисунок 3.6). Узел, который потерял шину, может сделать попытку передачи снова, когда текущая передача завершена.

Рисунок 3.6 - Пример поразрядного арбитража

Важно следующее: идентификатор с самым низким значением выигрывает арбитраж.

Из сказанного можно сделать следующие выводы. Приоритетным является не передающий или приемный узел, а сообщение, имеющее меньшее значение идентификатора. Если в сети один из узлов (сервер) будет ответственным за принятие решений, то он должен иметь наименьший адрес из задействованных. Вторая возможность, которую дает механизм арбитража, использована в сети верхнего уровня DeviceNet. В этой сети количество узлов ограничено 64 и для адресации отведены младшие разряды идентификатора, а старшие разряды предназначены для кодирования видов сообщений. Естественно, что сообщение, имеющее 0 в старшем бите, захватит шину первым, независимо от адреса узла приемника. Это, в свою очередь, обеспечивает передачу сообщений первого вида, например об аварии, по сети первыми, независимо от адресов приемных и передающих узлов.

CAN - это протокол, ориентированный на использование в условиях помех.

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

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

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

Существуют следующие два типа входных фильтров:

фиксированные - фильтры, которые требуют, чтобы биты соответствовали точно один к одному (one for one);

Mask and Match (маскируемые) - фильтры, которые применяют маску к полю идентификатора, прежде чем он сравнивается с приемным регистром кода.

Например, на рисунок 3.7 регистр маски сконфигурирован так, что полученные биты 10-6 идентификатора должны соответствовать битам 10-6 в приемном регистре кода.



Рисунок 3.7 - Пример поразрядного маскирования

В этом примере биты 10-6 идентификатора должны быть установлены в 11110, а остальные не имеют значения. Если биты 10-6 установлены в 11110, то эти сообщения принимаются независимо от значений битов 5-0.

CAN протокол обеспечивает механизмы обнаружения следующих типов ошибок.

Разрядная ошибка появляется, когда передатчик сравнивает уровень на шине с уровнем, который должен передаваться, и обнаруживает их неравенство. При этом обнаружение активного бита, когда передается пассивный бит, не выдает ошибку в течение передачи поля арбитража, поля ACK Slot или флажка пассивной ошибки.

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

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

CRC ошибка появляется, когда CRC-значение (контрольный код)не соответствует значению, сгенерированному передатчиком. Каждый фрейм содержит поле контрольного кода, которое инициализировано передатчиком. Приемники вычисляют CRC и сравнивают его со значением, сгенерированным передатчиком. Если эти два значения не тождественны, то имеет место CRC ошибка.

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

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

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

Шина выключена - узел на шине в выключенном состоянии и не откликается на любое воздействие на шине. Это логическое отключение от сети.

Общий краткий обзор действий, имеющихся в механизме минимизации неисправностей, приведен далее.

Узлы следят, передают и получают значения счетчиков ошибок.

Узел начинает передачу в состоянии активной ошибки со счетчиками ошибок, равными нулю (0).Узел в этом состоянии «понимает», что любая обнаруженная ошибка - не неисправность.

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

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

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

Когда и передающий, и приемный счетчики пассивной ошибки узла декрементируются ниже определенного порога, узел еще раз подтверждает со стояние активной ошибки.

CAN микросхемы поддерживают стандартный или расширенный фрейм.

Стандартный фрейм означает, что CAN микросхема поддерживает 11 битовое поле идентификатора. Расширенный фрейм означает, что микросхема поддерживает 29 битовое поле идентификатора. Новые САN микросхемы могут поддерживать форматы как стандартного фрейма, так и форматы расширенного фрейма.

Периферийная

Проектировщики должны учитывать интервал возможных прерываний их CAN контроллеров при проектировании своих изделий. Так как фрейм данных в CAN протоколе короткий (от 0 до 8 байт), скорость поступления прерываний на процессор может быть высокой.

В связи с этим следует рассматривать CAN как высокоскоростную сеть.

Рисунок 3.8 демонстрирует два передаваемых подряд CAN фрейма данных с минимальным интервалом между фреймами, называемым интервалом межфрейма.

Рисунок 3.8 - Минимальный интервал межфрейма

На рисунке 3.9 приведена таблица, которая показывает самый жесткий режим прерывания для случая, если CAN приемник получает все фреймы во время текущей связи (непрерывные фреймы в режиме back to back).

Рисунок 3.9 - Трафик прерываний

Строка «Число битов в CAN протоколе» в таблице принимается с условием, что заполнение дополнительными битами отсутствует (естественно, что такое заполнение увеличило бы время между прерываниями).

Из таблицы на рисунке 3.9 видно, что трафик прерываний достаточно интенсивен. На скорости 500 кбит/с прерывания могут происходить каждые 94 мкc при отсутствии информации в фреймах данных.

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

Следует выбирать CAN контроллер, который обеспечивает соответствующий уровень предварительной фильтрации.

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

Также следует помнить, что некоторые CAN микросхемы маскируют только восемь наиболее значащих битов поля идентификатора (не все 11 битов) и имеют один фильтр МАСКИ/СООТВЕТСТВИЯ.

Микросхемы, которые поддерживают CAN протокол, выпус каются различными поставщиками, такими как Philips, Motorola, Siemens, National Instruments и Intel.

Существуют следующие два типа микросхем. Встроенные - микросхемы, которые включают в себя CAN контроллер и один из видов интегрированного микроконтроллера. Это Intel 80196СА, содержащий в одном кристалле стандартный контроллер 80196 и CAN контроллер 82527; Philips 82С592 и 82С598, имеющие контроллер 80С51 и CAN контроллер 82С200; Motorola 68HC05X4,68HC705X4, 68HC705X32 на основе М6805.

Периферийные - микросхемы, которые содержат только CAN контроллер. Это Intel 82527 с 14 фиксированными входными фильтрами, одним типа Mask-and-Match и поддержкой стандартного и расширенного фреймов; Philips 82С200 с одним входным фильтром типа Mask-and-Match и поддержкой стандартного фрейма; Siemens SAB 81C90,81C91 c 16 фиксированными входными фильтрами. Кроме того, фирмами Philips и Texas Instruments выпускается ряд буферных микросхем, формирующих сигналы CAN магистрали.

В настоящее время СAN протокол активно используется в индустриальных сетях. Такие известные фирмы, как Hoheywell и Allan Bradley, разработали и поддерживают сетевые протоколы верхнего уровня SDS и DeviceNet, причем последний является открытым и на данный момент более 200 фирм выпускают и разрабатывают свои изделия в этом стандарте. Кроме того, достаточно известными в Европе являются стандарты сети верхнего уровня CanOpen, CAL (Германия) и CanKingdom (Швеция). Все эти сети используют CAN протокол на физическом и транспортном уровнях. Фирма Advantech выпустила плату PCL 841, имеющую 2 гальванически развязанных CAN порта на Philips 82C200 и разрабатывает модули удаленного сбора информации с выходом на CAN; фирмы Grayhill и Opto22 выпустили недорогие периферийные контроллеры, поддерживающие сеть DeviceNet, в комплекте WAGO I/O System также имеется контроллер с выходом на CanOpen, DeviceNet и CAL. Фирма Hilscher выпускает богатый набор плат с CAN протоколами (CanOpen, Device Net, SDS)для распространенных системных шин типа ISA и PCI, для мезонинной шины PC/104,а также в виде OЕМ модулей для изготовителей контроллеров, которые хотят встроить в свои изделия совместимость с CAN протоколами, не затрачивая время и средства на собственные разработки. Ряд отечественных фирм также выпускает изделия с CAN протоколом, в том числе в популярном формате MicroPC.

Использование CAN протокола и сетей верхнего уровня на его основе при модернизации отечественных промышленных предприятий позволит разработчикам средств АСУ ТП решить ряд остро стоящих проблем:

выполнить требования помехоустойчивости;

обеспечить совместимость с действующими в развитых странах стандартами;

повысить надежность за счет того, что обеспечивается обязательное подтверждение приема сообщения приемником;

обеспечить повышение живучести системы при применении режима «мультимастер»;

снизить стоимость коммуникаций (требуется витая пара).

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

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

Ряд оригинальных и эффективных технических решений, положенных в основу CAN протокола фирмой Bosch, а также последующие годы «проверки на прочность» CAN сетей в самых разных, как правило, очень не простых условиях эксплуатации - поистине, во всех трех стихиях: на земле, в небесах и на море - обеспечили CAN мировое признание, закрепленное в 1993 году в международном стандарте ISO 11898. На сегодняшний день стандарт ISO 11898 наряду с современной спецификацией 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 11898),форматы сообщений, процессы передачи данных длиной до 8 байт, механизмы обнаружения ошибок и др. Но за рамками стандарта остаются решения таких важных при разработке вопросов, как адресация узлов, распределение между ними CAN идентификаторов, интерпретация содержимого фрейма данных, передача данных длиной более 8 байтов и др., то есть все то, что обычно рассматривается на более высоких уровнях, вплоть до 7 го прикладного. Разумеется, сервисов двух нижних уровней может оказаться вполне достаточно, когда речь идет о разработке сравнительно простой сети, не планируемой к расширению и вдобавок состоящей из созданных под нее узлов модулей. Или, к примеру, стоит задача создать «закрытую» сеть на основе оригинального протокола. Но в подавляющем большинстве случаев практических CAN разработок двух «стандартных» уровней оказывается явно мало, а изобретение «велосипеда протоколов» для конкретной задачи - слишком дорогое, долгое и, следовательно, малоэффективное занятие. Поэтому с самого начала опубликования CAN-спецификаций и выпуска первых CAN компонентов как независимыми компаниями, так и ассоциациями по промышленной автоматизации непрерывно велась и продолжается до сих пор работа над созданием спецификаций протоколов верхнего уровня - HLP (Higher Level Protocol) для CAN сетей.

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

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

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

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

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

3.2.1 CAL (CAN ApplicationLayer)

Одной из главных целей создания организации CiA в 1992 году была разработка и последующая поддержка открытого протокола прикладного уровня (7-й уровень модели OSI), предназначенного для CAN-сетей в сфере промышленной автоматизации. В качестве прототипа при разработке такого протокола был взят уже существовавший в то время и положительно зарекомендовавший себя HLP, разработанный фирмой Philips. Результатом его апробации и последующего усовершенствования специальной рабочей группой CiA явилось опубликование 1993 году спецификаций CAL - CANApplication Layer (CiA DS 20x). Фундаментом CAL служит канальный уровень CAN. CAL не является ориентированным на конкретные приложения стандартом протокола, не содержит каких либо профилей, привязанных конкретным устройствам или задачам, и не определяет содержание передаваемых данных, но предлагает стандартизованные элементы сетевого сервиса прикладного уровня. Решение же вопроса, какую часть из них использовать, находится в ведении разработчика. CAL включает в себя четыре составные части:

спецификация CAN сообщений (CMS - CAN Message Specification);

сетевое управление (NMT Network Management);

распределение идентификаторов (DBT - Identifier Distributor);

управление уровнем (LMT - Layer Management).

Спецификация CMS описывает типы объектов взаимодействия в рамках объектно-ориентированного подхода, правила передачи данных разных типов посредством CAN фреймов, взаимодействие между модулями в терминах модели клиент сервер, механизмы передачи данных, включая передачу пакетов длиной более 8 байтов. Сетевое управление построено на взаимодействии типа master slave.

Один модуль сети является NMT мастером, все остальные - NMT ведомые. Посредством сервисов управления NMT мастер инициализирует, управляет NMT ведомыми, которые желают принять участие во взаимодействии, и позволяет им общаться между собой посредством CMS сервисов.

Также в задачи сетевого управления входят контроль ошибок и конфигурирования устройств. Благодаря DBT сервисам происходит бесконфликтное распределение идентификаторов среди модулей под контролем DBT мастера. Посредством LMT сервисов возможны запрос и изменение текущих параметров (значений идентификаторов, скорости передачи, битового квантования и т.п.)в модулях непосредственно из CAN сети.

Сетевые CAN приложения, основанные на прикладном уровне CAL, в настоящее время успешно работают в медицинской электронике, системах контроля дорожного движения, на транспорте, в промышленном оборудовании.

3.2.2 CANopen

Результатом дополнения CAL (точнее, некоторого его подмножества) системой профилей (устройств, интерфейсов, приложений и т.д.) и спецификациями физического уровня (типы соединителей, правила битового квантования, определяющие, насколько квантов разделять бит и в каком месте бита считывать его значение, и т.д.) явилось появление более «конкретного» стандарта протокола CANopen. По существу, CANopen является одним из приложений прикладного уровня CAL, но единственным приложением подобного рода, поддерживаемым ассоциацией CiA. Профили устройств (CiA DS 40x) упрощают интеграцию модулей разных производителей в единую сеть, а определение минимального обязательного (mandatory) набора свойств модулей гарантирует работоспособность системы на базовом уровне.

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

Структура CANopen в соответствии с моделью OSI приведена на рисунке 3.11.



Рисунок 3.11 - Архитектура протокола CANopen

Два нижних уровня соответствуют стандарту CAN (ISO 11898,CAN Specification 2.0 A/B).В дополнение к спецификациям физического уровня ISO 11898 (среда передачи данных - экранированная или неэкранированная двухпроводная дифференциальная линия) CANopen содержит cобственные правила битового квантования, а также определяет три рекомендуемых типа оединителей:

9 контактный D Sub (DIN 41652);

5 контактный круглый Mini (ANSI/B93.55M 1981);

5 контактное открытое клеммное соединение.

Рекомендуемой разводкой контактов для всех типов соединителей предусмотрена возможность подачи питания (положительной полярности) на трансиверы узлов, имеющих гальваническую развязку. В сети CANopen определены восемь градаций скоростей передачи данных:1 Мбит/с,800, 500, 250, 125, 50, 20 и 10 кбит/с. Поддержка скорости 20 кбит/с является обязательной для всех модулей.

Прикладной уровень представляет собой некоторое подмножество CAL и базируется на четырех его основных сервисных элементах: CMS, NMT, DBT и LMT, дополненных профилем соединения (CiA DS 301), определяющим базовые правила обмена данными и структуру словаря объектов. Более развитые механизмы сетевого взаимодействия для интеллектуальных устройств (человеко-машинные интерфейсы - HMI, PC контроллеры, PLC, инструментальные средства и т.п.) описаны в дополнении к коммуникационному профилю (CiA DS302).

В сети CANopen на прикладном уровне модули обмениваются между собой объектами сообщениями - COB (Communication Object), включающими в себя один или более CAN фреймов. Всего существует четыре типа таких объектов:

объекты данных процесса - ProcessData Objects (PDO);

объекты сервисных данных - Service Data Object (SDO);

объекты специальных функций - Special Function Objects;

объекты сетевого управления - Network Management Objects.

Собственно для целей передачи данных используются два различных механизма - использованием PDO и на основе SDO. SDO позволяют модулям обмениваться данными любого объема (при последовательностях более 8 байтов - благодаря использованию нескольких CAN фреймов) в ацикличном низкоприоритетном режиме. Как правило, этот тип обмена используется для конфигурирования устройств или настройки формата PDO. Любое устройство, интегрируемое в сеть CANopen, должно обязательно поддерживать SDO обмен. В противоположность SDO типу, обмен на основе PDO используется для синхронной (цикличной или ацикличной) или асинхронной (инициируемой внешними прерываниями) скоростной передачи не более 8 байтов (длина поля данных фрейма CAN), имеет более высокий приоритет, чем SDO, и применяется для пересылок данных в режиме реального времени.

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

Для выполнения специальных задач, в том числе диктуемых спецификой режима реального времени, служат объекты специальных функций:

синхронизации - Synchronization Object (SYNC) - служит для запуска синхронных процессов;

временных маркеров - Time StampObject - содержит значение абсолютного времени;

аварийный - Emergency Object(EMCY) - служит для передачи кодов ошибок модулей.

Объекты сетевого управления включают сообщения сервисов NMT,LMT и DBT. Администрированием сети занимается NMT мастер, который инициализирует устройства, обеспечивает контроль ошибок, а также производит их периодическую «перекличку» (LifeGuarding) с помощью PDO сообщений (Node Guarding Object) для выявления узлов, находящихся в нерабочем состоянии ввиду физического отсутствия или отключения от шины (bus off) по счетчику ошибок.

Устройство в сети CANopen включает в себя три основные логические части:

интерфейс связи и ПО протокола;

словарь объектов;

интерфейс ввода вывода и прикладное ПО.

Первая часть обеспечивает прием передачу объектов по сети. Словарь объектов описывает типы данных, объектов связи (COB) и прикладных объектов, используемых в данном устройстве. Третья часть обеспечивает внутреннюю функциональность устройства и взаимодействие с его аппаратным интерфейсом.

В целях максимального упрощения процесса интеграции модулей независимых производителей в единую сеть CANopen использует концепцию профилей устройств.

К настоящему времени завершено

формирование следующих профилей:

модули ввода вывода (аналоговые и цифровые DSP 401);

приводы и модули управления перемещением (DSP 402);

элементы человеко-машинного интерфейса (DSP 403);

измерительные устройства и регуляторы (WD 404);

кодеры (DSP 406).

В процессе разработки находятся профили для модулей управления гидравлическими механизмами, дизельными двигателями и железнодорожным транспортом. Кроме этого, существует единственный пока профиль интерфейса - IEC 1131 (DSP 405). Отдельного упоминания заслуживает профиль приложения WD 407 (IBIS CAN) CAN сетей в области управления электроникой на общественном транспорте (где CAN сети вообще используются довольно интенсивно по всей Европе): билетный контроль, подсчет пассажиров, информационные панели и т.п.

Другим менее известным протоколом приложением прикладного уровня CAL (и, в отличие от CANopen, требующим лицензирования) является протокол P CAL (Portable CAN Application Layer), разработанный Университетом Вооруженных сил Германии.

3.2.3 CAN Kingdom

За названием протокола шведской компании KVASER AB скрывается красивая и оригинальная концепция сетевого взаимодействия устройств, выделяющая его на общем фоне других протоколов высокого уровня. Началу работ над первой версией (текущая - третья) протокола CAN Kingdom в 1990 году предшествовал многолетний опыт компании в области создания систем распределенного управления. Протокол был специально разработан для управления машинами и механизмами: промышленными роботами, текстильными станками, мобильными гидравлическими устройствами - и позволяет удовлетворить такие свойственные подобным приложениям требования, как:

эффективность функционирования в режиме реального времени;

жесткие требования безопасности;

высокая общая производительность.

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

Основной целью создания протокола было предоставление системному разработчику максимальной свободы в реализации своих идей при построении сети, сохранив при этом возможность использования стандартных модулей независимых производителей. CAN Kingdom не является «готовым» протоколом в том смысле, в каком это справедливо, например, по отношению к стандартам типа CANopen или DeviceNet. Это скорее набор примитивов - метапротокол, с помощью которых можно «собрать» протокол для конкретной сети модулей, что позволяет достичь уникального сочетания простоты интеграции готовых модулей с высокой степенью «закрытости», защищенности оригинального протокола.

При разработке спецификации CAN Kingdom авторы отказались от принятого в подобных случаях и широко распространенного следования правилам взаимосвязи открытых систем OSI. Причина этого проста: семиуровневая модель OSI/ISO создавалась изначально для описания традиционных компьютерных сетей, телекоммуникационных, корпоративных, офисных, которые предназначены не для работы в реальном масштабе времени, а для обслуживания пользователей, требования которых заранее (на этапе построения такой сети) неизвестны и непредсказуемы, и в процессе работы подвержены частым изменениям (следует отметить, что большинство протоколов компьютерных сетей также редко в точности следуют этой абстрактной модели, особенно в плане обособления и полной изоляции различных уровней сетевого сервиса). В системах же управления реального времени ситуация прямо противоположная: на стадии разработки все коммуникационные потребности модулей должны быть известны. И готовая сеть должна функционировать точно так, как задумал системный разработчик. Краеугольным камнем концепции сетевого взаимодействия CANKingdom является принцип «Модули обслуживают сеть» (MSN - Modules Serves the Network), в отличие от принципа «Сеть обслуживает пользователей» (NSM - Network Serves the Modules), свойственного компьютерным сетям.

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

Следствием принципа MSN также является и то, что в сети CAN Kingdom всегда должен существовать один модуль супервизор, содержащий всю информацию о системе и ответственный за ее инициализацию.

Представление CAN сети в терминах CAN Kingdom (в равнении с традиционным взглядом) дано на рисунке 3.12.

Рисунок 3.12 - Структура CAN-сети

а) традиционная;

б) по протоколы CAN Kingdom.

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

Типы почтовой корреспонденции (информация, передаваемая по сети) и ее соответствие CAN понятиям таковы:

ПИСЬМО - CAN фрейм (данных или удаленного запроса);

КОНВЕРТ - CAN идентификатор;

СТРАНИЦА - поле данных CAN фрейма;

СТРОКА - байт данных;

ЭЛЕМЕНТ СТРОКИ - бит данных.

Для организации и хранения входящей и исходящей «корреспонденции» применяются понятия форм, документов, папок и листов.

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

Перечислим некоторые особенности CAN системы на базе протокола CAN Kingdom.

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

Максимальное время прохождения любого сообщения в сети предсказуемо.

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

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

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

В сеть CAN Kingdom возможна интеграция любых CAN модулей (включая разработанные для других протоколов, например DeviceNet или SDS), удовлетворяющих стандарту ISO 11898.

Не существует каких либо рекомендуемых скоростей передачи данных. Но в первые 200 мс после подачи питания узел обязан настроиться на прослушивание шины на скорости 125 кбит/с. Допустимы отличающиеся от ISO 11898 спецификации физического уровня.

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

Правила идентификации модулей основаны на использовании международного кода EAN/UPC, включающего код производителя и продукта. Система распознает только авторизованные системным разработчиком модули. Неавторизованный модуль не получит в свое распоряжение CAN идентификаторов от короля при инициализации сети. Для поддержки режима plug&play король хранит информацию о том, какие модули и при каких обстоятельствах могут быть добавлены в систему.

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

3.2.4 DeviceNet

DeviceNet - протокол, разработанный и опубликованный в 1994 году компанией Allen Bradley и впоследствии переданный в ведение специально организованной для его поддержки ассоциации ODVA (OpenDeviceNet Vendor Association Inc.).

DeviceNet - недорогое, простое и эффективное решение для объединения в единую систему разнообразных устройств промышленной автоматизации независимых производителей (фото, термодатчики, стартеры, считыватели штриховых кодов, элементы человек- машинного интерфейса: клавиатуры, дисплейные панели, - наряду управляющими устройствами: PLC, компьютерами и т.д. рисунок 3.13.)

Рисунок 3.13 - Пример сети DeviceNet

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

Сеть DeviceNet имеет шинную топологию с отводами. Физической средой передачи является 4 проводной кабель (CAN_H, CAN_L, Vcc, Ground), причем возможны две его разновидности: толстый (внешний диаметр 12,2 мм) и тонкий (6,9 мм).Оба варианта кабеля могут использоваться как для основной магистрали (транка), так и для отводов или комбинироваться. Определены лишь три значения скорости передачи данных - 125,250 и 500 кбит/с. Максимальные длины центральной магистрали и отводов в зависимости от скорости передачи и типа кабеля приведены в таблице 3.1.

Таблица 3.1 - Соотношение длины и скоростей передачи

Скорость передачи кбит/сек	Длина магистрали, м	Длина отводов, м
	Толстый кабель	Тонкий кабель	Одиночных	Суммарная
125	500	100	6	156
250	250	100	6	78
500	100	100	6	39

Важной особенностью сети DeviceNet является возможность питания модулей непосредственно от сетевого кабеля, причем стандартизованы как напряжение питания (24 В), так и максимальная токовая нагрузка (8 А на толстом кабеле,3 А на тонком), а также допускается применение нескольких (в отличие от других стандартов на базе CAN, которые вообще предусматривают питание от шины) источников питания, например с целью резервирования, в любой точке шины. Все это дает возможность построения автономной сети, не зависящей от наличия или качества внешнего питания, а при необходимости позволяет легко демонтировать и снова развернуть систему на новом месте. Сеть DeviceNet допускает «горячее» (без обесточивания сети) подключение и отключение модулей. При наличии оптоэлектронной развязки сигнальных цепей в модулях их питание может осуществляться от внешнего источника. Спецификацией DeviceNet предусмотрены и такие нюансы, как типы, цвет и количество индикаторов состояния модуля (включения, работоспособности, подключения к сети), хотя само по себе наличие таких индикаторов не является обязательным. Стандарт DeviceNet содержит также подробное описание многочисленных типов переходников, разветвителей (одиночных и многопортовых), соединителей (mini, micro),сетевых отводов и т.п.

В целях еще большего снижения стоимости системы на базе сети DeviceNet не так давно фирмой Allen Bradley был предложен новый тип кабельной разводки на основе 4 проводного плоского кабеля - KwikLink.

При описании организации типов данных, сетевого поведения модулей в DeviceNet используется объектно-ориентированная модель. Обязательные классы объектов включают в себя следующие:

объект удостоверения (Identity object) содержит информацию о модуле (код производителя, продукта, версия и т.п.);

объект соединения (Connection object) - логический порт вводавывода устройства;

объект DeviceNet включает MAC ID (идентификатор модуля), скорость передачи, состояние модуля и т.п.;

объект сообщения (Message router object) перенаправляет явное сообщение получателю.

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

сообщения ввода вывода (I/O messages)предназначены для целей управления устройствами и передачи данных в реальном времени между узлами в широковещательном режиме или в режиме «точка-точка», используют идентификаторы высоким приоритетом, которые и определяют содержание сообщения;

явные сообщения (Explicit messages) предназначены для многоцелевого обмена данными в режиме «точка-точка» и обеспечивают типичный сервис «запрос ответ», используют идентификаторы с низким приоритетом и применяются обычно для конфигурирования устройств и целей диагностики, значение сообщения содержится в поле данных.

...