Привет, Хабр!
На связи Рафис Гатауллин, ведущий эксперт отдела фронтенд, и Рамис Закиев, ведущий эксперт отдела аналитики в «Татнефть Цифровые Технологии». В этой статье по мотивам нашего доклада на конференции Industrial++ расскажем, об опыте внедрения мобильного решения, которое позволило оптимизировать процессы в цехах нефтедобычи, где нет условий для работы обычных сетей связи.
Поговорим о том, как мы реализовали передачу данных с мобильных устройств к сервисам по каналу радиосвязи стандарта TETRA. Об опыте подключения и взаимодействия с SDK, написанном на Java, в мобильном приложении на Xamarin. И о подходах, которые использовали для оптимизации трафика при передаче данных приложения и данных геопозиционирования.
Анализ организации производства в цехах нефтедобычи и выявление проблем
«Татнефть. Цифровые технологии» — дочерняя IT-компания ПАО «Татнефть», центр продуктовой разработки и технического сопровождения. Наша команда автоматизирует деятельность группы компаний и разрабатывает пользовательские сервисы.
В 2015 году специалисты нефтегазодобывающего управления «Альметьевнефть» провели анализ, как работает производство в одном из цехов нефтедобычи и выявили четыре проблемы, характерные, в принципе, для всех нефтепромыслов:
Неэффективный процесс приёма-передачи информации.
Диспетчеры теряли в процессе работы порядка 35% рабочего времени, а операторы по добыче нефти и газа — около 3%. Это достаточно много, и свидетельствовало о том, что взаимодействие сотрудников нужно оптимизировать.
Низкое качество мониторинга.
Система мониторинга не обеспечивала должного уровня контроля. В результате время на реакцию из-за отклонений в работе оборудования увеличивалось.
Отсутствие возможности проведения своевременного и качественного анализа больших объёмов данных.
Исторические данные хранились в локальных файлах, что делало невозможным прогнозирование сбоев, оптимизацию процессов или аналитику. Например, нельзя было выявить закономерности в поломках оборудования.
Отсутствие возможности передачи данных от линейного персонала до потребителей всех уровней.
Это приводит к недостаточно прозрачным процессам, как результат — важная информация о работе и состоянии оборудования не доходит вовремя до заинтересованных сторон.
Решением стала разработка мобильного приложения «АРМ-оператора» (Автоматизированное рабочее место), задачами которого были:
улучшить процессы приёма и передачи информации;
повысить качество мониторинга;
обеспечить быстрый и точный анализ данных в режиме реального времени.
Выбор инструментов для разработки: почему Xamarin.Forms
Выбирая инструмент для разработки мобильного приложения, мы ориентировались на опыт команды: разработчики были сильны в программировании на языке C# с фреймворком .NET и в создании десктопных приложений на WPF. Это сделало Xamarin.Forms очевидным выбором, поскольку он сочетает знакомый синтаксис разметки XAML и язык программирования C#.
На тот момент нам нужны были быстрые победы. Однако, если бы мы начинали проект сегодня, с учётом опыта разработки своего решения, то вероятно, сделали бы выбор в пользу Android Native Application. Это позволило бы избежать избыточной работы и некоторых сложностей, с которыми мы столкнулись, а также обеспечило бы лучшую производительность и лучший доступ к функционалу устройства.
Результат внедрения
Внедрение приложения в работу помогло улучшить организацию и управление производственными процессами цехов нефтедобычи:
Разгрузили диспетчерские службы нефти и газа. Это позволило перенаправить их на выполнение более важных задач.
Обеспечили оперативный обмен информацией в корпоративной информационной системе (КИС). Это существенно повысило эффективность, учёт и анализ информации, а также в значительной степени улучшило скорость реакции на любые изменения в работе оборудования и других процессов.
Настроили автоматическую интеграцию данных в КИС. Автоматизированная подкачка и хранение данных в общей системе повысили прозрачность процессов и качество управленческих решений на всех уровнях.
Приложение помогло оптимизировать производственные процессы и сделать их более управляемыми. Это положительно сказалось на общем уровне работы цехов.
AРМ оператора + TETRA: новые вызовы 2019 года
В 2019 году перед нашей командой возникли новые задачи, которые потребовали от нас внимания и серьёзного анализа. Важным вызовом стала необходимость обеспечить обмен оперативной информацией там, где сотовые сети не работают. Нам предстояло отслеживать местонахождение операторов в режиме реального времени, а также передавать информацию об аварийных ситуациях и решать другие задачи.
Это дало нам возможность протестировать данную технологию на практике.
Решение задачи мониторинга
Мониторинг операторов был в приоритете, особенно в удалённых зонах, где сотовая связь не работала. Бизнес предложил протестировать устройство связи, которое на тот момент находилось в распоряжении компании. Под него уже была развернута необходимая инфраструктура. Устройство работало под управлением Android 7.0 и поддерживало работу в сетях стандарта TETRA (TErrestrial Trunked RAdio). Это открытый стандарт цифровой транкинговой радиосвязи, разработанный Европейским институтом телекоммуникационных стандартов (ETSI). Такая технология обеспечивала надёжную связь в условиях отсутствия традиционных сотовых сетей.
С учётом новых задач мы начали разработку мобильного приложения.
Основой для нового приложения стало уже существующее решение с базовым функционалом, а одной из основных задач было обеспечить передачу данных по сети TETRA. Это должно было обеспечить надёжный и безопасный обмен информацией в оперативном режиме, что критически важно для работы на удалённых участках, где связь оставалась нестабильной.
Мы стремились создать приложение, которое соответствовало бы требованиям информационной безопасности, предоставляло пользователям доступ к необходимой информации в любое время и повышало контроль и оперативность реагирования на проблемы.
Три задачи, которые необходимо было решить:
«Подружить» Xamarin-приложение с SDK, написанным на Java.
Реализовать передачу данных по радиоканалу TETRA.
Расширить функционал приложения без изменения архитектуры.
Интеграция SDK с Xamarin.Forms
На первом этапе мы запросили SDK и документацию к нему у производителя мобильных, чтобы глубже понять возможности и ограничения работы устройства в сети стандарта TETRA.
Параллельно приступили к интеграции SDK в приложение на Xamarin. Нам пришлось рассмотреть два подхода к взаимодействию с Java-библиотеками, каждый из которых имел преимущества:
Android Bindings Library (библиотека привязок)
Создание библиотеки привязок позволяет обернуть существующие Java-библиотеки и сделать их доступными для вызова из C#, упрощает их использование и позволяет избежать переписывания кода.
Java Native Interface (JNI)
Этот мощный инструмент для взаимодействия между нативным и управляемым кодом позволяет выполнять поиск типов и членов по имени, читать и записывать значения полей, а также вызывать методы, конструкторы и т.д.
JNI позволяет напрямую работать с низкоуровневыми функциями, недоступными через стандартные АРІ, и рекомендуется в случаях, когда необходимо взаимодействовать с низкоуровневыми API или когда критична высокая производительность.
Каждый из подходов к интеграции имел нюансы. Мы тщательно взвесили все «за» и «против», стремясь не только решить текущие задачи, но и создать основу для будущего сопровождения и развития приложения.
Учитывая опыт работы с типами .NET, мы выбрали первый вариант — Android Bindings Library.
На первых порах казалось, что будет быстро: подключим библиотеки, и всё взлетит. На деле оказалось сложнее. Первые попытки запустить приложение сопровождались ошибками, связанными в основном с известными проблемами Xamarin. Проблем было не просто много, они были разнообразными, что потребовало тщательного анализа и поиска решений. Вот некоторые из них:
Несоответствие версий Java.
Различные версии Java вызывали конфликты, начиная от несовместимости классов до ошибок во время выполнения. Для устранения нужно было убедиться, что версия Java, которую мы используем в приложении, соответствует версии, для которой разработан SDK.
Проблемы загрузки средств привязки.
Возникали ошибки при подключении библиотек. Чтобы их устранить, нужно было тщательно пересмотреть порядок сборки, добавить недостающие зависимости, изменить конфигурацию проекта, чтобы правильно загружались все необходимые компоненты.
Отсутствие зависимых типов C# в выходных данных.
Это приводило к некорректной работе приложения без необходимой типизации. Чтобы устранить проблему, пришлось дополнить конфигурацию привязок и убедиться, что все необходимые типы настроены.
Несоответствие типов параметров в сборке C#.
Повторяющиеся пользовательские типы.
Каждая из этих проблем описывалась в документации, но их повторяемость и рутинность значительно замедляли работу. Мы начали искать более эффективный подход, который позволил бы нам действовать более продуктивно и сократить время на устранение ошибок.
Приняли решение создать обёртку (Wrapper) над SDK. Эта обёртка должна была закрыть более 90% обнаруженных ошибок, сократить рутинную работу, упростить взаимодействие с SDK и абстрагироваться от множества трудностей.
SDK Wrapper: упрощение взаимодействия
К счастью, язык Java и C# имеют схожий синтаксис, это позволило быстро и эффективно разработать обёртку:
Мы понимали, что создание грамотно спроектированного интерфейса существенно повысит удобство и гибкость работы с SDK. Для этого разработали несколько классов, каждый из которых решал конкретную задачу и оборачивал определённые методы SDK.
Мы проектировали классы простыми, интуитивно понятными в использовании, чтобы сосредоточиться на основной логике приложения, не отвлекаясь на низкоуровневые детали.
В случае, если бы мы писали нативное приложение на Android, то могли бы вызывать API напрямую, исключив необходимость создания обёртки.
После изучения документации стало понятно, что устройство поддерживает два способа передачи данных по каналу TETRA.
Пакетная передача данных
У пакетной передачи данных есть преимущества:
Возможность передачи данных в бинарном формате.
Высокая надёжность передаваемой информации.
Хорошая скорость передачи данных.
Для тестирования этого метода мы использовали отдельное мобильное приложение, которое служило платформой для проверки функциональности устройства. С его помощью выявили серьёзные недостатки такого подхода:
Периодические «зависания» модуля передачи данных.
В какой-то момент приложение переставало передавать данные. Это лечилось перезагрузкой устройства. После продолжительных переговоров разработчик устройств признался, что не реализовал этот функционал полноценно и рекомендовал его не использовать, пообещав доработать это в следующих версиях. На 2024 год ситуация не изменилась.
Паразитирующий эффект.
Из открытых источников мы узнали, что пакетная передача данных использует основной голосовой канал. Это могло негативно сказываться на качестве голосовой связи, что в наших условиях было неприемлемо, и мы отказались от этого способа.
Служба коротких сообщений SDS
Следующим этапом решили попробовать передавать данные с помощью коротких служебных сообщений SDS. У этого похода также есть свои плюсы и минусы.
Преимущества:
Собственный выделенный канал связи.
Возможность передачи сообщений в фоновом режиме.
Программная обработка входящих сообщений.
Стабильная работа даже при очень низком уровне сигнала.
Недостатки:
Только текстовый формат данных.
Ограничения на длину сообщений.
Время передачи, около 500ms.
В итоге пришли к выводу, что использование SDS, даже при имеющихся недостатках — наиболее оптимальный вариант.
Реализация передачи данных с помощью SDS
Для реализации передачи данных через служебные сообщения SDS мы использовали уже существующее приложение, основанное на классической схеме через Web API. Для поддержки передачи данных по каналу стандарта TETRA потребовались доработки.
Доработки включали разработку дополнительного программного обеспечения, способного регистрироваться на сервере TETRA в качестве полноценного клиента и обеспечивать коммуникацию с внешними сервисами.
Изначально все данные в сервисе передавались в формате JSON. Однако этот формат не подошёл для SDS из-за избыточности, ведущей к увеличению объёма трафика. Полный переход на более эффективные форматы, такие как gRPC, потребовал бы значительных усилий.
Возникла необходимость в решении, которое позволит уменьшить объём передаваемых данных без кардинального изменения архитектуры. Мы реализовали передачу данных таким образом, что любой объект передаваемый по каналу TETRA, упаковывается в разработанный нами бинарный формат, убирая всю избыточность JSON. Сжатие определёнными алгоритмами позволило уменьшить объём передаваемых данных.
Для достижения максимально эффективного использования служебного канала при передаче сообщений были разработаны вспомогательные классы. Их задача — обеспечить нарезку больших объёмов данных на небольшие пакеты.
Процесс включает следующие этапы:
При формировании запроса на сервер приложение создаёт объект.
Объект преобразуется в бинарный вид, затем кодируется в формат Base64.
Закодированные данные нарезаются на сегменты.
Каждый сегмент преобразуемся в SDS-сообщение и отправляется серверному приложению.
Далее покажу структуру каждого сообщения и способ расчёта длины.
Серверное приложение принимает SDS-сообщения, собирает сегменты в единый массив, преобразует его обратно в объект запроса, выполняет его и ожидает ответа.
При получении ответа от сервиса происходят все манипуляции с объектом ответа в обратном порядке:
Ответ преобразуется в бинарный формат, кодируется в Base64.
Данные сегментируются и преобразуются в SDS-сообщения.
Готовые сообщения отправляются обратно на устройство.
Обработка данных на мобильном устройстве происходит по тому же алгоритму.
Полученные сегменты преобразуются обратно в объекты ответа и передаются следующему слою приложения. В итоге ответ доходит к приложению как бы от классического API, реализованного ранее. Это позволило не переписывать полностью API и мобильное приложение.
Каждое SDS сообщение представляет собой структуру, преобразованную в строковое представление Base64. Эта структура включает:
Метаданные: информация о сообщении.
Полезная нагрузка: массив байт данных.
Длина одного SDS-сообщения составляет 104 байта.
Преобразование массива байт в формат Base64 накладывает свои ограничения, так как длина сообщений возрастает приблизительно на 30%, и считается по формуле:
(ClientSidePackageSize−HeaderSize)68=73.573 байта полезной нагрузки
Например, если длина запроса, преобразованного в Base64, составляет 255 байт:
255733.5 4 SDS сообщения (округление до большего целого)
Если длина ответа, преобразованного в Base64, составляет 1 килобайт, то на устройство надо отправить 15 SDS сообщений.
Следующим этапом стала оптимизация передачи данных геопозиционирования с мобильных устройств на сервер без потери качества. Для этого написали вспомогательные классы, которые переводят набор координат в набор смещений относительно опорной точки. То есть, в сообщение отправляется одна координата плюс набор смещений по осям и времени.
Преобразование набора координат в смещения работает так:
Приложение в фоне собирает координаты в течение одной минуты.
Формирует запрос, тело которого содержит модель вида:
Координата 1 — полноценная опорная координата, которая содержит данные по широте, долготе и заряду батареи. Это 8 байт на широту, 8 байт на долготу, 8 байт на дату/время и 1 байт на заряд батареи, итого получаем длину одной координаты 25 байт.
Относительно опорной координаты формируется набор смещений в метрах по широте и долготе в диапазоне от −127 до 127 метров, так как мы использовали знаковый байт (sign byte).
Получаем, что 1 байт — это смещение по широте, 1 байт — смещение по долготе, 1 байт — смещение по времени в секундах и 1 байт — заряд батареи, в итоге 4 байта на одну запись смещения.
В случае выхода значений за пределы допустимых, то есть если смещение по широте или долготе выйдут за пределы 127 метров, начинаем формировать новый запрос по тому же алгоритму: берём текущую координату и формируем смещение относительно неё.
Выводы
В условиях отсутствия пакетной передачи данных в сетях связи можно успешно применять нестандартные методы передачи информации. Одно из таких решений — использование текстовых сообщений в качестве транспорта данных. Однако надо учитывать, что данный метод имеет свои ограничения и нюансы — скорость, ограничения по объёму данных и др.
Решение с небольшими доработками можно масштабировать для использования в качестве транспорта данных стандартных SMS-сообщений, которые предлагает практически любой оператор связи. Стоит также учитывать требования и ограничения подхода со стороны сотового оператора.
Разработка мобильного приложения «АРМ-оператора» позволила не только решить ранее существовавшие проблемы, но и реализовать ряд важных задач:
Распределение поступающей информации между потребителями (журналы, модули, программы).
Автоматизация выдачи заданий операторам.
Повышение уровня контроля исполнительной дисциплины.
Полный отказ от бумажных носителей.
Контроль за передвижением операторов в режиме реального времени.
Фиксация скорости передвижения операторами на средствах малых механизаций.
Увеличение скорости реакции на аварийные ситуации.
Приложение позволяет операторам получать всю необходимую информацию о скважине прямо у объекта. С помощью приложения они могут планировать свой рабочий день, а руководство — контролировать выполнение задач.
Поручения направляются в автоматическом режиме операторам на смартфон. Это позволяет контролировать рабочий график и отслеживать перемещения.
«АРМ-оператора» защищён патентом и стал лауреатом всероссийского конкурса «100 лучших товаров России 2021 года» в номинации продукции производственно-технического назначения, лауреатом конкурса «Лучшие товары и услуги Республики Татарстан 2021 года», а также получил диплом конкурса «Лучший экспонат, проект или техническое решение» в рамках ТНФ-2021.