DEP SPECIFICATION

REQUIREMENTS FOR REAL-TIME PRODUCTION

OPERATIONS AND PRODUCTION-CRITICAL
REAL-TIME DATA

DEP 32.01.40.31-Gen.

February 2014

ECCN EAR99

DESIGN AND ENGINEERING PRACTICE

© 2014 Shell Group of companies

All rights reserved. No part of this document may be reproduced, stored in a retrieval system, published or transmitted, in any form or by any means, without the prior
written permission of the copyright owner or Shell Global Solutions International BV.

This document contains information that is classified as EAR99 and, as a consequence, can neither be exported nor re-exported to any country which is under an
embargo of the U.S. government pursuant to Part 746 of the Export Administration Regulations (15 C.F.R. Part 746) nor can be made available to any national of such
country. In addition, the information in this document cannot be exported nor re-exported to an end-user or for an end-use that is prohibited by Part 744 of the Export
Administration Regulations (15 C.F.R. Part 744).
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 2

PREFACE

DEP (Design and Engineering Practice) publications reflect the views, at the time of publication, of Shell Global Solutions
International B.V. (Shell GSI) and, in some cases, of other Shell Companies.
These views are based on the experience acquired during involvement with the design, construction, operation and
maintenance of processing units and facilities. Where deemed appropriate DEPs are based on, or reference international,
regional, national and industry standards.
The objective is to set the standard for good design and engineering practice to be applied by Shell companies in oil and
gas production, oil refining, gas handling, gasification, chemical processing, or any other such facility, and thereby to help
achieve maximum technical and economic benefit from standardization.
The information set forth in these publications is provided to Shell companies for their consideration and decision to
implement. This is of particular importance where DEPs may not cover every requirement or diversity of condition at each
locality. The system of DEPs is expected to be sufficiently flexible to allow individual Operating Units to adapt the
information set forth in DEPs to their own environment and requirements.
When Contractors or Manufacturers/Suppliers use DEPs, they shall be solely responsible for such use, including the
quality of their work and the attainment of the required design and engineering standards. In particular, for those
requirements not specifically covered, the Principal will typically expect them to follow those design and engineering
practices that will achieve at least the same level of integrity as reflected in the DEPs. If in doubt, the Contractor or
Manufacturer/Supplier shall, without detracting from his own responsibility, consult the Principal.
The right to obtain and to use DEPs is restricted, and is typically granted by Shell GSI (and in some cases by other Shell
Companies) under a Service Agreement or a License Agreement. This right is granted primarily to Shell companies and
other companies receiving technical advice and services from Shell GSI or another Shell Company. Consequently, three
categories of users of DEPs can be distinguished:
1) Operating Units having a Service Agreement with Shell GSI or another Shell Company. The use of DEPs by these
Operating Units is subject in all respects to the terms and conditions of the relevant Service Agreement.
2) Other parties who are authorised to use DEPs subject to appropriate contractual arrangements (whether as part of
a Service Agreement or otherwise).
3) Contractors/subcontractors and Manufacturers/Suppliers under a contract with users referred to under 1) or 2)
which requires that tenders for projects, materials supplied or - generally - work performed on behalf of the said
users comply with the relevant standards.
Subject to any particular terms and conditions as may be set forth in specific agreements with users, Shell GSI disclaims
any liability of whatsoever nature for any damage (including injury or death) suffered by any company or person
whomsoever as a result of or in connection with the use, application or implementation of any DEP, combination of DEPs
or any part thereof, even if it is wholly or partly caused by negligence on the part of Shell GSI or other Shell Company. The
benefit of this disclaimer shall inure in all respects to Shell GSI and/or any Shell Company, or companies affiliated to these
companies, that may issue DEPs or advise or require the use of DEPs.
Without prejudice to any specific terms in respect of confidentiality under relevant contractual arrangements, DEPs shall
not, without the prior written consent of Shell GSI, be disclosed by users to any company or person whomsoever and the
DEPs shall be used exclusively for the purpose for which they have been provided to the user. They shall be returned after
use, including any copies which shall only be made by users with the express prior written consent of Shell GSI. The
copyright of DEPs vests in Shell Group of companies. Users shall arrange for DEPs to be held in safe custody and Shell
GSI may at any time require information satisfactory to them in order to ascertain how users implement this requirement.
All administrative queries should be directed to the DEP Administrator in Shell GSI.
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 3

TABLE OF CONTENTS
1. INTRODUCTION ........................................................................................................ 4
1.1 SCOPE........................................................................................................................ 4
1.2 DISTRIBUTION, INTENDED USE AND REGULATORY CONSIDERATIONS ......... 4
1.3 DEFINITIONS ............................................................................................................. 4
1.4 CROSS-REFERENCES ............................................................................................. 7
1.5 SUMMARY OF MAIN CHANGES ............................................................................... 7
1.6 COMMENTS ON THIS DEP ....................................................................................... 8
2. REQUIREMENTS AND GUIDELINES FOR PRODUCTION RTO
CAPABILITIES ........................................................................................................... 9
2.1 BACKGROUND .......................................................................................................... 9
2.2 SCOPE AND CONTEXT............................................................................................. 9
2.3 REQUIREMENTS FOR SYSTEMS SUPPORTING RTO CAPABILTIES ................ 10
2.4 REQUIREMENT FOR SUSTAINABLE RTO CAPABILITIES ................................... 16
3. PRODUCTION CRITICAL REAL TIME DATA ........................................................ 18
3.1 BACKGROUND ........................................................................................................ 18
3.2 SCOPE AND CONTEXT........................................................................................... 18
3.3 RTO DATA CRITICALITY RANKING ....................................................................... 18
4. REFERENCES ......................................................................................................... 21

APPENDICES
APPENDIX 1 BASIC GENERIC DATA CHECKING ............................................................. 22
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 4

1. INTRODUCTION

1.1 SCOPE
This DEP specifies requirements and gives recommendations for the setting up of the
technology infrastructure to support Upstream Production Real Time Operations (RTO) and
the acquisition and quality assurance of related real-time production data.
This DEP is intended for use by those involved in the designing, deploying, and upgrading
systems for the support of Upstream Production RTO. This DEP identifies generic
functionality, standards and best practices, whilst allowing for differences in history,
business requirements or local legislation that may require different implementations from
one project to another.
This DEP provides:
• Specification of the key functionalities required and key supporting elements of the
infrastructure to be put in place to support Real Time Operations.
• Together with Standard Form DEP 59.01.10.80-Gen. a minimum set of criticality-
ranked real-time data crucial to executing key RTO processes.
This is a revision of the DEP of the same number dated February 2012; see (1.5) for an
overview of the main changes.

1.2 DISTRIBUTION, INTENDED USE AND REGULATORY CONSIDERATIONS

Unless otherwise authorised by Shell GSI, the distribution of this DEP is confined to Shell
companies and, where necessary, to Contractors and Manufacturers/Suppliers nominated
by them. Any authorised access to DEPs does not for that reason constitute an
authorization to any documents, data or information to which the DEPs may refer.
This DEP is intended for use primarily in the design and operation of oil and gas production
wells and facilities. Such facilities and operations are termed "assets" in this DEP. This
DEP may also be applied in other similar facilities.
When DEPs are applied, a Management of Change (MOC) process shall be implemented;
this is of particular importance when existing facilities are to be modified.
If national and/or local regulations exist in which some of the requirements could be more
stringent than in this DEP, the Contractor shall determine by careful scrutiny which of the
requirements are the more stringent and which combination of requirements will be
acceptable with regards to the safety, environmental, economic and legal aspects. In all
cases, the Contractor shall inform the Principal of any deviation from the requirements of
this DEP which is considered to be necessary in order to comply with national and/or local
regulations. The Principal may then negotiate with the Authorities concerned, the objective
being to obtain agreement to follow this DEP as closely as possible.

1.3 DEFINITIONS
1.3.1 General definitions
The Contractor is the party which carries out all or part of the design, engineering,
procurement, construction, commissioning or management of a project or operation of a
facility. The Principal may undertake all or part of the duties of the Contractor.
The Manufacturer/Supplier is the party which manufactures or supplies equipment and
services to perform the duties specified by the Contractor.
The Principal is the party which initiates the project and ultimately pays for it. The Principal
may also include an agent or consultant authorized to act for, and on behalf of, the
Principal.
The word shall indicates a requirement.
The word should indicates a recommendation.
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 5

1.3.2 Specific definitions

Term Definition
Alarm The notification type used to notify operators of the exceedance of a
Critical Limit or Standard Limit. Refer to DEP 32.80.10.14-Gen. for related
definitions.

Alert The notification type used to notify operators and/or operations support
personnel of the exceedance of a target limit or other event that is not a
Critical or Standard Limit. Refer to DEP 32.80.10.14-Gen. for related
definitions.

Critical Limit Critical Limit: The value at which the operator has a last opportunity to
or Standard diagnose a situation and respond in order to correct the process and
Limit prevent the consequences in a timely manner. Standard Limit: The limit,
when exceeded for longer than the allowable time in exceedance, where
sustained or recurring short-term operations will begin to cause
cumulative degradation of equipment integrity or reliability, or other
cumulative effects that could lead to reduction of production.

The Shell The Shell PCD Technical Reference Model is set out in
PCD DEP 32.01.20.12-Gen., Appendix 1. The model divides the process data
Technical acquisition architecture into a number of distinct levels as follows:
Reference • Level 5: The public Internet, Global Communications
Model
• Level 4: The Shell GI Office Domain Network.
• Level 3: Process Control Network or Process Information Network,
Optimizing Control.
• Level 2: Includes functions involved in monitoring and controlling
the physical process. Distributed Control System, Real Time
Operations Human Interface / Primary Operator Interface.
• Level 1: Process Connected Sub Systems and I/O. Continuous
Controllers.
• Level 0: Field Devices

Office The Office Domain (OD) includes all devices, nodes, systems and
Domain (OD) networks required to provide a standardised enterprise-wide Information
Technology environment, hence Levels 4 and 5 in the standard model.
The Shell Office Domain is standardised on GI and this DEP assumes
that GI is fully implemented.

P&ID Piping and Instrumentation Diagram

PEFS Process Engineering Flow Sheet
Process A Secure Cell consists of a Process Control Access Domain (PCAD) and
Control one or more enclosed Process Control Domains (PCD). The Secure Cell
Access ensures that Process Control Domains can work independently of the rest
Domain of the IT infrastructure (Office Domain). The PCD shall continue to
(PCAD) function without losing its availability and integrity so that production is not
jeopardised even if there are problems in the Office Domain.
Access to a Secure Cell shall be through one single entry point, the
Process Control Access Domain (PCAD). (Reference
DEP 32.01.20.12-Gen.)
Process Process Control Domain (PCD) covers Levels 1, 2 and 3 above, and has
Control high level of security and availability, and a defined integrity level. Most
Domain PCD applications and systems are in direct communications with, and in
(PCD) control of, the production facilities. The PCD shall be managed and
engineered in accordance with DEP 32.01.20.12-Gen.
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 6

Term Definition
Production Production critical data and documents are those which, when of good
Critical Data quality (accurate, consistent, accessible, available on time), can be used
in key business processes at Levels 3 to 5 to improve the overall value
derived from an asset, and when of poor quality (inaccurate, inconsistent,
inaccessible or unavailable on time) may adversely affect the
performance of the business processes. Safety and environmental data,
while being critical in their own right, are out of scope of this DEP.
Process Data System for the storage, archiving and retrieval of a broad range of
Historian process data.
Production The Production Enterprise Architecture provides the Information
Enterprise Technology (IT) / Information Management (IM) framework to allow
Architecture efficient delivery of information to support Production Engineering
workflows. This architecture defines RTO IT requirements for Levels 4
and 5 of the General Process Management and Control System Model.
Several platform / service layers are defined, including:
1. Data Sources
2. Application Components
3. Integration Platform comprising Application Services and Data
Services
4. Presentation Services
Production The purpose of Production Real Time Operations is to enable ‘just-in-time’
Real Time local/remote monitoring and collaboration, optimisation and control of
Operations product flows within the Integrated Production System operating
(RTO) envelope. RTO refers to activities related to the management of oil and
gas production based on real time data and with actions to be taken in the
hours to days-time frame.

1.3.3 Abbreviations

Term Definition
CWE Collaborative Work Environment
DACA Data Acquisition and Control Architecture
DCAF Group Discipline Controls and Assurance Framework (DCAF).
This framework standardises Quality Control (QC) and Quality Assurance
(QA) across all disciplines, in all Opportunity Realisation Process phases
applicable to major Greenfield and Brownfield projects.
DCS Distributed Control System.
For the purposes of this DEP, the abbreviation “DCS” is used
interchangeably with other Process Control Domain data acquisition and
control systems such as Programmable Logic Controllers (PLCs),
Supervisory Control and Data Acquisition (SCADA) systems.
DQ Data Quality
EBS Exception Based Surveillance
EDW Engineering Data Warehouse
ERP Enterprise Resource Planning
ESP Electric Submersible Pump
IPM Integrated Production Modelling - a suite of modelling tools.
IPSM Integrated Production System Model
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 7

Term Definition
IT Information Technology
KPI Key Performance Indicator
PCP Progressive Cavity Pump
PEFS Process Engineering Flow Scheme
PI Plant Information, an application by OSIsoft.
POCC Production Operations Collaborative Centres
PSO Production System Optimisation
P&ID Process and Instrumentation Diagram
QC Quality Control/Check
SAP The Primary Shell ERP System
SCADA Supervisory Control and Data Acquisition
SOP Standard Operating Procedure
WRFM Wells, Reservoir and Facilities Management

1.4 CROSS-REFERENCES
Where cross-references to other parts of this DEP are made, the referenced section or
clause number is shown in brackets ( ). Other documents referenced by this DEP are listed
in (4).

1.5 SUMMARY OF MAIN CHANGES

This DEP is a minor revision of the DEP of the same number dated February 2012, in
conjunction with a major update to Standard Form DEP 59.01.10.80-Gen. See (3), with
some other minor updates.
The following are the main, non-editorial changes.

Section/Clause Change
1.3.2 Definitions for alarm, alert and critical limit added
1.3.3 Abbreviations for DCAF and WRFM added
2.2.1 Levels updated
2.2.1/5 CWE text added
2.3.1 Text updated (para 2,4)
2.3.2 Text updated (para 1; para 7 point 1,2 and 5)
2.3.3 Text updated
2.3.7 Added last paragraph
2.3.9 Text updated
2.4.2 Text updated
3.1 Text updated
3.2 Section updated
3.3.1 Section updated
3.3.2 Section updated
3.3.3 Section added
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 8

3.3.4 Section numbered/text updated

1.6 COMMENTS ON THIS DEP

Comments on this DEP may be submitted to the Administrator using one of the following
options:

Shell DEPs Online Enter the Shell DEPs Online system at

https://www.shelldeps.com
(Users with access to
Shell DEPs Online) Select a DEP and then go to the details screen for
that DEP.
Click on the “Give feedback” link, fill in the online
form and submit.

DEP Feedback System Enter comments directly in the DEP Feedback

(Users with access to System which is accessible from the Technical
Shell Wide Web) Standards Portal http://sww.shell.com/standards.
Select “Submit DEP Feedback”, fill in the online form
and submit.

DEP Standard Form Use DEP Standard Form 00.00.05.80-Gen. to record

(Other users) feedback and email the form to the Administrator at
standards@shell.com.

Feedback that has been registered in the DEP Feedback System by using one of the above
options will be reviewed by the DEP Custodian for potential improvements to the DEP.
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 9

2. REQUIREMENTS AND GUIDELINES FOR PRODUCTION RTO CAPABILITIES

2.1 BACKGROUND
The purpose of Production RTO is to enable ‘just-in-time’ local and remote monitoring,
collaboration, optimisation and control of product flows within the Integrated Production
System operating envelope.
RTO requires, as a minimum, the automated acquisition of production data for monitoring in
real time the overall production process from a remotely located Production Office, and a
means of communicating timely instructions to field operations.

2.2 SCOPE AND CONTEXT

2.2.1 Items inside or outside the scope of this DEP
The systems enabling the process data flow from the field to Process Control Domain, and
thereafter, into the Office Domain for Production RTO may be divided into a number of
distinct levels as follows (the Shell PCD Technical Reference Model):
• Level 0: Field Devices
• Level 1: Process Connected Sub Systems and I/O
• Level 2: Distributed Control System, Real Time Operations Human Interface
• Level 3: Process Control Network or Process Information Network
• Level 4: Desktop Networked Access, Office Domain, Usually Site Wide. This level
includes Site Operations Management.
• Level 5: Internet, Global Communications
The proper functioning of the systems in Levels 0 to 4 is necessary for efficient and
meaningful RTO workflows. However, this DEP focuses mainly on the requirements for the
systems and functionality in Levels 3 and 4 as they relate to Production RTO.
The following is specifically EXCLUDED from the scope of this DEP:
1. Level 3, 4 and 5 IT architecture requirements.
2. Levels 1, 2 and 3 Process Control Domain IT architecture and security aspects (refer
to DEP 32.01.20.12-Gen.).
3. Levels 0, 1 and 2 in their entirety: The specific requirements for instrumentation and
metering systems (refer to DEP 32.31.00.32-Gen.), field radio telemetry systems,
instrumented protective functions (refer to DEP 32.80.10.10-Gen.), and the base
layer production monitoring and control system, including control room equipment
and operations (refer to DEP 32.30.20.15-Gen.) are excluded from the scope of this
DEP.
4. Level 3 base layer and advanced close loop set point control (refer to
DEP 32.30.20.16-Gen.).
5. Collaborative Work Environments (CWE). CWEs (or Production Operations
Collaborative Centers (POCC) or Remote Control Rooms) allow multi-way audio-
visual communication across multiple manned process control, production
operations and production support locations, enabling staff from various disciplines
and locations to collaborate more effectively. CWEs are critical for efficient RTO as
they significantly improve human communications and operational coordination.
However, CWEs are EXCLUDED from the scope of this DEP as there are separate
internal Group guidelines for CWE design and implementation, see the Informative
version of this DEP.
6. Rotating equipment condition monitoring systems (refer to DEP 31.29.00.11-Gen.).
7. Hydrocarbon Production Information System.
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 10

8. [Integrated] Production System Modeling (IPSM), although updating of IPSM models

with RTO data is included, as is the use of IPSM models for RTO purposes.
The scope of this DEP INCLUDES specifically functional requirements for the following
systems supporting RTO in the Office Domain (OD), using high frequency data from the
PCD:
1. Systems for the visualization of the state of Production, in the forms of real time
trends or daily summaries, possibly within operating envelopes.
2. Systems for the storage, archiving and retrieval of a broad range of process data
(the Data Services Layer and Process Data Historians).
3. Systems for the acquisition and processing of production well test data and for the
estimation of production flows (virtual meters).
4. Systems for the monitoring of surface and subsea facilities and pipelines.
5. Systems for the management and use of models required for RTO, including the
computation of forecasts or optimized settings for manual or automated application
on an on-demand or daily basis for implementation within the same day.
6. Systems for the detection of events or exceptions, and their archiving and
subsequent use for “Exception Based Surveillance”.
7. Systems for cascading process set point commands from the OD to the field
(if applicable).

2.3 REQUIREMENTS FOR SYSTEMS SUPPORTING RTO CAPABILTIES

2.3.1 Data sources and the Hydrocarbon Production Information System
Data from Levels 0, 1, 2 shall be made available to OD systems in Levels 4 and 5 primarily
via a Process Data Historian, the requirements of which are further discussed in (2.3.2).
The Production Enterprise Architecture defines a Data Sources Layer which includes both
the Process Data Historian, as well as the data from non-real time systems, in particular the
Hydrocarbon Production Information System.
The framework for data interchange from the data sources and their associated application
platforms to the other layers should be managed via data services and applications
services layers, as per the Production Enterprise Architecture, normally executed by the
Principal.
The Principal shall be consulted for latest requirements on interfacing between Data
Sources and their associated Application Services and the Data Services layers. The
overriding requirement for the final IT solution shall be the fitness for sustained use for
Production RTO.
Metering data for use in the Hydrocarbon Production Information System should be
transferred from the Process Control Domain directly to the Hydrocarbon Production
Information System. An alternative is to use the long term Process Data Historian but this is
subject to approval from the Principal’s Hydrocarbon Allocation authority. Meter readings or
totalized daily values from the PCD shall be transferred to the Hydrocarbon Production
Information System exactly the same and without changes at a resolution and compression
acceptable to the Principal’s Hydrocarbon Allocation authority. For Class I and II metering,
daily volume totalization for Hydrocarbon Allocation shall not be conducted within the
Process Data Historian. Totalization shall be achieved within PCD flow computers or
control systems and the daily values may then be stored within the Process Data Historian.
It is the Principal’s responsibility to put in place a data management plan for production
data. Refer to (3.3.4).
2.3.2 Process data historian requirements
A Process Data Historian shall be provided for the medium and long term archiving of, and
for near real time access to, process data from process measurements and controls. As a
minimum, data identified to be production critical at levels MEDIUM or HIGH in
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 11

DEP 59.01.10.80-Gen. shall be captured and stored in the Process Data Historian,
reference (3.3). Data identified at LOW overall criticality should also be captured and
stored in the Process Data Historian unless there are significant communications and data
management issues. The Process Data Historian shall receive its data in real time from
various Level 2 and Level 3 systems. The DCS and other systems in the PCD may have
their own separate native data historians for operator graphics and trends. These will not
be further discussed within this DEP and all references to Process Data Historians will refer
to long term Process Data Historian.
A mirrored dual long term Process Data Historian configuration, with one Historian in
Level 3 and another in Level 4 is the default standard and should be implemented. The
data in the Historians shall be synchronized. The dual Process Data Historian configuration
is shown in DEP 32.01.20.12-Gen., Appendix 2.
Due to its central role in support of RTO, the design of the Process Data Historian system
shall be subject to business continuity/disaster recovery analysis. Process Data Historian
outage impact categorization shall be conducted, target Recovery Time Objectives and
Recovery Point Objections defined, and the systems designed accordingly. Process Data
Historian collectives may be part of the final design.
The Process Data Historian, residing in the PCD, interfaces to the L2 or L3 Process Control
Domain data providers via the Process Control Network. The design and implementation of
the Process Data Historian - L2 or L3 Process Control Data Sources link are critical for
RTO and shall be subject to availability, redundancy and data-throughput considerations
under supervision from the Principal’s Process Data Historian focal point.
The Process Data Historian shall also be able to receive and archive real time and
historical process data from various applications in Levels 3 and 4. For example, virtual
metering/instrument estimates of production rates or tank levels may be stored in the
Process Data Historian.
While data presentation is not its prime function, the Process Data Historian shall support at
least one user interface to allow users in the OD to view both real time and historical data
trends. The Process Data Historian shall support data transfer interfaces to other
applications, including downloads of process data into Microsoft Excel®.
For the overall system transmitting process data from the field to the OD, archiving and
performance requirements include, as a minimum:
1. The Process Data Historian shall continuously scan process data samples from the
field at 1 minute intervals or less. Real time data changes should appear in the
Process Data Historian user interface within 2 scan intervals of actual process data
change in the field. The Principal should be consulted to identify if any events are to
be logged at higher scan rates and with high resolution time stamping. In assets
with significant geographical spread and large numbers of wells, such as
Unconventional Gas or Oil assets, the foregoing Process Data Historian
requirements may be relaxed with Principal’s explicit approval to scanning of data
points at 15 minute intervals.
2. The Process Data Historian may have time compression and resolution settings to
allow reduction of transmission bandwidth and storage capacity requirements. The
party responsible for the configuration of the time compression and resolution shall
propose settings for approval by Principal’s RTO representative. The settings
(resolution, time window size) shall be adjustable for individual signals.
3. The Process Data Historian shall have availability in excess of 99.9 %.
4. The performance of the Process Data Historian in making data available to the Office
Domain shall be part of the Commissioning Testing of a facility. Performance of the
Process Data Historian and its interfaces shall be demonstrated to and approved by
Principal’s RTO representative.

5. The historian needs to have the ability to store all measured data values for at least
five years without additional processing. Verify time frame with local data retention
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 12

policy.

2.3.3 Presentation layer for production status visualization and reporting

Means shall be provided for the visualization and reporting in the OD, on user desktops, of
real time and historical process data.
The visualized information should include, but not be limited to:
1. Overall production and injection real time rates, daily volumes from the previous day,
and cumulative volumes for the month. Overall production and injection deferments
and forecasts.
2. Well production network and equipment critical process data, with operating
envelopes. This should include Well production and injection real time rates, daily
volumes from the previous day, and cumulative volumes for the month.
3. Various presentation formats for the efficient analysis and review of production, well,
facilities and reservoir performance, including well downhole pressures (if available)
and tubing head pressures.
4. Exceptions detected from normal operating envelopes for wells, production network
and equipment.
5. Indication of the quality of the data. Process data with critically ranking of HIGH in
DEP 59.01.10.80-Gen., shall be provided with data quality indicators, see (3.3.3).
6. Means for the user to ascertain if a value was measured, filtered, manually entered,
or calculated. This can be reflected in the tag of the value. Ideally a means to
identify the source of data should also be provided.
7. Multiple process values shall be able to be visualized on one trend on a common
time scale.
8. Various time scales shall be supported, ranging from last hour to any hourly, daily,
monthly or yearly interval.
9. Process Trends may be presented with underlying operating envelopes or
performance curves.
10. Trends of process values should follow a standard colour coding convention such
that it is easy to follow a process stream from one trend to the next. This may be
generalized to unique markers to account for color blind personnel.
11. Trends should support the ability to zoom in to view regions of interest in greater
detail. Zoom support must include both axes.
12. Trends should be able to support multiple y-axes. As a minimum, two y-axes should
be supported in order to display process data of different unit sets, e.g., oil rates in
cubic meters per day and water cut as a percent.
13. An associated table should exist which can display the actual data values being
displayed in the trend.
Production critical data at overall criticality levels of MEDIUM or HIGH listed in
DEP 59.01.10.80-Gen. applicable to the producing asset should provide a basis for the
visualizations above. The visual presentation of the production status of the asset should
be in the form of at least one of the below:
• Dedicated Production or Well Review web portals in accordance with the Production
Enterprise Framework. This is the preferred integrated, workflow focussed medium.
• Client user interfaces of various server based applications.
• Process Data Historian office domain client (PI Processbooks).
For Green Field Assets, the Presentation Layer shall be the current Upstream standard of
WRFM IT Toolkit Daily Production Review portal or centralized version-controlled
PI Processbooks, as a minimum.
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 13

Slow response times affect the user experience significantly. Once the client application or
portal is initiated, values or time trends from the Process Data Historian should be
presented typically less than 5 seconds after activation of the request.
It is acceptable for especially large sets of data to be presented after longer delays, on
Principal approval. For example, one year of data for five process variables should be
presented within 30 seconds. The response times of the presentation layer shall be
specified as part of the system design, tested and demonstrated to the Principal for
acceptance in all cases.
Formal production reporting requirements are based on the Hydrocarbon Production
Information System, and are excluded from scope of this DEP.
2.3.4 Well testing support
Regular data on individual well production rates is an integral part of the license to operate
of an asset, and a significant pre-requisite to meaningful Upstream Production RTO and
well and reservoir management.
For assets with well testing facilities, a means shall be provided for the efficient automated
acquisition of oil, water and gas production rates from the well testing facilities into an OD
Well Test Storage and Validation framework. The framework should provide a means for
the following:
1. Recording well test data, as a minimum, the identifier of the well on test, the
estimated steady state well flow rates from the well test streams and other relevant
process data, such as tubing head pressure and production choke settings.
2. Allowance for exclusion of parts of the test when the recorded flows and pressures
are in transient state due to purging. This may be implemented by use of flow
computers in the field at Level 1 or 2, or be part of the well testing system at the PCD
or OD level.
3. Manual input of suitable parameters, such as sample water cut, fluid density or
composition data or orifice plate sizes. This may be implemented by use of flow
computers in the field at Level 1 or 2, or be part of the well testing system at the
PCD or OD level.
4. Allowing manual validation of each complete Well Test data set, and on validation,
transmission of the well test data to the Hydrocarbon Production Information System.
The user and time of the validation of well tests is to be logged.
5. All manual input or over-writes of input parameters or well test results shall be
logged.
6. (Optionally) As part of the validation process, alerting the user of a well test which is
potentially invalid, for example due to an inadequate test period.
The means for the transfer of validated well test data from the Well Test Storage and
Validation Framework to the Hydrocarbon Production Information System shall be subject
to approval from the Principal’s Hydrocarbon Allocation authority.
2.3.5 Daily and continuous well production estimation and reconciliation
The tracking of overall oil, water and gas production flows across a production gathering
network is central to management of production, and of the wells and facilities.
The design of the production network shall incorporate metering to allow real time
estimates of all main single phase and multiphase production flow streams across the
network. The allocation and metering design of an asset shall include this required support
for RTO and Well, Reservoir and Facilities Management.
Well production volumes shall be estimated at least on a daily basis even if individual wells
do not have dedicated multiphase flow meters.
A means should be provided of automatically detecting and recording well “closed in” and
“in production” status. Simple estimates of daily well-by-well production may then be
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 14

generated by multiplying well potentials from well test data in the Hydrocarbon Production
Information System by fraction of the day the well is in production.
The Upstream Smart Fields standard for well production estimation is to estimate or
measure individual well multiphase production continuously in real time. In such cases,
either multiphase meters or wet gas meters or virtual flow metering shall be provided as
part of the design to support RTO capability.
If a Virtual Metering System is the design choice for the estimation of well rates in real time,
the virtual metering system shall:
• Provide real time estimates of well production rates, at least at intervals of
15 minutes or less, with 1 minute intervals preferred. The estimates should be
based on use of real time data with subsurface or surface well or well flow line
models that relate the real time data to the production rates to be estimated.
• Have a transparent means of generating and updating the underlying models for
estimating real time well production rates. The models used may be constructed
from well test data correlations or from first principles models. Models of both types
shall be calibrated using well test data, at intervals consistent with the Asset
minimum standard for acquiring validated well tests.
• Allow the flagging of out-of-date or out-of-calibration models or well operation
beyond the usable range of the models.
• Have means for detecting and alerting if the underlying real time data used is not
suitable for estimating real time well production rates. The conditions to be detected
should include drop outs, flat-lines, and extreme values beyond sensible possibility.
Regardless of the means of estimating daily well production, the system providing well
estimates shall be provided with a means of comparing the sum of the individual well oil,
water and gas estimates to the total commingled metered oil, water and gas measurements
from nearest downstream meter. A reconciliation factor defined as below shall be computed
and any deviation significantly from 1.0 shall be flagged to activate a review of the well
estimates.

Total Production Volume for Period (from Meter)

Reconciliation Factor =
Sum of Estimated Well Production Volumes for Period

2.3.6 Exception based surveillance requirements

An Exception Based Surveillance (EBS) system shall be provided for detecting in real time
deviations of process variables and equipment performance from their normal operational
operating envelopes.
The alerts in the EBS system shall be generated and initially addressed within the OD, and
shall not require immediate (within minutes or within hours) remedial action with Process
Safety or HSE consequences.
The automated detection and handling of EBS system exceptions via alerts shall be rigidly
differentiated from the management of Process Safety or HSSE related alarms which shall
be activated and managed within the process control domain. All alarms requiring
immediate remedial action shall be managed within the Process Control Domain, and are
outside the scope of this DEP. Process Safety or HSSE related alarms shall be managed
in accordance with DEP 32.80.10.14-Gen.
Alarms or trips from the PCD may be recorded within an integrated EBS system for longer
time horizon follow up actions, such as root cause analysis or analysis of the causes of
production deferment.
The EBS system shall have the following components:
1. Means of pre-processing raw signals, for detecting flat lines, for eliminating
unwanted effects of spurious spikes and dropouts, and for computing averages and
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 15

filtered values. This may be part of the Data Services Layer.

2. Means of applying rules on process measurements to trigger exception alerts, which
are binary variables (with two states: exception or no exception). This may be a
separate component termed an Exception Detector.
3. Means of integrating the alerts from multiple exception detectors, managing the
alerts, recording the time of the origination and the source of the alert.
4. Means of organizing and presenting the alerts so as to avoid alert floods. If PCD
level alarms are transmitted to the Office Domain Process Data Historian or EBS,
alarm masking implementation within the DCS shall be such that the masked alarms
are still logged and presented to the Process Data Historian and EBS.
5. Means of further processing to summarize and consolidate alerts and of presenting
and reporting the alerts for further action, including initiation and management of
appropriate workflows, and for acknowledging the alerts.
The design, configuration and operational commissioning of the EBS system shall:
• Target to provide a high proportion of actionable alerts and summaries.
• Allow use of templates applicable to significant groups of wells and facilities for
efficient deployment and maintenance of rules and set-points.
• Align with workflows and standard operating procedures for the management of
detected exceptions.
As various exception detectors, architectures and user interfaces are currently in operation
within the Group, the design of the EBS system shall be subject to guidance from the
Principal’s RTO focal point.
2.3.7 Surface and subsea facilities and pipeline monitoring
The following systems shall be provided in the OD for the RTO monitoring of surface and
subsea processing facilities and pipelines:
• Systems for displaying real time and recent operating points, against the base
operating envelopes of the subsea and surface facilities and pipelines. Such
systems should include, in particular, tracking of operating points with respect to flow
assurance related limits.
• Systems for displaying in real time KPI and current status of rotating equipment, in
particular turbines, compressors.
The Production RTO system design shall provide means for the controlled management of
operating envelops required for RTO presentations and computations.
Production RTO systems for visualization of rotating equipment status shall receive
appropriate inputs from the more specialized Condition Monitoring Systems as per
DEP 31.29.00.11-Gen. Condition Monitoring Systems are primarily the responsibility of
asset preventive maintenance groups and outside the Scope of this DEP.
Excursions of processes outside the operating envelops should raise alerts through the
Exception Based Surveillance System.
2.3.8 Integration of production models
Models are in place for all aspects of the production system (reservoirs, wells, facilities) and
are combined to form Integrated Production System Models (IPSM). Shell's strategy is to
have an IPSM in place for all producing assets used for surveillance, production system
optimisation, forecasting and development planning.
Production RTO systems shall be interfaced to environments for the management of IPSM
models and their component models to:
• Link production and injection data to models for calibration and surveillance. This is
done by comparing model parameters with field measurements for all produced and
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 16

injected phases such as well test data, well flowline pressure drops, gas and water
injection rates, etc.
• Enable the acquisition of production system capacities, model-based operating
envelopes or curves from models for comparing expected versus actual well and
facilities performance in real time.
• Optionally, provide set point guidance, on demand or on a schedule, for the
management of production flows, based on model predictions or optimization.
The model management environments shall include means for controlling the revision
status of models, and making transparent the validity or update status of models.
The models used for Production RTO shall be managed by relevant model management
environments.
2.3.9 Optimization and management of remote and advisory set points
A central Production RTO requirement is the capability to initiate the remote start and stop
of pumps or wells, and the ramping up and down of production. The requirements for
remote adjustments of production volumes shall be addressed upfront as part of the
Production RTO design.
In particular, for geographically widely distributed land assets with pumped wells, means
shall be provided for the remote start and stop of pumps or wells from a central control
facility.
Manual remote adjustment to production levels may be achieved via direct access to
applications within the PCD, or by logging into the PCD from an OD environment, and
thereafter manually changing set points in PCD applications, or by cascading instructions
manually into the Process Central Control Room or the Operators via radio or other
communications links for the settings to be manually changed. While this functionality is
part of DEP 32.01.20.12-Gen., Section 16, the functionality to log into the PCD from an OD
environment for the management of individual wells shall be authorized by Principal with
appropriate risk assessment, and only for the start / stop of previously enabled pumps or for
changing well settings within preset bounds (e.g., frequency of ESP Variable Speed
Drives).
If required by the particular operational strategy, a Real Time Optimizer shall be provided to
support real time automated scheduling and optimization requirements. The requirement for
a Real Time Optimiser shall be driven by the incremental business value from optimisation
in real time, compared to optimisation on an ad hoc basis or optimization on longer time
scales, e.g., monthly. As such systems are not common as yet, requirements for the Real
time Optimizer are provided in the Informative part of this DEP.

2.4 REQUIREMENT FOR SUSTAINABLE RTO CAPABILITIES

2.4.1 Workflows and skills development
The design and selection of RTO capabilities for an asset shall be developed from a high
level, based on business requirements and identified areas of improvement.
Standard Operating Procedures (SOP) reflecting the technology to be implemented shall be
generated for all workflows significantly impacted by the introduction of RTO technology.
Roles and responsibilities shall be clarified as new technologies and workflows are
introduced or initiated. Ideally, SOPs should be developed using LEAN techniques such as
Value Stream Mapping with the relevant engineers and Process Owners involved.
RTO capability design shall include suitable development of the personnel aspects for
potential users, via training, motivation, suitable clarification of duties and responsibilities.
A knowledge management and continuity plan shall be put in place. If an existing system is
to be changed over to a new improved system based on a new technology or work process,
this shall be supported by a Change Management plan.
A Skills Management Plan should be established. This should include: training
requirements (awareness sessions and technical and business/process training); an
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 17

approach for newcomer induction (introduction, training, coaching); and coaching by the
Process Champions.
2.4.2 Maintaining level 0, 1, 2 support for RTO, data quality
RTO capability is fully dependent on the proper functioning of Levels 0, 1 and 2 process
measurement, data acquisition and control systems. RTO requirements for Levels 0, 1 and
2 shall be fully defined and implemented during the design stage.
At the Operational phase, a work process shall be put in place to cascade data integrity and
acquisition issues from the RTO users to the Operations, Instrumentation and Controls
personnel in the field for their efficient resolution. RTO Data Criticality should be translated
in line with Maintenance and Integrity work-stream guidelines so that the maintenance jobs
are accordingly scheduled / prioritized using Corrective Maintenance Prioritization Tool
(CMPT). Level 0 instrumentation and related equipment maintenance strategy and tasks
(including calibrations) should be captured in the asset maintenance management system
and compliance should be tracked as part of overall asset integrity KPI.
2.4.3 Maintaining applications for RTO
As part of the design for sustainable RTO, the applications and systems for supporting RTO
shall be provided with:
1. A framework for IT support which efficiently manages and maintains hardware,
applications as well as interface issues, and to manage the underlying data quality.
2. A framework for the Group support for the central management of applications,
including for periodic upgrades of software and for addressing bugs or requests for
enhancements.
3. A means for testing the interfaces between the applications, to ensure continued
functionality and performance when any of the linked applications is upgraded.
4. A test environment for the pre-deployment testing of application upgrades, and for
the testing of configuration changes.
5. A business super-user who will focus on the production operations or engineering
use of the applications or integrated solutions.
6. Clear interfaces to the discipline owners and Group central specialist support of the
various models and systems, ranging from Production Technology, Production
Programming, Hydrocarbon Allocation focal points to the Process Engineering, and
Process Automation Control and Optimization disciplines.
2.4.4 Business ownership and focus on business value
Business Owners shall be established for each Production RTO solution. The Business
Owners should be responsible for the sustainability and continuous Improvement of
Production RTO capabilities. The Business Owner should establish and monitor business
and technical KPIs.
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 18

3. PRODUCTION CRITICAL REAL TIME DATA

3.1 BACKGROUND
The focus of this DEP section is the identification of online data critical to the Production
RTO process and its management. Given limits on budgets and maintenance resources,
identification of data criticality levels establishes the relative importance of real-time data
points so that critical data and their associated source instrumentation are put in place as
part of the overall asset design, and thereafter, appropriately prioritized for maintenance
and management.

3.2 SCOPE AND CONTEXT

A starter set for the criticality ranking of real-time data is set out in DEP 59.01.10.80-Gen.
and has been determined according to the relative importance of the data points for and
impact on the key day to day production operations work processes.
The focus in DEP 59.01.10.80-Gen. is solely on data which can be collected in real time by
means of field instruments and devices, or generated as real time trips or alerts in Process
Management and Control System Model Level 1,2,3 systems such as the Distributed
Control System.
There are other critical but non-real-time production data, for example, data from manual
samples for computing watercut, or the quality of a particular production system model.
This DEP does not address the criticality of this category of production data.
DEP 59.01.10.80-Gen., does NOT specify or set minimum standards for the overall well
and facilities design for safeguarding and process operability, maintenance requirement or
control room monitoring. The aspects of DEP 59.01.10.80-Gen. touching on Integrity and
Maintenance requirements are for information or cross reference only.
Criticality with respect to process safety is not in the scope of this DEP or the
DEP 59.01.10.80-Gen. but should be maintained via existing Technical Integrity
management processes such as DEP 32.80.10.10-Gen. In the event of contradictions
between DEP 32.80.10.10-Gen. and this DEP; the requirements of the former shall take
precedence. It is also not the intent of this DEP to specify or determine requirements for
the basic wells and process facilities operability during start-up or normal operations, which
will be part of the Wells and Process Engineering design.

3.3 RTO DATA CRITICALITY RANKING

3.3.1 General requirements for the provision of real time data
The instrumentation and data acquisition systems design of a Greenfield or Brownfield
project shall propose an Asset Real-Time Data Criticality Ranking. This is a list of RTO-
required data with criticality ranking of HIGH and MEDIUM or LOW applicable to the asset
consistent with Principal’s Operational Excellence requirements. The design will then
provide field data acquisition and availability in the Office Domain Data Services Layer for
all RTO-required data with criticality ranking of HIGH and MEDIUM as a minimum.
A proposal for the Asset RT Data Criticality Ranking shall be based on a review of the
DEP 59.01.10.80-Gen. The proposal shall document reasons for reducing the criticality of
any item ranked H or M in DEP 59.01.10.80-Gen.
The proposed list of HIGH and MEDIUM data sources shall be reviewed for completeness
at the development stage as part of the Well, Reservoir and Facilities Management and
Smart Fields screening process.
3.3.2 Data criticality spreadsheet
The data criticality spreadsheet DEP 59.01.10.80-Gen. contains several tabs, each of
which states the data criticality for a well type or facility or production unit based on the
necessity of the data in the execution of key work processes for the day to day
management of production. The work processes forming the basis for the criticality
rankings are as follows:
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 19

• Well / Artificial Lift Operating Envelope Surveillance, including Exception Based

Surveillance for Wells
• Well Test Monitoring & Optimisation
• Well Production Rate Measurement / Estimation
• Well Integrity
• Validation and Calibration of Integrated Production System Models and selected
measurements
• Day to Day Management of Secondary and Tertiary Injection and Recovery
• Operation within Facilities Operating Envelops at Train or Separator Level, including
during Start-up and Shutdown, and all data from IPF systems, and for Optimization
• Flow Assurance & Chemical Injection Management
• Facilities Integrity and Leak Detection.
• Record and Reconcile Well and Overall Production, including Custody Transfer
Metering
• Record of Production Facilities Consumption, Emissions and Flaring.
All data required for the above processes are ranked MEDIUM or HIGH.
Specifically:

HIGH The data is essential for at least one of the processes considered
and the loss of the data point may result in the potential loss of
greater than 100 kUSD or 2500 barrels of oil equivalent production
per month, or equivalent in loss optimization opportunity.

MEDIUM The data is essential for at least one of the processes considered.

LOW The data is not essential for the processes considered, but will
assist in a detailed analysis.

BLANKS The data is not used by the processes considered.

The data points provided should be regarded as a starter set for the Asset RT Data
Criticality Ranking, providing minimum requirements. For assets with special requirements,
more data points will need to be added or the indicated criticalities will have to be adjusted
to reflect the specific requirements.
The data point listing is provided for the following wells and facilities groups:
1. All well types, including naturally flowing oil and gas wells, gas lifted wells, ESP
wells, rod-driven PCP wells, beam pumped wells and injection wells (water and gas).
2. Well Testing Facilities
3. Oil Production, Storage and Export Facilities
4. Gas Production and Export Facilities.
For specialized systems such as Rotating and Reciprocating Equipment and Heaters,
more detailed requirements for process data to be monitored are set out in the specific
equipment DEPs, for example, DEP 31.29.00.11-Gen. for Rotating and Reciprocating
Equipment.
The following comments apply to the Wells Sheet in DEP 59.01.10.80-Gen.
1. This sheet does not specify whether the following data is required or not to be included
as part of the design:
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 20

• Down hole instrumentation and controls such as downhole pressure gauges or

inflow control valves.
• Well down hole pump / artificial lift instrumentation.
• Well flowline multiphase meters.
This DEP Standard Form sheet merely specifies the requirements for the automated
acquisition and management of the above data from the above devices, IF they are
provided as part of the flowline or well completion design.
2. For other less common well types not listed in the DEP 59.01.10.80-Gen., the
identification of the production critical data shall be identified in consultation with the
Principal.
3.3.3 Operational data quality monitoring and remediation
Process data with Asset RT Data Criticality Ranking of HIGH shall be provided with data
quality indicators. Data quality indicators shall include out of range, flatline and drop out
alerts as a minimum, and ideally include generic data quality checking as per (Appendix 1).
The data quality indication system should allow an overall level of monitoring and the
construction of key performance indices on the availability of the data.
The requirements for data quality shall be confirmed with the Principal’s RTO
representative. A service level agreement integrating L0 – L4 real time services and
automation and controls maintenance organizations shall be put in place to rectify data
quality issues.
3.3.4 Real-time data lifecycle support requirements
In a Greenfield project, the production RTO data acquisition design shall be coordinated
with the Principal’s overall data management plan for the management of production RTO
data for the design, commissioning and operational phases of the asset.
The production RTO data is required to be managed within the overall strategy for
Engineering Data management. The Contractor shall liaise with the Principal to confirm the
requirements for the data and tag systems.
The Contractor shall identify early in the plant-design stage sensors which will eventually
generate real-time data for RTO. Sensors from wells, including subsurface sensors and
controls, shall be identified as part of a number of well delivery activities. At this point, the
engineering tag names should be created according to the guidelines in
DEP 32.10.03.10-Gen. The engineering tag names list shall include subsurface sensors
and controls.
The tag naming for sensors at this stage is related to the function block tagging within the
DCS. These tags are unique per plant. Such tag specifications should form part of the
information handed over by the Engineering Contractor to the Principal.
Tag names used in the Process Data Historian, EDW and ultimately the ERP system
(e.g., SAP) shall contain the plant name and the tag name from the DCS to ensure
traceability back to the DCS.
The Contractor shall liaise with the Principal to determine Data Validation requirements to
be addressed as part of the Contractor-designed data acquisition architecture.
When well, facility or process plant alterations indicate a sensor is no longer required; the
sensor is decommissioned in accordance with the Principal’s Management of Change
process. The data acquired from the sensor up to the decommissioning of the sensor shall
be retained in the long term Process Data Historian indefinitely, and shall not be deleted
unless there are specific instructions otherwise.
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 21

4. REFERENCES
In this DEP, reference is made to the following publications:
NOTES: 1. Unless specifically designated by date, the latest edition of each publication shall be used,
together with any amendments/supplements/revisions thereto.
2. The DEPs and most referenced external standards are available to Shell staff on the SWW (Shell
Wide Web) at http://sww.shell.com/standards/.

SHELL STANDARDS
DEP feedback form DEP 00.00.05.80-Gen.
Condition monitoring of rotating equipment DEP 31.29.00.11-Gen.
Process Control Domain - Enterprise industrial automation DEP 32.01.20.12-Gen.
information technology and security
Instrument symbols and identification on process engineering flow DEP 32.10.03.10-Gen.
schemes
DCS basic application standards DEP 32.30.20.15-Gen.
Baselayer control applications DEP 32.30.20.16-Gen.
Instruments for measurement and control DEP 32.31.00.32-Gen.
Instrumented Protective Functions (IPF) DEP 32.80.10.10-Gen.
Alarm management DEP 32.80.10.14-Gen.
Standard form (spreadsheet) for data criticality assessment DEP 59.01.10.80-Gen.
ECCN EAR99 DEP 32.01.40.31-Gen.
February 2014
Page 22

APPENDIX 1 BASIC GENERIC DATA CHECKING

Functions Checking rules Remarks

This signal is independent of
Process Data Historian and
does not rely on Process Data
Historian interfaces to eliminate
Heartbeat Is the transmitter operational?
the problem of knowing whether
the transmitter is working even
when the interface is down
(which happens sometimes).
Out of range Values are outside zero and span Zero and span attributes in
attributes defined in the Process Data Process Data Historian do not
Historian tag database. necessarily indicate instrument
range. Also they may not be
updated to reflect changes at
DCS.
Out of physical Is the sensor within the operating Invalid signals like negative
range range? pressures, impossible high
pressures, etc.
Flatlining Values are frozen beyond a certain time Rules may be true for some but
period depending on the measurements not true for the others.
group :-
Flows – xxx min For example, it is acceptable for
Pressures – xxx min flow values from standby
Levels – xxx min facilities (e.g., metering station,
genset, etc.) to be frozen.
etc.
Drifting Can only be detected with
redundant sensors, or with
other sensors and an
appropriate model.
Spikes Sharp excursions from normal
range not due to changes in the
monitored process.
Missing data Values are: Possible returned value for
“bad data” or “bad input” or “CONN missing data, depending on
closed” etc. Process Data Historian
Interface configuration.
Inconsistent Check that the parameter values and This is a very common source
Units engineering units are consistent across of errors.
the transmitter, DCS, Instrument dB
and Process Data Historian.