Технологии для
Интеллектуальных
Зданий

+7 (495) 987-42-98
info@sga-bms.ru
контакты

 Компания 
 Наши объекты
 Лицензии и сертификаты
 Рейтинги и награды
 Партнеры
 Виды деятельности 
 Комплексные решения
 Внешний аутсорсинг
 Создание концепции
 Обучение и курсы
 Оборудование 
 SIEMENS
 LONIX
 ЭТОЛОН
 LonArena
 PRODUAL
 Технологии 
 Публикации и статьи 
 Контакты 

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

17.01.2012

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

На сегодняшний день известно три поколения систем автоматизации. Перечислим кратко. К первому поколению систем автоматики относят исключительно централизованные системы. Ко второму – иерархические. Третьим поколением называют распределенные (децентрализованные системы) . Реально применяются до сих пор все три типа

На сегодняшний день известно три поколения систем автоматизации. Перечислим кратко. К первому поколению систем автоматики относят исключительно централизованные системы. Ко второму – иерархические. Третьим поколением называют распределенные (децентрализованные системы) . Реально применяются до сих пор все три типа.

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

Поддержка нескольких интерфейсов одновременно (Мульти-интерфейсность)
При проектировании сетей передачи данных в системах автоматики крайне сложно найти идеальный компромисс между минимизацией времени прохождения сигнала peer-to-peer и временем обновления экранов SCADA.

Для первого нужны децентрализованные сети с малым размером пакета класса Lonworks, CAN, KNX и т.д. Для вторых оптимальнее использовать иерархические системы с большим размером пакета. Конечно, возможно добавить в децентрализованную систему некий «собиратель мониторинговой информации», который будет «вытягивать» из опрашиваемых узлов биты и байты, причем используя штатный по-событийный механизм, компоновать их в килобайтные логические объекты и передавать их (в порядке организованного опроса) на SCADA.

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

Если приводить конкретные примеры – это Lonworks TP/FT10 в качестве первого и BACNET/IP Ethernet в качестве второго. Кроме этого, при необходимости контроллер должен иметь возможность туннелировать телеграммы одного протокола средствами второго и наоборот. Такая особенность может кардинально помочь в случае пропадания связи на одном из каналов.

Опять же, если рассматривать предложенную пару Lonworks-Bacnet, то давно уже реализованы подпротоколы туннелирования Lonworks/IP и Bacnet/LonTalk, т.е. технически все готово для создания подобного устройства.

Хранение исходных кодов программ в самом контроллере
Имеется ввиду возможность хранения на постоянном или сменном Flash – носителе всей необходимой информации для программиста, который собирается видоизменять текст программы. Данный прием уже давно применяется в контроллерах промышленной серии. Например – Siemens Step7.

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

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

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

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

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

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

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

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

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

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

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

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

Таким образом, программист может использовать абсолютно любые средства разработки (в мое время был популярен Java Beans) и загружать бинарный файл в контроллер. При этом абсолютно несложно создать эмулятор контроллера, причем универсальный.

Портрет контроллера будущего
Итак, поразмыслив над каждой из проблем и о путях ее возможного решения перейдем так сказать от анализа к синтезу и обрисуем портрет контроллера будущего. Конструктив контроллера выполнен как стандартный ДИН-реечный корпус. Клеммы быстросъемные, унифицированны, винтовые (хотя многие здесь со мной не согласятся). Клеммы контроллера подробно отмаркированы, исключая ошибки монтажника. На корпусе приведена примерная схема расключения. Все входы и выходы снабжены светодиодной индикацией, даже аналоговые. Есть возможность ручного переключения состояния выходов. Контроллер имеет выход на полевую шину Lonworks TP/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-сервер. Однако съемность карты может здорово пригодится при фатальном сбое контроллера. У меня все. Далее каждый может дописать согласно своего опыта и фантазии.

Григорий Латышев
17 января 2012г.

Возврат к списку
Версия для печати


 Главная  Комплексные решения  Продажа оборудования  Внешний аутсорсинг  Создание концепции 
ООО "СтройГруппАвтоматика" © Разработка сайта