АСКУЭ для ОРЭ РК c АО "KEGOC": локальное решение или облачное — что выбрать

Вы приняли решение: выходите на оптовый рынок электроэнергии. АСКУЭ — обязательное условие. Теперь перед вами другой вопрос, и он важнее, чем кажется на первый взгляд.

Как будет построена система? Где будут храниться данные? Кто будет за это отвечать через три года?

На рынке Казахстана два подхода: локальное решение и облачное (консолидированное) арендное решение. У каждого — своя цена входа, свои скрытые издержки и своя операционная реальность.

Вариант 1. Локальное решение

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

Выглядит надёжно. На старте — дешевле арендного. Но дальше начинается то, о чём не предупреждают.

Кибербезопасность и каналы связи

KEGOC для передачи данных использует FTP. Это протокол 1971 года. Он не шифрует данные. Он не проверяет целостность передачи. В профессиональном сообществе по кибербезопасности FTP давно считается устаревшим и небезопасным.

Для работы локальной АСКУЭ нужны два независимых канала связи — это требование регулятора. Организация, обслуживание, резервирование — ваша зона ответственности.

Кто это будет обслуживать

Вот типичный разговор, который происходит через год после внедрения локального решения.

Главный энергетик приходит в IT-отдел: «Нужно обновить ПО АСКУЭ, проверить жёсткие диски, настроить резервирование каналов». IT-отдел отвечает: «Это не наша система. Это энергетики».

Энергетик возвращается к себе. Он знает счётчики. Он знает электросети. Он не знает как обновлять Windows Server, следить за S.M.A.R.T. жёстких дисков и диагностировать проблемы с VPN-туннелями.

Через шесть лет после внедрения локальная АСКУЭ требует:

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

Это OPEX, который не был заложен в бюджет при покупке. Плюс выезды специалистов. Плюс лицензии на обновления.

Ответственный по приказу

В АСКУЭ есть обязательный приказ о назначении ответственного лица. Как правило, это главный энергетик — он указывает свои контакты.

Это значит: когда случается отключение, сдвиг времени у счётчика или пропуск данных — звонят ему. Лично. В любое время. С просьбой объяснить, заполнить дыру или переотправить данные.

Человек, который всю жизнь занимался электросетями, теперь вынужден разбираться в форматах передачи данных, флагах интервального учёта и протоколах взаимодействия с ОРЭРК.

Это не его компетенция. И это не должно быть его проблемой.

Вариант 2. Облачное арендное решение

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

Это другая модель: вы платите абонентскую плату и получаете работающую систему — без собственного железа, без IT-команды для её обслуживания, без головной боли про жёсткие диски и обновления Windows.

Как это работает в Amivisor

Принципиальное техническое отличие от конкурентов — в архитектуре подключения.

В большинстве систем для связи с модемом счётчика нужен статический IP-адрес. Это дополнительные расходы на специальный тариф у оператора связи. И это ограничение: не каждый объект может получить статический IP без сложностей.

В Amivisor счётчик (модем) сам инициирует соединение с нашим сервером. Статический IP не нужен. Подходит обычная SIM-карта с динамическим IP от любого оператора. Это проще, дешевле и работает там, где другие решения требуют дополнительной инфраструктуры.

Кто закрывает дыры

Если счётчик завис, было отключение или данные за несколько часов не пришли — это наша задача, не ваша. Система автоматически заполняет пропуски расчётными значениями с корректными флагами. Отчёт уходит в ОРЭРК в срок.

Если нужно разобраться с инцидентом детально — наш специалист берёт это на себя. Главный энергетик занимается энергетикой, а не технической поддержкой программного комплекса.

Обновления и безопасность

Обновления ПО, обновления операционных систем, резервирование данных, мониторинг каналов связи — всё это происходит на нашей стороне. Предприятие об этом не знает и не должно знать.

История Серика: «Я выбрал не то, что дешевле. Я выбрал то, что работает»

Серик — главный энергетик предприятия. Принял решение выходить на ОРЭРК. Изучил два предложения: локальное решение от одного поставщика и облачное арендное от Amivisor.

Шаг 1. Кто и где

Серик 15 лет в профессии. Он хорошо понимает счётчики, силовые схемы, трансформаторы. IT-инфраструктура — не его область. Он честен с собой в этом.

Шаг 2. Инцидент

Первое коммерческое предложение — локальное решение. Сервер, ПО, внедрение. Цена входа казалась приемлемой.

Серик задал поставщику три вопроса: «Кто будет следить за жёсткими дисками? Кто будет звонить в KEGOC если дыра в данных? Что происходит когда выходит обновление Windows и оно ломает совместимость с вашим ПО?»

Ответы были размытыми. «Есть сервисный договор». «Выезд специалиста». «Раз в год обновления».

Серик понял: он покупает не систему. Он покупает проблему, которая начнёт проявляться через год.

Шаг 3. Боль

Серик представил себя через три года. Звонок в 23:00: «У вас дыра в данных за 18-е число, нужно срочно разобраться». Он открывает ноутбук. Смотрит на интерфейс системы, в котором не разбирается. Звонит в техподдержку. Ждёт.

Это не то чем должен заниматься главный энергетик.

Шаг 4. Изменение

Серик выбрал облачное арендное решение Amivisor. Подключение заняло несколько дней. Обычные SIM-карты — никакого статического IP.

Первый отчётный период закрылся без его участия в технической части. Данные пришли. Таблица сформировалась. Отчёт ушёл в ОРЭРК.

Серик занимался энергетикой — а не IT.

Шаг 5. Победа

Через четыре месяца в одну из ночей два счётчика не передали данные — технический сбой на стороне оператора связи. Серик узнал об этом из уведомления утром: «Пропуск данных устранён, таблица обновлена, отчёт корректен».

Он не делал ничего. Проблема была решена до того, как он пришёл на работу.

Шаг 6. Карьерный момент

На совещании технический директор спросил: «Серик, как у нас с АСКУЭ? Всё работает?»

— Да, — ответил Серик. — За полгода ни одного инцидента, который потребовал бы моего вмешательства в техническую часть. Система работает сама.

Технический директор: «Это хороший результат. Обычно с такими системами постоянно что-то надо делать руками».

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

Сравнение подходов

Про недобросовестное внедрение АСКУЭ

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

Наш специалист по желанию заказчика может участвовать в приёмке и внедрении АСКУЭ — чтобы убедиться, что всё сделано по нормативам, и предотвратить проблемы до того, как они возникнут. Либо не участвовать — если заказчик уверен в своих подрядчиках.

Выбор остаётся за вами. Мы просто говорим об этом прямо.

Алгоритм перехода

Шаг 1: Аудит существующего учёта

Какие счётчики установлены, поддерживают ли они профиль мощности, есть ли уже данные для прогнозирования.

Шаг 2: Выбор архитектуры

Локальное или облачное — зависит от ваших требований к IT-суверенитету, бюджета и того, кто реально будет обслуживать систему через 3 года.

Шаг 3: Подключение и накопление данных

Минимум 3 месяца реального почасового профиля — для корректного прогнозирования на ОРЭРК.

Шаг 4: Регистрация субъекта ОРЭ РК

С работающей АСКУЭ и накопленными данными — процедура регистрации понятна и предсказуема.

Архивный момент

Через пять лет работы на ОРЭ РК плановая проверка соответствия АСКУЭ нормативным требованиям. Проверяющие запросили архив данных за 18 месяцев — по каждой точке учёта, с флагами, с журналами инцидентов.

Серик выгрузил всё за 15 минут. Данные непрерывные — ни одного необъяснённого пропуска. Все инциденты задокументированы с датами и способом устранения.

Проверка прошла без замечаний. У соседнего предприятия с локальным решением — заняла три дня, потому что часть данных за прошлый год восстановить не смогли.