РАЗРАБОТКА СЕРВЕРА СБОРА ТЕХНОЛОГИЧЕСКИХ ПАРАМЕТРОВ В ГАЗОВОЙ ПРОМЫШЛЕННОСТИ

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

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

Прототипом для работы является терминальная программа для датчика-расходомера «Гиперфлоу-ЗПМ» НПО «Вымпел».

В работе на основе функционала терминальной программы НПО «Вымпел» представлен программный продукт в виде сервера сбора данных технологических параметров, использующий современные технологи разработки.

Ключевые слова: Гиперфлоу-3ПМ, Modbus, j2mod, PostgreSQL, Java.

Введение.

Одним из примеров нефтегазовой компании послужил ООО «Газпром трансгаз Югорск» – газотранспортное предприятие, осуществляющие транспортировку газа с месторождений Северо-Западной Сибири потребителям европейской части страны, странам ближнего и дальнего зарубежья.

На производстве суммарно задействованы 214 компрессорных цехов, оснащенных 1143 газоперекачивающими агрегатами (ГПА), измерительные микропроцессорные комплексы – узлы учета расхода газа, промышленные измерительные датчики и т. д.

Объектом автоматизации является процесс передачи технологических данных с измерительных микропроцессорных комплексов (ИМК) посредством локальной технологической сети предприятия.

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

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

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

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

Автор Гороховицкая Т.Н. в своей статье говорит о том, что рост эффективности производства до 50% происходит за счет совершенствования технологий [2, 3]. Отслеживание сбоев технологического процесса и нештатных ситуаций является критически важным для предприятия. Одновременно такие ситуации приводят к материальным и финансовым потерям [3].

Далее представлены информационные источники, которые помогут в работе.

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

Бородин И.Ф. и Андреев С.А. в своих трудах [5] изложили основы автоматизации, даны краткое описание и характеристики технических средств систем автоматического управления, принципы автоматизации типовых технологических процессов на примере сельскохозяйственного производства.

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

В статье [7] рассматривается вклад современных технологий в направление развития нового поколения SCADA-систем и пример применения этих технологий.

Методы и материалы

В результате анализа руководства по эксплуатации расходомера «Гиперфлоу 3Пм» [8] решено использовать в разработки программно-технического средства реализацию коммуникационного протокола связи Modbus, который является довольно распространённым протоколом в системах автоматизации на среднем и нижнем (полевом) уровнях. Средний — это уровень контроллеров — устройств, осуществляющих сбор данных и управление технологическим процессом.

Нижний или полевой — это уровень взаимодействия датчиков и контроллеров или датчиков напрямую с сервером. Является стандартом де-факто и поддерживается почти всеми производителями промышленного оборудования. Благодаря универсальности и открытости, стандарт позволяет интегрировать оборудование разных производителей. Modbus используется для сбора показания с датчиков, управления реле и контроллерами, мониторинга, и т. д. [9].

Средой исполнения выбрана операционная система Базальт СПО «Альт Линукс Сервер» [10] являющейся одобренной правительством Российской Федерацией к использованию на объектах критической инфраструктуры, коим являются технологические данные, используемые в разрабатываемом ПО.

База данных, используемая для хранения технологических данных – PostgreSQL [11], являющейся свободной объектно-реляционной системой управления базами данных.

Существует в реализациях для множества UNIX-подобных платформ, включая AIX, различные BSD-системы, HP-UX, IRIX, Linux, macOS, Solaris/OpenSolaris, Tru64, QNX, а также для Microsoft Windows.

Язык разработки Java — строго типизированный объектно-ориентированный язык программирования общего назначения [12].

Для описания логики взаимодействия сбора данных с измерительных микропроцессорных комплексов по протоколу Modbus TCP выбрана библиотека j2mod [13], являющейся расширением библиотеки jamod [14], которая в свою очередь является открытой и свободно распространяемой реализацией протокола Modbus на Java.

Результат

В соответствии с руководством по эксплуатации «ГиперФлоу-3ПМ», вычленен состав технологических параметров, принимаемых от узлов учета газа, через системы телеметрии газораспределительной станции предприятия. Следуя составу технологических параметров и иерархии газотранспортной системы предприятия, спроектирована база данных, даталогическая диаграмма представлена на схеме 1.

Рисунок 1. Схема базы данных для хранения технологических параметров

В качестве имитации работы датчика расходомера газа был собран стенд на основе программируемого реле Овен ПР200 и преобразователя интерфейса Мoxa Mgate 3180.

Для последующей апробации разрабатываемого сервера сбора данных, программируемое реле запрограммировано на передачу случайных значений, соответствующих эксплуатационным характеристикам расходомера, по протоколу Modbus RTU по интерфейсу RS-232 через преобразователь Moxa. Часть функционального блока программируемого реле представлен на схеме 2.

Рисунок 2. Функциональный блок программируемого реле Овен ПР200

При разработке непосредственно сервера сбора параметров использован язык программирования Java, библиотека j2mod и драйвер PostgreSQL JDBC [15]. На рисунке 3 показана диаграмма классов разрабатываемого приложения.

Рисунок 3. Диаграмма классов разработанного сервера сбора данных

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

SELECT l.lpu_name, k.kc_name, g.grs_name, y.yy_name, t.tag_name, d.value, des.description, d.add_at, p.ed

FROM "GRSYYD" AS gy

JOIN "GRS" AS g ON gy.id_grs = g.grs_id

JOIN "KC" AS k ON g.id_kc = k.kc_id

JOIN "LPU" AS l ON k.id_lpu = l.lpu_id

JOIN "YYD" AS yd ON gy.id_yyd = yd.yyd_id

JOIN "YY" AS y ON yd.id_yy = y.yy_id

JOIN "DataParamTag" AS dpt ON yd.id_dataparamtag = dpt.dataparamtag_id

JOIN "Data" AS d ON dpt.id_data = d.data_id

JOIN "Parameter" AS p ON dpt.id_parameter = p.parameter_id

JOIN "Tag" AS t ON dpt.id_tag = t.tag_id

JOIN "Description" AS des ON t.id_description = des.description_id

WHERE t.tag_name like '%q%'

ORDER BY d.add_at

Результат наполнения базы данных после запуска разработанного приложения показано на рисунке 4.

Рисунок 4. Результат наполнения базы данных

Обсуждение

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

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

Следуя стандарту IEE754, определяющего представление отрицательных и положительных чисел с плавающей запятой, написаны два метода для преобразования полученного значения обратно в формат float:

    public static long combineDwords(int dword1, int dword2) {

        long combined = ((long) dword1 << 16) | (dword2 & 0xFFFFFFFFL);

        return combined;

    }

    public static float convertToFloat(long number) {

        int bits = (int) (number & 0xFFFFFFFFL);

        float result = Float.intBitsToFloat(bits);

        return result;

    }

Спецификация Modbus не определяет формат хранения и передачи float величин [16], поэтому каждый производитель придумывает свой способ передачи значений.

Отсюда напрашивается вывод, что созданный имитационный стенд призван помочь только на этапе отладки функций записи и получения значений сервером сбора данных. Для гарантирована правильности интерпретирования полученных значений следует обращаться напрямую к разработчику «Гиперфлоу-3ПМ» для выяснения в каком формате передаются данные по протоколу Modbus, и только после этого дорабатывать систему.

Заключение

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