Заключение
Сравнение протоколов. Прочие HLP.
Несмотря на все разнообразие представленных на рынке протоколов верхнего уровня, включая не рассмотренные в данной статье, все они решают в целом ряд очень похожих между собой задач, описанных в начале статьи, — распределение идентификаторов, передача данных более 8 байтов и т. п. Задачи эти возникают в связи с функциональной незавершенностью CAN-спецификаций, ограниченных описанием лишь двух нижних уровней сетевого взаимодействия. Тем не менее, различия в способах их решения в тех или иныхHLPприводят, в конечном счете, к различиям, порой весьма существенным, в стоимостных и функциональных характеристиках сетей на их основе, что необходимо учитывать при выбореHLPдля конкретного приложения. Далеко не последнюю роль играет и поддержка того или иногоHLPсо стороны производителейCAN-оборудования и инструментальных средств. Самым простым и компактным вариантом объединения несложных промышленных устройств под управлением одного мастера является стандартSDS. Несколько более развитые сервисы предоставляет спецификацияDeviceNet. Наибольшей гибкостью и возможностью максимально эффективной реализации режима реального времени обладает протоколCANKingdom. В отличие от трех других рассмотренных протоколов,CANKingdomне касается каких-либо аспектов физического уровня (среда, соединители и т. п.), выходящих зарамки стандартаISO11898, и представляет собой высокоуровневую надстройку над канальным уровнемCAN.
В таблицу 3 сведены некоторые характеристики четырех рассмотренных в статье HLP. Среди других прикладныхCAN-протоколов, получивших признание в последнее время, можно выделить стандартSAEJ1939 (SAE—SocietyofAutomotiveEngineers), пришедший на смену более старомуJ1708/J1587 и предназначенный для управления в режиме реального времени узлами транспортных средств (грузовики, автобусы), реализующийplug&playрежим для модулей и использующий расширенный формат (29-битовый идентификатор)CAN-фрейма. Ряд специализированных групп (например,HUG—HydraulicUsersGroup) в области промышленной автоматизации работают над собственными дополнениями уже существующихCANHLPв целях адаптации их параметров к своим областям применения. Следует отметить, что большинство существующих на рынкеHLP, включая рассмотренные в данной статье, находятся в процессе развития и далеки от завершения, особенно в плане формирования библиотек профилей (для техHLP, в которых они определены), в связи с непрерывным расширением областей примененияCAN-сетей.
В последние годы во всем мире наблюдается стремительный рост числа разработок CAN-сетей и расширение спектра областей примененияCAN-технологий. По информации ассоциацииCiA, если в 1996 году в мире было установлено 11 млн.CAN-узлов, в 1997 — 25 млн., то в 1998 — уже более 59 миллионов. Прогнозируемое число на 1999 год — около 83 млн., а на 2000 год — более 125 млн. узлов. Эти прогнозы не учитывают все возрастающий интерес к сетямCANсо стороны североамериканских производителей, а также крупнейших юго-восточных корпораций. Непрерывно расширяется и предложение готовых модулей, а также инструментальных программных и аппаратных средств для тех или иных стандартов прикладных протоколов. В подобной ситуации вопрос — использовать или не использовать стандартныйCANHLP— переходит в иную плоскость: какой из существующихHLPпредпочесть для решения той или иной задачи, поскольку только на основе стандартного и правильно выбранногоHLPзачастую становятся возможными создание конкурентоспособной продукции, интеграция в одной сети готовых модулей, экономия средств и времени на разработку самой сети и ряд других, уже упомянутых ранее преимуществ.
Таблица 3. Сравнительные характеристики четырех CANHLP
| CANopen | Can Kingdom | DeviceNet | SDS |
Допустимые скорости передачи данных, кбит/с | 10, 20 (обязательная), 50, 125, 250, 500, 800, 1000 | Любые до 1000, инициализация на 125 | 125, 250, 500 | 125, 250, 500, 1000 |
Защита от некорректной установки скорости передачи модулей | Нет | Да | Нет | Да |
Автонастройка скорости передачи | Нет | Возможна, но не определена | Возможна, но не определена | Да |
Допустимые номера узлов | 0-127 | 0-255 | 0-63 | 0-125 |
Поддержка расширенного CAN-фрейма | Нет | Да | Нет | Да |
Наличие профилей устройств | Да (CiA SIG) | Нет | Да (ODVASIG) | Да (Honeywell Inc.) |
Поддержка протокола | CiA (CAN in Automation) | KVASER AB | ODVA (Open DeviceNet Vendor Assoc.) | HoneywellInc. |
Спецификация соединителей | Да | Нет | Да | Нет |
Краткий экскурс в историю промышленных сетей
Что такое Fieldbus?
Экскурс в теорию
Foundation Fieldbus
Profibus
Заключение
Три основные предпосылки, создающие поистине революционную ситуацию, которая вызывает сегодня повсеместный переход разработчиков систем АСУ к применению распределенных сетевых технологий.
1. Изделия из кремния дешевеют, изделия из меди дорожают.
За последние годы эта тенденция стала особенно заметна. Прошли те времена, когда нормой жизни считался огромный шкаф, напичканный автоматикой, с выходящими из него толстыми пучками кабелей, ведущими к датчикам и исполнительным механизмам.
Сегодня в большинстве случаев становится экономически целесообразной установка на площади цеха или участка нескольких локальных контроллеров или интеллектуальных УСО, объединенных в единую сеть, чем прокладка разветвленных кабельных систем.
2. Стоимость работ по установке, тестированию, вводу в эксплуатацию и сопровождению централизованной системы гораздо выше, чем у распределенной.
Количество проводных соединений в централизованной системе, как минимум, в два раза больше, чем в распределенной (рис. 1). Нужно учитывать многократно возрастающую вероятность ошибки при монтаже проводников в многочисленных кроссовых клеммных колодках и сложность поиска и устранения неисправностей. Отдельно стоит упомянуть о ситуации, когда в составе объекта управления появляется еще несколько входных или выходных каналов. Добавление новых линий связи к уже проложенной кабельной системе — занятие не из простых.
Сегодня, когда микропроцессоры и другие специализированные микросхемы стали достаточно дешевыми, стало целесообразным выделять в общей системе АСУ отдельные локальные задачи, решение которых поручать локальным контроллерам. Контур управления, таким образом, замыкается на нижнем уровне. Сеть же позволяет контроллерам в качестве аргументов для вычисления управляющего вектора использовать переменные других контроллеров, обеспечивая связанность системы управления в целом. Такая архитектура существенно увеличивает производительность, надежность и масштабируемость систем. Кроме того, современные исполнительные механизмы, как правило, уже сами являются интеллектуальными и законченными «субъектами» промышленных сетей.
- 1. Сравнительный анализ протоколов Fieldbus
- Введение
- Общие требования к системе fieldbus
- Типичные стандарты
- Сравнительное изучение
- Метод передачи
- Введение
- Общие черты и отличительные особенности profibus-pa
- Foundation™ fieldbus
- Управление на базе систем нижнего уровня
- Функциональная совместимость
- Открытость
- Заключение
- Введение
- Типы фреймов в can-протоколе
- Средства управления доступом к шине в can-протоколе
- Адресация в can-протоколе
- Управление ошибками
- Стандартный и расширенный фрейм
- Прерывания в can-протоколе
- Микросхемы, поддерживающие can-протокол
- Применение в индустриальных приложениях
- Заключение
- Вступление
- Cal (can Application Layer)
- CaNopen
- Can Kingdom
- DeviceNet
- Sds (Smart Distributed System)
- Заключение
- Что такое Fieldbus?
- Экскурс в теорию
- Foundation Fieldbus
- Profibus
- Введение
- Основные понятия и определения
- Основная конфигурация системы
- Средства объединения устройств системы
- Методика выбора кабеля
- Влияние среды обмена
- Электромагнитные помехи и симметрия параметров канала связи
- Дополнительные требования к реализации заземления
- Конфликтные ситуации