Михаил Шехтман. Система учета мечты

Михаил Шехтман. Система учета мечты

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

Михаил ШЕХТМАН, эксперт в сфере промышленной автоматизации, к.т.н.

 

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

 

Под «системой учета» понимается совокупность технических и программных средств,
включая датчики и приборы учета, устройства сбора и передачи данных,
серверное оборудование, АРМ пользователей, программное,
информационное, математическое и метрологическое обеспечение.

 

Прежде всего, разница в системах учета обусловлена их функционалом (коммерческий, технический либо комбинированный учет), что влияет и на метрологические требования. Кроме того, важна отраслевая специфика. Учет для ЖКХ, теплосетевых компаний, электросетевых или сбытовых, для водоснабжения, для источников генерации, в целом для предприятия или даже холдинга будет различен. Однако можно выделить основные тенденции, характерные для всех, и базовые функции, которыми должна обладать любая подобная система.

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

Рис. 1. Тренды в развитии систем учета

 

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

 

Общесистемные требования

Интервальный учет. Система должна подсчитывать не просто количество энергоресурсов (ЭР), а за определенный интервал времени (день, месяц, от даты до даты, от одного события до другого).

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

 

Система учета всех энергоресурсов в МКД и бюджетных учреждениях, установленная в одном из областных центров, обладала функционалом контроля качества ресурсов. За полгода оказалось, что для группы зданий температура горячей воды не достигала 60°С в течение большого интервала времени. Пересчет стоимости ГВС с учетом штрафных санкций составил порядка 20 млн рублей. Результатом стало мировое соглашение между потребителем и РСО (т.к. потребитель тоже имел долги. Кроме того, резко улучшилась технологическая дисциплина на стороне ресурсника. А УК приступили к восстановлению циркуляции ГВС в домах.

 

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

 

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

 

Дружественный интерфейс, удобный и понятный пользователям самого разного уровня.

Точность до секунды. Время с точки зрения метрологии такая же измеряемая переменная, как и количество ЭР. Все компоненты системы учета должны работать в единой системе времени – все таймеры всех устройств (от счетчиков до серверов) необходимо взаимно синхронизировать, а также с «главным таймером» системы, например, Сервером единого времени. Не рекомендовал бы применять счётчики, которые не позволяют осуществлять коррекцию их таймера «сверху», более того, целесообразно подумать о введении нормы, ограничивающей применение таковых.

Система должна быть масштабируемой от нескольких десятков счетчиков до миллионов.

 

Система учета в МКД с функционалом расчёта баланса по каждому подъезду позволила обнаружить, что в одном из подъездов дома небаланс потребления электроэнергии между суммой квартир и общим составлял около 20% (при этом в остальных 2-4%). Причина оказалась банальна – «безучетное» потребление, или попросту воровство коммерческим помещением на первом этаже. И это продолжалось много лет, пока не была установлена хорошая система учета. Ответственный сотрудник был мгновенно  уволен, жильцы стали платить меньше.

 

Всеядность. Система должна уметь работать с приборами учета любых производителей (с открытым протоколом).

Комплексный учет – учёт всех видов ЭР, что означает работу со счетчиками всех типов (теплоэнергия, ГВС, ХВС, электроэнергия, а для промышленности – газы и их смеси и любые жидкости).

Открытость. Здесь целый набор пожеланий. Легкая бесшовная интеграция:

  • с системами биллинга
  • с ГИС ЖКХ (для коммунального сектора), ГИС ТЭК (для генерации) и ГИС Энергоэффективность
  • с геоинформационными системами
  • с софтом уровней MES и ERP предприятия, в том числе с корпоративными СУБД и системами энергоменеджмента
  • в идеале – с программами расчета гидравлических и температурно-гидравлических режимов (актуально для теплосетей и водоканалов)

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

 

Система тотального учета всех энергоресурсов,
потребляемых крупным технологическим оборудованием и зданиями,
на нефтеперерабатывающем заводе. Модуль материально-энергетического баланса
практически сразу выявил небаланс по пару между двумя объектами.
При расстоянии между ними и длине трубы 700 м потери составляли около 20%,
и так продолжалось много лет. Во время останова трубу вскрыли и заизолировали.
Так довольно дорогая система учета окупила себя за один год.

 

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

Экономичность. Важна совокупная стоимость владения в расчете на одну точку учета, причем она должна определяться на горизонте срока жизни системы. Здесь заказчика могут подстерегать неожиданные сюрпризы, и выбор оптимальной системы может оказаться неожиданным по сравнению с оценкой по критерию начальной стоимости установки. Чтобы потребителю определить стоимость на протяжении жизненного цикла, надо учесть стоимость сопровождения, т.е. оценить степень «привязанности» к поставщику системы, трудоемкость наращивания информационной мощности, стоимость развития системы при добавлении функционала и др.

 

Система учета потребления в МКД обнаружила постоянное повышенное потребление ГВС
в одном из домов даже в ночные часы (порядка 2 куб. м в час).
В подвале сухо, в доме тоже. Комиссия пошла с обходом,
услышали шум в трубе на пятом этаже, в квартире обнаружили сорванный кран на ГВС
и от него шланг, опущенный в унитаз. Так утекали почти 50 кубометров в сутки, и не один день.
Так в доме обнаружилась причина «необъяснимо высокого значения ОДН».

 

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

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

Наконец, передовые системы переходят от учета к управлению, развиваются до полнофункциональный системы диспетчеризации/управления генерацией, транспортом, отпуском ЭР, работающей в режиме реального времени, либо интегрируются с действующими системами управления. «Учитывать, чтобы управлять» — такой принцип все чаще встречается среди заказчиков, ведь учет – лишь инструмент решения задачи снижения издержек.

 

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

 

Программные и сервисные требования

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

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

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

 

Нередкий случай – в одном из подъездов МКД в половине квартир
перегорели телевизоры и другая бытовая техника. Кто виноват?
Кому предъявлять ущерб? Ресурсник допустил грубое нарушение
по качеству электроснабжения (скачок напряжения),
или эксплуатирующая дом организация нарушила правила эксплуатации?
Дополнительный модуль контроля установленной системы учета качества
постоянно отслеживал уровень напряжения и зафиксировал
действительно резкий скачок по напряжению в определённый момент времени.
Когда комиссия проводила «разбор полетов», то выяснилось,
что именно в это время ремонтная бригада выполняла сварку.
Бесконфликтное и быстрое разрешение сложных ситуаций
на границе ответственности «РСО – эксплуатирующая организация» —
это неожиданный дополнительный позитивный эффект длительного действия
от хорошей системы учета с расширенными функциями.

 

При этом добавление нового счетчика в систему при мастшабировании можно организовать в один клик, а ещё лучше посредством автоматического конфигурирования. А замена и удаление могут происходить в режиме реального времени без останова системы. Для реализации этой опции необходимо, чтобы такой функционал поддерживали  счётчики (через QR-код, NFC или иные метки), и за этим будущее.

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

Нужно отслеживание жизненного цикла всех единиц, входящих в систему, от установки до полной замены, включая ТОиР, поверки и проч., включая оперативную диагностику работоспособности счетчиков, модемов/устройств обработки и передачи данных, серверов, программного обеспечения.

 

Рис. 2. Структурная схемы системы учета

 

Архитектура «идеальной» системы учета

Функциональная структурная схема «идеальной» системы учета достаточно проста (рис. 2). Базовая платформа – программный продукт, являющийся ядром системы, реализует основные функции. Опции реализуются в виде отдельных модулей, их набор и отражает отраслевую специфику системы учета. Получается своего рода конструктор, позволяющий пользователю скомпоновать систему учета под собственные потребности. Причем, при соблюдении требования интероперабельности новые специализированные модули-опции создаются сторонними ИТ-компаниями (а не производителем базовой платформы!) или ИТ-службой пользователя системы.

 

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

 

При этом технологии программирования (клиент-серверные, веб-технологии, микросерверная архитектура и т.д.) могут быть различны и меняться, однако названные требования к системе учета сохраняются в любом случае.

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

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

 

Другие статьи автора:

Михаил Шехтман. Цифровое предприятие: семь отличительных признаков

 

Михаил Шехтман. АСУ ТП плюс искусственный интеллект. Часть 1. Функции работы с данными

 

 

Добавить комментарий

Нет комментариев

Нет Комментариев!

Вы можете быть первым, кто прокомментирует эту статью.

Написать комментарий
Просмотреть комментарии

Добавить комментарий

Ваш E-mail адрес не будет опубликован.
Обязательные к заполнению поля помечены*

*

code