Что такое датчик opc
Как просто подключить любой датчик OPC сервера к проекту narodmon.ru
Совсем недавно я узнал что существует один простой, но полезный проект «Народный мониторинг» Смысл его в том, если вкратце, чтобы объединить множество разрозненных датчиков мониторинга окружающей среды в одном месте. Ведь одно дело например посмотреть прогноз погоды в интернете и совсем другое дело увидеть реально где какие температура, влажность, давление и их изменение с течением времени.
Или например если банально лень встать и посмотреть на градусник за окном)
Проект этот позволяет «складировать», отображать и смотреть историю изменения данных. В общем все что для счастья надо — там есть. Можно датчики делать публичными или приватными.
Для желающих приобщится существуют готовые устройства и как их заполучить можно узнать на сайте. Вот ссылка на пост с которого все начиналось и пример устройства там же.
Кроме этого существует множество датчиков в составе SCADA систем и многие из них могут отражать параметры окружающей среды в самых различных географических точках. Вот об этом я и хочу рассказать — как любой датчик OPC сервера любой SCADA системы прикрутить к вышеописанному сервису.
Итак нам понадобится:
Все это устанавливается на машину туда же где крутится OPC сервер, или удаленно. Я устанавливал локально.
Далее просто запускаем мой скрипт поражающий своей сложностью:
Как видно я подключаюсь к ОРС серверу «OWEN.RS485» и считываю значение «итема» ‘Com1/TRM138(8bit adr=24)/ChannelData3/rEAd’. Таким образом можно читать значение любого «итема» ОРС сервера.
Кстати если изучить документацию к OpenOPC то вы там найдете много полезных функций которых вполне достаточно для создания например небольшой визуализации.
Пакет для отправки формируется из уникального ID устройства 123456789ABCDE (можно придумать и свой, но лучше использовать серийный номер датчика или модуля ввода) и уникального ID датчика. Последний я получил добавив к ID устройства 0x10, что означает что это температурный датчик. Подробнее можно почитать на сайте проекта в разделе для разработчиков.
Само подключение к сервису происходит очень просто. Нужно зарегистрироваться на сайте и начинать отсылать пакеты. Когда система получит несколько пакетов можно будет создать новое устройство и добавить в него датчик. Для отладки есть мониторинг пакетов с вашего IP в разделе для разработчиков. Со всеми вопросами, благодарностями и предложениями по поводу сервиса можете обращаться к создателю сервиса SSar
Для тех кто не ищет легких путей добавлю листинг службы windows которая делает тоже самое:
Все попытки писать сообщения в системный журнал закомментированны потому что в WinXP они не работают. Разбираться дальше не стал потому что на Win7 все нормально. Можете «запилить» себе свою службу с «блэкджеком и женщинами легкого провидения».
Протокол OPC UA в приборах ОВЕН
Технология OPC получила широкое распространение в промышленной автоматизации. В последние годы все более актуальной становится ее современная версия – OPC UA (Unified Architecture). В данной статье описываются преимущества новой технологии и ее использование в приборах компании ОВЕН.
Первая версия стандарта OPC была опубликована консорциумом OPC Foundation в 1996 году. Целью стандарта являлось создание унифицированного интерфейса для подключения устройств автоматизации к SCADA-системам. В то время в отрасли было относительно немного открытых промышленных протоколов, из-за чего большинство компаний разрабатывали собственные решения. Это, в свою очередь, затрудняло процесс интеграции приборов в SCADA-системы: разработчикам SCADA приходилось либо создавать и поддерживать множество коммуникационных драйверов, либо производители приборов были вынуждены разрабатывать драйвер для каждой SCADA, к которой предполагалось подключать их устройства.
Стандарт OPC основан на технологии OLE (Object Linking and Embedding), разработанной компанией Microsoft для ОС Windows. Аббревиатура «OPC» означает OLE for Process Control (OLE для управления процессами). В стандарте описывается интерфейс обмена данными между OPC-клиентом (SCADA-системой) и OPC-сервером. OPC-сервер – это специализированное программное обеспечение, установленное на ПК, которое опрашивает подключенные устройства по промышленным протоколам и предоставляет SCADA-системе доступ к данным этих устройств. Таким образом, производителям оборудования достаточно однократно разработать свой OPC-сервер, чтобы обеспечить возможность подключения оборудования к любой SCADA-системе, поддерживающей технологию OPC. Сейчас эту технологию поддерживает практически каждая SCADA-система.
Компания ОВЕН разработала Owen OPC Server, который доступен для загрузки на сайте owen.ru в разделе Программное обеспечение, устройства связи/OPC-серверы. OPC-сервер не имеет ограничений по числу опрашиваемых параметров и не требует лицензирования. Сервер поддерживает протоколы Modbus RTU/ASCII/TCP, протокол ОВЕН, также имеется возможность обмена данными с приборами, подключенными к облачному сервису OwenCloud (рис. 1). Сервер содержит шаблоны опроса для большинства устройств ОВЕН (кроме свободно программируемых) и позволяет импортировать карты регистров из программируемых реле с помощью плагина среды OwenLogic OPC-сервер экспорт.
Контроллеры ОВЕН, программируемые в среде CODESYS, могут подключаться к SCADA-системам через CODESYS OPC Server, который входит в дистрибутив CODESYS. Процесс настройки обмена предельно прост – пользователь добавляет в проект компонент Символьная конфигурация и помечает галочками переменные, которые должны быть доступны в SCADA.
Стандарт OPC оказал существенное влияние на рынок промышленной автоматизации. Но с развитием технологий стали проявляться некоторые его недостатки.
Современная версия стандарта – OPC UA
Недостатки классической технологии OPC (исходной редакции OPC DA) привели к необходимости разработки нового стандарта. Он получил название OPC UA (OPC Unified Architecture). Первая версия нового стандарта была представлена в 2006 году, и с тех пор он постоянно развивается и дополняется.
Ключевыми особенностями нового стандарта являются:
Стандарт OPC UA продолжает развиваться. Основными векторами развития стандарта в последние годы являются:
Поддержка OPC UA в устройствах ОВЕН
Контроллеры ОВЕН, программируемые в среде CODESYS V3.5 (ПЛК210, ПЛК200, СПК1хх), включают в себя OPC UA сервер. Поддерживается доступ к оперативным данным (DA) и защита подключения к серверу с использованием логинов/паролей и сертификатов. Работа с OPC UA сервером происходит через символьную конфигурацию (как и в случае с CODESYS OPC Server V3) – пользователю достаточно определить переменные проекта, которые будут доступны OPC UA-клиенту.
В будущих версиях CODESYS планируется поддержка доступа к историческим данным (профиль HA), передача тревог и событий (профиль AE), вызов программных модулей (POU) контроллера со стороны клиента. В перспективе ожидается разработка OPC UA-клиента и поддержка архитектуры «Издатель/Подписчик» (PubSub).
Контроллеры ПЛК110-MS4 [М02], программируемые в SoftLogic пакете MasterSCADA 4D, могут использоваться в роли OPC UA-сервера. Кроме того, компания ИнСАТ (разработчик MasterSCADA 4D) поддерживает технологию OPC UA и в других своих продуктах – таких, как SCADA-система MasterSCADA 3.x и OPC-сервер Multi-Protocol MasterOPC Server. В этом ПО поддерживается функционал как OPC UA-клиента, так и OPC UA-сервера. Компания ОВЕН является официальным дистрибьютором программных продуктов компании ИнСАТ.
Облачный сервис OwenCloud поддерживает обмен по OPC UA, выполняя роль сервера. Это позволяет считывать и записывать данные в приборы, подключенные к сервису, через SCADA-системы, панели оператора и другие устройства, имеющие встроенный OPC UA-клиент.
© Автоматизация и Производство, 2021. Все права защищены. Любое использование материалов допускается только с согласия редакции. За достоверность сведений, представленных в журнале, ответственность несут авторы статей.
Издание зарегистрировано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций. Свидетельство о регистрации средств массовой информации ПИ № ФС77-68720.
Просто о стандартах OPC DA и OPC UA
OPC (аббр. от англ. Open Platform Communications, ранее англ. OLE for Process Control) – это набор программных технологий, которые предоставляют единый интерфейс для управления различными устройствами и обмена данными. Спецификации OPC были разработаны международной некоммерческой организацией OPC Foundation, которую создали в 1994 году ведущие производители средств промышленной автоматизации. Целью создания OPC было предоставить инженерам универсальный интерфейс для управления различными устройствами.
Реализовав поддержку OPC-клиента, разработчики SCADA систем избавились от необходимости поддерживать сотни драйверов для различных устройств, а производители оборудования, добавив OPC-сервер, обрели уверенность в том, что их продукт может применяться пользователями любых SCADA систем.
Технология OPC включает несколько стандартов, которые описывают набор функций определенного назначения. Текущие стандарты:
OPC DA (Data Access)— наиболее распространённый стандарт. Описывает набор функций обмена данными в реальном времени с ПЛК, РСУ, ЧМИ, ЧПУ и другими устройствами.
OPC HDA (Historical Data Access)предоставляет доступ к уже сохраненным данным и истории.
OPC AE (Alarms & Events)— предоставляет функции уведомления по требованию о различных событиях: аварийные ситуации, действия оператора, информационные сообщения и другие.
OPC Batch— предоставляет функции шагового и рецептурного управления технологическим процессом.
OPC DX (Data eXchange)— предоставляет функции организации обмена данными между OPC-серверами через сеть Ethernet. Основное назначение — создание шлюзов для обмена данными между устройствами и программами разных производителей.
OPC Security— определяет функции организации прав доступа клиентов к данным OPC-сервера.
OPC XML-DA (XML-Data Access)— предоставляет гибкий, управляемый правилами формат обмена данными через XML, SOAP и HTTP.
OPC Complex Data— дополнительные спецификации к OPC DA и XML-DA, которые позволяют серверам работать со сложными типами данных, такими как бинарные структуры и XML-документы.
OPC Commands— набор программных интерфейсов, который позволяет ОРС клиентам и серверам идентифицировать, посылать и контролировать команды, исполняемые в контроллере или модуле ввода-вывода.
OPC UA (Unified Architecture)— последняя по времени выпуска спецификация, которая основана не на технологии Microsoft COM, что предоставляет кроссплатформенную совместимость.
Самое широкое распространение получил стандарт OPC DA, но у него есть существенный недостаток. Во времена его разработки он был построен на современных Windows-технологиях: OLE, ActiveX, COM/DCOM, но с тех пор в отрасли прошли изменения и большое распространение получили другие ОС и технологии. Поэтому технологию OPC сделали платформонезависимой и разработали стандарт OPC UA (Unified Architecture) на открытых кроссплатформенных технологиях.
Применение OPC
Обычно технологию OPC применяют для обмена данными между контроллерами и SCADA системой, но также возможна организация сложных систем на разных уровнях АСУ ТП.
OPC состоит из двух частей: OPC клиента и OPC сервера. ПО OPC сервера через драйверы устройств по полевым шинам опрашивает различные устройства. ПО OPC клиента обычно встроено в SCADA систему и предназначено для получения данных с OPC сервера.
На предприятии можно выделить несколько уровней АСУ:
Нижний уровень — полевые шины (fieldbus) и отдельные контроллеры;
Средний уровень — цеховые сети;
Уровень АСУ ТП — уровень работы систем типа SCADA;
Уровень АСУП — уровень приложений управления ресурсами предприятия, ERP, MES.
Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC-клиенту на более высоком уровне или соседнему устройству.
Работа OPC DA сервера
OPC DA сервер обеспечивает обмен данными (запись и чтение) между клиентской программой (обычно SCADA системой) и конечными устройствами. Данные в OPC представляют собой переменную Тег с некоторыми свойствами. Переменная может быть любого типа, допустимого в OLE: различные целые и вещественные типы, логический тип, строковый, дата, массивом и т. д. Свойства могут быть обязательными, рекомендуемыми и пользовательскими.
Текущее значение переменной, ее тип и права доступа (чтение и/или запись).
Качество переменнойзависит от выхода измеряемой величины за границы динамического диапазона, отсутствии данных, ошибки связи и других параметров. Обычно принимает значения: хорошее/плохое/неопределенное и дополнительная информация.
Метка временисообщает о времени, когда переменная получила данное значение.
Частота опроса переменной OPC-серверомзадает время обновления значения переменной.
Описание переменной, которое содержит информацию для пользователя о том, что представляет собой эта переменная.
Дополнительно могут быть указаны необязательные свойства: диапазон изменения значения, единица измерения и другие пользовательские параметры.
Для чтения данных из ОРС сервера можно использовать различные режимы:
Синхронный режим: клиент посылает запрос серверу и ждет от него ответ.
Асинхронный режим: клиент отправляет запрос и сразу же переходит к выполнению других задач. Сервер после обработки запроса посылает клиенту уведомление и тот забирает предоставленные данные.
Режим подписки: сервер отсылает клиенту только те теги, которые изменились. Для того, чтобы шум данных не был принят за их изменение, вводится понятие «мертвой зоны», которая слегка превышает максимально возможный размах помехи.
Режим обновления данных: клиент вызывает одновременное чтение всех активных тегов. Активными называются все теги, кроме обозначенных как «пассивные». Такое деление тегов уменьшает загрузку процессора обновлением данных, принимаемых из физического устройства.
Клиент получает данные от ОРС сервера либо из буфера, либо сразу из конечного устройства. Чтение из буфера выполняется быстрее, но данные в нем могут устареть к моменту чтения. ОРС сервер периодически обновляет данные, запрашивая информацию у конечных устройств.
Запись данных в конечное устройство осуществляется в синхронном или асинхронном режимах без промежуточной буферизации. В синхронном режиме клиент осуществляет запись данных и ждет пока не получит подтверждение о выполнении команды от конечного устройства. Этот процесс может занимать много времени, в течении которого клиент находится в ожидании. Асинхронный режим позволяет клиенту отправить запрос серверу и заниматься другими задачами. После окончания записи сервер отправит клиенту уведомление.
Примеры OPC DA сервера
Для примера возьмём SCADA систему Trace Mode 6, в которой реализована функция OPC DA сервера. Trace Mode 6 можно поставить на ПК, либо сразу на контроллер.
SCADA Trace Mode 6 может опрашивать различные модули ввода-вывода и управлять контроллерами по стандартным промышленным протоколам типа: Modbus, МЭК 60870-5-104, HART и другим. Но промышленные протоколы не предназначены для обмена данными между SCADA и ERP, MES системами. Тут придет на помощь стандарт OPC DA, который позволит собрать различные данные с исполнительных модулей SCADA. OPC DA сервер для получения данных с Trace Mode доступен как отдельный модуль, так и в составе модулей OPC МРВ+ или OPC ДокМРВ+.
Также Trace Mode 6 может выступать в качестве OPC клиента и получать данные с OPC DA серверов различных производителей. Например, есть видео урок подключения Trace Mode 6 к NAPOPC DA Server – это OPC DA сервер от компании ICP DAS.
NAPOPC DA Server – это бесплатный OPC DA сервер для опроса модулей ввода-вывода ICP DAS. Его можно установить на ПК, либо прямо контроллеры ICP DAS с ОС:
Windows 10 — XP-9781-IoT
Windows WES — XP-9781-WES7
Windows CE 6.0 — XP-8731-CE6
Windows CE 5.0 — WP-8841-EN
NAPOPC DA Server позволяет опрашивать модули: I-7000, M-7000, ET-7000, I-8K, I-87K и корзины RU-87Pn.
Стандарт OPC UA
OPC UA (Unified Architecture) – это современный стандарт, описывающий передачу данных в промышленных сетях. Он обеспечивает защищенную и надежную коммуникацию между устройствами, являясь при этом аппаратно- и платформо-независимым, что позволяет обеспечить обмен данными между устройствами с разными операционными системами.
Сильными сторонами OPC UA является объектно-ориентированная информационная модель, которая позволяет «просматривать» данные (в стиле web-браузера), и сервис ориентированная архитектура (SOA). Если раньше приходилось использовать несколько OPC серверов: OPC DA для данных в реальном времени, OPC HDA для истории и OPC AE для событий, то теперь все это и многое другое доступно в одном стандарте OPC UA. Вместо дерева тегов, теперь вводится понятие узлов или объектов. Каждый узел включает в себя переменные, методы и другие структуры данных реального объекта.
Обмен данными теперь происходит через бинарные структуры и XML документы. В дополнение к модели клиент/сервер становится доступна модель издатель/подписчик. Также стандарт определяет механизм для поддержки резервирования (если один клиент станет не доступным, то его заменит другой) и быстрого восстановления связи в случае сбоя. Передача данных происходит через транспортный слой TCP, HTTP/SOAP или HTTPS. Вместо механизмов контроля прав доступа Windows, в OPC UA реализована поддержка цифровых сертификатов и возможность шифрования передаваемых данных.
Реализована обратная совместимость с OPC DA через специальную оболочку (wrapper) и proxy-модуль. Для передачи данных через маршрутизаторы и межсетевые экраны OPC DA требовал использовать промежуточное ПО, OPC UA же работает без прослойки. Спецификация OPC UA включает в себя несколько частей, которые описывают логику работы серверов и клиентов. Детальная версия спецификации доступна в стандарте IEC 62541.
Пример OPC UA сервера
Примером OPC UA сервера может стать набор ПО MX-AOPC UA Suite от компании MOXA. В MX-AOPC UA Suite входит 3 программы:
Server – для получения данных с Modbus устройств
Viewer – для просмотра тегов и состояния сервера (Viewer встроен в Server)
Logger – для ведения истории изменения данных, а также интеграции с базами данных и Облачными решениями
В первую очередь MX-AOPC UA Server ориентирован на модули ввода-вывода MOXA, т.к. там реализована функция Active Tag, но также поддерживается подключение сторонних устройств по протоколам Modbus RTU и Modbus TCP. ФункцияActive Tagпозволяет обновлять состояние каналов сразу после их изменения, не дожидаясь команды со стороны сервера.
MX-AOPC UA Logger позволяет отправлять данные в Облако Microsoft Azure и базы данных Microsoft SQL Server, MySQL, Oracle, Microsoft Office 2003 Access или Excel через ODBC.
В MX-AOPC UA реализована защита данных через шифрование ключом Basic128Rsa15 и подтверждение сертификатом X509.
Минусы применения OPC
Конечно у любой хорошей технологии есть свои минусы. Например, разработчики SCADA Trace Mode 6 из компании АдАстра Рисерч Груп, выделяют типовые ошибки в проектировании АСУ ТП.
К ошибкам можно отнести:
Неоправданное применение WEB-технологий в АСУ ТП
Применение протоколов реального времени в телемеханических задачах
Например, вы узнали о хорошей технологии OPC и стремитесь заменить все протоколы нижнего уровня только на OPC. Но конвертация промышленных протоколов Modbus, Profibus и любых других на ПК будет занимать дополнительное время и тратить ресурсы компьютера. Тесты показали, что SCADA система работает в 2 раза быстрее напрямую с промышленными протоколами, чем через промежуточный OPC сервер. Конечно, есть системы где процесс не нужно контролировать в реальном времени, но это нужно учитывать при проектировании АСУ ТП.
К недостаткам также можно отнести сложность настройки OPC сервера и необходимость ручной привязки тысячи тегов. Кроме того, OPC-сервер не всегда поставляется бесплатно и чаще всего на каждый ПК придется покупать отдельную лицензию.
Если система отправляет данные через Интернет в Облако, то наличие слабого шифрования может стать потенциальной уязвимостью и целью для атак хакеров, что ставит под сомнение безопасность всей АСУ ТП.
OPC UA для работы в реальном времени
OPC UA over TSN— для поддержки работы в реальном времени технология OPC UA (вместо модели клиент/сервер) может использовать модель издатель/подписчик совместно с технологией TSN (Time-Sensitive Networking).
Модель клиент/сервер хорошо работает в случае подключения точка-точка, но если устройств становится много, то появляются задержки в обновлении данных. Модель издатель/подписчик обеспечивает связь от одного ко многим и от многих ко многим. Сервер отправляет свои данные в сеть (публикация) и каждый клиент может получить эти данные (подписка).
Технология Ethernet с TSN дополняет существующие средства Ethernet в том, что касается обеспечения качества обслуживания трафика (QoS), включая выделение полосы пропускания, синхронизацию, гарантию низких значений задержки и обеспечения резервирования. Данные, которые передают различные устройства по Ethernet сети, представляют собой потоки. Ethernet коммутаторы с TSN позволяют выделить для каждого потока свою полосу пропускания и обеспечить его передачу в реальном времени. Несколько потоков можно объединить (это называется сетевой конвергенцией) и организовать их передачу по одной сети в режиме реального времени. Получается без технологии TSN по одной Ethernet сети можно передавать только один протокол реального времени, а с TSN несколько.
Объединение технологий OPC UA over TSN позволяет организовать коммуникацию между оборудованием от разных производителей и гарантировать непрерывное получение данных в режиме реального времени.
OPC Foundation планирует использовать OPC UA не только для передачи данных между контроллерами и SCADA системой, но и на полевом уровне от датчиков и IoT устройств к контроллерам, а также от локальных систем в Облако. Для этого планируют разбить стандарт OPC UA на 4 части в зависимости от производительности устройства и необходимых ему возможностей.
Nano Embedded Device Server: подходит для самых маленьких датчиков;
Micro Embedded Device Server: подходит для недорогих ПЛК;
Embedded UA Server: подходит для более мощных ПЛК и пограничных шлюзов;
Standard UA Server: полноценная реализация, поддерживающая все функции.
ScadaPy — использование OPC UA
В предыдущих нескольких статьях, мною были описаны возможности применения протокола modbus для создания собственной Scada системы на базе python. В этот раз хочется поделиться опытом построения системы опроса подчиненных устройств с использованием ОРС технологии.
Недостатки OPC серверов в том, что их можно использовать только в операционных системах семейства Microsoft Windows (как правило они платные), а об устройствах использующих ОС Linux можно было забыть.
Но со временем была создана спецификация OPC Unified Architecture (англ. Унифицированная архитектура OPC), что дало возможность использовать данную технологию передачи данных на иных операционных системах отличных от Windows. Это касается и встраиваемых систем, где может быть запущен полноценный Linux.
Подробнее можно прочитать здесь.
Например, на одноплатном компьютере Raspberry Pi можно запустить одновременно несколько различных OPC UA серверов для опроса терминальных устройств, счетчиков, датчиков и т.д., при этом система будет работать вполне стабильно.
Установка библиотек
Для работы с OPC UA и modbus серверами используются Xubuntu 17.04 Desktop и Windows 8.1. В Xubuntu 17.04 уже установлены Python 2.7 и Python 3.5 по умолчанию. Выбираем Python 3.5.
Если после установки операционной системы на компьютер не были добавлены необходимые пакеты, то нужно выполнить:
Решаем проблему зависимостей:
После поставим еще необходимые библиотеки:
Для windows можно установить через pip3.exe, библиотека и примеры находятся здесь
Для запуска сервера, библиотеку нужно импортировать:
Теперь создаем OPC UA сервер.
Вот и весь код на python для запуска OPC UA. Как оказалось ничего сложного, и если теперь подключиться к запущенному серверу с помощью UA Expert, то можно увидеть иерархический список наших объектов и переменных со значениями.
Для модификации значений переменных используется функция set_value типа:
Конечно это очень примитивный пример, но в библиотеке OPC UA заложено намного больше возможностей, о которых можно прочитать здесь.
Единственное в чем не удалось разобраться, так это, как установить логин и пароль на сервер, вроде как-то посредством politics, думаю позже решу эту проблему.
Конфигуратор серверов
В продолжение к вышесказанному, возникла задача по оперативному конфигурированию каждого вновь создаваемого сервера.
Для данной цели был написан «Конфигуратор серверов» на библиотеке PyQt5.
— создается база данных на sqlite3
— формируются таблицы для slave и master частей сервера.
— таблицы заполняются необходимыми параметрами.
— формируется скрипт запуска.
Основная идея – серверы должны одинаково работать как в Windows, так и в Linux.
Скачать можно здесь
Для Windows будет создан файл типа start_XX.bat, для Linux файл типа start_XX.sh, где ХХ порядковый номер сервера в таблице servers.
Содержимое файла start_XX.bat:
Содержимое файла start_XX.sh для Linux:
В параметрах запуска для Linux используется xfce4-terminal, т.к. работаю в Xubuntu 17.04,
но можно указать и другой тип запуска, вроде gnome-terminal.
В примерах довольно понятно описаны параметры заполнения таблиц.
Примечательно, что на raspberry Pi запускалось одновременно 4 сервера — mobus_ping, opcua_http, opcua_mercury230 на /dev/ttyUSB0 и modbus_dcon на /dev/ttyUSB1, при этом он работал довольно стабильно и без сбоев.
Управление на данный момент реализовано частично и только в master_dcon, поэтому используется только телесигнализация и телеизмерения. В дальнейшем думаю добавить и телеуправление.