SDS (Smart Distributed System)

SDS — детище компании Honeywell Inc. (Micro Switch Division). Наряду со стандартом DeviceNet, SDS представляет собой еще одно недорогое и законченное решение для сетевого управления интеллектуальными датчиками и актуаторами от центрального контроллера (PLC, компьютера) в системах промышленной автоматизации. По степени завершенности — от спецификаций физической среды до прикладного уровня — и по ориентировке на снижение стоимости системы SDS-стандарт напоминает DeviceNet, а функционирование сети походит на работу сети DeviceNet в режиме Predefined Master/Slave. Архитектура протокола SDS включает в себя три уровня модели OSI/ISO — физический, канальный и прикладной. Шинная топология представляет собой линейную шину (магистраль или транк) с короткими отводами (рис. 5)

Определены два базовых типа кабельной разводки: Mini (применяемый при сборке транка сети) — 4-проводной кабель с максимальной токовой нагрузкой 8 А, 5-контактный разъем, и Micro (для подключения физических устройств к сети) — 4-проводной кабель, 3 А, 4-контактный разъем без отдельного контакта для экрана кабеля. В сети SDS допускается и обычная проводная разводка с использованием открытых клеммных соединителей. Всеми типами кабельной разводки и соединителей, так же как и в сети DeviceNet, предусмотрено подведение питающего напряжения (диапазон 11-25 В на стороне устройства) кузлам. Предельные значения длин магистрали и отводов сети SDS в зависимости от скорости передачи приведены в таблице

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

Сообщения, циркулирующие в сети SDS, носят название APDU (Application layer Protocol Data Unit) — блоки данных протокола прикладного уровня. APDU представляет собой CAN-фрейм стандартного формата (расширенный формат фрейма в SDS-сети не применяется), элементы которого имеют свое собственное назначение в SDS (рис. 6)

Поле арбитража (ID3-ID9) расположен 7-разрядный адрес устройства (максимально допустимое количество устройств в сети SDS — 126). Тип APDU (3-разрядное поле) определяет тип сервиса (0…7) прикладного уровня, которому соответствует данный APDU. Нулевое значение бита ID10 (DIR) поля арбитража указывает, что адрес устройства (device adrress) является адресом назначения, а единичное — адресом источника. Чем ниже значения логического адреса, тем выше приоритет сообщения. Бит RTR в SDS CAN-фреймах всегда имеет нулевое значение (удаленный CAN-фрейм в SDS-спецификации не применяется). Блок APDU имеет две формы — укороченную и длинную. Укороченная форма APDU содержит в поле DLC все нули и для передачи данных не используется. В поле данных длинной формы APDU содержится код длины (2…8) поля данных CAN-фрейма (2), два первых байта которого содержат спецификатор сервиса (Service Specifier), идентификатор встроенного объекта (EOID) и дополнительные параметры сервиса, а оставшиеся шесть предназначены для передачи собственно данных. При необходимости передачи последовательностей данных более шести байтов используется фрагментированный формат (до 64 фрагментов по 4 байта) длинной формы APDU.

Укороченная форма APDU используется в следующих сервисах прикладного уровня:

§ Change of State (Off, On, Off ACK, On ACK) — обнаружение изменения состояния логического устройства,

§ Write (On State, Off State, On State ACK, Off State ACK) — управление состояниями логического устройства.

К сервисам, использующим длинную форму APDU, относятся следующие:

§ Channel — обеспечение как широковещательного (multicast), так и равноправного (peer-to-peer) каналов соединения,

§ Connection — открытие/закрытие индивидуальных типов соединения,

§ Write — чтение атрибутов объектов устройства,

§ Read — изменение атрибутов объектов устройства,

§ Action — команда объекту устройства выполнить действие,

§ Event — сигнализация объектов устройства о событии.

При инициализации взаимодействия модулей сети SDS используются 4 сервисные функции-примитива:

§ Запрос (Request) — генерация APDU устройством-инициатором соединения,

§ Ответ (Response) — ответный APDU устройства-ответчика, Индикация (Indication) — фиксация факта приема APDU устройством-ответчиком,

§ Подтверждение (Confirm) — подтверждение приема APDU устройством-инициатором.

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

Модули с внешним питанием (не от SDS-шины) должны иметь механизм обнаружения пропадания питания шины для блокировки своей активности и выполнения автонастройки скорости после повторного включения сети. В сети SDS возможны четыре скорости передачи данных: 1 Мбит/с, 500, 250 и 125 кбит/с.

Заключение

Сравнение протоколов. Прочие HLP.

Несмотря на все разнообразие представленных на рынке протоколов верхнего уровня, включая не рассмотренные в данной статье, все они решают в целом ряд очень похожих между собой задач, описанных в начале статьи, — распределение идентификаторов, передача данных более 8 байтов и т. п. Задачи эти возникают в связи с функциональной незавершенностью CAN-спецификаций, ограниченных описанием лишь двух нижних уровней сетевого взаимодействия. Тем не менее, различия в способах их решения в тех или иных HLP приводят, в конечном счете, к различиям, порой весьма существенным, в стоимостных и функциональных характеристиках сетей на их основе, что необходимо учитывать при выборе HLP для конкретного приложения. Далеко не последнюю роль играет и поддержка того или иного HLP со стороны производителей CAN-оборудования и инструментальных средств. Самым простым и компактным вариантом объединения несложных промышленных устройств под управлением одного мастера является стандарт SDS. Несколько более развитые сервисы предоставляет спецификация DeviceNet. Наибольшей гибкостью и возможностью максимально эффективной реализации режима реального времени обладает протокол CAN Kingdom. В отличие от трех других рассмотренных протоколов, CAN Kingdom не касается каких-либо аспектов физического уровня (среда, соединители и т. п.), выходящих зарамки стандарта ISO 11898, и представляет собой высокоуровневую надстройку над канальным уровнем CAN.

В таблицу 3 сведены некоторые характеристики четырех рассмотренных в статье HLP. Среди других прикладных CAN-протоколов, получивших признание в последнее время, можно выделить стандарт SAE J1939 (SAE — Society of Automotive Engineers), пришедший на смену более старому J1708/J1587 и предназначенный для управления в режиме реального времени узлами транспортных средств (грузовики, автобусы), реализующий plug&play режим для модулей и использующий расширенный формат (29-битовый идентификатор) CAN-фрейма. Ряд специализированных групп (например, HUG — Hydraulic Users Group) в области промышленной автоматизации работают над собственными дополнениями уже существующих CAN HLP в целях адаптации их параметров к своим областям применения. Следует отметить, что большинство существующих на рынке HLP, включая рассмотренные в данной статье, находятся в процессе развития и далеки от завершения, особенно в плане формирования библиотек профилей (для тех HLP, в которых они определены), в связи с непрерывным расширением областей применения CAN-сетей.

В последние годы во всем мире наблюдается стремительный рост числа разработок CAN-сетей и расширение спектра областей применения CAN-технологий. По информации ассоциации CiA, если в 1996 году в мире было установлено 11 млн. CAN-узлов, в 1997 — 25 млн., то в 1998 — уже более 59 миллионов. Прогнозируемое число на 1999 год — около 83 млн., а на 2000 год — более 125 млн. узлов. Эти прогнозы не учитывают все возрастающий интерес к сетям CAN со стороны североамериканских производителей, а также крупнейших юго-восточных корпораций. Непрерывно расширяется и предложение готовых модулей, а также инструментальных программных и аппаратных средств для тех или иных стандартов прикладных протоколов. В подобной ситуации вопрос — использовать или не использовать стандартный CAN HLP — переходит в иную плоскость: какой из существующих HLP предпочесть для решения той или иной задачи, поскольку только на основе стандартного и правильно выбранного HLP зачастую становятся возможными создание конкурентоспособной продукции, интеграция в одной сети готовых модулей, экономия средств и времени на разработку самой сети и ряд других, уже упомянутых ранее преимуществ.

Таблица 3. Сравнительные характеристики четырех CAN HLP

Поиск по сайту: