Для взаимодействия между сма ицтс и есма используется адаптер сопряжения протоколов

Обновлено: 30.06.2024

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

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

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

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

Взаимодействие между уровнями

Рис. 1. Теоретическая модель OSI.

Прикладной уровень

Представительский уровень

Сеансовый уровень

Сеансовый уровень (англ. Session layer) управляет созданием/завершением сеанса связи, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений. Синхронизация передачи обеспечивается помещением в поток данных контрольных точек, начиная с которых возобновляется процесс при нарушении взаимодействия. Используемые протоколы: ASP, ADSP, DLC, Named Pipes, NBT, NetBIOS, NWLink, Printer Access Protocol, Zone Information Protocol, SSL, TLS, SOCKS.

Транспортный уровень

Транспортный уровень (англ. Transport layer) организует доставку данных без ошибок, потерь и дублирования в той последовательности, как они были переданы. Разделяет данные на фрагменты равной величины, объединяя короткие и разбивая длинные (размер фрагмента зависит от используемого протокола). Используемые протоколы: TCP, UDP, NetBEUI, AEP, ATP, IL, NBP, RTMP, SMB, SPX, SCTP, DCCP, RTP, TFTP.

Сетевой уровень

Сетевой уровень (англ. Network layer) определяет пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, за определение кратчайших маршрутов, коммутацию и маршрутизацию, за отслеживание неполадок и заторов в сети. Используемые протоколы: IP, IPv6, ICMP, IGMP, IPX, NWLink, NetBEUI, DDP, IPSec, ARP, RARP, DHCP, BootP, SKIP, RIP.

Канальный уровень

Канальный уровень (англ. Data link layer) предназначен для обеспечения взаимодействия сетей на физическом уровне. Полученные с физического уровня данные проверяет на ошибки, если нужно исправляет, упаковывает во фреймы, проверяет на целостность, и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями. Спецификация IEEE 802 разделяет этот уровень на 2 подуровня — MAC (Media Access Control) регулирует доступ к разделяемой физической среде, LLC (Logical Link Control) обеспечивает обслуживание сетевого уровня. Используемые протоколы: STP, ARCnet, ATM, DTM, SLIP, SMDS, Ethernet, FDDI, Frame Relay, LocalTalk, Token ring, StarLan, L2F, L2TP, PPTP, PPP, PPPoE, PROFIBUS.

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

Физический уровень (англ. Physical layer) предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель или в радиоэфир и, соответственно, их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов. Используемые протоколы: RS-232, RS-422, RS-423, RS-449, RS-485, ITU-T, xDSL, ISDN, T1, E1, 10BASE-T, 10BASE2, 10BASE5, 100BASE-T, 1000BASE-T, 1000BASE-TX, 1000BASE-SX.

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

Технология клиент-сервер

Рис. 2. Технология клиент сервер.

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

Области промышленного применения: создание удаленных диспетчерских пунктов, Web-приложения для SCADA систем, программное обеспечение промышленных контроллеров, организация видеонаблюдения.

Совместимость протоколов семейства Modbus

Рис. 3. Совместимость протоколов семейства Modbus.

Для организации взаимодействия между элементами автоматизации в промышленных сетях передачи данных широко применяется коммуникационный протокол Modbus. Существуют три основные реализации протокола Modbus, две для передачи данных по последовательным линиям связи, как медным EIA/TIA-232-E (RS-232), EIA-422, EIA/TIA-485-A (RS-485), так и оптическим и радио: Modbus RTU и Modbus ASCII, и для передачи данных по сетям Ethernet поверх TCP/IP: Modbus TCP.

Протоколы семейства Modbus (Modbus ASCII, Modbus RTU и Modbus TCP/IP) используют один прикладной протокол, что позволяет обеспечить их совместимость. Максимальное количество сетевых узлов в сети Modbus – 31. Протяженность линий связи и скорость передачи данных зависит от физической реализации интерфейса. Элементы сети Modbus взаимодействуют, используя клиент-серверную модель, основанную на транзакциях, состоящих из запроса и ответа.

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

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

Компания ICPDAS предлагает широкий спектр коммуникационного оборудования для организации сетей на базе протоколов семейства Modbus: серия I-7000 (шлюзы DeviceNet, серверы Modbus, адресуемые коммуникационные контроллеры); программируемые контроллеры серий ХРАК, WinPAC, WinCon, LinPAC, ViewPAC.

Операторские панели производства компании Weintek, частотные преобразователи Control Techniques для связи с контроллерами также используют протокол Modbus.

Традиционно протоколы семейства Modbus поддерживаются OPC серверами SCADA систем (Clear SCADA, компании Control Microsystems, InTouch Wonderware, TRACE MODE)для связи с элементами управления (контроллерами, ЧРП, регуляторами и др.).

Сеть Profibus

Рис. 4. Сеть Profibus.

В Европе широкое распространение получила открытая промышленная сеть PROFIBUS (PROcess FIeld BUS). Изначально, прототип этой сети был разработан компанией Siemens для своих промышленных контроллеров.

PROFIBUS объединяет технологические и функциональные особенности последовательной связи полевого уровня. Она позволяет объединять разрозненные устройства автоматизации в единую систему на уровне датчиков и приводов. Сеть PROFIBUS основывается на нескольких стандартах и протоколах, использует обмен данными между ведущим и ведомыми устройствами (протоколы DP и PA) или между несколькими ведущими устройствами (протоколы FDL и FMS).

Сеть PROFIBUS можно ассоциировать с тремя уровнями модели OSI: физический, канальный и уровень приложений.

Одни и те же каналы связи сети PROFIBUS допускают одновременное использование нескольких протоколов передачи данных. Рассмотрим каждый из них.

PROFIBUS DP (Decentralized Peripheral - Распределенная периферия) — протокол, ориентированный на обеспечение скоростного обмена данными между ведущими DP-устройствами и устройствами распределённого ввода-вывода. Протокол характеризуется минимальным временем реакции и высокой стойкостью к воздействию внешних электромагнитных полей. Оптимизирован для высокоскоростных и недорогих систем.

PROFIBUS PA (Process Automation - Автоматизация процесса) — протокол обмена данными с оборудованием полевого уровня, расположенным в обычных или взрывоопасных зонах. Протокол позволяет подключать датчики и приводы на одну линейную шину или кольцевую шину.

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

Положительные стороны: открытость, независимость от поставщика, распространенность.

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

Основную массу оборудования использующего протокол PROFIBUS составляет оборудование компании SIEMENS. Но в последнее время этот протокол получил применение у большинства производителей. Во многом это обусловлено распространенностью систем управления на базе контроллеров Siemens.

Сеть Profibus на базе оборудования ICP DAS

Рис. 5. Сеть Profibus на базе оборудования ICP DAS.

Компания ICPDAS для реализации проектов на базе PROFIBUS предлагает ряд ведомых устройств: шлюзы PROFIBUS/Modbus серии GW, преобразователи PROFIBUS в RS-232/485/422 серии I-7000, модули и каркасы удаленного ввода/вывода PROFIBUS серии PROFI-8000. В настоящие время инженерами компании ICPDAS ведутся интенсивные разработки в области создания PROFIBUS ведущего устройства.

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


Программа разработана совместно с АО "Сбербанк-АСТ". Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Продукты и услуги Информационно-правовое обеспечение ПРАЙМ Документы ленты ПРАЙМ Постановление Правительства Москвы от 6 февраля 2019 г. N 59-ПП "Об информационной системе "Единая система мониторинга и администрирования телекоммуникационных услуг"


Обзор документа

Постановление Правительства Москвы от 6 февраля 2019 г. N 59-ПП "Об информационной системе "Единая система мониторинга и администрирования телекоммуникационных услуг"

В целях обеспечения автоматизации контроля качества сказания услуг связи для нужд органов исполнительной власти города Москвы и подведомственных им организаций Правительство Москвы постановляет

1. Утвердить Положение об информационной системе "Единая система мониторинга и администрирования телекоммуникационных услуг" (приложение).

2. Установить, что Департамент информационных технологий города Москвы осуществляет от имени города Москвы правомочия собственника информационной системы "Единая система мониторинга и администрирования телекоммуникационных услуг" (далее - ЕСМА), а также является оператором ЕСМА.

3. Внести изменения в постановление Правительства Москвы от 29 апреля 2014 г. N 224-ПП "Об автоматизированной информационной системе "Система мониторинга информационных систем города Москвы" (в редакции постановления Правительства Москвы от 19 декабря 2017 г. N 1051-ПП):

3.1. В пункте 3 постановления слова "Ермолаева А.В." заменить словами "Лысенко Э.А.".

3.2. В пункте 2 приложения к постановлению слова "и обеспечения оказания услуг связи для нужд органов исполнительной власти города Москвы и подведомственных им государственных учреждений города Москвы" исключить.

3.3. В пункте 4.1 принижения к постановлению слова ", а также оказываемых органам исполнительной власти города Москвы и подведомственным им государственным учреждениям города Москвы услуг связи" исключить.

3.4. В пункте 4.3 приложения к постановлению слова "и оказании услуг связи для органов исполнительной власти города Москвы и подведомственных им государственных учреждений города Москвы" исключить.

3.5. В пункте 4.4 приложения к постановлению слова "и оказания услуг связи для органов исполнительной власти города Москвы и подведомственных им государственных учреждений города Москвы" исключить.

3.6. В пункте 4.5 приложения к постановлению слова ", а также обеспечения оказания услуг связи для органов исполнительной власти города Москвы и подведомственных им государственных учреждений города Москвы" и слова ", а также обоснованного ведения претензионной работы с исполнителями по государственным контрактам (контрактам, договорам), заключенным Департаментом информационных технологий города Москвы, подведомственными ему государственными учреждениями города Москвы" исключить.

3.7. В пункте 4.6 приложения к постановлению слова "и качественного оказания услуг связи для нужд органов исполнительной власти города Москвы к подведомственных им государственных учреждений города Москвы" исключить.

3.8. В пункте 4.7 приложения к постановлению слова "и обеспечение услугами связи органов исполнительной власти города Москвы и подведомственных им государственных учреждений города Москвы" исключить.

3.9. Пункты 5.3, 6.4-6.7 приложения к постановлению признать утратившими силу.

3.10. В пункте 6.2 приложения к постановлению слова "и оказании услуг связи" исключить.

3.11. В пункте 6.8 приложения к постановлению слова "и качестве сказанных услуг связи в интересах органов исполнительной власти города Москвы и подведомственных им государственных учреждений города Москвы" исключить.

3.12. В пункте 7 приложения к постановлению слова "услуг связи," исключить.

3.13. В пункте 9 приложения к постановлению слова "и оказанию услуг связи" исключить.

3.14. Пункт 10.1 приложения к постановлению изложить в следующей редакции:

"10.1. Размешают в СМИС информацию об используемых оборудовании и программно-аппаратных средствах информационных систем и параметрах их настройки, о возникших сбоях, неполадках в работе информационных систем и ресурсов города Москвы и затем актуализируют ее в порядке к сроки, устанавливаемые Департаментом информационных технологий города Москвы.".

3.15. В пункте 12.5 приложения к постановлению слова "и оказанию услуг связи" исключить.

4. Контроль за выполнением настоящего постановления возложить на министра Правительства Москвы, руководителя Департамента информационных технологий города Москвы Лысенко Э.А.

Мэр Москвы С.С. Собянин

Приложение
к постановлению Правительства Москвы
от 6 февраля 2019 г. N 59-ПП

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

1. Общие положения

1.1. Положение об информационной системе "Единая система мониторинга и администрирования телекоммуникационных услуг" (далее - Положение) определяет назначение и правила функционирования информационной системы "Единая система мониторинга и администрирования телекоммуникационных услуг" (далее - ЕСМА), состав участников информационного взаимодействия с использованием ЕСМА (далее - участники информационного взаимодействия) и их полномочия.

1.2. ЕСМА представляет собой информационную систему города Москвы, содержащую информацию, программно-технические средства, обеспечивающие автоматизацию процессов взаимодействия между участниками информационного взаимодействия с целью обеспечения контроля качества оказываемых телекоммуникационных услуг, в том числе услуг связи для нужд органов исполнительной власти города Москвы и подведомственных им организаций города Москвы.

1.3. ЕСМА является собственностью города Москвы.

2. Основные задачи и функции ЕСМА

2.1. Основными задачами ЕСМА являются:

2.1.1. Автоматизация процесса непрерывного и качественного оказания телекоммуникационных услуг, в том числе услуг связи (далее - телекоммуникационные услуги) пользователям ЕСМА.

2.1.2. Контроль качества, своевременности и объема оказания телекоммуникационных услуг по контрактам (договорам), заключенным органами исполнительной власти города Москвы и подведомственными им организациями города Москвы.

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

2.1.4. Обеспечение ведения претензионной работы с исполнителями по контрактам (договорам) на оказание телекоммуникационных услуг, заключенным органами исполнительной власти города Москвы и подведомственными им организациями города Москвы.

2.2. Основными функциями ЕСМА являются:

2.2.1. Мониторинг, управление и учет телекоммуникационных услуг, оказываемых пользователям ЕСМА, а также информационных ресурсов, используемых для обеспечения сказания указанных услуг.

2.2.2. Сбор и обобщение информации о сбоях в оказании телекоммуникационных услуг, поступающей от пользователей ЕСМА.

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

2.2.4. Формирование статистических и оперативных отчетов о функционировании телекоммуникационного оборудования и качестве оказанных телекоммуникационных услуг пользователям ЕСМА.

2.3. ЕСМА состоит из следующих подсистем:

2.3.1. Подсистема предоставления информации, обеспечивающая доступ пользователей ЕСМА к информации, обрабатываемой в ЕСМА.

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

2.3.3. Подсистема учета и администрирования телекоммуникационных услуг, обеспечивающая автоматизацию процессов заказа и предоставления таких услуг пользователям ЕСМА.

2.3.4. Подсистема учета и хранения данных о ресурсах, используемых для оказания телекоммуникационных услуг пользователям ЕСМА.

2.4. Состав информации, размещаемой и обрабатываемой в ЕСМА, порядок взаимодействия участников информационного взаимодействия, порядок доступа к информации, содержащейся в ЕСМА, в том числе порядок организации информационного взаимодействия ЕСМА с другими информационными системами, а также иные правила функционирования ЕСМА определяются в Регламенте информационного взаимодействия с использованием ЕСМА (далее - Регламент).

3. Участники информационного взаимодействия

3.1. Участниками информационного взаимодействия являются оператор ЕСМА, пользователи ЕСМА.

3.2. Пользователями ЕСМА являются органы исполнительной власти города Москвы и подведомственные им организации города Москвы, исполнители по контрактам (договорам) на оказание телекоммуникационных услуг.

4. Полномочия участников информационного взаимодействия

4.1. Оператор ЕСМА:

4.1.1. Обеспечивает функционирование ЕСМА в круглосуточном режиме.

4.1.2. Обеспечивает эксплуатацию, развитие (модернизацию) ЕСМА.

4.1.3 Разрабатывает и утверждает Регламент.

4.1.4. Обеспечивает информационное взаимодействие ЕСМА с иными информационными системами.

4.1.5. Обеспечивает разграничение прав доступа к ЕСМА, подключение (доступ) пользователей ЕСМА, ведет учет и статистику пользовательской активности в соответствии с Регламентом.

4.1.6. Обеспечивает целостность и неизменность информации с момента ее размещения в ЕСМА, ее доступность для пользователей ЕСМА и защиту такой информации от несанкционированного доступа к ней

4.1.7. Осуществляет методическое руководство при использовании ЕСМА, консультационную поддержку пользователей ЕСМА по вопросам использования и функционирования ЕСМА.

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

4.2. Отдельные функции оператора ЕСМА по его решению могут быть переданы другому органу исполнительной власти города Москвы, государственному учреждению города Москвы или иной организации в соответствии с нормативными правовыми актами Российской Федерации, правовыми актами города Москвы.

4.3. Пользователь ЕСМА:

4.3.1. Соблюдает требования Регламента.

4.3.2. В установленном порядке в соответствии с Регламентом осуществляет доступ к информации, содержащейся в ЕСМА, и размещение информации в ЕСМА.

4.3.3. Обеспечивает достоверность, полноту размещения информации в ЕСМА, ее соответствие иным требованиям, установленным Регламентом.

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

Обзор документа

Информационная система "Единая система мониторинга и администрирования телекоммуникационных услуг" (далее - ЕСМА) используется для осуществления мониторинга, управления и учета телекоммуникационных услуг, оказываемых пользователям, информационных ресурсов, используемых для оказания таких услуг; сбора и обобщения информации о сбоях в оказании телекоммуникационных услуг; автоматизированного взаимодействия с информационными системами организаций, оказывающих телекоммуникационные услуги, в целях обеспечения контроля качества, объемов и сроков оказания услуг; формирование статистических и оперативных отчетов о функционировании телекоммуникационного оборудования и качестве оказываемых услуг пользователям ЕСМА.

В ЕСМА входят следующие подсистемы: подсистема мониторинга, подсистема предоставления информации, подсистема учета и хранения данных о ресурсах, подсистема учета и администрирования телекоммуникационных услуг.

Пользователями ЕСМА являются органы исполнительной власти Москвы и подведомственные им организации, исполнители по контрактам (договорам) на оказание телекоммуникационных услуг.

ЕСМА является собственностью города Москвы.

Для просмотра актуального текста документа и получения полной информации о вступлении в силу, изменениях и порядке применения документа, воспользуйтесь поиском в Интернет-версии системы ГАРАНТ:

Дорожный уровень – Центры технического управления (ЦТУ) сетями связи, организованные на основе Дирекций связи 17-ти Железных Дорог;

Функциональная структура системы представлена на Рис. 1.


Рис.1 Функциональная структура системы

С точки зрения выполняемых функций в ЕСМА можно выделить следующие самостоятельные программные модули:

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

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

Существуют следующие режимы использования программы:

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


Режим Статистической отчетности позволяет сформировать дополнительные отчетные формы:

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

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

Детализация местоположения отображаемых объектов выполняется с точностью до железнодорожной станции.


Рис.3. Отображение данных в системе

Данный модуль реализован в виде Windows-программы, инсталлируемой на компьютере пользователя системы и получающей актуальные данные с сервера ЕСМА. Период запроса установлен 15 сек.


Рис. 4. Фрагмент работающей системы

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

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

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

Модули стыковки с СУСП (Системами Управления Сетями Производителей)

image

В прошлой публикации мы рассказали о том, как работают шины и протоколы в промышленной автоматизации. В этот раз сфокусируемся на современных рабочих решениях: посмотрим, какие протоколы используются в системах по всему миру. Рассмотрим технологии немецких компаний Beckhoff и Siemens, австрийской B&R, американской Rockwell Automation и русской Fastwel. А также изучим универсальные решения, которые не привязаны к конкретному производителю, такие как EtherCAT и CAN.

В конце статьи будет сравнительная таблица с характеристиками протоколов EtherCAT, POWERLINK, PROFINET, EtherNet/IP и ModbusTCP.

Стандарт промышленной сети EtherCAT, разработка компании Beckhoff

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

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

Спецификация протокола открыта и доступна, но только в рамках ассоциации разработки — EtherCAT Technology Group.

Вот, как работает EtherCAT (зрелище завораживает, как игра Zuma Inca):

Сеть EtherCAT может иметь любую топологию, но по сути это всегда будет кольцо — из-за использования полнодуплексного режима и двух разъемов Ethernet. Таким образом, телеграмма всегда будет передаваться последовательно каждому устройству на шине.

Кстати, спецификация EtherCAT не содержит ограничений физического уровня 100Base-TX, поэтому реализация протокола возможна на основе гигабитных и оптических линий.

Открытые промышленные сети и стандарты PROFIBUS/NET компании Siemens

Немецкий концерн Siemens давно известен своими программируемыми логическими контроллерами (ПЛК), которые используется по всему миру.

Обмен данными между узлами автоматизированной системы под управлением оборудования Siemens реализуется как по полевой шине, которая называется PROFIBUS, так и в промышленной сети PROFINET.

Шина PROFIBUS использует специальный двужильный кабель с разъемами DB-9. У Siemens он фиолетовый, но мы на практике встречали и другие :). Для связи нескольких узлов разъем может соединять два кабеля. Также в нем есть переключатель для терминального резистора. Терминальный резистор должен быть включен на концевых устройствах сети, таким образом сообщается, что это первое или последнее устройство, а после него уже ничего нет, только мрак и пустота (все rs485 так работают). Если на промежуточном разъеме включить резистор, то следующий за ним участок будет отключен.



Кабель PROFIBUS с соединительными разъемами. Источник: VIPA ControlsAmerica

В сети PROFINET используется аналог витой пары, как правило, с разъемами RJ-45, кабель окрашен в зеленый цвет. Если топология PROFIBUS —шина, то топология сети PROFINET может представлять собой что угодно: хоть кольцо, хоть звезду, хоть дерево, хоть все вместе взятое.

Существуют несколько протоколов обмена по шине PROFIBUS и в сети PROFINET.

  1. PROFIBUS DP — реализация этого протокола подразумевает связь с удаленными подчиненными устройствами, в случае с PROFINET этому протоколу соответствует протокол PROFINET IO.
  2. PROFIBUS PA — является по сути тем же PROFIBUS DP, только используется для взрывобезопасных исполнений передачи данных и питания (аналог PROFIBUS DP с другими физическими свойствами). Для PROFINET взрывобезопасного протокола по аналогии с PROFIBUS пока не существует.
  3. PROFIBUS FMS — предназначен для обмена данными с системами других производителей, которые не могут использовать PROFIBUS DP. Аналогом PROFIBUS FMS в сети PROFINET является протокол PROFINET CBA.

Протокол PROFINET IO делится на несколько классов:

  • PROFINET NRT (без реального времени) — используется в приложениях, где временные параметры не критичны. В нем используется протокол передачи данных Ethernet TCP/IP, а также UDP/IP.
  • PROFINET RT (реальное время) — тут обмен данными ввода/вывода реализован с помощью фреймов Ethernet, но диагностические данные и данные связи все еще передаются через UDP/IP.
  • PROFINET IRT (изохронное реальное время) — этот протокол был разработан специально для приложений управления движением и включает в себя изохронную фазу передачи данных.

Что касается реализации протокола жесткого реального времени PROFINET IRT, то для коммуникаций с удаленными устройствами в нем выделяют два канала обмена: изохронный и асинхронный. Изохронный канал с фиксированной по времени длиной цикла обмена использует тактовую синхронизацию и передает критичные ко времени данные, для передачи используются телеграммы второго уровня. Длительность передачи в изохронном канале не превышает 1 миллисекунду.

В асинхронном канале передаются так называемые real-time-данные, которые тоже адресуются посредством MAC-адреса. Дополнительно передается различная диагностическая и вспомогательная информация уже поверх TCP/IP. Ни real-time-данные, ни тем более другая информация, разумеется, не может прерывать изохронный цикл.

Расширенный набор функций PROFINET IO нужен далеко не для каждой системы промышленной автоматики, поэтому этот протокол масштабируют под конкретный проект, с учетом классов соответствия или классов применения (conformance classes): СС-A, CC-B, CC-CC. Классы соответствия позволяют выбрать полевые устройства и магистральные компоненты с минимально необходимой функциональностью.


Источник: PROFINET university lesson

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

Протокол Ethernet POWERLINK компании B&R

Протокол Powerlink разработан австрийской компанией B&R в начале 2000-х. Это еще одна реализация протокола реального времени поверх стандарта Ethernet. Спецификация протокола доступна и распространяется свободно.

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

Изначально протокол был реализован поверх физического уровня 100Base-TX, но позже была разработана и гигабитная реализация.



Схематическое представление сети Ethernet POWERLINK с несколькими узлами.

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

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

Протокол Ethernet/IP компании Rockwell Automation

Протокол EtherNet/IP разработан при активном участии американской компании Rockwell Automation в 2000 году. Он использует стек TCP и UDP IP, и расширяет его для применения в промышленной автоматизации. Вторая часть названия, вопреки расхожему мнению, означает не Internet Protocol, а Industrial Protocol. UDP IP использует коммуникационный стек протокола CIP (Common Interface Protocol), который также используется в сетях ControlNet / DeviceNet и реализуется поверх TCP/IP.

Спецификация EtherNet/IP является общедоступной и распространяется бесплатно. Топология сети Ethernet/IP может быть произвольной и включать в себя кольцо, звезду, дерево или шину.

Для синхронизации времени в распределенных системах EtherNet/IP использует протокол CIPsync, который является расширением коммуникационного протокола CIP.

Для упрощения настройки сети EtherNet/IP большинство стандартных устройств автоматики имеют в комплекте заранее определенные конфигурационные файлы.

Реализация протокола FBUS в компании Fastwel

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

Существует две физические реализации FBUS. Одна из них — это шина, в которой протокол FBUS работает поверх стандарта RS485. Кроме этого есть реализация FBUS в промышленной сети Ethernet.

FBUS сложно назвать быстродействующим протоколом, время ответа сильно зависит от количества модулей ввода-вывода на шине и от параметров обмена, обычно оно колеблется в пределах 0,5—10 миллисекунд. Один подчиненный узел FBUS может содержать только 64 модуля ввода-вывода. Для полевой шины длина кабеля не может превышать 1 метр, поэтому о распределенных системах речь не идет. Вернее идет, но только при использовании промышленной сети FBUS поверх TCP/IP, что означает увеличение времени опроса в несколько раз. Для подключения модулей могут использоваться удлинители шины, что позволяет удобно расположить модули в шкафу автоматики.



Контроллер Fastwel с подключенными модулями ввода-вывода. Источник: Control Engineering Россия

Итого: как всё это используется на практике в АСУ ТП

Естественно, видовое разнообразие современных промышленных протоколов передачи данных намного больше, чем мы описали в этой статье. Некоторые привязаны к конкретному производителю, некоторые, напротив, универсальны. При разработке автоматизированных систем управления технологическим процессом (АСУ ТП) инженер выбирает оптимальные протоколы, с учетом конкретных задач и ограничений (технических и по бюджету).

Если говорить о распространенности того или иного протокола обмена, то можно привести диаграмму компании HMS Networks AB, которая иллюстрирует доли рынка различных технологий обмена в промышленных сетях.




Источник: HMS Networks AB

Как видно на диаграмме, PRONET и PROFIBUS от Siemens занимают лидирующие позиции.

В таблице ниже собраны сводные данные по описанным протоколам обмена. Некоторые параметры, например, производительность выражены абстрактными терминами: высокая /низкая. Числовые эквиваленты можно отыскать в статьях по анализу производительности.

На рис. 20.3 приведён стек протоколов ОКС№7 в интеллектуальной сети. INAP является прикладным протоколом пользователя интеллектуальной сети, который обеспечивает необходимые функции и процедуры системы ОКС№7 в интеллектуальной сети. ТСАР (Transaction Capability Application Part) является прикладной подсистемой возможностей транзакций и обеспечивает интерфейс необходимого протокола пользователя (в данном случае протокола INAP) и его взаимодействие с SCCP.

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



Рис. 20.3. Стек протоколов системы ОКС№7 в интеллектуальной сети

Подсистема SCCP выполняет следующие дополнительные возможности при работе через подсистему MTP:

· расширяет функции сетевого уровня подсистемы MTP - третьего уровня модели OSI;

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

· обеспечивает гибкие механизмы управления маршрутизацией;

· обеспечивает управление подсистемой SCCP;

· осуществляет расширение адресации.

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

· управление маршрутизацией SCCP (SCRC, SCCP Routing Control);

· управление подсистемой SCCP (SCMG, SCCP Management).


Рис. 20.4. Диаграмма обмена информацией SCCP без установления соединения

· АК - подтверждение приема данных.



Рис. 20.5. Диаграмма обмена информацией SCCP с установлением соединения

Управление маршрутизацией

Управление подсистемой SCCP

· SSC (SCCP/Subsystem Congested). Перегруженность протоколов/подсистемы SCCP.

· SOR (Subsystem Out-of-Service Request). Используется для передачи запроса перехода на дублирующую систему.

· SOG ( Subsystem Out-of-Service -grant). Используется в качестве ответа на SOR согласием на резервирование.

Расширение адресации

SCCP используется для расширения адресации пунктов сигнализации. В число объектов, требующих наличия кода пункта сигнализации (OPC и DPC), входят не только узлы коммутации SSP и SCP интеллектуальной сети, станции коммутации ТфОП/ISDN, но и узлы сотовых сетей подвижной связи GSM (использование ОКС№7 в GSM рассматривается в следующих главах). Единая сеть электросвязи России относится к одной из крупнейших сетей в мире, поэтому поля в 14 бит для кода OPC / DPC может оказаться недостаточно общее число пунктов сигнализации 214=16384.
Для решения этого вопроса надо было либо отводить под это поле 24 бита этикетки (как принято в США), либо строить сеть по иерархическому способу, оставив поле 14 бит. Было принято второе решение.

Взаимодействие уровней ОКС №7 в сети IN. Пример алгоритма представления услуги



Рис. 20.6. Взаимодействие уровней ОКС №7 в сети IN

Здесь используются следующие термины и определения:

· Пользователи ТС (Transaction Capability, пользователи возможности транзакций) – прикладной процесс, использующий TCAP как протокол с сетью. В случае IN это прикладной протокол INAP (в мобильных сетях связи – MAP; в системе эксплуатации, технического обслуживания и администрирования сети ОКС№7 – ОМАР).

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

· Компанент – единица данных протокола для обмена между двумя пользователями ТС.

· Диалог – логическая связь, устанавливаемая между пользователями ТС для обмена компонентами.

· пересчет кода и номера услуги в адрес В-пользователя;

· определение размера и адресата оплаты и распределение оплаты между оператором связи и абонентом услуги (в нашем случае – врачом педиатором).

А- пользователь В-пользователь



Рис 20.7. Схема предоставления услуги PRM

На рис. 20.8 приведена архитектура протокола INAP при взаимодействии SCP и SSP. Протокол INAP представлен набором из подпротоколов ASE (Application Service Element) выполнения отдельных операций. В свою очередь, каждый ASE опирается на подсистему транзакций TCAP, т.е. подпротоколы ASE являются пользователями ТС. Коммутатор услуг SSP реализует три функции:

· коммутацию услуги SSF, выполняющую переключение к SCP при обнаружении запроса на интеллектуальную услугу;

· установление соединения через данную АТС (ССF);

· специализированных ресурсов SRF (Specialized Resource Function), т.е. функцию интеллектуальной периферии.



Рис. 20.8. Архитектура протокола INAP при взаимодействии SSP и SCP


Рис. 20.4. Диаграмма обмена информацией SCCP без установления соединения

· АК - подтверждение приема данных.



Рис. 20.5. Диаграмма обмена информацией SCCP с установлением соединения

Управление маршрутизацией

Управление подсистемой SCCP

· SSC (SCCP/Subsystem Congested). Перегруженность протоколов/подсистемы SCCP.

· SOR (Subsystem Out-of-Service Request). Используется для передачи запроса перехода на дублирующую систему.

· SOG ( Subsystem Out-of-Service -grant). Используется в качестве ответа на SOR согласием на резервирование.

Расширение адресации

SCCP используется для расширения адресации пунктов сигнализации. В число объектов, требующих наличия кода пункта сигнализации (OPC и DPC), входят не только узлы коммутации SSP и SCP интеллектуальной сети, станции коммутации ТфОП/ISDN, но и узлы сотовых сетей подвижной связи GSM (использование ОКС№7 в GSM рассматривается в следующих главах). Единая сеть электросвязи России относится к одной из крупнейших сетей в мире, поэтому поля в 14 бит для кода OPC / DPC может оказаться недостаточно общее число пунктов сигнализации 214=16384.
Для решения этого вопроса надо было либо отводить под это поле 24 бита этикетки (как принято в США), либо строить сеть по иерархическому способу, оставив поле 14 бит. Было принято второе решение.

Взаимодействие уровней ОКС №7 в сети IN. Пример алгоритма представления услуги



Рис. 20.6. Взаимодействие уровней ОКС №7 в сети IN

Здесь используются следующие термины и определения:

· Пользователи ТС (Transaction Capability, пользователи возможности транзакций) – прикладной процесс, использующий TCAP как протокол с сетью. В случае IN это прикладной протокол INAP (в мобильных сетях связи – MAP; в системе эксплуатации, технического обслуживания и администрирования сети ОКС№7 – ОМАР).

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

· Компанент – единица данных протокола для обмена между двумя пользователями ТС.

· Диалог – логическая связь, устанавливаемая между пользователями ТС для обмена компонентами.

· пересчет кода и номера услуги в адрес В-пользователя;

· определение размера и адресата оплаты и распределение оплаты между оператором связи и абонентом услуги (в нашем случае – врачом педиатором).

А- пользователь В-пользователь



Рис 20.7. Схема предоставления услуги PRM

На рис. 20.8 приведена архитектура протокола INAP при взаимодействии SCP и SSP. Протокол INAP представлен набором из подпротоколов ASE (Application Service Element) выполнения отдельных операций. В свою очередь, каждый ASE опирается на подсистему транзакций TCAP, т.е. подпротоколы ASE являются пользователями ТС. Коммутатор услуг SSP реализует три функции:

· коммутацию услуги SSF, выполняющую переключение к SCP при обнаружении запроса на интеллектуальную услугу;

· установление соединения через данную АТС (ССF);

· специализированных ресурсов SRF (Specialized Resource Function), т.е. функцию интеллектуальной периферии.



Рис. 20.8. Архитектура протокола INAP при взаимодействии SSP и SCP


Рис. 20.4. Диаграмма обмена информацией SCCP без установления соединения

· АК - подтверждение приема данных.



Рис. 20.5. Диаграмма обмена информацией SCCP с установлением соединения

Управление маршрутизацией

Управление подсистемой SCCP

· SSC (SCCP/Subsystem Congested). Перегруженность протоколов/подсистемы SCCP.

· SOR (Subsystem Out-of-Service Request). Используется для передачи запроса перехода на дублирующую систему.

· SOG ( Subsystem Out-of-Service -grant). Используется в качестве ответа на SOR согласием на резервирование.

Расширение адресации

SCCP используется для расширения адресации пунктов сигнализации. В число объектов, требующих наличия кода пункта сигнализации (OPC и DPC), входят не только узлы коммутации SSP и SCP интеллектуальной сети, станции коммутации ТфОП/ISDN, но и узлы сотовых сетей подвижной связи GSM (использование ОКС№7 в GSM рассматривается в следующих главах). Единая сеть электросвязи России относится к одной из крупнейших сетей в мире, поэтому поля в 14 бит для кода OPC / DPC может оказаться недостаточно общее число пунктов сигнализации 214=16384.
Для решения этого вопроса надо было либо отводить под это поле 24 бита этикетки (как принято в США), либо строить сеть по иерархическому способу, оставив поле 14 бит. Было принято второе решение.

Взаимодействие уровней ОКС №7 в сети IN. Пример алгоритма представления услуги



Рис. 20.6. Взаимодействие уровней ОКС №7 в сети IN

Здесь используются следующие термины и определения:

· Пользователи ТС (Transaction Capability, пользователи возможности транзакций) – прикладной процесс, использующий TCAP как протокол с сетью. В случае IN это прикладной протокол INAP (в мобильных сетях связи – MAP; в системе эксплуатации, технического обслуживания и администрирования сети ОКС№7 – ОМАР).

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

· Компанент – единица данных протокола для обмена между двумя пользователями ТС.

· Диалог – логическая связь, устанавливаемая между пользователями ТС для обмена компонентами.

· пересчет кода и номера услуги в адрес В-пользователя;

· определение размера и адресата оплаты и распределение оплаты между оператором связи и абонентом услуги (в нашем случае – врачом педиатором).

Читайте также: