ЖУРНАЛ «СТА» №1/2008

торами и выходную переменную типа LREAL, ссылающуюся на адрес в облас- ти выходных данных программы, кото- рый относится к первому из созданных четырёх регистров с наименьшим иден- тификатором. Особенности реализации Основная проблема реализации про- токола Modbus «поверх» RS485 на ос- нове стандартных универсальных асин- хронных приёмопередатчиков (UART), совместимых с 8250/16550, которые вхо- дят в состав персональных компьютеров и микроконтроллеров, состоит в том, что протокол основан на таймаутах. По нашему мнению, любой сетевой прото- кол, основанный на таймаутах, напри- мер в части принятия решения о завер- шении приёма очередного пакета, явля- ется не очень хорошим протоколом, а вернее – очень нехорошим протоколом. Например, в режиме RTU об окончании передачи очередного пакета свидетель- ствует «тишина» в линии в течение, как минимум, 3,5 символов. Спрашивается, как определить, что эта самая «тишина» наступила, используя стандартный UART, особенно через стандартный драйвер коммуникационного порта Windows? Ответ: абсолютно корректно — никак. Разработка специ- ального драйвера для Windows нереаль- на, поскольку во многих случаях ис- пользуются мультипортовые платы ки- тайского производства, для которых са- ми производители зачастую не в состоя- нии выпустить качественную программ- ную поддержку. В результате встречают- ся ситуации, когда Modbusустройство одного производителя несовместимо с программным обеспечением для Windows другого производителя. В текущей версии системного ПО контроллера CPM702 распознавание окончания передачи пакетов Modbus осуществляется во время обработки пре- рываний от встроенного UART микро- процессора R1610C. Одной из возмож- ных причин прерывания является исте- чение времени, равного длительности четырёх символов (при текущей скоро- сти обмена), в течение которого из приёмного буфера (FIFO) UART ничего не доставалось обработчиком, ничего не поступало из сети, но в буфере присутст- вовал хотя бы один символ. Именно эта причина прерывания и является основа- нием для утверждения, что пакет Modbus RTU принят полностью. ПакетыModbus ASCII завершаются специальными сим- воламиразделителями, поэтому их се- лекция не вызывает затруднений. Как только пакет полностью принят, обра- ботчик прерывания сигнализирует об этом потоку исполнения, в контексте которого исполняется сервис протокола Modbus RTU/ASCII. Данный поток «просыпается» и проверяет правиль- ность пришедшего пакета, вычисляя CRC в соответствии со стандартной про- цедурой, после чего вызывает функцию по номеру, находящемуся в заголовке па- кета. Следует отметить, что все запросы чтения и записи данных по сети Modbus абсолютно асинхронны относительно исполнения прикладной программы контроллера, поскольку информация при этом поступает и считывается из от- дельного коммуникационного буфера. При реализации протокола Modbus «поверх» TCP в контроллере основную трудность представляет разработка или адаптация хотя бы минимального стека протоколов TCP IP. В процессе работы над контроллером CPM703 мы адаптировали две реализации стека: RTIP фирмы EBSnet, приобретённый с операционной системой CMX (http://www.cmx.com/tcpip.htm ), а так- же имеющийся в свободном доступе стек lwIP (http://savannah.nongnu.org/ projects/lwip/). В текущей версии про- граммного обеспечения CPM703 функ- ционирует стек RTIP. Довольно подроб- ный анализ и сравнение различных ар- хитектур стеков TCP/IP приведён в ста- тье Adam Dunkels “Full TCP/IP for 8 Bit Architectures” (http://www.sics.se/~adam/ mobisys2003.pdf). Стек RTIP представляет собой доволь- но «тяжёлую» реализацию традиционно- го интерфейса BSDсокетов, если гово- рить об использовании на столь неболь- шом по вычислительным возможностям устройстве, как CPM703, который, как указывалось в предыдущих частях ста- тьи, реализован на базе 16разрядного микропроцессора R1610C. С а м а р е а л и з а ц и я с е р в е р а Modbus TCP довольно традиционна: имеется отдельный поток операцион- ной системы контроллера, который ожидает на серверном сокете запросов установления соединения. Как только поступает запрос на соединение от не- которого клиента (скажем, от OPCсер- вера), выполняется поиск свободного дескриптора клиентского соединения. Если таковой имеется, соединение с клиентом разрешается, после чего по- ток начинает реагировать на события на вновь открытом клиентском сокете. Со- бытиями являются запросы чтения и за- писи коммуникационных объектов Modbus или инкапсулированного транспорта, а реакцией – вызов соот- ветствующих функций чтения и записи регистров и битовых полей. Каждое клиентское соединение остаётся откры- тым и не освобождается в течение 30 се- кунд при отсутствии запросов по нему. Наша ре ализ ация протокола Modbus TCP поддерживает до трёх со- единений с клиентами (мастерами Modbus TCP), то есть возможно одно- временно просматривать переменные в среде разработки CoDeSys и обмени- ваться данными между контроллером и двумя OPCсерверами на разных ком- пьютерах. В случае если все клиентские соединения заняты и очередной клиент пытается установить соединение, ему предоставляется занятое соединение с самым большим временем «простоя». Во время тестирования мы подверга- ли контроллер «хакерским атакам» в ви- де шквала ложных запросов на установ- ление соединения (до 1500 пакетов в се- кунду), и контроллер в итоге справился с нагрузкой, возобновив нормальный обмен данными по сети после снятия тестовой нагрузки. Однако мы надеем- ся, что пользователи контроллеров CPM703 предусмотрят определённые меры по защите своих промышленных сетей от хакерских атак. В ЗАКЛЮЧЕНИЕ О СЕТЯХ Проделанная нами работа по реализа- ции сетей CANopen (с учётом опыта на- ладки и эксплуатации в системах авто- ведения на электровозах) и Modbus по- зволяет утверждать, что наши предпоч- тения всецело находятся на стороне ин- терфейса CAN как наиболее приспо- собленного к применению в автомати- зированных системах управления, в том числе на узлах с ограниченными вычис- лительными ресурсами. Единственным, на наш взгляд, недостатком CAN явля- ется отсутствие стандартизованного программного интерфейса между драй- вером CANадаптера и приложением, реализующим протокол прикладного уровня. По этой причине мы выпустили OPCсервер для сетей CAN, который поддерживает претендующий на «стан- дартность» программный интерфейс VCI 2.16, предложенный фирмой IXXAT. ● Автор — сотрудник фирмы Fastwel Телефон: +7 (495) 234-0639 E-mail: info@fastwel.ru Web: www.fastwel.ru АППА РАТ НЫ Е С Р Е Д С Т В А / П Р ОМЫШЛ Е ННЫ Е КОН Т Р ОЛЛ Е Р Ы 51 СТА 1/2008 www.cta.ru