By Kevin Fox; Matt Hackworth, SPE; Alex Salinas; Alex Lach, SPE; and Qian Li, Occidental Petroleum
This article describes how Oxy developed an in-house application to handle critical production operations tasks including surveillance, optimization, downtime entry, and well testing. The application, called Nexus, includes all real-time well data, an analytics platform, closed-loop control, and the automated field processes needed for the daily operation of Oxy’s 27,000 active producers and injectors. Used monthly by more than 50% of Oxy’s US onshore employees and daily by 10%, Nexus allows well analysts and production engineers to manage twice the number of wells they were able to manage just 5 years ago; thus, it has become critical to Oxy’s operating success.
Oxy’s ESP Problem
In 2013, Oxy had 2,000 electrical-submersible-pump (ESP) and 8,000 beam-pump wells. Oxy had an agreement with an oilfield service company to pay $27 million over 5 years to analyze the ESPs using the vendor’s ESP surveillance system. In addition to this high cost, the total ESP failure cost was double that of all the beam-pump wells, even though there were four times as many beam pumps. Communication between the vendor and Oxy was inefficient through email and phone calls.
After Oxy noticed an ESP failure, it was difficult to view the well history because the available well-management software only stored daily averages after 30 days and was slow to use. Additionally, the analytics in software were not sufficient to manage wells by exception. Oxy decided to manage its wells directly and looked for solutions to manage these wells with fewer than 30 users.
Starting Small and Agile
Oxy executives decided to develop a custom solution with a project that would be led from inside the oil and gas production operations department. The core team of one developer and one business lead started a search for commercially available software. After an extensive review, they concluded that the available commercial software could not create exceptions and surveillance plots for more than 6,000 wells. They decided to use OSI PI and a customized application that eventually would become known as Nexus. The Nexus team had full support from the information technology department, the automation team, the business units, and the central engineering group.
From the start the team knew that designing a complicated application like this completely right away was impossible. Thus, the Nexus team used the agile approach, where solutions were provided to the end users before they were complete and designs were adjusted based on their feedback. This iterative approach was used from Day 1 and continues through today, creating a culture among the development team and the application users of continuous improvement to both the application and the business processes in operations.
The first step was expanding the use of OSI PI and developing a tag naming and data standard. Once the tag data were available, the Nexus team developed plots using an OSI PI SharePoint plugin and exceptions using the Oracle database. Functionalities that the ESP well analysts especially liked included the ease of use through their browser, identification of exceptions, the ability to clean up OSI PI data, integration of data from Oxy’s databases, an action tracker, an equipment inventory, dashboards, and integrations with third-party tools. Well analysts used the tool and improved the data. Engineers started using the tool when they realized that Nexus used an open data model and the data collected for Nexus could be used for other projects.
Initial Results
Nexus started delivering value as soon as it was implemented. For example, in 2013, Nexus users found that one ESP was turning in the wrong direction. The direction was reversed in October 2013, and pump intake pressure started decreasing, which increased production and avoided a failure. Right away, it was clear that Nexus would be an important part of the people, process, and technology that would make Oxy successful.
In 2015, Oxy saved $27 million dollars by terminating a 5-year contract for an outside party to manage ESPs. At the same time, ESP runtime increased by 13%. In 2016, gas-lift wells were added to Nexus, which increased production by 3,500 BOPD because of offline production that was not visible in any other system. Bringing on that offline production allowed management to see that Nexus was not just for managing ESPs but could improve all production operations. At this point, the Nexus application worked well for gas lift and ESPs, but it was dependent on SharePoint and an OSI PI plugin, which had a limited life span. Additionally, it was built by one in-house developer with no backup. Oxy had to decide if Nexus was going to be a core solution or if it was going to be a fringe tool that could be allowed to wither away.
Nexus: A Core Solution With Added Capability
After reviewing Nexus’ performance, Oxy executives identified Nexus as the core data source for surveillance and exceptions for gas lift and ESPs and deemed it the future solution for other artificial lift types. The first official funding for Nexus came in 2017 with a multiyear budget and a 12‑person development team. This allowed Nexus to be redesigned as an enterprise application using standard Microsoft on-premise servers as well as the cloud with the same code that vendor applications use to pull and show data from OSI PI. Additionally, this team had the resources to focus on uptime and had backup when a developer was unavailable. Fortunately, the business owner and developer from the initial project stayed on and continued to grow the user relationships that allowed the first version of the tool to be agile and successful.
What Is Nexus?
Nexus has 850 unique daily users monitoring 27,000 wells. It is used monthly by over 50% of Oxy’s US onshore employees and daily by 10%. It is the main source for well analysts and operators to
- Control wells via the Open Platform Communications standard and surveil with real-time data and alarms
- Set up automated well tests and approve automated and manual well tests
- Manage automated and manual downtime entry
- Track overall field operations with notes, equipment documentation, artificial lift analysis, fluid analysis, workover history, and treatment history
Nexus is a custom application developed on standard Microsoft servers. Exceptions, closed-loop control, and advanced analytics all run in Python. Complex visualizations are accomplished through embedded Spotfire reports. Nexus is hosted in Microsoft Azure. Each screen loads in a few seconds or less, making it possible for an analyst to act quickly and move on to the next well.
Advanced Artificial Lift Analysis
Oxy’s data analytics teams have worked with Oxy’s artificial lift specialists to develop advanced analysis for gas lift, ESP, rod pump, hydraulic (jet pumps), injectors, and flowing wells. These analyses are automatically available for all wells that have the relevant equipment and real-time data. Additionally, Nexus provides estimated daily bottomhole pressure for all wells based on an Oxy lift correlation. For each well, Nexus stores equipment details with the engineering specifications required for analysis. This high level of detail requires significant effort and is kept up to date by the artificial lift teams that need the data.
In addition to the artificial lift teams, vendors use spreadsheet uploaders to upload complicated equipment such as gas lift equipment. Other examples of using Nexus’ equipment data are continuous improvement processes such as root-cause-failure analysis and valve-performance evaluations.
Each morning, well analysts open their Nexus dashboard (Fig. 1), which allows them to quickly identify how to optimize their wells. Analysts can click on an exception to view the well, then change controller settings or shut down the well to prevent damage or to improve production.
Nexus Advanced Artificial Lift, Rod Pump Analysis
Oxy’s data analytics team has developed a variety of solutions for rod pump analysis. For example, a custom equation to calculate downhole dynamometer cards has been created and implemented. These cards are pulled on a schedule and can also be pulled on demand. Machine learning image recognition is used to identify tagging and other card features. Card tagging is one of the exceptions analysts can use to manage the wells by exception. In addition to image recognition, other machine learning solutions identify runtime deviations.
Additionally, a generalized physics-based model has been created that estimates downhole dynamometer cards for deviated rod-pumped wells. Unlike other beam lift analysis tools commonly used in the industry that only apply to vertical wells, such a generalized model considers the effects of 3D wellbore geometry, viscous fluid damping, friction between the rod and the tubing, and more detail, thus it leads to a more realistic estimation. A fit-for-purpose finite-difference solver and other in-house algorithms were developed to calculate downhole cards, fluid load, gearbox loading, pump tagging, pump efficiency, and various other parameters. These items are used to create exceptions that analysts can use to manage many wells.
Other advanced analysis and optimization modules in Nexus include the Ideal Card Simulator, Beam Load Shed Optimizer, real-time rod-string buckling detection, pump fillage detection, pump off controller position sensor malfunction detection, and other solutions by either using physics-based modeling methods or machine learning approaches. Oxy has been able to use these tools to improve production at lower cost.
Future Challenges
It might seem that getting Nexus to its current state was easy or that the future of Nexus is certain, but that is not the case. The future requires that Oxy not lose sight of Nexus being a large part of its operational efficiency and that the company can find the appropriate people to work on these projects.
Crafting a product that aligns with operational requirements requires people with a unique blend of skills—excellence in engineering coupled with a comprehensive understanding of analytics, data, software, and the software development lifecycle. These individuals are in high demand, and many may be hesitant to embrace the long-term nature of a major software project. Additionally, the routine of managing support tickets, addressing user concerns, and navigating the gradual pace of custom software development requires a certain personal disposition. Managing custom-developed software is becoming its own petrotechnical engineering specialty like reservoir engineering and production engineering. For the oil industry to succeed in custom software development, it must find a way to encourage engineers to lead these projects.
In contrast to vendor products, there is no Nexus certification for developers or available talent pool. Any layoffs, retirements, or attrition will slow down development for multiple quarters until the team strength can be rebuilt. Additionally, these types of highly skilled developers have many options, so retention strategies are important for the survival of an in-house application. These issues become a new type of operational risk, where a custom-made, essential operations application must have key expertise and maintenance just like any other oil and gas asset.