БИБЛИОТЕКА «ТЕПЛОПУНКТА»
Д. Л. Анисимов
Информационное обслуживание приборов учёта
(Ранее опубликовано:
Коммунальный комплекс России, № 11'2017)
Все мы помним, что на заре эпохи приборного учёта тепла и воды большинство приборов использовались «локально». Чтобы «снять» показания теплосчётчика, к нему нужно было подойти и, нажимая на кнопки, списать цифры с дисплея. Те, кто свято соблюдал требования тогдашних Правил учёта (документ 1995 г.), делали это ежедневно, занося списанные данные в журнал. Остальные исполняли сию обязанность раз за отчётный месяц, благо, теплосчётчики и тогда уже имели архивы. Ходить в таком случае нужно было меньше, зато писать — намного больше.
Когда стал развиваться бизнес по обслуживанию узлов учёта, «в моду» вошли так называемые пульты сбора данных. Проблему долгого и нудного переписывания (часто ведущего к ошибкам) они решали, но от необходимости ходить по узлам не избавляли. Для потребителя, имеющего один теплосчётчик, такое устройство стоило неоправданно дорого, а вот для организации, собирающей (за деньги) показания с десятков узлов учёта, оно становилось необходимым и быстро окупающимся инструментом. Одна беда: приборы каждой марки (то есть каждого производителя) требовали своего пульта. Поэтому сотрудники «мультибрендовых» обслуживающих фирм ходили порой буквально обвешанные этими «гаджетами»...
Одновременно с «пультовым» начал развиваться и дистанционный сбор данных. По большому счёту вариантов здесь было два: либо прямое кабельное соединение, либо телефонный модем. Первый вариант применялся на «коротких дистанциях», когда, например, теплосчётчик находился в подвале, а данные с него считывались стоящим в одном из кабинетов того же здания компьютером. То есть это был такой «локальный дистанционный учёт».
Во втором варианте теплосчётчик и компьютер (диспетчерский пункт) могли находиться хоть в разных городах, да и теплосчётчиков один диспетчер мог опрашивать множество. Однако построение подобных систем было затруднено из-за повсеместного дефицита свободных телефонных номеров. Очень часто счётчики подключались к телефонной сети «параллельно» обычным аппаратам; автор этих строк ещё помнит, как приходилось порой перед опросом прибора звонить на объект и говорить ответившему человеку: сейчас сюда перезвонит модем, трубку не берите! Хотя в основном такие «параллельные» счётчики опрашивались по ночам: программы сбора данных умели делать это автоматически в заданные интервалы времени. К слову, качество связи по телефонным линиям было ужасным. Но других вариантов не было — по крайней мере, в жилищно-коммунальном секторе.
Ситуация значительно упростилась с появлением сотовой связи. Проблема дефицита номеров исчезла сразу, проблема качества передачи данных решалась по мере развития технологий. Оборудование, конечно, влетало в копеечку, да и тарифы сотовых операторов не радовали. Но здесь достаточно просто было «просчитать экономику» и принять решение: стоит ли идти на острие прогресса или же вы- годнее (пока) оставаться за его бортами.
Ну, а настоящий прорыв в деле дистанционного сбора показаний приборов учета произошел на волне интернет-технологий. «Повсеместно протянутая паутина» (www — world wide web) позволяет соединять устройства, расположенные хоть на разных сторонах земного шара. Подключаться же к ней («паутине») можно массой общедоступных способов. Особенно приятно то, что коммуникационные устройства в наше время стали весьма недороги, выбор их огромен, а стоимость передачи данных упала ниже некуда. Пользователь же может получать доступ к показаниям приборов вообще без всяких «спецприспособлений», а непосредственно со своего (подключенного к сети интернет, но иначе сейчас и не бывает) компьютера, ноутбука, планшета, смартфона. Проблема только одна — нужен хороший софт...
Но прежде, чем говорить о программном обеспечении, давайте рассмотрим структуру типичной современной системы сбора данных (системы диспетчеризации). На приборном уровне всё выглядит «классически»: это теплосчётчики, состоящие в свою очередь из первичных преобразователей (расходомеров, датчиков температуры и давления) и вычислителей. Верхний же уровень находится, как сейчас принято говорить, «в облаке». Это сервер, но вот что он из себя представляет физически и где фактически находится — не важно ни интегратору системы, ни, тем более, пользователю. Это может быть компьютер, установленный в офисе обслуживающей организации, а может — виртуальная машина, арендуемая этой организацией у какого-либо (может, даже зарубежного) хостинг-провайдера.
Сервер связывается с приборами (или приборы с сервером), используя существующую инфраструктуру сети интернет. Интегратору системы нет необходимости задумываться об организации каналов связи: он должен лишь выбрать способ подключения приборов учёта ко всемирной паутине. Выбор зависит от того, что в каждом конкретном случае проще, надежней, выгодней — как в момент приобретения оборудования, так и в эксплуатации. Например, в здание, что стоит в чистом поле, поставят, скорее всего, GPRS-модем, ведь сети сотовой связи в наше время покрывают почти все чистые поля, в которых стоят хоть какие-нибудь здания. А в жилом доме в гуще городской застройки лучше, наверное, подключиться к розетке Ethernet или сети Wi-Fi местного провайдера.
Что касается пользователей системы (по-старинному — операторов), то они работают с сервером (и далее — с приборами учёта) также через интернет. Инструмент — обычный компьютер, ноутбук, планшет, смартфон. Во многих случаях (но это, конечно, зависит от установленного на сервере софта) на этом устройстве для работы им достаточно будет стандартного браузера. Количество пользователей теоретически не ограничено, права доступа для них могут назначаться индивидуально (или по группам). То есть вообще понятие «оператора системы» с его «автоматизированным рабочим местом» (терминология буквально прошлой пятилетки) теряет всякий смысл.
Пользователь — сотрудник обслуживающей организации с правами администратора может настраивать систему, формировать разнообразные отчеты по любым включенным в нее приборам и т.п. Пользователь — владелец обслуживаемого прибора (например, житель многоквартирного дома, где установлен теплосчетчик) может, например, только просматривать показания (и только по своему дому). Количество «промежуточных» уровней доступа — любое.
Из вышесказанного должно быть понятно, что при построении современных систем сбора показаний приборов учёта (систем диспетчеризации) проблемы аппаратного обеспечения больше не существует. У любого теплосчетчика/тепловычислителя есть какой-нибудь интерфейс, коммуникационных устройств, способных самыми разными способами обеспечить транспорт данных теплосчётчика в «облако» — множество. «Собрать» свой сервер — не проблема, еще проще арендовать виртуальную машину. И остается только один вопрос — какое на этот сервер поставить программное обеспечение. Потому что именно оно, и только оно, определяет функции системы.
В недавнюю и очень краткосрочную эпоху «пультового» и «локального дистанционного» сбора данных (об этом написано выше) каждый производитель приборов учёта предлагал (часто — бесплатно) какую-нибудь программу для считывания и обработки (сохранение в файл, формирование и печать отчетов) данных своих теплосчётчиков. Такие программы могли применяться и при опросе приборов через модемы. Но если опрашивались приборы разных производителей, программ приходилось использовать несколько. Понятно, что «мультибрендовым» обслуживающим организациям это было неудобно.
Спрос породил предложение, и на рынок вышли разработчики универсального софта. Их продукты могли работать с приборами разных производителей, умели приводить «разносортные» показания к общему (системному) виду, обеспечивали опрос по расписанию, автоматическое формирование, сохранение, печать, рассылку отчетов и пр. И, что особенно важно — обладали функциями анализа показаний, обнаружения отказов приборов и диагностики всякого рода нештатных ситуаций, возникающих в системах тепло- и водоснабжения.
Однако возможности такого софта упирались в ограничения, накладываемые технологиями опроса. Современность эти ограничения практически сняла. Сегодня мы можем доверить «автоматике и кибернетике» весь комплекс задач по информационному обслуживанию приборов учета — от сбора показаний до... команды (например, через SMS) слесарю пойти на такой-то объект и подтянуть такую-то гайку. Если, конечно, это предусмотрено используемым нами программным обеспечением.
В рамках данной статьи мы не будем описывать какие-либо конкретные современные системы (читай — программные продукты) сбора и обработки показаний приборов учёта. Отметим лишь, что их можно разделить на две большие группы: система как продукт и система как услуга. Первое означает, что вы покупаете программное обеспечение... по привычке хотелось написать «на диске», но нет — сегодня вы, скорее, скачиваете его с интернет-сайта разработчика (а оплачиваете через интернет-банк). Это программное обеспечение вы устанавливаете на своем реальном или виртуальном сервере, и вот у вас уже есть собственная система учёта.
Второй вариант (система как услуга) означает, что софт уже развернут на «чьём-то» сервере — этим «кем-то» может быть разработчик программы, или какой-то его представитель, или обслуживающая организация. Вы регистрируетесь в этой готовой системе и можете подключать к ней свои приборы учёта. Оплата за пользование — помесячная (к примеру). Не понравится — отключитесь и зарегистрируетесь в каком-нибудь другом (конкурирующем) сервисе.
Разумеется, классификация «продукт / услуга» относительна: ничто не мешает вам купить продукт, установить на свой сервер и предлагать другим как услугу. Однако существуют системы, которые как продукт просто не продаются: разработчик предлагает их только сам и только как услугу.
В заключение — о «правовом статусе» систем сбора показаний приборов учёта. В современных «Правилах коммерческого учёта тепловой энергии, теплоносителя» упоминания о них разбросаны по тексту, а используемая терминология заставляет порой задумываться, что именно имели в виду авторы правил. Эта неопределенность вкупе с традиционной российской любовью ко всякого рода бумажкам с печатями (а равно и с врождённым стремлением некоторых сограждан при каждой возможности вставлять палки в чужие колеса) ведёт к тому, что кто-то кое-где у нас порой требует, чтобы система сбора показаний была сертифицирована... как средство измерений! Абсурдность такого подхода комментировать здесь не будем. Считаем, что здравый смысл все равно когда-нибудь победит повсеместно... но для ускорения процесса неплохо было бы переписать «Правила ...», и чем раньше и решительней, тем лучше.
