ѕоиск по сайту
ќписани€ и документы
Ќовости компании
 оротко о новом
 ак это работает
“ехнологии и решени€

ѕротоколы св€зи в ј—” “ѕ.

ѕротоколы св€зи в ј—” “ѕ

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


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


ƒл€ организации промышленных сетей используетс€ множество интерфейсов и протоколов передачи данных, например Modbus, Ethernet, CAN, HART, PROFIBUS и пр. ќни необходимы дл€ передачи данных между датчиками, контроллерами и исполнительными механизмами (»ћ); калибровки датчиков; питани€ датчиков и »ћ; св€зи нижнего и верхнего уровней ј—” “ѕ. ѕротоколы разрабатываютс€ с учетом особенностей производства и технических систем, обеспечива€ надежное соединение и высокую точность передачи данных между различными устройствами. Ќар€ду с надежностью работы в жестких услови€х все более важными требовани€ми в системах ј—” “ѕ станов€тс€ функциональные возможности, гибкость в построении, простота интеграции и обслуживани€, соответствие промышленным стандартам.


Ќаиболее распространЄнной системой классификации сетевых протоколов €вл€етс€ теоретическа€ модель OSI (базова€ эталонна€ модель взаимодействи€ открытых систем, англ. Open Systems Interconnection Basic Reference Model). —пецификаци€ этой модели была окончательно прин€та в 1984 году ћеждународной ќрганизацией по —тандартизации (ISO). ¬ соответствии с моделью OSI протоколы дел€тс€ на 7 уровней, расположенных друг над другом, по своему назначению — от физического (формирование и распознавание электрических или других сигналов) до прикладного (API дл€ передачи информации приложени€ми). ¬заимодействие между уровн€ми может осуществл€тьс€, как вертикально, так и горизонтально (–ис. 1). ¬ горизонтальном взаимодействии программам требуетс€ общий протокол дл€ обмена данными. ¬ вертикальном – посредством интерфейсов.


 ¬заимодействие между уровн€ми

–ис. 1. “еоретическа€ модель OSI.


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

ѕрикладной уровень – уровень приложений (англ. Application layer). ќбеспечивает взаимодействие сети и приложений пользовател€, выход€щих за рамки модели OSI. Ќа этом уровне используютс€ следующие протоколы: https, gopher, Telnet, DNS, SMTP, SNMP, CMIP, FTP, TFTP, SSH, IRC, AIM, NFS, NNTP, NTP, SNTP, XMPP, FTAM, APPC, X.400, X.500, AFP, LDAP, SIP, ITMS, Modbus TCP, BACnet IP, IMAP, POP3, SMB, MFTP, BitTorrent, eD2k, PROFIBUS.


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

ѕредставительский уровень (англ. Presentation layer) – уровень представлени€ данных. Ќа этом уровне может осуществл€тьс€ преобразование протоколов и сжатие/распаковка или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально. «апросы приложений, полученные с уровн€ приложений, он преобразует в формат дл€ передачи по сети, а полученные из сети данные преобразует в формат, пон€тный приложени€м.   этому уровню традиционно относ€т следующие протоколы: https, ASN.1, XML-RPC, TDI, XDR, SNMP, FTP, Telnet, SMTP, NCP, AFP.


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

—еансовый уровень (англ. 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 €вл€етс€ условной.


¬ мировой практике, среди сетей общего применени€, наиболее широко распространен протокол https (англ. HyperText Transfer Protocol — «протокол передачи гипертекста»). ќтноситс€ к прикладному и представительскому уровн€м теоретической модели OSI. https базируетс€ на технологии «клиент-сервер», то есть существует потребитель (клиент), который инициирует соединение и посылает запрос, и поставщик (сервер), который ожидает соединени€ дл€ получени€ запроса, производит необходимые действи€ и возвращает обратно сообщение с результатом. ќсновным типом Ќ““–-клиента €вл€етс€ браузер, например Mozilla Firefox, Opera или Microsoft Internet Explorer. https в насто€щее врем€ повсеместно используетс€ во ¬семирной паутине дл€ получени€ информации с веб-сайтов.


“ехнологи€ клиент-сервер 

–ис. 2. “ехнологи€ клиент сервер.


Ќа базе https разработаны расширенные протоколы: httpsS (англ. Hypertext Transfer Protocol Secure), поддерживающий шифрование, и https-NG (англ. https Next Generation), увеличивающий быстродействие Web и расшир€ющий возможности промышленного применени€.


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


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


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


Ќа сегодн€шний день протокол https и его модификации поддерживаютс€ оборудованием и программным обеспечением большинства производителей. –ассмотрим некоторые из них.


¬ оборудовании компании Korenix серий JetNet, JetRock, JetPort, JetI/O, JetBox (построение сетей на базе промышленного Ethernet), JetWave (беспроводные решени€) протоколы семейства https используютс€ дл€ организации доступа, конфигурировани€ и управлени€ устройствами.


 омпани€ ICPDAS дл€ работы с протоколом https предлагает следующее оборудование и программное обеспечение.  онтроллеры серии ’–ј , WinPAC, WinCon, LinPAC, ViewPAC работают под управлением операционных систем Windows и Linux, с встроенным https-сервером. ѕрограммные пакеты InduSoft (SCADA), ISaGRAF, Web HMI, VXCOMM, MiniOS7 Studio, также используют https-сервер дл€ св€зи и взаимодействи€ с устройствами.


”правл€емые коммутаторы, встраиваемые компьютеры, оборудование промышленных беспроводных сетей, производства компании ћоха, не обход€тс€ без использовани€ протоколов семейства https.


—овместимость протоколов семейства 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 ASCII и Modbus RTU заключаетс€ в способе кодировани€ символов. ¬ режиме ASCII данные кодируютс€ при помощи таблицы ASCII, где каждому символу соответствует два байта данных. ¬ режиме RTU данные передаютс€ в виде 8-ми разр€дных двоичных символов, что обеспечивает более высокую скорость передачи данных. ASCII допускает задержку до 1 секунды в отличии от RTU, где сообщени€ должны быть непрерывны. “акже режим ASCII имеет упрощенную систему декодировани€ и управлени€ данными.


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


ќбычно в сети есть только один клиент, так называемое, «главное» (англ. master) устройство, и несколько серверов — «подчиненных» (slaves) устройств. √лавное устройство инициирует транзакции (передаЄт запросы). ѕодчиненные устройства передают запрашиваемые главным устройством данные, или производ€т запрашиваемые действи€. √лавный может адресоватьс€ индивидуально к подчиненному или инициировать передачу широковещательного сообщени€ дл€ всех подчиненных устройств. ѕодчиненное устройство формирует сообщение и возвращает его в ответ на запрос, адресованный именно ему.


ќбласти промышленного применени€: организаци€ св€зи датчиков и исполнительных механизмов с контроллером, св€зь контроллеров и управл€ющих компьютеров, св€зь с датчиками, контроллерами и корпоративными сет€ми, в 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 €вл€етс€ реализованный на втором уровне модели OSI протокол PROFIBUS-FDL. ƒанный протокол использует процедуру доступа с помощью маркера (token). “ак же, как и сети на базе протоколов Modbus, сеть PROFIBUS состоит из ведущих (master) и ведомых (slave) устройств. ¬едущее устройство может управл€ть шиной.  огда у ведущего (master) устройства есть право доступа к шине, оно может передавать сообщени€ без удаленного запроса. ¬едомые устройства – это обычные периферийные устройства, не имеют прав доступа к шине, то есть они могут только подтверждать принимаемые сообщени€ или передавать сообщени€ ведущему устройству по его запросу. ¬ минимальной конфигурации сеть может состо€ть либо из двух ведущих, либо из одного ведущего и одного ведомого устройства.


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


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


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


PROFIBUS FMS (Fieldbus Message Specification - —пецификаци€ сообщений полевого уровн€) - универсальный протокол дл€ решени€ задач по обмену данными между интеллектуальными сетевыми устройствами (контроллерами, компьютерами/программаторами, системами человеко-машинного интерфейса) на полевом уровне. Ќекоторый аналог промышленного Ethernet, обычно используетс€ дл€ высокоскоростной св€зи между контроллерами и компьютерами верхнего уровн€.


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


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


ќбласти промышленного применени€: организаци€ св€зи датчиков и исполнительных механизмов с контроллером, св€зь контроллеров и управл€ющих компьютеров, св€зь с датчиками, контроллерами и корпоративными сет€ми, в 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 ведущего устройства.


јвтор: ‘атыхов ћ. Ѕ., ќќќ «ѕЋ -—истемы»

–азделы
навигаци€
ќбратна€ св€зь
вопросы и ответы
¬аше им€:
E-mail:
“елефон:
—ообщение:
220072, –еспублика Ѕеларусь, г. ћинск, ул. ѕ.Ѕровки, 19 - оф.438 / E-mail: info@plcsystems.by