Подсистема SMS-оповещений (GMS)

Когда слышишь ?Подсистема SMS-оповещений (GMS)?, многие сразу думают о простом модуле рассылки. На деле же — это нервная система для диспетчера, особенно в таких нишах, как мониторинг высоковольтной изоляции. В ООО Нанкин Чуаньцзисин Автоматизация и Технологии мы через это прошли: изначально воспринимали её как дополнение, а потом осознали, что без глубокой интеграции в логику GMS это просто трата денег на сим-карты.

Ошибки начального этапа и ?проблема ложных срабатываний?

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

Пришлось пересматривать архитектуру. Мы поняли, что подсистема должна не просто брать событие из базы, а анализировать его контекст: длительность отклонения, приоритет, предыдущее состояние объекта. Это потребовало тесной интеграции ядра GMS с модулем оповещений. Не просто API-вызов, а общая логика обработки данных.

Кстати, о данных. Важный нюанс — формат сообщения. Раньше мы гнали в смс все телеметрические параметры, получая нечитаемую простыню. Сейчас формат строгий: ?Объект, Код аварии, Значение, Порог, Время?. Диспетчер за 5 секунд должен понять суть. Этому научились после пары дежурств с заказчиком на их щите.

Интеграция с продуктом ООО Нанкин Чуаньцзисин: где возникает сложность

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

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

Ещё один практический момент — управление получателями. На объектах часто меняется график дежурств. Мы сделали веб-интерфейс, где ответственный инженер может сам, без программистов, менять список телефонов для разных типов событий. Это снизило нагрузку на поддержку и уменьшило количество ошибок ?отправили не тому?.

Аппаратная часть и надёжность: про шлюзы и резервирование

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

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

Выбор оператора связи — тоже неочевидная задача. На удалённых подстанциях сигнал может быть неустойчивым. Приходится заранее тестировать, а иногда и использовать специализированные операторов для М2М-связи, у которых лучше покрытие в промышленных зонах.

Логирование и отчётность: чтобы потом не было ?мы не получали?

Отправленное смс должно иметь железобетонное подтверждение. Наша подсистема логирует не только факт отправки в свою БД, но и, по возможности, статус-доставки от оператора. Это критически важно для разбора полётов после инцидента.

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

Также мы добавили периодические тестовые оповещения (раз в сутки) и обязательное смс-подтверждение от диспетчера на команду ?авария квитирована?. Это замкнуло цикл и повысило дисциплину реагирования.

Эволюция и будущее: куда движется оповещение

Сегодня SMS-оповещения в GMS — это уже не изолированный сервис. Мы постепенно интегрируем его с мессенджерами (Telegram API для технического персонала), но смс остаётся каналом номер один для критических алертов. Причина — максимальная гарантия доставки и независимость от интернета на стороне получателя.

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

В итоге, для компании ООО Нанкин Чуаньцзисин Автоматизация и Технологии такая подсистема стала не ?фичей?, а страховочным тросом для клиентов. Когда ты мониторишь состояние дорогостоящего высоковольтного оборудования, цена пропущенного оповещения — это уже не просто штраф по SLA, а риск серьёзных последствий. Поэтому и подход к ней должен быть соответствующий — инженерный, скептический и с постоянной оглядкой на практику.