Единый протокол ТМС
В рамках формирования единых технических требований и обеспечения совместной работы погружных и наземных блоков телеметрических систем (ТМС) независимо от их типа и производителя в ПАО «ЛУКОЙЛ» в 2016-2017 годах был разработан и внедрен «Единый Протокол ТМС».
Ключевая особенность Протокола по сравнению с другими аналогичными протоколами заключается в том, что основной акцент по настройке базовых адресов, карт памяти оборудования и описания поддерживаемых параметров перенесен из описательной части на файлы конфигурации оборудования. Для этого в рамках Протокола реализован механизм уникальной идентификации каждого элемента ТМС.
В результате проведенных в 2016-2017 годах работ по формированию единых технических требований и обеспечению возможности совместной работы погружных и наземных блоков телеметрических систем независимо от их типа и производителя в ПАО «ЛУКОЙЛ» был разработан «Единый протокол ТМС». По состоянию на сентябрь 2017 года Протокол был оформлен и проходил процедуру утверждения. Планируется, что с 2018 года соответствие требованиям Протокола будет внесено в технические требования на закупку ТМС для организаций Группы «ЛУКОЙЛ».
КОНЦЕПЦИЯ ПРОТОКОЛА
В рамках данной статьи в первую очередь рассмотрим, какие базовые принципы и подходы были использованы при построении Протокола и почему Протокол получился именно таким.
На начальном этапе обсуждении концепции построения Протокола мы пришли к выводу, что любая стандартизация и унификация на первом этапе ее внедрения приведет к необходимости доработки и корректировки оборудования ТМС, а также к решению вопросов обеспечения поддержки наследственного оборудования на переходном этапе внедрения Протокола.
В тоже время, анализируя существующие протоколы ТМС, мы видели, что все они были срезом возможностей ТМС на момент написания протокола. А это значит, что список поддерживаемых форматов передачи данных и адресов расположения параметров в памяти жестко прописан в рамках бумажного протокола. Плюс такого подхода заключается в том, что это позволяет упростить реализацию протокола в «железе». Минус – проблемы для дальнейшего развития протокола. Например, производитель разработал новый тип датчика, но в рамках существующего протокола невозможно передать данные с датчика, так как изначально это не предусмотрено протоколом.
При создании Протокола мы не хотели опираться исключительно на существующие возможности ТМС, ведь через некоторое время они устареют, каждый производитель в рамках развития ТМС начнет вводить свои собственные расширения, и расхождение функционала ТМС и Протокола станет лишь вопросом времени.
Поэтому изначально мы решили создать Протокол, который будет развиваться и расширяться параллельно с развитием ТМС без потери совместимости и с возможностью совместной работы погружного и наземного оборудования независимо от их типа и производителя. Также мы стремились достичь автоматического определения, настройки и включения в состав ТМС как уже работающих, так и новых, еще только проектируемых, типов устройств, при этом Протокол должен был быть максимально совместимым с существующим парком ТМС в организациях Группы «ЛУКОЙЛ».
СТРУКТУРА ПРОТОКОЛА
Структурно Протокол разбит на четыре основные части (рис. 1):
- протокол передачи информации от погружного оборудования к наземному – ТМСП→ТМСН;
- протокол передачи информации между наземным блоком и контроллером станции управления – ТМСН↔КСУ;
- конфигурация оборудования;
- протокол передачи информации от КСУ и ТМСН к ТМСП.
В протоколы ТМСП→ТМСН и ТМСН↔КСУ введен базовый функционал для поддержки автоматической конфигурации оборудования.
ПРОТОКОЛ ТМСП→ТМСН
В протоколе ТМСП→ТМСН (рис. 2) для передачи информации используется погружной кабель питания. На физическом уровне для передачи данных используется фазоманипулированный код «Манчестер-II». С целью реализации механизма автоматического определения и настройки погружного и наземного оборудования в Протокол дополнительно введены кадр UUID и кадр конфигурации. Как можно видеть из рис. 2, данные кадры передаются на начальном этапе инициализации ТМС и в дальнейшем никак не влияют на ее работу. Назначение данных кадров передать ТМСН и КСУ уникальный идентификатор (UUID, Universally Unique Identifier) и особенности конфигурации ТМСП.
Получив уникальный идентификатор ТМСП, КСУ сможет по нему найти необходимый файл конфигурации и загрузить из него список параметров, режимов работы и особенностей подключенного ТМСП.
В будущем использование уникальных идентификаторов UUID сможет обеспечить возможность бесшовной интеграции ТМС в системы управления более высокого уровня и, в конечном счете, в состав так называемого интеллектуального месторождения.
Для подтверждения приема команд от КСУ и ТМСН введен кадр подтверждения приема команды.
ПРОТОКОЛ ТМСН↔КСУ
В протоколе ТМСН↔КСУ для передачи данных на физическом уровне используется интерфейс RS-485, на канальном уровне – протокол Modbus RTU. На прикладном уровне используются следующие функции протокола Modbus:
- 0x03 – чтение регистров хранения;
- 0x04 – чтение входных регистров;
- 0x06 – запись значения в регистр хранения.
Отличительная особенность реализации Протокола ТМСН↔КСУ заключается в использовании конфигурационного пространства протокола Modbus (функция 0x2B/0x0E) для автоматической настройки и конфигурации оборудования. В процессе инициализации ТМСН заносит в конфигурационное пространство Modbus свой UUID и после получения от ТМСП блока конфигурации UUID ТМСП.
Для контроля корректности файлов конфигурации могут применяться параметры HASH. Параметр HASH представляет собой контрольную сумму файла конфигурации, которая рассчитывается как циклический избыточный код CRC16 протокола Modbus и может выполнять функцию цифровой подписи файла конфигурации. В рамках Протокола допускается использовать файлы конфигурации без или с некорректным значением HASH, но такие события должны обязательно протоколироваться КСУ.
ПЕРЕДАЧА ИНФОРМАЦИИ ТМСП-ТМСН-КСУ
Каждый параметр, передаваемый в кадрах протокола от ТМСП к КСУ, однозначно связан с номером страницы и смещением внутри нее (рис. 3). После приема кадра ТМСН распаковывает его и заносит значение параметра в соответствующую страницу и по соответствующему смещению. КСУ считывает информацию из ТМСН по протоколу Modbus. Адрес Modbus определяется как BaseAdrTMSN + номер страницы × 256 + смещение. Базовый адрес ТМСН, а также адреса параметров ТМСН и ТМСП–КСУ может получить из соответствующих файлов конфигурации. По умолчанию карта распределения памяти Протокола сделана максимально обратно совместимой с существующими протоколами.
КОНФИГУРАЦИЯ ОБОРУДОВАНИЯ
Для уникальной идентификации оборудования и производителя в рамках Протокола используется UUID (Universally Unique Identifier) уникальный 128-битный идентификатор. Он позволяет в рамках ТМС уникально идентифицировать информацию без единого центра координации, что исключает необходимость ведения общей базы данных оборудования.
В настоящее время существует широкий набор программных средств для генерации UUID как в виде отдельных утилит, входящих в состав средств разработки, так и на основе Web-интерфейса. Благодаря этому любой производитель ТМС может при помощи стандартных средств сгенерировать UUID и использовать его для уникальной идентификации производимого оборудования.
Автоматическая конфигурация ТМС осуществляется по следующему алгоритму (рис. 4). После начальной инициализации КСУ запрашивает у ТМСН идентификаторы ТМСН и ТМСП. В первую очередь ТМСН передает КСУ свой UUID и ожидает получения идентификатора ТМСП. Получив идентификатор ТМСН, КСУ осуществляет поиск файла конфигурации ТМСН и после этого осуществляет загрузку информации о конфигурации ТМСН, его функциональных возможностях и режимах работы. Затем КСУ запрашивает у ТМСН UUID ТМСП и, выполняя аналогичный набор действий, загружает конфигурационные данные ТМСП.
Технически файл конфигурации представляет собой файл в формате XML, его имя задается в формате UUID.xml (например, для оборудования с UUID 22345200-ABE8-4F60-90C8-0D43C5F6C0F7 имя файла конфигурации будет 22345200-ABE8-4F60-90C80D43C5F6C0F7.xml).
ПЕРЕДАЧА КОМАНД КСУ, ТМСН→ТМСП
Практически все современные протоколы передачи данных, используемые в ТМС, способны передавать информацию только в одном направлении – от ТМСП к ТМСН. При этом со стороны заказчика все чаще возникает потребность в управлении работой погружного оборудования, например, пакера или клапана. Поэтому при разработке Протокола мы решили заложить в него поддержку передачи команд для погружного оборудования, а также стандартизировать эту функцию, чтобы исключить ситуацию, когда каждый производитель предлагает отдельные собственные решения, которые затем приходится совмещать и заново интегрировать. Поддержка команд для ТМСП задается в файле конфигурации и размещается в секции FeedbackChannel. На текущий момент поддержка передачи команд имеет статус рекомендуемой, то есть указывает на желательность реализации данной возможности, но необходимость ее реализации в рамках Протокола не требуется.
Передача команд осуществляется следующим образом (рис. 5). В памяти ТМСН есть область, в которую записывается код команды. КСУ, определив из файла конфигурации, что ТМСП поддерживает прием команд от наземного оборудования, обращается к соответствующей секции файла конфигурации, заносит код команды и параметры, установленные разработчиком ТМСП в память ТМСН. После того как этот блок памяти подготовлен, КСУ записывает в определенный регистр ТМСН команду начать передачу данных. ТМСН формирует необходимый пакет и передает его ТМСП. Приняв команду, ТМСП приступает к ее обработке и первым ответным кадром подтверждает ее получение. Получив кадр подтверждения приема команды, ТМСН заносит ее в соответствующие регистры, которые доступны для чтения КСУ. Файлы конфигурации в случае необходимости также позволяют указать соответствие между командой, ее данными, дополнительными параметрами, которые измеряет ТМС, и их местонахождением в памяти.
РАЗВИТИЕ ПРОТОКОЛА
В рамках дальнейшего развития Протокола планируется провести стандартизацию установочных размеров, разъемов, напряжений питания ТМСН. Это позволит избавить сервисные службы от выполнения разного рода «доделок» и рутинных работ.
Для обеспечения дальнейшей стандартизации и унификации оборудования предполагается определение типовых классов устройств ТМС с присущим каждому из них набором параметров. Это могут быть такие классы, как «стандартная ТМС», «высокоточная ТМС», «ТМС с поддержкой виртуального расходомера» и т.д. Также мы планируем реализовать возможность загрузки программного кода в КСУ с использованием Java-платформы и наладить использование файлов конфигурации для описания СУ и ее интеграции с системами АСУТП и АСУП, в том числе в рамках концепции интеллектуального месторождения.
Понятно, что в рамках одной статьи трудно дать исчерпывающий ответ по всем возможным нюансам и вопросам, связанным с Протоколом. Поэтому на площадке сайта «Инженерной практики» организована сетевая рабочая группа по координации и развитию Протокола, а также обсуждению и решению вопросов, связанных с ТМС.
Для отправки комментария вам необходимо авторизоваться.