Many challenges confront software vendors seeking to increase Pocket PC adoption in the oil field. These may be categorized into five areas:
- Data acquisition
- Quality control
- First-line surveillance
- Communications
- Cost of ownership
While developing Handheld Field Operator, our development team was met with several interesting challenges. With hard work, lots of long days, and a bit of luck, we were able to release the application within a nine-month project timeline and budget. The major challenges included:
- Code portability
- .NET Framework 1.0 Beta
- Performance of SQL CE 2.0 on Pocket PC 2002
- Application and data hosting
- Internet security
- Hardware inde pendence
Oil field automation is a common method of data collection for high-production oil or gas wells. However, many oil fields in the United States have been producing for 50 to 100 years, and a well may yield just 5–10 barrels of oil per day. At such levels, economics preclude the installation of expensive automated field data capture systems.
Manual field data capture typically involves a field operator driving from well site to well site and writing well temperatures, pressures, and other pertinent information on a piece of paper known as a "gauge sheet," then faxing it to a clerk for entry into a computer. Data quality is marginal, and it can take from one day to several weeks for the information to become available to production engineers, who are responsible for maintaining production levels and ensuring well uptime. Potential problem identification is delayed, and resolution may be too late, which leads to deferred or lost production.
Recent improvements in Pocket PC technology enable the field operators to enter data directly into an electronic form and then synchronize with an engineering database through cellular or wireless systems. When real-time information captured on a Pocket PC is brought into an engineering relational database where historic field information is readily available, the surveillance engineer can further discover production performance variances and use other analytical tools to understand the issues and quickly recommend remedial action.
Today's economic climate and competitive pressures are driving software vendors to find more efficient ways to build these new technologies and reduce ongoing maintenance costs. To fulfill these goals, our development team chose .NET as our development environment. We used .NET Visual Studio and .NET Compact Framework with a local database in SQL CE. Each element of the code was built to suit the handheld, laptop, tablet PC, and desktop environments. While the screen design for each platform had to be appropriate to the available screen real estate, the business rules, data access layers, mathematical engines, communications, validations, and panel editors were common across all platforms.
At the start of the project we faced a potential problem: .NET CF 1.1 was in its beta release. Counting on our strong technical relationship with Microsoft, we began development. The full release of .NET CF 1.1 was to come while we were transitioning our application from development to testing, four months before its release. Microsoft kept us current with code changes and release dates. Other than causing a few minor delays, the release of .NET CF 1.1 did not interfere with our concentration on the product's core functionality.
Data acquisition
The core component of any field force automation tool is data acquisition. Without up-to-date information, the remaining elements are useless.
Smart use of limited screen real estate is of the utmost importance. It is important to provide the system administrator with a panel editor on the desktop to tailor each panel to the operator's preferences. Options may include:
Printer-friendly version