ProductionPro

Оператор месторождения объезжает скважины и вручную записывает показания: уровень в резервуаре, данные счётчика, сколько нефти забрал бензовоз. Бумажные записи переносят в систему позже, часто не тот человек, который был на объекте. На каждой передаче данных накапливаются ошибки.

ProductionPro (ProductionPro LLC, Плано, Техас) перенёс этот процесс в планшет. CimpleO разработала приложение под Android.

Задача

Маршрут оператора за день проходит через десятки лизинговых участков (leases), у каждого свои скважины, резервуары и счётчики. Приложению нужно было работать офлайн, поскольку на месторождении сотовая связь нестабильна, и при этом привязывать каждый замер к нужной скважине, резервуару и времени после синхронизации. Плюс конкретная документация отрасли: замеры резервуаров, показания счётчиков, путевые листы (run tickets) на вывоз нефти и записи о том, куда она делась дальше (disposition).

Готовая форм-платформа сюда не ложится. Замер резервуара требует объёмов на открытие и закрытие плюс показатель BS&W (basic sediment & water, «осадок и вода»): это реальная промысловая единица измерения, не придуманное поле. Путевой лист должен сверяться с резервуаром, из которого забрали нефть. У контактов и компаний своя иерархия: у одного участка может быть несколько совладельцев, которых нужно уведомлять.

Что построили

Полевой ввод данных. Экраны для внесения замеров резервуаров, показаний счётчиков и путевых листов, каждый привязан к конкретному участку, скважине и резервуару. Раскатной 45-дневный календарь на экране ввода красит каждый день красным, жёлтым или зелёным по мере заполнения замеров по всем участкам оператора: и оператор, и офис на той же картинке в веб-панели сразу видят, что ещё не сделано. Отдельный экран правки замеров (rewrite gauges) позволяет вносить исправления постфактум, не ломая историю: приложение сохраняет исправленную запись как новую пронумерованную ревизию (-r1, -r2…) с датой исходного отчёта, а не датой правки, и вся история ревизий остаётся видна в Gauge History.

Иерархия участков и объектов. Участки содержат скважины, скважины наполняют резервуары, резервуары читают через замеры и опустошают через путевые листы. Модель данных (lease, wells, tank, tank_height, gauges, meter_data, meter_run) повторяет реальную структуру бизнеса на месторождении, а не список площадок в один уровень. Один оператор может быть привязан сразу к нескольким компаниям-заказчикам: логин возвращает массив компаний, у каждой свой токен доступа, так одно устройство обслуживает подрядчика, качающего сразу для нескольких операторов месторождения.

Вывоз и учёт disposition. Экран disposition фиксирует, куда ушла вывезенная нефть: какому покупателю, каким бензовозом, и замыкает цепочку от резервуара до продажи. Экраны pickup и истории дают офису видимость по каждому вывозу без звонка в поле.

Контакты. Отдельный модуль контактов и компаний с привязкой контактов к конкретному участку и разбивкой по типу (покупатель нефти, покупатель газа, поддержка приложения, поддержка планшета). Нужный диспетчер или служба поддержки всплывают автоматически, вместо того чтобы оператор искал номер телефона.

Постановка задач. Помимо замеров офис может ставить оператору задачи напрямую. GetTasks подтягивает открытые задачи по всем участкам оператора на ближайшие 14 дней, с флагом важности, а ChangeTaskStatus даёт оператору отметить задачу выполненной или отклонённой. Сервер отклонит обновление, если задачу уже забрал кто-то другой, она уже закрыта или отменена офисом за это время.

Отчёты по добыче. GetProduction отдаёт 45 дней ежедневных объёмов нефти, воды и газа по каждому участку. Эти данные питают экран Lease Daily Production, свайпаемый график добычи по дням, который оператор смотрит прямо в поле, а видит те же цифры, что и офис в отчётах веб-панели.

Офлайн-синхронизация. Приложение построено на Titanium Alloy и работало на Samsung Galaxy Tab: планшет выбрали под полевые условия. Каждый замер, показание счётчика и запись истории кешируются в локальной базе SQLite (Ti.Database); модуль синхронизации FirstStart и модель cold_start сверяют локальное хранилище с REST API компании при восстановлении связи, точечно удаляя и перезаписывая отдельные строки замеров, а не сбрасывая весь кеш целиком. Сам API принимает только POST-запросы с JSON-конвертом ({success, errorMessage, data}), а самые тяжёлые методы (GetLeases, GetGauges, GetContacts, GetRunTicketPhoto) поддерживают условные запросы через заголовки Last-Modified/If-Modified-Since: при плохой связи планшет получает 304 Not Modified вместо повторной загрузки всего массива данных.

Синхронизация по push-команде. Офис не ждёт очередной плановой синхронизации. ProductionPro использует GCM, чтобы отправить команду прямо на устройство (GetGauges, GetContacts, GetLeases, GetDeviceState), и CommandManager на телефоне выполняет нужное обновление сразу по приходу push-уведомления, без перезапуска приложения.

Удалённая блокировка устройства. Если телефон потерян или нужно закрыть доступ подрядчику, офис помечает устройство на сервере. Следующая проверка GetDeviceState обращается к эндпоинту IsBlocked, который возвращает отдельный код ошибки (9898, «Device is locked») вместо общей ошибки; приложение в ответ показывает полноэкранное уведомление с отключённой кнопкой «назад» на Android, и устройством нельзя пользоваться, пока офис его не разблокирует.

Удалённая диагностика. Уровень логирования на любом устройстве настраивается удалённо: ErrorLevel сообщает конкретному устройству (по ID, модели и версии ОС), работать ли на уровне Debug, Info, Warning или Error, а SendError отправляет лог ошибок этого устройства на сервер. Поддержка может включить подробное логирование на планшете конкретного оператора в поле, не выезжая на объект.

Переключение окружений. Экран настроек позволял направить устройство на продакшн-API, стейджинг-окружение или кастомный сервер, с переключаемой проверкой SSL для каждого. Одна и та же сборка обслуживала активную разработку, приёмку у клиента и работающий в поле парк устройств одновременно.

Разработка

Приложение выпустили за три месяца (апрель–июль 2014 года): 612 коммитов, несколько фиче-веток (замеры, контакты, фоновая синхронизация) разрабатывались параллельно и вливались в master. Приёмочное тестирование шло параллельно и продолжалось уже после последнего коммита, на смеси Samsung Galaxy S2, S3 и Tab. Календарь с цветовой индикацией, офлайн-очередь, ревизии замеров и валидация выше — это как раз то, что ловило это тестирование.