Требования к перспективным системам автоматики манифест автоматики 4-го поколения

На сегодняшний день известно три поколения систем автоматизации. Перечислим их кратко. К первому поколению систем автоматики относят исключительно централизованные системы. Ко второму — иерархические. Третьим поколением называют распределенные (децентрализованные системы). Реально применяются до сих пор все три типа. Последней новинке (децентрализованным системам) стукнуло недавно уже 20 лет. Пришло время задуматься о том, какие задачи не решены в существующих системах. Другими словами, пора задуматься и сформулировать требования и пожелания к системам будущего, даже если на нынешнем уровне развития науки и техники они кажутся невыполнимыми.

ПОПЫТАЕМСЯ ПЕРЕЧИСЛИТЬ ПРОБЛЕМЫ И ВОЗМОЖНЫЕ ПУТИ ИХ РЕШЕНИЯ:

1. Поддержка нескольких интерфейсов одновременно (мульти-интерфейсность)

При проектировании сетей передачи данных в системах автоматики крайне сложно найти идеальный компромисс между минимизацией времени прохождения сигнала peer-to-peer и временем обновления экранов SCADA. Для первого нужны децентрализованные сети с малым размером пакета класса Lonworks, CAN, KNX и т.д. Для вторых оптимальнее использовать иерархические системы с большим размером пакета. Конечно, возможно добавить в децентрализованную систему некий «собиратель мониторинговой информации», который будет „вытягивать“ из опрашиваемых узлов биты и байты, причем, используя штатный пособытийный механизм, компоновать их в килобайтные логические объекты и передавать их (в порядке организованного опроса) на SCADA. Однако такой путь очень трудоемок в настройке. Суть предлагаемого решения — снабдить каждый контроллер сразу двумя интерфейсами. Один оптимизировать для работы в классических „полевых шинах“, устроенных по принципу децентрализованной автоматики, а второй — оптимизированный для „килобайтного“ мониторинга. Если приводить конкретные примеры — это Lon-worksTP/FT10 в качестве первого и BACNET/IPEthernet в качестве второго. Кроме этого при необходимости контроллер должен иметь возможность туннели-ровать телеграммы одного протокола средствами второго и наоборот. Такая особенность может кардинально помочь в случае пропадания связи на одном из каналов. Опять же, если рассматривать предложенную пару Lonworks-Bacnet, то давно уже реализованы под протоколы туннели-рования Lonworks/IP и Bacnet/LonTalk, т.е. технически все готово для создания подобного устройства.

2. Хранение исходных кодов программ в самом контроллере

Имеется в виду возможность хранения на постоянном или сменном Flash-носителе всей необходимой информации для программиста, который собирается видоизменять текст программы. Данный прием уже давно применяется в контроллерах промышленной серии. Например, SiemensStep7. Конечно, данное требование приведет к удорожанию оборудования, однако электроника дешевеет, а время работы программиста — нет. Наверное, каждый профессиональный программист сможет назвать сотни случаев, когда исходные коды программ для свободно программируемых контроллеров были безвозвратно потеряны спустя два или три года. Даже применительно к контроллерам с фиксированной программой данная опция позволит хранить ману-алы и описания, что опять же сэкономит время специалиста. Еще одно возможное применение такой памяти — смена программ и/или заводских прошивок. Однако для этой последней опции желательно применять съемный конструктив.

3. Свободный унифицированный слот для подключения интерфейсных плат

Каждый раз, когда на рынке появляются новые технологии передачи данных, появляются новые модели контроллеров, их поддерживающие. Идея очень проста -снабдить контроллер специализированным внутренним разъемом (слотом), в который можно будет вставить существующие или только проектируемые интерфейсные карты. Тогда при появлении на рынке нового протокола не нужно будет менять контроллер целиком. Достаточно будет поменять интерфейсную плату. Вопрос выбора формата такого разъема сложен и неочевиден, возможно, это будет USB, возможно, FireWire или SPI. С определенностью можно только сказать, что это будет разновидность некой последовательной шины. Если данная идея станет реализовываться, возможно, на рынке появятся узкоспециализированные производители интерфейсных карт для сетей автоматики. Следующий напрашивающийся вывод — конструирование контроллера сразу с использованием таких слотов. На рынке уже существуют прототипы, построенные частично по такому принципу. Достаточно взглянуть на PCD1 от Saia-Burgesили PCO от Carel.

4. Использование радиочастоты как резервного канала

Сфера применения радиочастотных физических каналов традиционно ограничена либо квартирами, либо мобильными/передвижными САУ. В первом случае главной причиной является невозможность прокладки кабеля, во втором — его принципиальное отсутствие. Однако даже для классического объекта применение радиочастоты способно серьезно сократить время работы пуско-наладчика и/или ремонтника. Предлагается снабдить каждый контроллер радиочастотной интерфейсной картой, имплементирующей один из используемых в контроллере протоколов. Опускаясь до конкретики, могу предложить Wi-Fi карту с использованием Lonworks/IP протокола.

5. Автонастройка сети (плаг-энд-плэй нового поколения)

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

6. Встроенный Web-интерфейс для настройки основных параметров

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

7. Защита от действий злоумышленника

Контроллер должен иметь как минимум три механизма защиты от действий злоумышленника:

■ защита настройки сетевых параметров и т.д.;

■ аутентификация отправителя сообщений;

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

8. Автоматическое балансирование трафика с использованием нескольких физических сред передачи

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

9. Встроенный режим сетевого адаптера

Так как контроллер согласно перечисленным идеям у нас уже имеет несколько сред передачи (в том числе Ethernet), возникает идея внедрить во встроенную операционную систему контроллера подпрограмму сетевого интерфейса класса IP для примененной в контроллере полевой шины. Например, мы хотим подключиться к полевой шине с ноутбука. Мы переключаем контроллер в режим туннелирующего адаптера в протокол TCP/IP и работаем через него как через сетевой адаптер. В идеале работа контроллера по его основному предназначению при этом может вообще не прерываться. Данная опция способна кардинально облегчить работу не только пуско-наладчика, она способна внести абсолютно новые перспективы в технологию работы SCADA, которые смогут динамически искать оптимальную точку подключения к шине или же использовать несколько точек параллельно.

10. Аппаратная реализация через эмуляцию специализированных процессоров на универсальных АРМ или RISC процессорах

Данная идея предлагает отказаться от использования реальных специализированных чипсетов различных протоколов в пользу их микропрограммной эмуляции средствами АРМ или RISC процессоров. Данный подход гораздо более гибок и мощен одновременно.

11. Создание единой унифицированной платформы для разработки ПО контроллеров

Идея слегка утопичная на первый взгляд. Однако в мире, где даже производители мобильных телефонов узаконили Java-приложения, являющиеся кросс-платформенными, использование единого языка уже не кажется фантастикой. Зачем изобретать — пусть будет Java. Однако библиотеки обработки портов ввода/вывода лучше спрятать в ядро ОС контроллера. Таким образом, производитель свободно программируемого контроллера должен позаботиться, чтобы для Java приложения работа с портами выглядела как унифицированный ввод/вывод через ядро ОС. Так, например, дискретный вход №1 может иметь имя /dev/DI_01, аналоговый выход №2 — /dev/AO_2 и т.д. Таким образом, программист может использовать абсолютно любые средства разработки (в мое время был популярен JavaBeans) и загружать бинарный файл в контроллер. При этом абсолютно несложно создать эмулятор контроллера, причем универсальный.

ПОРТРЕТ КОНТРОЛЛЕРА БУДУЩЕГО

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

Конструктив контроллера выполнен как стандартный ДИН-реечный корпус. Клеммы быстросъемные, унифицированные, винтовые (хотя многие здесь со мной не согласятся). Клеммы контроллера подробно отмаркированы, исключая ошибки монтажника. На корпусе приведена примерная схема расключения. Все входы и выходы снабжены светодиодной индикацией, даже аналоговые. Есть возможность ручного переключения состояния выходов. Контроллер имеет выход на полевую шину LonworksTP/FT10 и разъем RJ45 с поддержкой гигабитного Ethernet. Дополнительно контроллер поддерживает беспроводной Ethernet через встроенный Wi-fi адаптер. Внутри предусмотрена возможность замены платы Lon на некую другую (KNX, CAN, Modbus и др.). При этом разъем платы — USB3. Контроллер снабжен матричным экраном и пятью кнопками навигации. Отдельно есть гнездо для микро SD-Card. Контроллер может быть модульным или моноблочным — здесь не берусь принять чью-то сторону.

А теперь обрисуем работу программиста пуско-наладчика будущего.

Итак, программист пришел на объект, где в элегантном шкафу исполнения IP-65 стоят, сверкая светодиодами, уже рас-ключенные монтажниками контроллеры.

Программист начинает с настройки IP-адресов сетевых карт контроллеров и параметров доступа (пароль и т.д.). Можно позволить контроллерам самостоятельно разобраться с адресами, просто списав их значения с экранов контроллеров (пример использования pLug-and-pLay). Заметим, что ничего сложнее планшетника (возможно, Ipad) или легкого ноутбука программисту иметь необязательно. Вторая стадия — настройка и юстировка портов ввода/вывода. Программист настраивает порты через Web-интерфейс контроллера, заставляя включаться и выключаться каждый дискретный выход и выдавая нужный ток или напряжение на аналоговые выходы. С входами — наоборот, нужно проверить адекватность измерения и единиц измерения. Для ускорения процесса можно применить какую-либо спецпрограмму типа «бегущий огонек» или „аналоговая пила“. После этого приходит очередь заливки программы. Как было описано выше, это бинарный файл Java машины, заранее отлаженный в домашних или офисных условиях. При таком уровне унификации, скорее всего, будут применяться „каталожные“ готовые алгоритмы, имеющие соответствующие сертификаты качества алгоритма (например, EUBAC). Программист всего лишь поправит имя порта, согласно применяемому контроллеру. Неиспользуемые порты пометит как dev/nuLL. Последний и самый сложный шаг — настройка взаимодействия контроллеров по сети (в тех случаях, когда это необходимо). Применительно к Lonworks это будет связывание сетевых переменных. Здесь можно и нужно применить pLug-and-pLay, например, для связывания переменных, транслирующих наружную температуру или такие глобальные аварийные сигналы, как „Пожар“. Остальное, к сожалению, придется связывать вручную. Искренне надеюсь на WEB-вер-сию LonMaker, внедренную в ОС каждого контроллера. Тестовый прогон системы придется делать как всегда — наблюдая в реальном времени за поведением управляемого оборудования. Можно попросить помочь более опытного коллегу, подключив его к процессу через Интернет. Когда все вроде как заработало — осталось самое главное. Нужно скопировать исходный код программы на встроенный носитель (SD-карта). Сделано это будет, скорее всего, через встроенный FTP-сервер. Однако съемность карты может здорово пригодиться при фатальном сбое контроллера.

видеонаблюдения,  система безопасности,  новинки,  контроль доступа 

Читайте новости