Какой протокол чаще всего используется в системах диспетчеризации коммуникационного оборудования

Обновлено: 09.05.2024

Система диспетчеризации представлена комплексом аппаратных и программных средств для удаленного мониторинга и управления инженерными системами. Контроль и управление может осуществляться как на одном, так и на нескольких технологических объектах. Подбор оборудования систем диспетчеризации, например, шкафа серии ACU-DIS, позволяет существенно экономить средства, повышая эффективность рабочих процессов.

Для чего нужен комплекс оборудования диспетчеризации

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

Средства диспетчеризации дают следующие преимущества:

Автоматизация процессов	Автоматизированное реагирование снижает затраты на энергоносители и позволяет существенно сократить количество обслуживающего персонала
Оперативность реагирования	Снижается время на организацию взаимодействия, как в штатном режиме, так и при срочном ремонте или аварийной ситуации
Мониторинг технологических процессов	Слежение за текущими технологическими процессами упрощает документирование и контроль состояния инженерных систем
Контроль сервисного обслуживания	В режиме реального времени проводится диагностика параметров работы оборудования. В случае выявления отклонений, формируется раннее оповещение о необходимости провести ремонтные работы. В результате оборудование работает без критических сбоев, и продлевается его ресурс
Анализ технологического состояния оборудования	Благодаря регулярному анализу экономятся энергоресурсы, снижаются расходы на эксплуатацию, предотвращаются аварийные ситуации
Экономия энергоресурсов	Происходит оптимизация режимов работы оборудования для сокращения затрат на энергоресурсы

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

Какие элементы и устройства диспетчеризации устанавливают

Элементы и устройства системы диспетчеризации включают:

Верхний уровень: серверы, автоматизированные рабочие места (АРМ) операторов и инженеров, видеостены;
Средний уровень: щиты автоматизации, коммуникационные шкафы;
Нижний уровень: контрольно-измерительные приборы и исполнительные механизмы.

Одними из важных элементов являются контроллеры системы диспетчеризации, которые обрабатывают и передают данные о текущем состоянии оборудования на пульт оператора.

Где применяется оборудование для диспетчеризации

Оборудование системы автоматизации и диспетчеризации технологических процессов устанавливают на объектах как гражданского, так и промышленного назначения. Система диспетчеризации может отличаться количеством элементов, сложностью организации и характеризуется количеством аналоговых и дискретных входных и выходных сигналов, а также количеством сетевых сигналов.

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

Области применения системы диспетчеризации:

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

Оборудование можно внедрить на любом этапе, но желательно предусмотреть его установку при разработке проектной документации.

Компания "Технологика" предлагает систему комплекса диспетчеризации с возможностью проектирования и внедрения на предприятии. Оставьте запрос на сайте или позвоните по телефону менеджеру для подробной консультации. У нас можно заказать полный комплекс оборудования и работ по внедрению комплексной автоматизации и диспетчеризации зданий, а также автоматизации и диспетчеризации технологических процессов для промышленных предприятий.

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

Событийные протоколы в основном применяются на объектах электроэнергетики, а также системах дистанционного управления различных систем шлюзов и водоразделов. Применяются везде, где необходима удаленная диспетчеризация и управление сильно удаленных друг от друга объектов.

История развития и внедрения событийных протоколов в автоматизации энергообъектов

Примером одной из первых успешных попыток стандартизации информационного обмена для промышленных контроллеров является протокол ModBus, разработанный компанией Modicon в 1979 г. В настоящее время протокол существует в трёх вариантах: ModBus ASCII, ModBus RTU и ModBus TCP; его развитием занимается некоммерческая организация ModBus-IDA. Несмотря на то, что ModBus относится к протоколам прикладного уровня сетевой модели OSI и регламентирует функции чтения и записи регистров, соответствие регистров типам измерений и измерительным каналам не регламентировано. На практике это приводит к несовместимости протоколов устройств разных типов даже одного производителя и необходимости поддержки большого количества протоколов и их модификаций встроенным программным обеспечением УСПД (при двухуровневой модели опроса - ПО сервера сбора) с ограниченной возможностью повторного использования программного кода. Учитывая избирательное следование стандартам производителями (использование нерегламентированных алгоритмов подсчёта контрольной суммы, изменение порядка следования байтов и т.п.), ситуация усугубляется ещё больше. На сегодняшний день факт того, что ModBus не способен решить проблему протокольной разобщённости измерительного и контрольного оборудования для энергосистем, очевиден. Спецификация DLMS/COSEM (Device Language Message Specification), разработанная Ассоциацией пользователей DLMS (DLMS User Association) и переросшая в семейство стандартов IEC 62056, призвана обеспечить, как указано на официальном сайте ассоциации, "интероперабельную среду для структурного моделирования и обмена данными с контроллером". Спецификация разделяет логическую модель и физическое представление специализированного оборудования, а также определяет важнейшие концепции (регистр, профиль, расписание и т.п.) и операции над ними. Основным является стандарт IEC 62056-21, заменивший вторую редакцию IEC 61107.
Несмотря на более детальную по сравнению с ModBus проработку модели представления устройства и его функционирования, проблема полноты и '"чистоты" реализации стандарта, к сожалению, сохранилась. На практике опрос устройства с заявленной поддержкой DLMS одного производителя программой опроса другого производителя либо ограничен основными параметрами, либо попросту невозможен. Следует отметить, что спецификация DLMS, в отличие от протокола ModBus, оказалась крайне непопулярной среди отечественных производителей приборов учёта, в первую очередь, из-за большей сложности протокола, а также дополнительных накладных расходов на установку соединения и получение конфигурации устройства.
Полнота поддержки существующих стандартов производителями измерительного и контрольного оборудования недостаточна для преодоления внутрисистемной информационной разобщённости. Заявленная производителем поддержка того или иного стандартизированного протокола, как правило, не означает полную его поддержку и отсутствие привнесённых изменений. Образцом комплекса зарубежных стандартов является семейство стандартов IЕС 60870-5, созданных Международной электротехнической комиссией.
Различные реализации IЕС 60870-5-102 — обобщающего стандарта по передаче интегральных параметров в энергосистемах - представлены в устройствах ряда зарубежных производителей: Iskraemeco d.d. (Словения), Landis&Gyr AG (Швейцария), Circutor SA (Испания), EDMI Ltd (Сингапур) и др., но в большинстве случаев — только как дополнительные. В качестве основных протоколов передачи данных используются проприетарные протоколы или вариации DLMS. Стоит отметить, что IЕС 870-5-102 не получил широкого распространения ещё и по той причине, что некоторые производители приборов учета, в том числе отечественные, реализовали в своих устройствах модифицированные телемеханические протоколы (IEС 60870-5-101, IEС 60870-5-104), игнорируя данный стандарт.

Похожая ситуация наблюдается и среди производителей РЗА: при наличии действующего стандарта IEС 60870-5-103 зачастую реализуется ModBus-подобный протокол. Предпосылкой к этому, очевидно, стало отсутствие поддержки указанных протоколов большинством систем верхнего уровня. Телемеханические протоколы, описанные в стандартах IEС 60870-5-101 и IEС 60870-5-104, могут быть использованы при необходимости интеграции систем телемеханики и учёта электроэнергии. В связи с этим, они нашли широкое применение в системах диспетчеризации.

Технические спецификации протоколов автоматизации

В современных системах автоматизации, в результате постоянной модернизации производства, все чаще встречаются задачи построения распределенных промышленных сетей с использованием событийных протоколов передачи данных. Для организации промышленных сетей энергообъектов используется множество интерфейсов и протоколов передачи данных, например, IEC 60870-5-104, IEC 61850 (MMS, GOOSE, SV) и пр. Они необходимы для передачи данных между датчиками, контроллерами и исполнительными механизмами (ИМ), связи нижнего и верхнего уровней АСУ ТП.

Протоколы разрабатываются с учетом особенностей технологического процесса, обеспечивая надежное соединение и высокую точность передачи данных между различными устройствами. Наряду с надежностью работы в жестких условиях все более важными требованиями в системах АСУ ТП становятся функциональные возможности, гибкость в построении, простота интеграции и обслуживания, соответствие промышленным стандартам. Рассмотрим технические особенности некоторых из указанных выше протоколов.

Протокол IEC 60870-5-104

Стандарт IEC 60870-5-104 формализует инкапсуляцию блока ASDU из документа IEC 60870-5-101 в стандартные сети TCP/IP. Поддерживается как Ethernet, так и модемное соединение с использованием протокола РРР. Криптографическая безопасность данных формализована в стандарте IEC 62351. Стандартный порт TCP 2404.
Данный стандарт определяет использование открытого интерфейса TCP/IP для сети, содержащей, например, LAN (локальная вычислительная сеть) для устройства телемеханики, которая передает ASDU в соответствии с МЭК 60870-5-101. Маршрутизаторы, включающие маршрутизаторы для WAN (глобальная вычислительная сеть) различных типов (например, Х.25, Фрейм реле, ISDN и т.п.), могут соединяться через общий интерфейс ТСР/IР-LAN.

Пример обшей архитектуры применения IEC 60870-5-104

Интерфейс транспортного уровня (интерфейс между пользователем и TCP) — это ориентированный на поток интерфейс, в котором не определяются какие-либо старт-стопные механизмы для ASDU (IEC 60870-5-101). Чтобы определить начало и конец ASDU, каждый заголовок APCI включает следующие маркировочные элементы: стартовый символ, указание длины ASDU вместе с полем управления. Может быть передан либо полный APDU, либо (для целей управления) только поля APCI.

Структура пакета данных протокола IEС 60870-5-104

- APCI - Управляющая Информация Прикладного Уровня;
- ASDU - Блок Данных. Обслуживаемый Прикладным Уровнем (Блок данных Прикладного Уровня);
- APDU - Протокольный Блок Данных Прикладного Уровня.
- СТАРТ 68 Н определяет точку начала внутри потока данных.
Длина APDU определяет длину тела APDU, которое состоит из четырех байтов поля управления APCI плюс ASDU. Первый учитываемый байт - это первый байт поля управления, а последний учитываемый байт - это последний байт ASDU. Максимальная длина ASDU ограничена 249 байтами, т.к. максимальное значение длины поля APDU равно 253 байта (APDUmax=255 минус 1 байт начала и 1 байт длины), а длина поля управления - 4 байта.
Данный протокол передачи данных, в настоящий момент, де-факто является стандартным протоколом диспетчеризации для предприятий электроэнергетического сектора. Модель данных в данном стандарте развита более серьёзно, однако в нём не представлено никакое унифицированное описание энергообъекта.

Протокол DNP-3

Вариации для постоянных данных:

Вариации для событийных данных:

Флаги подразумевают под собой наличие специального байта со следующими информационными битами: источник данных on-line, источник данных был перезагружен, соединение с источником потеряно, запись значения форсирована, значение вне допустимых границ.

Заголовок фрейма:

Синхронизация - 2 байта синхронизации, позволяющие получателю идентифицировать начало фрэйма. Длина - количество байт в оставшейся части пакета без учета октетов CRC. Контроль соединения - байт для координирования приема передачи фрэйма. Адрес назначения - адрес устройства, которому назначается передача. Исходный адрес - адрес устройства, осуществляющего передачу. CRC - контрольная сумма для байта заголовка. Раздел данных DNP3 фрэйма содержит (помимо самих данных) по 2 байта CRC для каждых 16 байт передаваемой информации. Максимальное количество байт данных (не включая CRC) для одного фрэйма - 250.

Протокол IEC 61850 MMS

Например, сервером в данном случае может выступать устройство релейной защиты, а клиентом — SCADA-система. Сервисы считывания информационной модели позволяют клиенту считать с устройства полную информационную модель, то есть воссоздать дерево из логических устройств, логических узлов, элементов и атрибутов данных. При этом клиент получит полное семантическое описание данных и их структуру. Сервисы считывания значений переменных позволяют считать фактические значения атрибутов данных, например, методом периодического опроса. Сервис передачи отчётов позволяет настроить отправку определенных данных при выполнении определенных условий. Одним из вариантов такого условия может быть изменение того или иного рода, связанное с одним или несколькими элементами из набора данных. Для реализации описанных абстрактных моделей передачи данных в стандарте МЭК 61850 описано назначение абстрактных моделей на конкретный протокол. Для рассматриваемых сервисов таким протоколом является MMS, описанный стандартом ИСО/МЭК 9506.

Общая структура применения протокола MMS для реализации сервисов передачи данных в соответствии с МЭК 61850 представлена ниже.

Диаграмма передачи данных по протоколу MMS

Протокол IEC 61850 GOOSE

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

Отправка информации нескольким адресатам

При построении систем РЗА на основе протокола GOOSE изменяются процедуры их наладки и тестирования. Теперь этап наладки заключается в организации сети Ethernet энергообъекта. в которую будут включены все устройства РЗА. между которыми требуется осуществлять обмен данными. Для проверки того, что система настроена и включена в соответствии с требованиями проекта, становится возможным использование персонального компьютера со специальным предустановленным программным обеспечением (Wireshak, GOOSE Monitor и др.) или специального проверочного оборудования с поддержкой протокола GOOSE (PETOM 61850. Omicron CMC). Важно отметить, что все проверки можно производить не нарушая предварительно установленные соединения между вторичным оборудованием (устройствами РЗА, коммутаторами и др.), поскольку обмен данными производится по сети Ethernet. При обмене дискретными сигналами между устройствами РЗА традиционным способом (подачей напряжения на дискретный вход устройства-приемника при замыкании выходного контакта устройства, передающего данные), напротив, часто требуется разрывать соединения между вторичным оборудованием для включения в цепь испытательных установок с целью проверки правильности электрических соединений и передачи соответствующих дискретных сигналов. Таким образом, протокол GOOSE предусматривает целый комплекс мер, направленных на обеспечение необходимых характеристик по быстродействию и надёжности при передаче ответственных сигналов. Применение данного протокола в сочетании с правильным проектированием и параметрированием информационной сети и устройств РЗА позволяет в ряде случаев отказаться от использования медных цепей для передачи сигналов, обеспечивая при этом необходимый уровень надёжности и быстродействия.

Автор: Тимофей Бусыгин (Московский Энергетический Институт)

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

Иногда возникает путаница, когда систему диспетчеризации здания определяют как систему управления зданием BMS. Это связано с тем, что в диспетчеризации применятся контроллеры и программное обеспечение SCADA систем BMS. Однако, система диспетчеризации является интерфейсной частью системы интеллектуального здания, она всего лишь выводит информацию на пульт и позволяет оператору вручную управлять частью процессов, пусть и удаленно. Алгоритмы оптимального и экономичного взаимодействия между подсистемами здания должны быть разработаны проектом автоматизации и запрограммированы в контроллерах управления, только тогда оператор освобождается от принятия большинства рутинных решений.

Обычно, в функции системы диспетчеризации входит:

На пульт диспетчера выводится информационный поток от следующих систем:

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

Могут выводиться параметры температуры наружного воздуха, охлаждённой воды в/от системы вентиляции, охлажденного этиленгликоля, подогретой воды отопления; значения давления охлажденной воды или этиленгликоля систем вентиляции и кондиционирования; положения регулирующих клапанов; мощности на двигателях циркуляционных насосов или вентиляторов; ; данные о засорении фильтров; сигнализация об угрозе замораживания калориферов информации о состоянии лифтов, подкрепленные видеоданными; состояния автоматических выключателей в электрощитах и т.п.

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

Управление такой системой осуществляется в режиме 24/7 квалифицированным персоналом, прошедшим специализированные курсы обучения. Кроме того, для каждой системы в процессе проектирования, наладки и эксплуатации технологами разрабатываются протоколы действий при возможных нештатных ситуациях.

Возможности современных систем диспетчеризации

Современные системы диспетчеризации все чаще реализовываются на контроллерах и программном обеспечении систем BMS. Это обуславливает большое количество программных возможностей по настройке их функций. В общем случае, системы диспетчеризации должны обеспечивать:

Отличие системы диспетчеризации от системы автоматического управления и диспетчеризации здания (САУиД)

Основные отличия функций системы диспетчеризации инженерного оборудования и системы автоматического управления зданием видны на приведенных ниже схемах. Типовая схема диспетчеризации инженерных систем объекта

Типовая схема автоматизации и диспетчеризации инженерных систем объекта (синонимы: BMS, интеллектуальное здание)

Таким образом, подсистема диспетчеризации является только частью системы управления зданием BMS.

Оборудование и программное обеспечение систем диспетчеризации

Задача диспетчеризации – отображение информации и предоставление возможности управления, следовательно, основными элементами системы диспетчеризации является программное обеспечение оператора и преобразователи интерфейсов, часто устанавливаемые в щитах автоматизации инженерного оборудования.

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

Передача данных от локальной системы автоматизации к SCADA системе диспетчеризации может осуществляться напрямую или через интерфейс OPC (Open Platform Communication) сервера. При этом OPC сервер является переводчиком между языком, которое понимает установленное оборудование, и языком программного интерфейса диспетчера.

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

После того, как стандарт OPC был введён в действие, практически все SCADA-пакеты были перепроектированы как ОРС-клиенты, а каждый производитель аппаратного обеспечения стал снабжать свои контроллеры, модули ввода-вывода, интеллектуальные датчики и исполнительные устройства стандартным ОРС сервером. Благодаря появлению стандартизации интерфейса стало возможным подключение любого физического устройства к любой SCADA, если они оба соответствовали стандарту ОРС. Разработчики получили возможность проектировать только один драйвер для всех SCADA-пакетов, а пользователи – возможность выбора оборудования и программ без прежних ограничений на их совместимость.

IP оборудование

90% современных систем диспетчеризации имеют возможность обмена информацией по IP сетям. Преобразование данных в соответствующие протоколы происходит либо непосредственно в контроллерах, либо на серверах верхнего уровня (Schneider Electric Automation Server), либо через шлюзы, например, Xenta -911.

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

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

Разработка и проектирование систем диспетчеризации

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

Проект системы диспетчеризации обычно сдержит следующие листы:

Общие данные;
Структурную схему системы диспетчеризации;
Функциональные схемы диспетчеризации;
Принципиальные электрические схемы щитов диспетчеризации;
Принципиальные схемы интерфейсных линий связи контроллеров;
Схемы внешний соединений или таблицы соединений;
Монтажные схемы оборудования (при необходимости);
Кабельные журналы;
Планы расположения оборудования и проводок;
Спецификации оборудования, изделий и материалов.

В рамках проекта диспетчеризации разрабатывается так же и автоматизированное рабочее место диспетчера. В зависимости от масштаба системы оно может быть оснащено:

Щитом с нанесенной мнемосхемой (в настоящее время такие системы встречаются все реже и на производствах);

ПК с установленной SCADA программой;

ПК с доступом по веб-интерфейсу к контроллеру-серверу системы (пример: automation server Schneider Electric);

ПК с установленной SCADA системой с выходом на несколько мониторов и на мониторную стену.

Еще более сложной задачей является использование SMS и сотовой связи в целом для реализации обмена данными с промышленными объектами и устройствами. Рассмотрим подробнее этот вопрос, но для начала краткий список терминов и обоснование выбора.

Краткий словарик

Сотовый терминал (коммуникационный модуль): оборудование, аналогичное применяемому в мобильных телефонах, облегченное за счет отбрасывания неиспользуемых в данном случае частей, таких как микрофон, динамик, клавиатура. Чаще всего сотовый терминал имеет только интерфейс RS-232.

Защищенный терминал (модуль): терминал в специальном исполнении, защищенном от различных воздействий, таких как высокие (или, напротив, низкие) температуры, влажность, давление. Часто защищенные терминалы оснащены механизмом для обнаружения факта вскрытия корпуса (intrusion detection).

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

АСКУ: автоматизированная система коммерческого учета, диспетчерская система с контролирующими функциями, включающая возможности по расчету финансовых параметров (тарификация).

Почему сотовая связь?

Очень часто к промышленным объектам затруднена или невозможна прокладка какой-либо кабельной инфраструктуры. В качестве примера можно привести насосную станцию: единственными кабелями, ведущими к ней, являются высоковольтные линии электропередачи. Прокладка кабеля к отдаленным станциям, естественно, обойдется в большую сумму, а задействован такой канал будет лишь на доли процентов.

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

Почему SMS?

Как с этим связан компьютер?

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

Реализация

Сама концепция диспетчерской системы предполагает наличие какого-либо центрального пункта сбора данных и некоторого количества объектов, контролируемых системой. Связующим звеном между объектами и диспетчерским пунктом является линия сотовой связи. Рассмотрим подробнее оборудование, используемое на данный момент в таких системах.

Промышленный объект

Мобильное оборудование, mobile equipment (ME)

В настоящее время Siemens готовит к массовому выпуску коммуникационные модули TC-35 с несколько расширенной по сравнению с М20 функциональностью; на данный момент ТС-35 существует только в виде Test Sample. С завидным постоянством Siemens оснащает модуль только интерфейсом RS-232, игнорируя RS-485, что в большинстве случаев приводит к необходимости использования отдельных контроллеров-преобразователей. Свято место пусто не бывает — компания Siemens уже нашла партнера (ТЭСС-Электроникс, что удивительно, в России!), взявшегося за создание специальной установочной платы со встроенным интеллектуальным контроллером. Идея создания крошечного коммуникационного модуля со встроенным многофункциональным SCADA-совместимым контроллером и интерфейсом RS-485 не нова, но вот до реализации дошло только сейчас. Перспективы применения подобных устройств очень широки, а установка и их настройка чрезвычайно просты (включил в сеть, подсоединил кабель к RS-485 или RS-232 — вуаля!).

На CeBIT 2001 компанией Siemens также были представлены модули МС-35, аналог ТС-35, но с поддержкой GPRS.

Компания Ericsson также предлагает целый ряд коммуникационных модулей. Среди них GSM-модули: Ericsson GM22, модель без поддержки передачи данных (только голос, SMS и факс) и его старший брат GM25 с поддержкой передачи данных (на скорости 9600 бит/с). Для сетей стандартов AMPS-800 и TDMA 850 компания Ericsson предлагает модуль DM10 (с поддержкой голоса, факса, данных, SMS), а также версию DM20, работающую в сетях AMPS-800 и TDMA 850/1900. О поставках модулей от Ericsson в Россию у меня сведений нет.

Существуют также модули линейки WISMO от компании Wavecom, но официально их поставки в Россию не производятся. Модельный ряд WISMO построен на базе собственных чипов компании, поставляющих как готовые сотовые модули, так и собственно микросхемы. Характеристики выпускаемой продукции внушают уважение, декларируется поддержка всех функций Phase2+ и даже GPRS! Недостатки те же, что и в случае с Siemens: отсутствие прямой поддержки RS-485, встроенного SCADA-контроллера, высокая стоимость. И самый главный — отсутствие в России как собственно модулей, так и представительства компании.

Другое оборудование

Диспетчерский пункт

Мобильное оборудование

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

Гораздо больший интерес представляет программное обеспечение. Рассмотрение принципов построения АСКУ не является целью статьи, поэтому речь в дальнейшем пойдет только об организации взаимодействия МЕ и программного обеспечения диспетчерской системы.

Стандарты

Практически для всех выпускаемых и продающихся в настоящее время коммуникационных модулей декларируется поддержка V.25ter (AT-команды Hayes-совместимых модемов), а также расширенного набора команд с префиксами AT+C в соответствии со стандартами GSM 07.07 и GSM 07.05 (for SMS). Это значит, что работа с терминалом ничем не отличается от работы с обычным телефонным модемом. Команды AT+Cxxx расширяют функциональность терминала по сравнению с обычным модемом, предоставляя сервисы для редактировании записей в телефонной книге (phonebook), отправки/приема SMS и др. Многие производители расширяют набор команд собственными силами, например, терминалы Siemens поддерживают команды группы AT^Sxxx, среди которых встречаются весьма интересные (AT^MONI, AT+MONP, знаменитый net monitor).

Управлять терминалами, поддерживающими расширенный набор АТ+С команд, очень легко. Для этого можно даже пользоваться HyperTerminal'ом из комплекта Windows. Да и разработка ПО для полностью автоматизированной диспетчерской системы заметно упрощается.

Системы

Создаваемые диспетчерские системы можно логически разделить на архивирующие и реального времени. Последние обычно работают с постоянными соединениями или в крайнем случае через канал данных GSM, но, естественно, не через SMS. Первые же, напротив, не критичны к скорости передачи данных, а вот стоимость их обслуживания должна быть минимальной. В каждом классе существует большое количество решений со своими преимуществами и недостатками. Особенно тяжко дело обстоит с простотой использования и установки - часто без помощи и непосредственного участия разработчиков или спецконсультантов не обойтись. Да и развертывание диспетчерского пункта занимает довольно длительное время. Остается надеяться, что в дальнейшем развитие будет происходить именно в сторону упрощения установки, настройки и использования ПО.

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

Вывод

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

Никакого специального обслуживания подобное оборудование не требует.

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

Читайте также: