Умная платформа | Большие Идеи

・ Технологии


Умная платформа

Как компания ЛУКОЙЛ оптимизирует нефтедобычу с помощью машинного обучения

Авторы: Андрей Скобеев , Антон Аристов , Владимир Рогов , Данис Маганов , Леонид Жуков

Умная платформа
Иллюстрация: Jorg Greuel / Gettyimages

читайте также

Переговорный тупик: что делать, если вы не можете договориться

Станислав Мартынов

Хотите понять, что чувствуют клиенты? Станьте клиентом сами

Адам Грант,  Эрин Хенкель

С гарвардом в башке

Евгения Чернозатонская

«Они инновации пекут как пирожки»

Александр Воробьев/"Ведомости"

В управлении производственным процессом программы машинного обучения пока редки, хотя именно такие системы сулят наибольшую выгоду. Искусственный интеллект уменьшает влияние человеческого фактора и нагрузку на операторов, позволяя аккумулировать, стандартизировать и распространять накопленный опыт управления комплексом оборудования. В нефтедобывающей компании ЛУКОЙЛ установили программу, которая позволяет уменьшить простои и оптимизировать режим техобслуживания и работы дорогостоящего оборудования на нефтяной платформе.

Сейчас мало кого надо убеждать в том, что искусственный интеллект (ИИ) способен выводить компании на новый уровень эффективности.

В опросе, проведенном в конце 2017 года Школой бизнеса Слоуна и BCG в 112 странах и охватившем более 3 тыс. руководителей компаний из 21 отрасли, три четверти респондентов признавали, что ИИ — мощный инструмент создания конкурентного преимущества. Однако при всей поддержке и понимании руководства собственная система ИИ, пусть даже совсем скромная, была лишь у каждой пятой компании. А если взять отдельно крупнейшие бизнесы (с численностью сотрудников более 100 тыс.), то на этот момент исследования стратегия развития ИИ была у половины, но опыт внедрения — лишь у каждой четвертой.

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

Основных причин отставания в «интеллектуализации» операционной деятельности три. Во-первых, выбирая сферы для внедрения ИИ, компании предпочитают относительно малорисковые: инвестируют в проекты не слишком большого масштаба, которые в случае неудачи не лягут тяжким бременем на бюджет. Во-вторых, для непроизводственных функций, таких как HR, существуют готовые «коробочные» ИИ-решения, а для производственной системы все приходится делать заново «под себя», привлекая сторонние компании. Дело усугубляется еще и тем, что разработанные и уже внедренные производственные ИИ-решения требуют регулярной калибровки, а нередко и дообучения моделей. Чтобы справиться с этой задачей, приходится создавать внутренние подразделения аналитики больших данных (отделы data science). Не все компании хотят и могут это осуществить.

В статье мы расскажем о том, как крупнейшая частная нефтяная компания России ЛУКОЙЛ решила встроить искусственный интеллект в управление нефтяной платформой, какие ресурсы для этого понадобились и какие результаты были достигнуты за первые полтора года работы.

ИДЕЯ КОРОТКО

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

Каспийский проект

Современная морская нефтяная платформа — очень дорогое предприятие. Бóльшую часть рукотворного острова на шельфе занимает оборудование, которое закупают у разных производителей. Строительство и запуск любой платформы требует крупных инвестиций, и чтобы их оправдать, нужно обеспечить соответствующий объем добычи. Как правило, он сопоставим с общей производительностью сотен традиционных континентальных скважин, таких, например, как известные месторождения Западной Сибири.

Размещенное на морской платформе дорогостоящее оборудование должно бесперебойно работать днем и ночью в самых разных погодных условиях: летний зной, высокая влажность, зимнее оледенение, шторм — и выдерживать большие перепады температуры воды и воздуха. Мониторинг состояния агрегатов ведется постоянно: каждый узел оборудован множеством датчиков. Производители прописывают условия периодической профилактики своего оборудования (а разных производителей на платформе несколько сотен) — чистку, замену деталей и проч. На время планового профилактического техобслуживания (ТО) работу приходится приостанавливать, что всякий раз означает потерю определенного объема добычи. Если же произойдет поломка и потребуется внеплановый ремонт, платформа остановится на неопределенный срок. Каждый час простоя чреват недобором нескольких сотен тонн нефти, а совокупные денежные потери на ТО и последствия сбоев могут исчисляться десятками миллионов долларов в год.

Владельцы и операторы морских платформ крайне заинтересованы в минимизации потерь. Можно ли оптимизировать режим так, чтобы на техобслуживание агрегатов в совокупности уходило меньше времени? Какую роль играют условия эксплуатации? Зачастую нормативы ТО производитель задает для усредненных условий эксплуатации, а на конкретной платформе они могут быть совершенно иными. В идеале нужна система, которая в текущем режиме агрегировала бы данные о состоянии оборудования и с учетом этой информации определяла бы реальную необходимость в ремонтно-профилактических работах. Тогда, возможно, простои удалось бы сократить. В разных отраслях — от энергетики до автомобилестроения — говорят о «техобслуживании оборудования на основе ИИ», стремясь предотвратить как выход узлов из строя, так и необоснованные простои. Для дорогостоящей «нефтянки» такие решения особенно привлекательны.

Другая задача, которую хотелось бы поручить ИИ, — в режиме реального времени выдавать комплексную сводку о состоянии платформы в целом — своего рода «индекс здоровья». Чтобы уровень добычи в каждый промежуток времени был оптимальным, операторам важно знать не только «самочувствие» комплекса в настоящий момент, но и то, как он может повести себя в ближайшие полчаса или час, в частности, чтобы решить, допустим ли вывод на более интенсивный режим работы. Простая аналогия: так спортивные врачи смотрят на кардиограмму спортсмена, чтобы определить, можно ли его нагружать больше.

«Индекс здоровья» агрегирует данные с помощью инструментов предиктивной аналитики. Нет аномалий — индекс высокий, а при их появлении он сразу понижается. Это интегральная метрика, описывающая общее состояние платформы, помогающая избегать как перегрузок, так и недогрузок. Она должна быть понятной и инженерам, и топ-менеджерам компаний.

Идея применения искусственного интеллекта и больших данных для оптимизации работы платформы, казалось бы, лежит на поверхности. Тем не менее в мире насчитываются лишь единичные случаи внедрения цифровой аналитики в нефтегазовой отрасли. (Норвежская нефтяная компания Equinor в 2018 году сообщила о создании Интегрированного операционного центра (IOC) для централизации сбора данных, улучшения процесса принятия решений и увеличения добычи; до 2020-го в него будет инвестировано более $200 млн.)

В создании подобной системы была заинтересована и компания ЛУКОЙЛ — для своих морских платформ, добывающих нефть на Каспийском шельфе. Но, прежде чем приступать к работе, нужно было понять, как собрать команду, способную поднять такой проект. На рынке существуют стартапы, обладающие знаниями и навыками в области машинного обучения, но, во-первых, для построения моделей необходимо разбираться в производственном процессе. Во-вторых, при разработке нельзя обойтись без тестирования и интегрирования системы с «живым оборудованием», что требует допуска на действующие промысловые объекты. Ни одна крупная компания не пойдет на риск и не доверит вчерашним победителям олимпиад реальное оборудование и ответственность за результат, который может принести как миллионы прибылей, так и огромные убытки. Поэтому большинству стартапов в сфере аналитики попросту негде набраться опыта, специфического для нефтяной отрасли. И кроме того, даже для лабораторного тестирования разработчикам требуются большие объемы данных с реально работающих предприятий, а компании делятся такими данными очень неохотно — информация слишком значима. Ее анализ может быть использован в целях коммерческого шпионажа. Чтобы вести проект ИИ на своей нефтяной платформе, ЛУКОЙЛ нужен был партнер, не только обладающий специальными компетенциями в нефтегазовой сфере, но и такой, которому компания полностью бы доверяла. Таким партнером оказалась ALMA Services Company — стартап, основанный выходцами из нефтегазовой отрасли, у которого уже был опыт сотрудничества с крупными компаниями. В сфере цифровой аналитики большие проекты часто выполняются силами стартапов типа spin-off (отделившиеся от материнской компании подразделения, специализированные в какой-либо актуальной сфере). ALMA Services Company была задумана как интеграционная площадка для сложных ИT-проектов в нефтегазовой отрасли.

В реализации проекта партнерами ALMA Services стала консалтинговая компания BCG, причем особая роль отводилась специалистам BCG Gamma (подразделение, специально созданное для ведения ИИ-проектов). Дополнительно к проекту привлекли специалистов Инжинирингового центра МФТИ по трудноизвлекаемым полезным ископаемым, а также нескольких отраслевых экспертов — людей, профессионально разбирающихся в динамическом оборудовании и разработке нефтегазовых месторождений. Всего в команде собрались 15 специалистов с самыми разными компетенциями. Разрабатываемая система получила название Digital ASTRA. Первое слово не нуждается в пояснениях, а второе несет сразу два смысла. Оно, с одной стороны, привязано к географии (центр управления нефтяными платформами ЛУКОЙЛ находится в Астрахани), а с другой — отражает энтузиазм авторов проекта (латинское Astra означает «звезда»).

Главная задача специалистов по данным (data science) — создать модели, способные по информации, поступающей с оборудования в режиме реального времени, определять его техническое состояние и предсказать возможные поломки узлов и отказы в ближайшем будущем. Для обучения модели (установления причинно-следственных связей) необходимы массивы данных, снятых с датчиков за длительные периоды работы в прошлом, а также сведения о поломках и проведенных ремонтах и техническом обслуживании. Поэтому на практике любой аналитический проект начинается с запроса у клиента так называемых исторических данных. Их приходится собирать с систем разных производителей, а это значит, что данные хранятся в разных форматах и передаются по разным протоколам. Перед моделированием они требуют очистки и консолидации.

Программисты применяют подходы эджайл, то есть ведут разработку циклически. Вначале создают продукт с минимальным необходимым функционалом (MVP), а потом его постепенно наращивают. После отладки систему запускают на сервере компании-заказчика, и в дальнейшем ее поддержкой занимаются ИТ-подразделения заказчика.

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

КОМАНДА РАЗРАБОТЧИКОВ: РАСПРЕДЕЛЕНИЕ РОЛЕЙ И ФУНКЦИОНАЛА СРЕДИ УЧАСТНИКОВ ПРОЕКТА Digital ASTRA

ALMA Services Company взяла на себя формулирование задачи в целом, обоснование ее актуальности в компании ЛУКОЙЛ и взаимодействие с производственными подразделениями нефтяной компании.

BCG Gamma занималась сбором, обработкой и анализом больших данных и разработкой и обучением моделей предсказания поломок оборудования на основе алгоритмов машинного обучения.

Cпециалисты из Инжинирингового центра МФТИ разрабатывали софт и ИТ-архитектуру. Они же занимались интеграцией интеллектуального софта Digital ASTRA c сервером заказчика, на который поступают данные с платформы.

Дизайном пользовательского интерфейса, вопросами доступности и удобства системы для пользователя озаботились соответствующие специалисты — UI/UX дизайнеры из BCG. Чтобы взаимодействие с системой было максимально комфортным, они продумывали интерфейс Digital ASTRA в мельчайших деталях, проводили множество интервью с будущими пользователями.

Консультанты BCG взяли на себя проработку общего подхода, проанализировали технологические процессы и провели серию интервью, чтобы выявить самые насущные потребности операторов платформы. Консультанты занимались общей координацией процессов в команде, направляя ее деятельность в общее русло и обеспечивая непрерывное взаимодействие с заказчиком.

Отраслевые эксперты — люди, профессионально разбирающиеся в вопросах нефтедобычи, геологии нефтяных месторождений, в тонкостях эксплуатации и обслуживания нефтегазового оборудования, консультировали прочих членов команды.

Коммуникация

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

В Digital ASTRA было принято принципиальное решение: все эти люди со всеми своими «профессиональными деформациями» и разными подходами должны работать в одном помещении. Это помогало им чувствовать себя членами одной команды, сформировало общий контекст — в ходе работы они могли слышать, какие вопросы и проблемы обсуждаются внутри отдельных групп специалистов, лучше понимали специфику составляющих проекта, могли на месте проконсультироваться друг с другом. На ежедневных утренних совещаниях — «стендапах» — каждый член команды кратко рассказывал, что сделал накануне и что запланировал на сегодня. Это помогало не задерживаться на какой-либо проблеме слишком долго — ежедневное упоминание о ней во время стендапа психологически мотивировало всех к поиску решения. В соответствии с принципами эджайл команда поддерживала постоянный контакт с клиентом. В Москве работу вели в одном из офисов ЛУКОЙЛ, и это также мотивировало исполнителей. Кроме того, команда регулярно выезжала в Астрахань и постоянно контактировала с операторами платформы.

По словам одного из участников, на проекте все стороны стремились «построить отношения на человеческом уровне». Члены команды понимали, что они в определенном смысле вторгаются на территорию нефтяников как некий чужеродный элемент, «белые воротнички». Они отдавали себе отчет в том, что им предстоит доказать на деле, что им можно доверять.

«Мы старались детально разобраться в процессах сепарации нефти и компримирования газа. Учитывали график работы операторов, звонки старались планировать как можно позже, ночью, поскольку днем на платформе много дел, связанных с обслуживанием оборудования», — говорит один из членов команды. В целом, по его словам, «контакт был налажен быстро, можно сказать, что взаимопонимание шло без затруднений».

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

На стороне заказчика

В основе проекта лежат большие данные. Но, если в рамках традиционного консалтингового проекта клиент обычно просто передает необходимую информацию в готовом виде на съемном носителе, то получить большие данные со сложного оборудования не так просто. Для начала нужно понять, какие данные есть в принципе, какие из них значимы для проекта, какие технологии нужны для их анализа и что мы рассчитываем из них узнать. В Digital ASTRA, в частности, выяснилось, что далеко не все показатели датчиков на оборудовании нефтяной платформы вообще можно экспортировать — многие архивируются уже спустя неделю после их регистрации и хранятся в закодированном виде, а для раскодирования требуется ключ от производителя.

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

В качестве «опытного полигона» для предварительного обоснования бизнес-кейса ЛУКОЙЛ предложил использовать данные с морской ледостойкой стационарной платформы, которая ведет добычу на месторождении имени Юрия Корчагина. Она функционирует с 2010 года и за время ее эксплуатации были накоплены терабайты информации, полученной с датчиков оборудования и зафиксировавшей, в частности, ряд технологических сложностей. Эти данные были использованы для обучения и тестирования моделей искусственного интеллекта, для выработки основных гипотез по оптимизации техобслуживания и предотвращению внеплановых остановок.

Данные с платформы на месторождении имени Юрия Корчагина были получены весной 2018 года, и команда сразу приступила к их анализу. В июле первые результаты показали заказчику. В ЛУКОЙЛ оценили объемы недобора нефти из-за технических неполадок и неоптимального режима. Появилось понимание того, что их можно снизить с помощью «подсказок» от ИИ.

Ознакомившись с итогами первой фазы проекта, заказчик предложил внедрять систему на другой, сравнительно молодой платформе, которая ведет добычу на месторождении имени Владимира Филановского. Эта платформа была введена в эксплуатацию в октябре 2016 года, а на проектную мощность вышла непосредственно перед презентацией бизнес-кейса — во втором квартале 2018-го. Клиент решил, что ИИ позволит превентивно отработать «детские болезни» оборудования и принять необходимые профилактические меры.

С сентября 2018 года команда приступила к работе на платформе месторождения имени Владимира Филановского. Через три месяца команда разработала пробную версию и поставила ее на сервер заказчика. А перед Новым годом для клиента провели официальную презентацию. Это был рабочий прототип, который позволяет анализировать поступающие данные и в тестовом режиме за 15—45 минут предупреждать оператора о возможных отклонениях — ситуациях, когда показатели могут выйти за пределы нормативных. В принципе этого времени достаточно, чтобы оператор успел скорректировать режим работы оборудования. Интерфейс системы помогает оператору платформы и менеджменту следить за ситуацией в режиме реального времени на экране любого устройства (компьютера, смартфона или планшета), подключенного к корпоративной сети.

Участникам официальной презентации запомнился один момент. Было решено продемонстрировать руководству работу прототипа в режиме реального времени с подключением к корпоративному серверу, который получает данные с платформы. Интерфейс Digital ASTRA был выведен на экран планшета одного из представителей заказчика. Неожиданно все увидели, что индекс здоровья одного из компрессоров резко пошел вниз — признак того, что в работе данного агрегата произошел какой-то сбой. Разработчики занервничали, испугавшись, что прототип работает некорректно. Представитель компании тут же позвонил на платформу и попросил доложить, что происходит. Выяснилось, что там началась плановая разгрузка именно этого компрессора, чем и обусловлено изменение показателей. Таким образом, система абсолютно правильно отреагировала на изменения и своевременно проинформировала о них оператора. Это был момент истины: заказчику наглядно продемонстрировали, что инструмент работает.

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

Внедрение ИИ в производственные системы: главные уроки

1. Сбор данных на подобных проектах — это трудоемкий и плохо автоматизируемый этап. На Digital ASTRA с момента официального запроса до начала получения самих данных прошло полтора месяца. Исторические данные о работе оборудования были архивированы на платформе, и, чтобы не нагружать каналы связи, жесткий диск с сотнями гигабайт данных был доставлен вертолетом. Для его разархивирования и расшифровки пришлось задействовать значительные вычислительные ресурсы.

2. Команда ставит перед собой задачу преобразовать управление платформой с помощью инструментов предиктивной аналитики. Такой команды в готовом виде на рынке не существовало, и ее пришлось формировать как коллаборацию весьма разнородных организаций.

При таком многообразии довольно сложно бывает наладить единый процесс. Роль связующего звена, направляющего усилия всей команды к цели, взяли на себя консультанты BCG. В подобных проектах жизненно необходим отлаженный рабочий контакт с коллегами на стороне клиента. Для того чтобы досконально изучить все особенности производства и собрать данные, учитывая все тонкости, команда приезжала не только в офис клиента в Астрахани, но и непосредственно на платформу, работая бок о бок с нефтяниками.

3. Интеграция в бизнес зачастую является слабым звеном проектов ИИ. Необходим исполнитель, который понимает бизнес, обладает техническими навыками и может говорить и на языке инженеров, и на языке управленцев. Такой исполнитель способен не только строить модели, создающие ценность для бизнеса, но и прототипировать, внедрять и масштабировать найденные решения. У BCG Gamma накоплен большой опыт разработки специализированных ИИ-решений для амбициозных масштабных задач. Подразделение действует глобально, и по его оценкам в сфере ИИ, собственно расширенная аналитика дает 10% добавленной ценности, 20% приходится на технологии, а остальные 70% связаны с управлением изменениями. Решение должно стать продуктом, которым пользуются на всех уровнях компании, от руководства до машиниста, ведь настоящая ценность создается, когда с ИИ сверяются и по нему ведут планирование. В данном проекте нужно добиться того, чтобы профилактика оборудования исходила не из старых графиков ТО, а из «Индекса здоровья».

4. Дизайнеры делают систему понятной и удобной для пользователей. В современном мире любая разработка должна начинаться с работы дизайнера, который стремится наглядно представить разработчикам опыт разных групп пользователей. В этом проекте работа дизайнеров была особенно интересной, потому что в промышленности не очень-то принято думать о том, насколько наглядны и удобны интерфейсы, если речь идет не о покупателях, а об операторах оборудования. Привнести в жесткий мир машинистов, обслуживающих платформу, правильный дизайн и эргономику, тем самым увеличив эффективность и безопасность их работы, — новая и достойная задача, ведь прежде об этой категории пользователей мало кто думал.

5. Машинное обучение не только снижает потери из-за простоев. Оно уменьшает влияние человеческого фактора и нагрузку на операторов. Зависимость работы нефтяной платформы от их профессионализма очень велика — зачастую только огромный опыт помогает оператору выбрать нужный режим работы оборудования, ориентируясь не только по показаниям приборов, но и по звуку. В недавней публикации газеты Telegraph директор по технологиям BP Дэвид Эйтон признался, что на месторождении Azeri-Chirag-Deepwater Gunashli (тоже на Каспийском шельфе) есть всего один эксперт, способный решать проблему высоких примесей песка в добываемой на месторождении нефти. Внедрение систем искусственного интеллекта — шаг к тому, чтобы передать компьютеру подобные сокровенные знания, уменьшить число людей, которые в тяжелейших условиях трудятся на нефтяных платформах, и создать условия для появления полностью безлюдных автоматических нефтяных платформ.

Об авторах. Андрей Скобеев — заместитель генерального директора ЛУКОЙЛ-Нижневолжскнефть. Данис Маганов — генеральный директор ALMA Services Company. Владимир Рогов — партнер и управляющий директор BCG. Антон Аристов — директор BCG. Леонид Жуков — директор BCG Gamma.