Производственно-технический нефтегазовый журнал
+7 (903) 580-85-63 +7 (495) 371-01-74 info@glavteh.ru

Единый протокол ТМС

В рамках формирования единых технических требований и обеспечения совместной работы погружных и наземных блоков телеметрических систем (ТМС) независимо от их типа и производителя в ПАО «ЛУКОЙЛ» в 2016-2017 годах был разработан и внедрен «Единый Протокол ТМС».

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

02.04.2018 Инженерная практика №02/2018
Смыслов Андрей Юрьевич Старший менеджер отдела технического обеспечения АСУ ТП Управления обеспечения деятельности АСУ ТП и производств ООО «ЛУКОЙЛ-ИНФОРМ»

В результате проведенных в 2016-2017 годах работ по формированию единых технических требований и обеспечению возможности совместной работы погружных и наземных блоков телеметрических систем независимо от их типа и производителя в ПАО «ЛУКОЙЛ» был разработан «Единый протокол ТМС». По состоянию на сентябрь 2017 года Протокол был оформлен и проходил процедуру утверждения. Планируется, что с 2018 года соответствие требованиям Протокола будет внесено в технические требования на закупку ТМС для организаций Группы «ЛУКОЙЛ».

КОНЦЕПЦИЯ ПРОТОКОЛА

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

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

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

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

Поэтому изначально мы решили создать Протокол, который будет развиваться и расширяться параллельно с развитием ТМС без потери совместимости и с возможностью совместной работы погружного и наземного оборудования независимо от их типа и производителя. Также мы стремились достичь автоматического определения, настройки и включения в состав ТМС как уже работающих, так и новых, еще только проектируемых, типов устройств, при этом Протокол должен был быть максимально совместимым с существующим парком ТМС в организациях Группы «ЛУКОЙЛ».

СТРУКТУРА ПРОТОКОЛА

Структурно Протокол разбит на четыре основные части (рис. 1):

  • протокол передачи информации от погружного оборудования к наземному – ТМСП→ТМСН;
  • протокол передачи информации между наземным блоком и контроллером станции управления – ТМСН↔КСУ;
  • конфигурация оборудования;
  • протокол передачи информации от КСУ и ТМСН к ТМСП.
Рис. 1. Структура Единого протокола ТМС
Рис. 1. Структура Единого протокола ТМС

В протоколы ТМСП→ТМСН и ТМСН↔КСУ введен базовый функционал для поддержки автоматической конфигурации оборудования.

ПРОТОКОЛ ТМСП→ТМСН

В протоколе ТМСП→ТМСН (рис. 2) для передачи информации используется погружной кабель питания. На физическом уровне для передачи данных используется фазоманипулированный код «Манчестер-II». С целью реализации механизма автоматического определения и настройки погружного и наземного оборудования в Протокол дополнительно введены кадр UUID и кадр конфигурации. Как можно видеть из рис. 2, данные кадры передаются на начальном этапе инициализации ТМС и в дальнейшем никак не влияют на ее работу. Назначение данных кадров передать ТМСН и КСУ уникальный идентификатор (UUID, Universally Unique Identifier) и особенности конфигурации ТМСП.

Рис. 2. Протокол ТМСП→ТМСН
Рис. 2. Протокол ТМСП→ТМСН

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

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

Для подтверждения приема команд от КСУ и ТМСН введен кадр подтверждения приема команды.

ПРОТОКОЛ ТМСН↔КСУ

В протоколе ТМСН↔КСУ для передачи данных на физическом уровне используется интерфейс RS-485, на канальном уровне – протокол Modbus RTU. На прикладном уровне используются следующие функции протокола Modbus:

  • 0x03 – чтение регистров хранения;
  • 0x04 – чтение входных регистров;
  • 0x06 – запись значения в регистр хранения.

Отличительная особенность реализации Протокола ТМСН↔КСУ заключается в использовании конфигурационного пространства протокола Modbus (функция 0x2B/0x0E) для автоматической настройки и конфигурации оборудования. В процессе инициализации ТМСН заносит в конфигурационное пространство Modbus свой UUID и после получения от ТМСП блока конфигурации UUID ТМСП.

Для контроля корректности файлов конфигурации могут применяться параметры HASH. Параметр HASH представляет собой контрольную сумму файла конфигурации, которая рассчитывается как циклический избыточный код CRC16 протокола Modbus и может выполнять функцию цифровой подписи файла конфигурации. В рамках Протокола допускается использовать файлы конфигурации без или с некорректным значением HASH, но такие события должны обязательно протоколироваться КСУ.

ПЕРЕДАЧА ИНФОРМАЦИИ ТМСП-ТМСН-КСУ

Рис. 3. Передача информации ТМСП-ТМСН-КСУ
Рис. 3. Передача информации ТМСП-ТМСН-КСУ

Каждый параметр, передаваемый в кадрах протокола от ТМСП к КСУ, однозначно связан с номером страницы и смещением внутри нее (рис. 3). После приема кадра ТМСН распаковывает его и заносит значение параметра в соответствующую страницу и по соответствующему смещению. КСУ считывает информацию из ТМСН по протоколу Modbus. Адрес Modbus определяется как BaseAdrTMSN + номер страницы × 256 + смещение. Базовый адрес ТМСН, а также адреса параметров ТМСН и ТМСП–КСУ может получить из соответствующих файлов конфигурации. По умолчанию карта распределения памяти Протокола сделана максимально обратно совместимой с существующими протоколами.

КОНФИГУРАЦИЯ ОБОРУДОВАНИЯ

Для уникальной идентификации оборудования и производителя в рамках Протокола используется UUID (Universally Unique Identifier) уникальный 128-битный идентификатор. Он позволяет в рамках ТМС уникально идентифицировать информацию без единого центра координации, что исключает необходимость ведения общей базы данных оборудования.

В настоящее время существует широкий набор программных средств для генерации UUID как в виде отдельных утилит, входящих в состав средств разработки, так и на основе Web-интерфейса. Благодаря этому любой производитель ТМС может при помощи стандартных средств сгенерировать UUID и использовать его для уникальной идентификации производимого оборудования.

Рис. 4. Конфигурация оборудования
Рис. 4. Конфигурация оборудования

Автоматическая конфигурация ТМС осуществляется по следующему алгоритму (рис. 4). После начальной инициализации КСУ запрашивает у ТМСН идентификаторы ТМСН и ТМСП. В первую очередь ТМСН передает КСУ свой UUID и ожидает получения идентификатора ТМСП. Получив идентификатор ТМСН, КСУ осуществляет поиск файла конфигурации ТМСН и после этого осуществляет загрузку информации о конфигурации ТМСН, его функциональных возможностях и режимах работы. Затем КСУ запрашивает у ТМСН UUID ТМСП и, выполняя аналогичный набор действий, загружает конфигурационные данные ТМСП.

Технически файл конфигурации представляет собой файл в формате XML, его имя задается в формате UUID.xml (например, для оборудования с UUID 22345200-ABE8-4F60-90C8-0D43C5F6C0F7 имя файла конфигурации будет 22345200-ABE8-4F60-90C80D43C5F6C0F7.xml).

ПЕРЕДАЧА КОМАНД КСУ, ТМСН→ТМСП

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

Рис. 5. Передача команд КСУ, ТМСН ТМСП
Рис. 5. Передача команд КСУ, ТМСН ТМСП

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

РАЗВИТИЕ ПРОТОКОЛА

В рамках дальнейшего развития Протокола планируется провести стандартизацию установочных размеров, разъемов, напряжений питания ТМСН. Это позволит избавить сервисные службы от выполнения разного рода «доделок» и рутинных работ.

Для обеспечения дальнейшей стандартизации и унификации оборудования предполагается определение типовых классов устройств ТМС с присущим каждому из них набором параметров. Это могут быть такие классы, как «стандартная ТМС», «высокоточная ТМС», «ТМС с поддержкой виртуального расходомера» и т.д. Также мы планируем реализовать возможность загрузки программного кода в КСУ с использованием Java-платформы и наладить использование файлов конфигурации для описания СУ и ее интеграции с системами АСУТП и АСУП, в том числе в рамках концепции интеллектуального месторождения.

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

Показать выдержки из обсуждения

ВЫДЕРЖКИ ИЗ ОБСУЖДЕНИЯ

Вопрос: Андрей Юрьевич, с чем связаны планы по использованию Java-платформы для загрузки программного кода в КСУ?
Андрей Смыслов: В данном случае использование Javaплатформы обеспечит участие сторонних по отношению к производителям ТМС организаций в развитии Протокола. Самый простой пример – РГУ нефти и газа (НИУ) имени И.М. Губкина, разработчик виртуального расходомера. Сегодня для того чтобы обеспечить внесение каких-то изменений в СУ, РГУ необходимо договариваться с производителем, а использование Java-платформы позволит им предложить свое решение непосредственно нам.
Вопрос: В рамках Протокола вы предлагаете ввести некий универсальный идентификатор в ТМСП и ТМСН. Но ведь протокол Transfer уже предполагает наличие первого кадра, где заложены идентификаторы завода-производителя и самого устройства. Если эта идентификация уже реализована, зачем нужна дублирующая функция?
А.С.: Дело в том, что в протоколе Transfer указаны идентификаторы конкретных заводов-производителей, и в случае появления нового производителя или разделения компании необходимо будет вносить в них соответствующие дополнения и изменения. Мы же предлагаем «глобальный» идентификатор, который даст возможность исключить всю эту бюрократическую работу.
Вопрос: Вы отметили, что в рамках протокола ТМСП→ТМСН предусмотрена передача блока конфигурационных данных от ТМСП к ТМСН. Какие данные входят в этот блок?
А.С.: Пока в этом блоке передается только HASH и «нулевая» информация по умолчанию. Но данный блок у нас зарезервирован для передачи кода класса устройства. Реализация возможности передачи таких кодов позволит отказаться от детального описания параметров в конфигурационном файле.
Комментарии

Эту публикацию еще никто не прокомментировал. Станьте первым, поделитесь своим мнением.

Написать комментарий
Комментировать
Читайте далее
Стандартизация установочных размеров систем погружной телеметрии
Повышение эффективности использования ТМС в скважинах месторождений ОАО «Сургутнефтегаз»
Реклама
Свежий выпуск
Инженерная практика №05/2018

Инженерная практика

Выпуск №05/2018

Промысловые трубопроводыМеханизированная добыча
Особенности и нормативная база в области эксплуатации и ремонта подводных трубопроводовДиагностика, мониторинг и обеспечение безаварийной эксплуатации промысловых трубопроводов, защитные покрытияПроектирование, строительство и ремонт стальных и полимерных трубопроводовОПИ глубинно-насосного оборудования и НКТ с защитными покрытиями, эксплуатация неметаллических НКТРеагенты и внутрискважинное оборудование для механизированной добычи нефти в осложненных условияхПодготовка нефти. Внедрение ГИС
Ближайшее совещание
Механизированная добыча, Трубопроводный транспорт
Коррозия 2018
Международная производственно-техническая конференция

КОРРОЗИЯ – 2018: Эффективные методы работы с фондом скважин, осложненным коррозией, эксплуатация промысловых нефтегазопроводов и водоводов в условиях высокой коррозионной активности

27-29 августа 2018 г., г. Казань, конференц-зал «Габдулла Тукай»
Задачей Конференции является обмен опытом и определение наиболее экономически и технологически эффективных решений и технологий в области работы с фондом скважин, осложненных коррозионным фактором и анализ применения современных методов и технологий для сокращения аварийности промысловых трубопроводов различного назначения в условиях высокой коррозионной активности.
Ближайший тренинг
Капитальный ремонт скважин
Ловильный сервис – сентябрь 2018
Тренинг-курс

Ловильный сервис на нефтяных и газовых скважинах

10 – 14 сентября 2018 г., г. Пермь
ООО «Инженерная практика» от имени журнала «Инженерная практика» проводит набор группы специалистов для прохождения производственно-технического тренинга по программе «Ловильный сервис на нефтяных и газовых скважинах». Пятидневный тренинг - курс будет проводиться в г. Перми (отель «Урал») в рамках авторского курса С. Балянова.