Универсальный блок коммутаций для промышленных сетей передачи данных

Размещено на http://www.allbest.ru/

Введение

блок коммутация сеть

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

Для организации промышленных сетей используется множество интерфейсов и протоколов передачи данных, например Modbus, Ethernet, CAN, HART, PROFIBUS и пр. Они необходимы для передачи данных между датчиками, контроллерами и исполнительными механизмами (ИМ); калибровки датчиков; питания датчиков и ИМ; связи нижнего и верхнего уровней АСУ ТП. Протоколы разрабатываются с учетом особенностей производства и технических систем, обеспечивая надежное соединение и высокую точность передачи данных между различными устройствами. Наряду с надежностью работы в жестких условиях все более важными требованиями в системах АСУ ТП становятся функциональные возможности, гибкость в построении, простота интеграции и обслуживания, соответствие промышленным стандартам.

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

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

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



1.Протоколы передачи данных в промышленных локальных вычислительных сетях (ЛВС)

1.1 Модель OSI для промышленных ЛВС

Наиболее распространённой системой классификации сетевых протоколов является теоретическая модель OSI (базовая эталонная модель взаимодействия открытых систем, англ. Open Systems Interconnection Basic Reference Model). Спецификация этой модели была окончательно принята в 1984 году Международной Организацией по Стандартизации (ISO). В соответствии с моделью OSI протоколы делятся на 7 уровней, расположенных друг над другом, по своему назначению -- от физического (формирование и распознавание электрических или других сигналов) до прикладного (API для передачи информации приложениями). Взаимодействие между уровнями может осуществляться, как вертикально, так и горизонтально. В горизонтальном взаимодействии программам требуется общий протокол для обмена данными. В вертикальном - посредством интерфейсов.

Рисунок 1.1 - Теоретическая модель OSI



Прикладной уровень - уровень приложений (англ. Application layer). Обеспечивает взаимодействие сети и приложений пользователя, выходящих за рамки модели OSI.

Представительский уровень (англ. Presentation layer) - уровень представления данных. На этом уровне может осуществляться преобразование протоколов и сжатие/распаковка или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально. Запросы приложений, полученные с уровня приложений, он преобразует в формат для передачи по сети, а полученные из сети данные преобразует в формат, понятный приложениям.

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

Транспортный уровень (англ. Transport layer) организует доставку данных без ошибок, потерь и дублирования в той последовательности, как они были переданы. Разделяет данные на фрагменты равной величины, объединяя короткие и разбивая длинные (размер фрагмента зависит от используемого протокола).

Сетевой уровень (англ. Network layer) определяет пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, за определение кратчайших маршрутов, коммутацию и маршрутизацию, за отслеживание неполадок и заторов в сети.

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

Физический уровень (англ. Physical layer) предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель или в радиоэфир и, соответственно, их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов.

В данном дипломном проекте будут рассматриваться промышленные протоколы передачи данных, реализуемые на физическом и канальном уровнях: HART, Modbus, Ethernet, CAN, PROFIBUS, LonTalk.

1.2 Обзор протоколов передачи данных

1. HART-протокол (с английского Highway Addressable Remote Transducer -- магистральный адресуемый удаленный преобразователь) - это промышленный цифровой протокол передачи данных, разработанный в 1980 году фирмой RosemountInc. Позже RosemountInc. сделали протокол открытым.

HART-протокол использует стандарт Bell 202 кодировки сигнала методом частотной модуляции (FSK) для осуществления обмена данными на скорости 1200 Бод. Он позволяет передавать одновременно аналоговый и цифровой сигнал, используя при этом одну и ту же пару проводов. Мало того, к одной паре проводов может быть подключено несколько устройств. Модулированный сигнал накладывают на токовую несущую аналоговой токовой петли 4-20мА. Если совсем просто, то для передачи данных аналоговый сигнал суммируется с цифровым, а полученная сумма передается с помощью источника тока 4…20 мА по линии связи. За счет того, что диапазоны частот аналогового (0…10 Гц) и цифрового (1200 Гц и 2200 Гц) сигналов разительно отличаются, нет никакой проблемы в разделении этих составляющих с помощью фильтров низких и высоких частот. На сегодняшний день это решение является практически стандартом для промышленных датчиков. Для передачи логической единицы используется один полный период частоты 1200 Гц, а для передачи логического нуля -- два неполных периода частотой 2200 Гц. HART-протокол использует 1-й, 2-й и 7-й уровни модели OSI.

Рисунок 1.2- Кодирование HART-сигнала

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

Рисунок 1.3- Принцип работы HART-протокола на физическом уровне



Существует два режима работы датчиков, поддерживающих обмен данными по HART протоколу.

Режим передачи цифровой информации одновременно с аналоговым сигналом. Обычно в этом режиме датчик работает в аналоговых АСУ ТП, а обмен по HART-протоколу осуществляется посредством HART-коммуникатора или компьютера. При этом можно удаленно (расстояние до 3000 м) осуществлять полную настройку и конфигурирование датчика. Оператору нет необходимости обходить все датчики на предприятии, он может их настроить непосредственно со своего рабочего места.

В многоточечном режиме - датчик передает и получает информацию только в цифровом виде. Аналоговый выход автоматически фиксируется на минимальном значении (только питание устройства - 4 мА) и не содержит информации об измеряемой величине. Информация о переменных процесса считывается по HART-протоколу. К одной паре проводов может быть подключено до 15 датчиков. Их количество определяется длиной и качеством линии, а также мощностью блока питания датчиков. Все датчики в многоточечном режиме имеют свой уникальный адрес от 1 до 15, и обращение к каждому идет по соответствующему адресу. Коммуникатор или система управления определяет все датчики, подключенные к линии, и может работать с любым из них.

Структура сообщения HART-протокола:

HART-сообщения кодируются как последовательность 8-разрядных байт, которые передаются по кабелю последовательной связи с использованием стандартного метода UART (Universal Asynchronous Receiver/Transmitter - Универсальный Асинхронный Приемник/Передатчик) для посылки каждого байта. Как и в RS-232 и других асинхронных коммуникационных связях, к каждому байту добавляются стартовый бит, бит четности и стоп бит. Это позволяет принимающему устройству UART распознавать начало каждого символа и обнаружить ошибку в разрядах из-за шума в электросети или других помех. HART использует проверку на нечетность. Таким образом, одиночный 8-разрядный байт посылается как следующая последовательность единиц и нулей:

Рисунок 1.4 - Последовательная передача одного 8-разрядного байта

Все устройства поддерживающее HART-протокол имеют свой уникальный адрес в сети. Изначально предусмотрено два вида адресов: короткий адрес (длиной 4 бита) и длинный адрес (длиной 38 бит).

Команды HART-протокола бывают трех типов: универсальные, общепринятые и специфические. Универсальные и общепринятые выполняют функции чтения и записи серийного номера, тега, дескриптора, даты и т.п. Специфические команды создаются изготовителем конкретного устройства.

Помимо прочего есть возможность использовать как среду передачи оптоволокно (FiberOptic HART) и радиоканал (Wireless HART).

В HART протоколе принята следующая структура сообщения:

Рисунок 1.5 - Структура сообщения



Несмотря на низкую скорость и существование более совершенных сетевых решений, HART-протокол завоевал большую популярность за счет высокой помехозащищённости, простоты и низкой стоимость монтажа, дешевизны оборудования.

2. Протокол Modbus -- открытый коммуникационный протокол, основанный на архитектуре «клиент-сервер». Широко применяется в промышленности для организации связи между электронными устройствами. Может использовать для передачи данных через последовательные линии связи RS-485, а также сети TCP/IP (Modbus TCP).

Протокол Modbus был разработан компанией Modicon (в настоящее время принадлежит компании SchneiderElectric) для обмена данными между контроллерами и модулями ввода/вывода данной компании. Он основан на архитектуре «клиент-сервер» и является открытым, поэтому любой производитель оборудования и программного обеспечения имеет доступ к структуре пакетов и может свободно применять этот протокол в собственных устройствах и программных модулях по собственному желанию. На сегодняшний день протокол Modbus является наиболее распространенным решением обмена данными между средствами автоматизации, и это справедливо как для промышленной автоматизации, так и для автоматизации зданий. Причиной распространенности протокола Modbus является простота его реализации.

Основной особенностью протокола является наличие в сети одного ведущего устройства - master. Только ведущее устройство может опрашивать остальные устройства сети, которые являются ведомыми (slave). Подчиненное устройство не может самостоятельно инициировать передачу данных или запрашивать какие-либо данные у других устройств, работа сети строится только по принципу "запрос-ответ". Мастер может так же выдать широковещательный запрос, адресованный всем устройствам в сети, в таком случае ответное сообщение не посылается.



Пакет данных в Modbus выглядит следующим образом:

Адрес	Код функции	Код функции	Контрольная сумма

Максимальный размер пакета для сетей RS232/RS485 -- 256 байт, для сетей TCP -- 260 байт.

Существует три типа функций:

· Стандартные. Описание этих функций опубликовано и утверждено Modbus-IDA. Эта категория включает в себя как опубликованные, так и свободные в настоящее время коды.

· Пользовательские. Два диапазона кодов (от 65 до 72 и от 100 до 110), для которых пользователь может создать произвольную функцию.

· Зарезервированные. В эту категорию входят коды функций, не являющиеся стандартными, но уже используемые в устройствах, производимых различными компаниями. К этим кодам относятся 9, 10, 13, 14, 41, 42, 90, 91, 125, 126 и 127.

Протокол Modbus состоит из трех частей:

1. Документ ModbusApplicationProtocol содержит описание для прикладного уровня модели OSI:- Пакет, который называется PDU (ProtocolDataUnit), один и тот же для всех физических уровней модели. PDU помещается в уникальный для каждого транспортного уровня applicationdataunit (ADU). - состав PDU и коды функций.

2. Документ протокол Modbusoverserialline содержит описание канального и физического уровней модели OSI для интерфейсов RS-485 и RS-232. Вообще, можно использовать любой физический уровень, основанный на асинхронном ресивере/трансивере.

3. Документ ModbusMessagingon TCP/IP ImplementationGuide содержит описание ADU для передачи через TCP/IP.

Спецификация Modbus описывает структуру запросов и ответов. Их основа -- элементарный пакет протокола, так называемый PDU (ProtocolDataUnit). Структура PDU не зависит от типа линии связи и включает в себя код функции и поле данных. Код функции кодируется однобайтовым полем и может принимать значения в диапазоне 1…127. Диапазон значений 128…255 зарезервирован для кодов ошибок. Поле данных может быть переменной длины. Размер пакета PDU ограничен 253 байтами.

Для передачи пакета по физическим линиям связи PDU помещается в другой пакет, содержащий дополнительные поля. Этот пакет носит название ADU (ApplicationDataUnit). Формат ADU зависит от типа линии связи.

Общая структура ADU следующая (в зависимости от реализации, некоторые из полей могут отсутствовать):

адрес ведомого устройства	номер функции	данные	блок обнаружения ошибок

Максимальный размер ADU для последовательных сетей RS232/RS485 -- 256 байт, для сетей TCP -- 260 байт.

Существуют три основных реализации протокола Modbus, две для передачи данных по последовательным линиям связи:

· Modbus ASCII -- для обмена используются только ASCII символы

· ModbusRTU

и для передачи данных по сетям Ethernet поверх TCP/IP:

· Modbus TCP.

Modbus ASCII - это спецификация сетевого протокола обмена данных, разработанная компанией Modicon в 1979 году, для обеспечения сетевой связи между интеллектуальными устройствами. Так же как и все другие спецификации Modbus ASCII является одномастерным протоколом, функционирующим по принципу «ведущий-ведомый».

Modbus ASCII использует шинную топологию, с использованием сетевых интерфейсов RS-232 или RS-485. Возможно использование преобразователей RS-485/Ethernet, так как Modbus ASCII и TCP используют одинаково реализованые уровни сетевой модели OSI.

Основным отличием Modbus ASCII от RTU является использование специальной таблицы значений. Каждому символу отвечают 2 байта данных, соответственно их используется в 2 раза больше, однако расшифровка и сетевое управление осуществляется намного проще. Задержка между кадрами допустима в пределах 1 секунды.

Сеть, построенная на использовании этой версии протокола, может включать в себя до 31 узла.

Структура сообщения имеет следующий вид: каждый байт передается в шестнадцатеричном представлении. В таком случае байты данных, код функции и байт поля проверки передаются в виде 0-9, A-F.

Для разграничения отдельных кадров используется символ «:» и специализированная последовательность «CR LF». Формат кадра представляет собой следующую последовательность: 1 стартовый, 7 битов данных 1 бит паритета + 1 стоповый или без паритета + 2 стоповых.

Рисунок 1.6 - Формат кадра Modbus ASCII

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

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

Modbus RTU - это открытый сетевой протокол передачи данных, разработанный компанией Modicon (сейчас входит в состав SchneiderElectric) для построения сетей между программируемыми логическими контроллерами. За счет своей открытости и широкой распространенности Modbus RTU стал де-факто стандартом сетевых протоколов в сфере промышленной автоматизации.

Modbus RTU имеет шинную топологию и использует модель Ведущий/Ведомый, как метод доступа к шине. Принято называть процесс ведущего клиентом, а процесс ведомого сервером.

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

Modbus RTU использует в качестве физического интерфейса RS-232 или RS-485. Именно применение этих интерфейсов и отличает эту спецификацию протокола от TCP (так же известным как IP, EtherNet или TCP/IP), который использует физический уровень EtherNet.

Отличие от ASCII спецификации Modbus RTU заключается в структуре сообщения и его кодировке. Сообщение использует 8 бит данных из выделенных 11. Формат сообщения представляет собой следующее: 1 стартовый бит, 8 бит данных, 1 бит паритета + 1 стоповый или без паритета + 2 стоповых. Контрольная сумма высчитывается по алгоритму CRC16. Разграничивают кадры между собой с помощью пауз.

Рисунок 1.7 - Формат кадра Modbus RTU



Modbus TCP - это сетевой протокол обмена данных, который представляет собой симбиоз RTU спецификации протокола и Ethernet-TCP/IP. Наряду с RTU и Plus, Modbus TCP использует тот же прикладной уровень сетевой модели, где и достигается совместимость на уровне обработки данных.

Modbus TCP считается эффективным сетевым решением для промышленности. Однако его производительность всецело зависит от характеристик Ethernet сети. На сегодняшний день Modbus TCP является одним из самых распространенных протоколов из семейства IndustrialEthernet.

Используя Modbus TCP, мы получаем, практически, ничем не ограниченное, количество узлов в сети, скорость передачи от 10 до 1000 Мбит/с, протяженность линий связи до 352000м (при использовании оптоволокна). Предпочтительной топологией сети является звезда.

Коммуникационная система Modbus TCP позволяет учувствовать в обмене и устройствами на последовательных линиях связи(RTU/ASCII/+).

Структура сообщения Modbus TCP схожа с RTU спецификацией, однако к ней еще добавляется специализированный MBAP-заголовок. Полученный модуль и передается в сеть.

Рисунок 1.8 - Формат модуля данных прикладного уровня Modbus TCP

Поле поля UnitID позволяет указать адрес узла. ProtocolID используется для межсистемного мультиплексирования. Устройство Modbus TCP идентифицируется IP адресом.

Основные достоинства стандарта - открытость и массовость. Огромное количество датчиков и исполнительных устройств выпущено промышленностью. Практически все промышленные системы контроля и управления имеют программные драйвера для работы с MODBUS сетями.

Недостатки стандарта:

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

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

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

· Стандарт не позволяет конечным устройствам обмениваться фиксированными данными друг с другом без участия мастера. Это существенно ограничивает применимость MODBUS-решений в системах регулирования реального времени.

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

3. Industrial Ethernet (промышленный Ethernet) -- стандартизованный (IEEE 802.3 и 802.11) вариант Ethernet для применения в промышленности. Сеть с процедурой доступа CSMA/CD.

IndustrialEthernet обычно используется для обмена данными между программируемыми контроллерами и системами человеко-машинного интерфейса, реже для обмена данных между контроллерами и, незначительно, для подключения к контроллерам удаленного оборудования (датчиков и исполнительных устройств). Широкому применению Ethernet в последних задачах препятствует суть метода CSMA/CD, делающая невозможным гарантию обмена небольшим количеством информации (единицы байт) с высокой частотой (миллисекундные циклы обмена).

В последнее время является одной из самых распространённых промышленных сетей. Широко применяется при автоматизации зданий и в областях не требующих высокой надёжности.

Для обеспечения гарантированного времени реакции используют протоколы реального времени:

· EtherCAT

· EthernetPowerlink

· EtherNet/IP

· SERCOS III

Эти протоколы в различной степени модифицируют стандартный стек TCP/IP, добавляя в него:

· функции синхронизации

· новые алгоритмы сетевого обмена

· диагностические функции

· методы самокорректировки

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

EtherCAT (Ethernet for Control Automation Technology) - концепция автоматизации на основе Ethernet, разработанная немецкой компанией Beckhoff. Главным отличием этой технологии является обработка фреймов Ethernet "на лету": каждый модуль в сети одновременно с получением адресуемых ему данных транслирует фрейм следующему модулю. При передаче выходные данные аналогичным образом вставляются в ретранслируемый фрейм. Таким образом каждый модуль в сети дает задержку всего в несколько наносекунд, обеспечивая системе в целом поддержку реального времени. Некритичные ко времени данные передаются во временных промежутках между передачами данных в реальном времени. В EtherCAT реализованы механизмы синхронизации на основе стандарта IEEE 1588. Малое время задержки при передаче данных позволяет применять EtherCAT в системах управления перемещением.

EtherNet/IP базируется на протоколах Ethernet TCP и UDP IP и расширяет коммуникационный стек для применения в промышленной автоматизации. Вторая часть названия "IP" означает "IndustrialProtocol" (Промышленный протокол). Протокол Ethernet/IP (IndustrialEthernetProtocol ) был разработан группой ODVA при активном участии компании RockwellAutomation в конце 2000 года на основе коммуникационного протокола CIP (CommonInterfaceProtocol), который используется так же в сетях ControlNet и DeviceNet.

Спецификация EtherNet/IP является общедоступной и распространяется бесплатно. В дополнение к типичным функциям протоколов HTTP, FTP, SMTP и SNMP, EtherNet/IP обеспечивает передачу критичных ко времени доставки данных между управляющим устройством и устройствами ввода-вывода. Надежность передачи некритичных ко времени данных (конфигурации, загрузка/выгрузка программ) обеспечивается стеком TCP, а критичная ко времени доставка циклических данных управления будет осуществлена через стек UDP. Для упрощения настройки сети EtherNet/IP большинство стандартных устройств автоматики имеют в комплекте заранее определенные конфигурационные файлы (EDS).

CIPsync является расширением коммуникационного протокола CIP и реализует механизмы синхронизации времени в распределенных системах на основе стандарта IEEE 1588.

Рис. 1.9 - Структура EtherNet/IP в уровнях модели OSI

В Ethernet Powerlink стеки TCP/IP и UDP/IP (Уровни 3 и 4) расширены стеком Powerlink. На основе стеков TCP, UDP и Powerlink осуществляется как асинхронная передача некритичных ко времени данных, так и быстрая, изохронная передача циклических данных. Стек Powerlink полностью управляет трафиком данных на сети для обеспечения работы в реальном масштабе времени. Для этого используется технология SCNM (Slot Communication Network Management), которая для каждой станции в сети определяет временной интервал и строгие права для передачи данных. В каждый такой временной интервал только одна станция имеет полный доступ к сети, что позволяет избавиться от коллизий и обеспечить детерминированность в работе. В дополнение к этим индивидуальным интервалам времени для изохронной передачи данных, SCNM обеспечивает общие интервалы времени для асинхронной передачи данных.

В сотрудничестве с группой CiA (CAN inAutomation) разработано расширение Powerlink v.2 с использованием профилей устройств CANopen. Powerlink v.3 включает механизмы синхронизации времени, основанные на стандарте IEEE 1588.

Рисунок 1.10 - Структура EtherNet/IP в уровнях модели OSI

SERCOS-III (Serial Real -Time Communication System) - это цифровой интерфейс, оптимизированный для связи между контроллером и ЧРП (преобразователями частоты) и использующий оптоволоконное кольцо. Разработан в первоначальном виде группой компаний еще в конце 80-х годов прошлого века. Работа в реальном времени достигается при помощи механизма TDMA (Time Division Multiplex Access) - Мультиплексный Доступ с Временным Уплотнением. SERCOS-III является последней версией этого интерфейса и базируется на Ethernet.

4. LonTalk - это сетевой протокол обмена данными, созданный компанией EchelonCorporation, специализированный для выполнения задач управления, слежения и диспетчеризации различных сетевых устройств в промышленной автоматике, транспорте, автоматизации зданий, а конкретно системах отопления, вентиляции и кондиционирования, так же системах «Умный дом».

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

Протокол LonTalk построен и использует все 7 уровней сетевой модели OSI. Собственно, схемная часть и специализированная прошивка реализованы на базе кремниевого чипа NeuronChip, представляющего собой вышеназванный специализированный микропроцессор. Помимо собственно реализации протокола обмена данными, NeuronChip выполняет функции цифро-аналоговых и аналогово-цифровых преобразований и выполнения внутренних программ устройства, на которое NeuronChipустановлен. Чипы разрабатываются эксклюзивно компаниями Motorola и Mitsubishi, имеют уникальный в мире 12-значный идентификатор Neuron ID для обнаружения новых сетевых устройств.

Протокол LonTalk поддерживает ряд функций, среди которых:

* Подтверждение транзакции

* Определение отправителя сообщения

* Приоритетная передача данных

* Поиск и обнаружение дубликатов сообщений протокола LonTalk

* Предотвращение конфликтов передачи

* Три вида адресации: конкретная, многопунктовая и широковещательная

* Поиск и обнаружение ошибок

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

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

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

Скорость канала протокола LonTalk может быть запрограммирована на различную величину, однако физические ограничения лежат в интервале от 0,6 кбит/с до 1,25 мбит/с.

5. CAN (англ.ControllerAreaNetwork -- сеть контроллеров) -- стандарт промышленной сети, ориентированный прежде всего на объединение в единую сеть различных исполнительных устройств и датчиков. Режим передачи -- последовательный, широковещательный, пакетный.

CAN разработан компанией RobertBoschGmbH в середине 1980-х и в настоящее время широко распространён в промышленной автоматизации, технологиях «умного дома«, автомобильной промышленности и многих других областях. Стандарт для автомобильной автоматики.

Синхронная шина, с типом доступа CollisionResolution (CR), который в отличие от CollisionDetect (CD) сетей (Ethernet -- это CD) детерминировано (приоритетно) обеспечивает доступ на передачу сообщения, что особо ценно для промышленных сетей управления (fieldbus). Передача ведётся кадрами. Полезная информация в кадре состоит из идентификатора длиной 11 бит (стандартный формат) или 29 бит (расширенный формат, надмножество предыдущего) и поля данных длиной от 0 до 8 байт. Идентификатор говорит о содержимом пакета и служит для определения приоритета при попытке одновременной передачи несколькими сетевыми узлами.

Данные в CAN передаются короткими сообщениями-кадрами стандартного формата. В CAN существуют четыре типа сообщений:

· DataFrame

· RemoteFrame

· ErrorFrame

· OverloadFrame

DataFrame - это наиболее часто используемый тип сообщения. Он состоит из следующих основных частей:

· поле арбитража (arbitrationfield) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть. Поле арбитража состоит в свою очередь из:

o для стандарта CAN-2.0A, 11-битного идентификатора + 1 бит RTR (retransmit)

o для стандарта CAN-2.0B, 29-битного идентификатора + 1 бит RTR (retransmit)

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

· поле данных (datafield) содержит от 0 до 8 байт данных

· поле CRC (CRC field) содержит 15-битную контрольную сумму сообщения, которая используется для обнаружения ошибок

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

RemoteFrame - это DataFrame без поля данных и с выставленным битом RTR (1 - рецессивные бит). Основное предназначение Remote кадра - это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике RemoteFrame сейчас используется редко (например, в DeviceNetRemoteFrame вовсе не используется).

ErrorFrame - это сообщение которое явно нарушает формат солобщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть ErrorFrame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. ErrorFrame состоит из поля ErrorFlag, которое состоит из 6 бит одинакового значения (и таким образом Errorframe нарушает проверку BitStuffing, см. ниже), и поля ErrorDelimiter, состоящее из 8 рецессивных битов. ErrorDelimiter дает возможность другим узлам сети обнаружив ErrorFrame послать в сеть свой ErrorFlag.

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

CAN протокол определяет пять способов обнаружения ошибок в сети:

· Bitmonitoring

· Bitstuffing

· Framecheck

· ACKnowledgementCheck

· CRC Check

Bitmonitoring - каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку BitError. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается. Bitstuffing - когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку StuffError.

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

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

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

Таблица 1.1 - Базовый формат кадра данных

Поле	Длина,бит	Описание
Начало кадра	1	Сигнализирует начало передачи кадра
Идентификатор	11	Уникальный идентификатор
Запрос на передачу (RTR)	1	Должен быть доминантным
Бит расширения идентификатора (IDE)	1	Должен быть доминантным
Зарезервированный бит	1	Резерв
Длина данных (DLC)	4	Длина поля данных в байтах (0-8)
Поле данных	0-8 байт	Передаваемые данные (длина в поле DLC)
Контрольная сумма (CRC)	15	Контрольная сумма всего кадра
Разграничитель контрольной суммы	1	Должен быть рецессивным
Промежуток подтверждения (ACK)	1	Передатчик шлёт рецессивный, приёмник вставляет доминанту
Разграничитель подтверждения	1	Должен быть рецессивным
Конец кадра (EOF)	7	Должен быть рецессивным



Первые 7 бит идентификатора не должны быть все рецессивными.

Формат кадра удаленного запроса совпадает с кадрами данных стандартного или расширенного формата за двумя исключениями:

· В поле RTR рецессив вместо доминанты.

· Отсутствует поле данных.

Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т.п. Существует несколько физических уровней протокола CAN (ISO 11898, ISO 11519, SAE J2411). В подавляющем большинстве случаев используется физический уровень CAN определенный в стандарте ISO 11898.

Физический уровень CAN реализуется экранированной витой парой с терминаторами RT на концах 118 Ом< RT< 130 Ом.

Рисунок 1.11 - Реализация физического уровня CAN

Сигнал в линии связи формируется в соответствии с рисунком. Уровень сигналов составляет 30% от значения напряжения питания, причем значение напряжение питания жестко не определяется. Например, на рисунке приведены значения уровней сигналов при напряжении питания +5В. Нижний уровень сигнала определяется как доминирующий, а верхний уровень определяется как рецессивный.

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

· CANopen

· DeviceNet

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

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

В основе протокола прикладного уровня лежит документ DS.301, который в свою очередь является практическим развитием идей декларированных в документах CiA DS-201-207. Он определяет протоколы конфигурирования и функционирования сети.

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

Функционирование сети -- это обмен данными. Для понимания функционирования сети CANopen разделим все данные на функциональные и технологические.

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

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

Документ CiA DS-201 выделяет 4 основных группы подсистем:

· CMS -- передача сообщений. Сюда относятся: обмен функциональными данными, обмен срочными сообщениями, обмен данными по запросу, управление объектным словарём

· NMT -- управление сетью, контроль работы устройств сети

· DBT -- динамическое распределение идентификаторов

· LMT -- управление конфигурированием устройства

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

Стандарт на промышленную сеть DeviceNet кроме протокола описывает:

· открытые и герметизированные типы разъемов устройств

· диагностические индикаторы (светодиоды)

· профайлы (файлы параметров) устройств

Сеть DeviceNet может:

· чтение состояния вкл/откл. датчиков

· управление пусковыми устройствами

· передать температуру и ток нагрузки пускового устройства

· изменить скорость замедления приводов

· отрегулировать чувствительность датчиков

· и так далее.

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

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

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

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

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

· Уменьшение простоев. Диагностика обеспечивает упреждающие сообщения об отказах и облегчает поиск неисправностей. Сеть DeviceNet предназначена для приложений, требующих:

o уменьшения количества проводных соединений

o быстрой установки и запуска

o гибкости в возможности добавления или перемещения устройств и сегментов кабелей

o малого времени отклика

o диагностики устройств, критичных к простоям

DeviceNet поддерживает скорости 125 kbit/s, 250 kbit/s и 500 kbit/s. Скорость зависит от длины кабеля и его типа максимально до 500 м. Типичная длина кабеля - 100 м. Для кабеля длиной 380 м скорость будет - 125 kbit/s , для 75 м - 500 kbit/s.

Формат кадра передачи данных сети CAN

· 1 Bit => StartofFrame

· 11 Bits => Identifier

· 1 Bit => RTR Bit

· 6 Bits => ControlField

· 0-8 Bytes=> DataField

· 15 Bits => CRC Sequence

· 1 Bit => CRC Delimiter

· 1 Bit => Acknowledge

· 1 Bit => AckDelimiter

· 7 Bits => EndofFrame

· >2 Bits => InterframeSpace

6. Протокол Profibus(ProcessFieldBus) - это комплексной понятие открытой промышленной сети, построенной на основе прототипа, разработанного компанией Siemens AG для промышленных контроллеров Simatic при поддержке правительственных органов Германии в 1989 году.

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

Протокол Profibus отвечает международным стандартам IEC 61158 и EN 50170. Построена сеть в соответствии многоуровневой сетевой модели ISO 7498. Из возможных вариантов обмена данными используется либо обмен данными между ведущим и ведомыми устройствами (протоколы DP и PA), либо обмен между несколькими ведущими устройствами (протоколы FDL и FMS). Открытая, независимая система связи возможна в построении благодаря использованию стандартных протоколов, речь о которых пойдет ниже.

Согласно сетевой модели ISO 7498, протокол Profibus имеет следующие уровни:

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

2. Канальный уровень. На этом уровне определяется конкретный протокол доступа сети.

3. Прикладной уровень. На этом уровне осуществляются прикладне функции.

На физическом уровне Profibus может представлять собой инфракрасную сеть/оптическую сеть/электрическую сеть с топологией шина, созданной на основе экранированной витой пары, в соответствии стандарта RS-485.

Скорость передачи данных, может колебаться в пределах от 9,6 Кбит/сек до 12 Мбит/сек(в случае использования FMS спецификации).

Существует 3 протокола передачи данных:

1. Profibus DP (где DP это- DecentralizedPeripheral -- Распределенная периферия) - протокол, основная задача которого состоит в осуществлении высокоскоростного обмена данными между ведущими -- системами автоматизации и ведомыми -- устройствами распределённого ввода-вывода данных. Этот протокол так же отмечают, как протокол с минимальным временем реакции и высокой степени стойкости к электромагнитным помехам. Протокол электрически близок к RS-485, однако сетевая карта оборудована рефлективной памятью, для минимизации загрузки центрального процессора контроллера.

2. Profibus PA (где РА - это ProcessAutomation -- автоматизация процесса) - это протокол обмена для оборудования расположенного в взрывоопасных зонах. Полностью соответствует стандарту IEC 61158-2. Датчики, исполнительные механизмы, приводы можно подключать на одну линейную шину или кольцевую шину.

3. Profibus FMS (где FMS - это FieldbusMessageSpecification -- спецификация сообщений полевого уровня) -- это протокол разработанный для обеспечения высокоскоростной передачи данных между контроллерами и компьютерами на более высоких уровнях АСУ ТП. Именно этот протокол позволяет достигать скорости передачи порядка 12 мБит/с.

Profibus DP - это профиль сетевого протокола обмена данными Profibus. Тут dp - это Decentralized Peripherals -- Распределенная периферия. Главной задачей для протокола Profibus DP является реализация высокоскоростного обмена между ведущим устройством и ведомыми устройствами.

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

В Profibus DP используются только 2 уровня модели OSI: физический и канальный. Используется так же пользовательский интерфейс. Поскольку уровни 3-7 не используются протоколом Profibus DP, достигается высокая скорость передачи данных.



Рисунок 1.12 - Архитектура Profibus DP

Доступ к канальному уровню организуется с помощью DirectDataLinkMapper (DDLM). Пользовательский интерфейс включает в себя набор функций пользователя и специальных аппаратных функций различных типов устройств Profibus DP.

Важно отметить, что Profibus DP и Profibus FMS обладают единой техникой передачи данных и единым протоколом доступа, а от того могут работать с общим кабелем.

Конфигурацией сети является одномастерная структура (Mono-Master-Struktur). Коммуникация между dp-master и dp-slave происходит следующим образом:

По требованию dp-master, переходит в состояние активного и занимает место в списке вызовов (Polling-Liste). Обмен даными от dp-slave к dp-master и наоборот происходит циклически. Этот цикл представляет собой запрос(кадр RequestFrame) от dp-master и ответ(кадр квитирования/подтверждения ResponseFrame) от dp-slave.

Для реализации мультимастерной структуры, необходимо, чтобы dp-master обменивались данными между собой с помощью Profibus FMS коммуникаций.

Физический уровень профиля протокола или интерфейс Profibus dp может быть реализован на базе RS485 и оптического волокна.

Profibus FMS (тут FMS - это Fieldbus Messa ge Specification -- спецификация сообщений полевого уровня) - это профиль сетевого протокола обмена данных Profibus, разработанный специально для обеспечения высокоскоростной работы между компьютерами и контроллерами на верхних уровнях АСУ ТП. Протокол Profibus FMS позволяет достигать скорости обмена до 12 мБит/с (при использовании оптоволокна).

На базе протокола Profibus FMS можно организовать мультимастерную сеть, где мастер сети будет опрашивать устройства по Profibus DP, а мастера будут обмениваться данными по протоколу Profibus FMS.

Рисунок 1.13 - Организация Profibus FMS

Profibus FMS использует 3 уровня сетевой модели OSI, а именно 1,2 и 7: физический, канальный и прикладной. Profibus DP и Profibus PA используют только физический и канальный. Именно поэтому протокол Profibus FMS предназначен для обмена данными между устройствами на регистровом уровне. Profibus FMS и Profibus DP работают с одинаковым физическим уровнем сетевой модели, а следовательно обладают одинаковой техникой передачи данных и могут работать с общим сетевым кабелем. Profibus FMS поддерживает использование RS-485 и оптического волокна.

Рисунок 1.14 - Архитектура Profibus FMS

Прикладной (иначе пользовательский) уровень Profibus FMS включает в себя FMS (FieldbusMessageSpecification) и LLI (LowerLayerInterface).

FMS несет в себе пользовательский протокол и предоставляет ряд коммуникационных служб. FMS применим для обмена данных между ПК и ПЛК.

LLI дает возможность осуществлять связь и отвечает за аппаратно независимый доступ к канальному уровню протокола Profibus FMS.

Profibus FMS организует отношения типа «клиент-сервер». Клиентом тут является определенный процесс приложения, сервер предоставляет доступ к объектам. Коммуникационные службы FMS, предоставляемые на прикладном уровне, жестко соответствуют функциям необходимого устройства. Для каждого устройства прописан необходимый набор функций, записанный в конкретный FMS-профиль.

Основными профилями Profibus FMS являются:

1. Профиль коммуникации между контроллерами. В этом FMS-профиле указано, какие FMS-службы применяются для коммуникаций между ПЛК. Типы контроллеров точно определены, а значит, определены и службы, параметры и типы данных, поддерживаемые ПЛК.

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

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

Profibus PA - это специализированный профиль протокола Profibus. Тут РА - это Process Automation -- автоматизация процесса. Основная область применения этого протокола - взрывоопасные зоны (далее Ех-зоны). В соответствии со стандартом IEC 1158-2 обеспечивается надежность и питание полевых приборов через шину.

Profibus PA позволяет реализовывать 3 топологии сети: линейные, каскадные, звездообразные, а кроме того и их всевозможные комбинации.

Profibus PA использует 2 уровня модели OSI: физический и канальный. Аналогично DP используются пользовательский интерфейс.

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

По своей сути Profibus PA представляет собой сетевой протокол, который использует основные и расширенные функции Profibus DP для передачи измеренных параметров, состояния аппаратуры и параметризации.

Общая протяженность сети в ЕХ-зоне 1 может составлять до 1,9 км. Длина ответвления может достигать 120м. В ЕХ-зоне 2 протяженность достигает 1 км, а длина ответвления 30 м.

Для построения сетей используют следующие устройства и кабели:

* Сетевые кабели FC (FastConnect) PA.

* Соединительные устройства SplitConnect.

* Согласующие модули DP/PA Coupler и блоки DP/PA Link связи DP/PA.

* Активные полевые разделители AFS и распределители AFD

Коммутировать элементы PA с DP позволяют специализированные модули DP/PA Coupler и блоки DP/PA Link.