Опыт разработки приложений на оборудовании Allen Bradley.

Наша работа с продукцией RocwellAutomation и Allen Bradley началась в роли субподрядчиков ОАО "Криогенмаш". Субподрядчик особо остро чувствует Два Правила Клиента:
  
1. Клиент всегда прав.
2. Если Клиент все-таки не прав см. п.1
  
Банально? Однако, при подробном знакомстве с программными продуктами RocwellAutomation, выяснилось, что эти два правила надо дополнять.
Клиент может не знать, что ему на самом деле нужно. Это нормально, ибо специфика Его работы может не требовать знания всех нюансов построения АСУ ТП. В этом случае мы выступаем в роли эксперта, указывая на "темные пятна" проекта, предупреждая о возможных сложностях реализации. При этом мы не принимаем решения за клиента и не навязываем их ему. Исходя из этого, необходимо было доработать имеющийся САПР так, чтобы на этап проектирования и этап наладки на объекте уходило минимум времени и сил. Иначе убыток гарантирован.

Разработчику еще необходим пакет RSEmulate для частичной проверки ТП, если под рукой нет контроллера AllenBradley. Если он есть - лучше тестироваться на нем, т.к. все нюансы работы его встроенной операционной системы (далее ОС) будут заметнее.

Сначала несколько слов о ПО RocwellAutomation.

Первые проекты мы делали статическими. Это значит, что при проектировании мнемосхем все связи между тегами и графическими отображениями прописываются на каждом видеокадре и в каждом экземпляре графического объекта. Хотите что-то поменять? Придется сделать в лучшем случае пару десятков замен в труднодоступных местах. И еще больше - при группировке графических примитивов. Все равно что-нибудь забудете. Результат неприглядный, плюс к тому - масса скрупулезной рутинной и малоэффективной работы.
Первым шагом в оптимизации проектирования стало написание некоего подобия пользовательского операционного ядра на Visual Basic. Почему Visual Basic? Потому что RSView  содержит встроенный интерпретатор этого языка, причем функции доступа и работы со внутренней БД RSView уже оформлены в виде отдельного класса. Самой лучшей аналогией того, что получилось в итоге, будет динамическая генерация HTML страниц. Файл мнемосхемы RSView  представляет собой скриптовый документ с указаниями внутреннему интерпретатору, что и где рисовать. Сюда мы вмешаться не смогли. Однако протокол построения мнемосхем RSView допускает использование параметрических макроподстановок (по аналогии с языком Си), в том числе и из файла. Синтаксис этих команд очень прост и выдается в качестве автоподсказки при создании любого нового параметрического файла. Желающих детально разобраться отсылаю к системе помощи RSView. Поверьте, это проще, чем Вы думаете.
Эти параметрические файлы, при необходимости, могут генерироваться с помощью скриптов Visual Basic. Система оказалась весьма удобной для использования одного и того же видеокадра, например, тренда, но для разных параметров.
С помощью скриптов получилось организовать и навигацию по мнемосхемам. К примеру, если Вы не указали прямой адрес перехода по параметру, на котором Вы кликнули мышью, то скрипт начинает исследовать параметрические файлы мнемосхем на предмет наличия оного параметра. Если найдет - переадресует, если нет - уведомит Вас. Время реакции - около 0.5 с при десяти больших статических мнемосхемах. А теперь, если представить необходимость построения, например, диагностической таблицы оборудования, с возможностью перехода по каждому параметру, то картина, полагаю, будет совсем ясной. Особенно для того, кто сам хоть раз вручную прописывал ссылки в RSView.
Однако, у этой медали оказалась и оборотная сторона. Чрезмерное количество скриптов, особенно периодически исполняемых, сильно нагружает компьютер. Кроме того, в случае "зависания" одного скрипта, остальные не могут быть выполнены. Данный Visual Basic - не самое лучшее средство для параллельного многопоточного программирования.
Все это привело к тому, что все вспомогательные функции, наподобие глобального редактирования БД, были из ядра убраны, а их роль взяли на себя маленькие сторонние программки, работающие с файлами-снимками БД. Импорт-экспорт этих файлов является стандартной утилитой RSView. Сами файлы имеют формат CSV и весьма просты для понимания и редактирования.
Также, в итоге, отказались, по возможности, от скриптов, которые можно было заменить стандартными макросами  RSView. В отличие от скриптов, макросы внутренний интерпретатор RSView исполняет в многопоточном режиме и вероятность их "зависания" ничтожно мала.
В итоге получилась гибрид-заготовка из стандартных видеокадров, скриптов, макросов и вызываемых прямо из проекта окон редактирования. На практике работа проектировщика стала сводиться к рисованию мнемосхем и внутренней БД. Сейчас дорабатывается механизм максимальной автоматизации создания БД на основе стандартной таблицы (перечня) входных и выходных сигналов, поставляемой нам в составе ТЗ. На текущий момент время, необходимое для разработки одним человеком проекта размером в 2500-3000 тэгов составляет около двух недель.
Замечу, что в данном случае речь идет о проекте верхнего (операторского) уровня. 3000 тэгов соответствуют 300 - 400 полевых сигналов контроля и управления на объекте.

Теперь об аппаратном обеспечении.

Нами активно используются две линейки "железной" продукции AllenBradley: CompactLogix и ControlLogix. Лично я являюсь сторонником второй, хотя формально разница между процессорными блоками Compact и  Control - только в мощности процессора и в архитектуре построения шины обмена данными с модулями УСО (Устройство Сопряжения с Объектом, куда попадают блоки дискретного и аналогового ввода-вывода, коммуникационные модули и т. д.).

Недостатками линейки CompactLogix являются, на мой взгляд, последовательная шина обмена с УСО и не совсем удачная компоновка процессорного модуля. Преимуществами являются меньший размер и меньшая стоимость, по сравнению с линейкой ControlLogix. Причем последняя проявляется за счет дешевизны не сколько самого контроллера CompactLogix, сколько модулей УСО к нему.
  
Немного подробнее о работе с CompactLogix.

Шина обмена.
Последовательное построение шины обмена данными вносит жесткие ограничения на количество модулей УСО, подключаемых к одному процессорному модулю (см. рис. 1), а также полную невозможность "горячей" замены вышедшего из строя модуля. Другими словами - для замены сломанного УСО придется останавливать технологическую программу, а, следовательно, и весь технологический процесс. Попытки "горячей" замены модуля категорически не рекомендуются. Разрыв последовательной шины, неизбежный при отключении стыковочных разъемов УСО, как минимум приведет к тому, что процессорный модуль перестанет видеть все модули УСО. Как максимум - к выходу из строя интерфейсного модуля процессора. В нашей практике такого не случалось, однако в руководстве пользователя подобный момент оговаривается.

 
Рис.1

Следует отметить, что в случае восстановления рассоединенной шины обмена, в любом случае пройдет еще некоторое время, пока контроллер снова "увидит" свои УСО. Причем во все это время ни один из УСО не будет управляться ТП. Если же время отсутствия связи с УСО в режиме работы ТП превысит некий лимит - ОС контроллера выдаст системный сигнал "критическая неисправность" с последующей остановкой ТП.
  
Компоновка процессорного модуля.
Главным недостатком контроллера CompactLogix L35E, с которым мы работаем, лично я считаю совмещение в одном корпусе процессорной платы и модуля Ethernet порта.
Подчеркиваю, что рассматривается вполне определенная разновидность контроллеров CompactLogix. Рискну предположить, что самая распространенная, но речь сейчас не об этом.
Такое решение о компоновке, скорей всего, было принято в связи с ограничением количества УСО на один процессор CompactLogix (следует заметить, что коммуникационный порт Ethernet выпускается для CompactLogix и отдельным модулем). Нечего сказать, идея неплохая, если бы не одно "но". В руководстве пользователя (в частности документ RocwellAutomation ВСТАВИТЬ НОМЕР) оговаривается, что в случае пропадания напряжения в момент изменения прошивки контроллера (Firmware), Ethernet порт может оказаться недоступен. Подобные повреждения устраняются только в гарантийной мастерской.
На нашей практике два контроллера отправились в гарантийный ремонт без всякого "пропадания питания". Перепрошивка осуществлялась по последовательному порту с использованием исключительно фирменных средств RocwellAutomation: RSLogix, RSLinx, ControlFlash и файл фирменной прошивки с сайта RocwellAutomation. Диагноз гарантийной мастерской - пропадание питания при обновлении прошивки. Время ремонта, с учетом всех возможных методов "ускорения", составило около одного месяца.
Подобные факты наталкивают на мысль, что между платой процессора и чипсетом Ethernet нет аппаратного детектирования, что, на мой взгляд, является серьезным проколом в проектировании процессорного модуля. Замечу также, что безопасным методом перепрошивки процессора CompactLogix является использование BootP-DHCP сервера. Это стандартная утилита, поставляемая в комплекте с RSLogix. Перепрошивка в данном случае осуществляется через Ethernet порт и, на нашей практике, ни разу не дала сбоя.

Рис.2

Еще один сюрприз ожидал нас при попытке использовать систему удаленных взаимосвязанных тэгов (см. рис.2). Данная модель подразумевает стыковку двух или более контроллеров по Ethernet. При этом некий тэг, управляемый на одном из них (Produced Tag), распространяет свои изменения на свои "отражения" (Consumed Tag) на других контроллерах. Модель имеет ограничения на количество "потребителей" и время доставки тега до его "отражения".
Два контроллера CompactLogix L35E объединялись в одну подсеть Ethernet с помощью SDSL-модемов ВСТАВИТЬ МОДЕЛЬ НОВОКУЗНЕЦК. Данная модель, сочетающая в себе сетевой концентратор (HUB) и SDSL-модем, позволяла организовать Ethernet мост через витую пару между удаленными точками. В случае Новокузнецкого Металлургического Комбината, где мы впервые применили подобную схему, расстояние между модемами составило около 1 км.
Нюанс состоял в том, что при стыковке двух контроллеров CompactLogix через локальный сетевой концентратор, система прекрасно работала. При подключении через SDSL, даже на коротком участке витой пары, связь между контроллерами по внутреннему протоколу рвалась. При этом маршрутизация Ethernet пакетов через SDSL-мост сохранялась. Изменение настроек времени доставки данных (для CompactLogix этот интервал составляет 2-750 мс) ничего не дал, хотя реальное время задержки составляло около 4 мс.
Связь между контроллерами удалось установить только при переходе с системы взаимосвязанных тэгов на систему отправки сообщений (SystemMessage, стандартное средство обмена упакованными данными в RSLogix), не имеющих фиксированного времени доставки информации.

Почему CompactLogix дешевле?
Его УСО обладают менее развитой самодиагностикой и самостоятельностью принятия решений по сравнению с аналогичными представителями ControlLogix. Например, нет аппаратной диагностики обрыва токовой петли в случае аналогового ввода-вывода 4-20 мА. Снижено энергопотребление. Несколько более медленная скорость опроса УСО. Одним словом, простите за каламбур, труба пониже и дым пожиже. В плане подключения полевого КИП соответствующие модули классов Compact и Control можно считать идентичными.

Источники питания
Стоит отметить одну неприятную особенность источников питания для линейки CompactLogix. Системный идентификатор конкретного модуля - 1769РА4. В связи с использованием последовательной шины, на модули УСО CompactLogix налагается еще одно ограничение: расстояние (в модулях) от блока питания. В инструкциях к УСО этот параметр отдельно оговаривается. Из-за этого, при размещении в 19' стойке большого количества УСО  CompactLogix (обычно в несколько ярусов, см. рис.3), их приходиться "разбавлять" модулями питания. Это приводит к тому, что высоковольтные линии питания могут оказаться в непосредственной близости от сигнальных линий, идущих к УСО. Данный момент приходиться отдельно учитывать при проектировании.
В нашей практике был и такой случай. На одном из объектов, при первом пуске стойки, в одном из модулей питания переключатель 220/110 В находился в положении 110 В. Переключатель малозаметен и скрыт под специальной защитной крышечкой, которая, в свою очередь, находится под лицевым откидным щитком модуля. Причем стойка уже тестировалась в лабораторных условиях в нашей фирме и была полностью проверена.
При включении питания сгорел предохранитель в модуле 1769РА4. После разбора обстоятельств предохранитель был заменен и снова подано питание на стойку. Модуль питания вышел из строя. Ремонт осуществили на месте, сорвав гарантийные пломбы. Это было сделано по согласованию с Клиентом, т.к. на объекте нашелся квалифицированный специалист по ремонту аппаратуры AllenBradley. Согласно его заключению, вышла из строя система контроля и ограничения напряжения. Я оставляю комментарии на Ваше усмотрение, уважаемый Клиент, замечу только, что подобных ситуаций у нас более не повторялось. На этом я пока что закончу краткий обзор нашей работы с CompactLogix и перехожу к следующей линейке: ControlLogix.