UNITE OIL AND GAS OPERATIONS WITH ON...

Offshore oil and gas operations present a technological challenge because on the one hand, in order to ensure efficient management, the software systems run on each rig and vessel must be connected with each other and with software systems run by land-based operations. On the other hand, real-time internet connectivity between these different entities is difficult given that there are no fiber optic cables or cellular towers that service the offshore environment. 

Enterprise software vendors often may have to rely on third-party communication solutions and expensive system integration projects to solve this problem. An enterprise software vendor committed to the offshore oil and gas industry—like IFS—will have a standard, embedded solution that will minimize cost and risk and implement more reliably than a one-off solution. This standard, commercial-off-the-shelf software must handle satellite replication of master data and transactional data between onshore and offshore sites. The solution must be stable, reliable and require little substantial operational day-to-day support. 

A standardized approach that is part and parcel of an enterprise application is attractive because data flows through application program interfaces (APIs), protecting data integrity. A traditional database-level integration will not benefit from this advanced error handling that results when data must conform to business rules defined in a secure and well-designed business system. 

In an ideal replication environment, data will flow through these APIs from a database onshore and databases located at each offshore location, with each vessel or rig configured as a "site" within the ERP software. As each offshore database will have its copy as an onshore site, each vessel will be represented by one site onshore and one site on the vessel. Data replication keeps business-critical data and transaction updates synchronized at both sites.

DATA AND PROCESSES

A replication solution for offshore ERP is based on a centralized database containing all data for all offshore assets, with a subset of that data synchronized to each offshore location. The exact requirements for what data is replicated will be determined during implementation. But some or all of several types of data are typically replicated. 

MASTER DATA

The solution supports replication of basic data like parts, equipment structures and suppliers. When master data changes on the onshore site, the replication engine will transfer these data to the offshore location.

Procurement (purchasing)

Procurement is typically handled onshore, so bigger-picture decisions and administration of supplier blanket agreements and requests for quotations are handled in a land-based office. But while some procurements are planned years in advance to support the asset lifecycle, offshore personnel still need to requisition parts, materials and services. In some cases offshore personnel can also authorize those purchases. 

But as items are received, everyone onshore and offshore needs to have visibility of that inbound inventory transaction.

MAINTENANCE (EQUIPMENT ASSETS AND WORK ORDERS)

Maintenance and asset management data is crucial for onshore/offshore data replication. One goal is to ensure that there is a single version of the truth when it comes to the current state of the asset. Current asset information is essential because: 

·      It affects the valuation of the rig or vessel as an asset. What components are currently being used, what is their age, condition and history, and how much is it costing to operate the asset? 

·       It can determine if the asset is being operated safely and in compliance with local regulation and industry safety standards? Everyone needs to have visibility and plan work according to lockout/tag out processes and work permits and equipment isolation during service. 

·       Preventive and scheduled maintenance activities are supported by staffing and procurement processes, so offshore maintenance functions must be tightly integrated with these administrative onshore services.

LOGISTICS (INVENTORY PARTS AND PART RELOCATION)

Replication needs to help you track when parts are relocated within a site—when parts move from one location on the vessel/rig to another location on the vessel/rig. Replication also helps you keep track of movement of parts from one vessel to another vessel.

FINANCIALS

Financial information triggered by various work processes carried out on the offshore rigs is accumulated and replicated to the centralized database. To support this, various basic data elements (cost accounts, accounting rules) required to support this process are also replicated.

HOW DOES IT WORK?

A replication solution should be based on out and in queues that reliably transmit data through a satellite communication link. Data is transformed into an XML message and sent to the out queue. To ensure high utilization and minimize the risk of disturbance, the onshore instance of software has one out queue for each vessel or rig. This is essential because downtime for one satellite connection will then not block communication to vessels that use other satellite links.

The statistics are available for a system supervisor to monitor the traffic. In case of communication problems, the log will show the message(s) affected and the transmission status. 

The solution’s performance should be auditable because it should collect statistics for all replicated messages. 

If a message transfer is not successful, the queue the message was to pass through will pause for a given, configurable time. If transmission fails over a longer period, a system administrator can diagnose and then resolve the issue.

Documents are usually larger in size than transmissions of transactional data, so the solution will send them to a separate port to reduce lag of transactional data replication. This also enables a system administrator to limit, or throttle, the actual bandwidth used to send documents prioritize transactional data.

THE TECHNICAL SOLUTION

The most important technical requirement is that replicated data received at a site will go through the business logic layer of the ERP solution  before being saved in the database. There are a few exceptions where data will be inserted into the table directly, but these situations are rare, and there must be a compelling reason to bypass this important data integrity step. As data passes through the business logic, the ERP solution will require that it conforms to the same field definition and specifications as data someone entered through a normal application screen. 

To ensure efficient network usage and message throughput on the type of networks typical in an offshore environment, a replication solution uses bundling and compression technologies to increase efficiency. The solution bundles multiple transactions into a single message, and then compresses it before sending it to the queue. The maximum number of messages per bundle and sending interval is configurable to ensure the best overall performance. 

SOLUTION PERFORMANCE

What kind of performance can you expect from ERP with an offshore data replication solution? IFS has performed a benchmark test at the independent IBM Power Systems Benchmark Center in Montpellier, France.

The objective was not only to verify capability, but also to future-proof the system, to meet the customer demands for rollouts, and to increase the scope of transaction volumes for each offshore site. The system was set up in a replicated environment with one onshore and 400 offshore sites, with a satellite simulator configured for 128kb symmetric satellite links with 1000ms latency and 5% packet loss per offshore site.

The conclusion of the results is that IFS Replication can transmit at a rate of 200,000 messages in 200 bundles (1,000 messages per bundle) per minute. In the same system, it can process (receive) 90,000 messages in 90 bundles (1000 messages per bundle) per minute. IFS Replication deployed in a configuration of 400 offshore sites successfully sent, received and processed 324,000 messages per site per day.

In the IFS Replication system, there are separate queues for documents. This improves system performance for transactions, which are more time sensitive.

MONITORING

An organization reliant on satellite communication to replicate data between a number of databases around the globe must still, of course, be prepared to handle and resolve any data errors may occur. Therefore, error recovery and status information services are built into a replication solution. 

The solution will need to gather and present statistics and status information from the offshore sites and overall system status in a single window so users can see what messages are causing any potential error without needing to use development tools or running SQL statements.

The replication monitoring solution is a configurable dashboard based on IFS Lobby . Displays are available that show trends and developments in the replication queues to visualize development over time.

EXCEPTION HANDLING AND NETWORK REQUIREMENTS

A replication solution must be very stable, and exception handing or message resending should not be necessary. However, due to the uncertain quality of the network infrastructure, methods and functions need to exist to deal with faults on both the sender and receiver side of the replication system. For instance when a message is sent, and there is no receipt acknowledgement, the replication engine on the sender side can resend the message after a set time (60 seconds, for example). And those parameters for how many times a message should be resent until it is moved to the error log should be easily configurable.

OFFSHORE NETWORK REQUIREMENTS

 The network requirements of offshore replication solutions will vary. But let’s use IFS Replication as a benchmark.

IFS Replication is transaction-based, which means that normally there is no need for large data volumes to be replicated simultaneously. IFS Replication requires VSAT (or better e.g. wi-fi)-enabled satellite communications between onshore and the offshore sites with minimum satellite bandwidth of 256 Kbit/s with a latency of around 600-800ms RTT for optimal performance. Packet loss should not exceed 1–2 percent. 

A network that meets these requirements will provide a good user experience. Replicating document attachments will use more bandwidth—potentially a great deal more depending on the document size. A 1–2 Mb document should not cause any performance issues if the customer sets up a throttling channel for the satellite communication of the documents. IFS Replication supports different queues and ports to enable throttling capabilities. With this setup, transactions will always have priority over documents in the satellite communications. 

IFS Replication will normally use ~64Kbits/s of the total bandwidth (transactions, document will consume higher bandwidth). IFS and customer experience show that network optimization tools like Riverbed) will improve the communication speed and reliability of the replication solution.