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 использует Appcelerator Cloud Services и 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. Приёмочное тестирование шло параллельно и продолжалось уже после последнего коммита: около 50 зафиксированных раундов тестирования с конца апреля по начало сентября 2014 года, на смеси Samsung Galaxy S2, S3 и Tab. Отслеживаемый процент прохождения тестов стартовал с 38% в первом раунде и вышел на 90–100% к последним — календарь с цветовой индикацией, офлайн-очередь, ревизии замеров и валидация выше как раз и есть то, что эта матрица ловила.