Computer Physics Communications 38 (1985) 301—308 301

North-Holland, Amsterdam

SOFTWARE SYSTEMS DEVELOPMENT IN PETROLEUM ENGINEERING

D.J. BROWNING, G.M. CAIN, N.P. CARMICHAEL, F.G. GOULDSTONE, A.W. WADSLEY,
S.J. WEBB and P. WINDER
IPEC International Petroleum Engineering Consultants Ltd., 18 Hanover Square, London WJA 2BB, UK

Many approaches to designing software systems have been developed for use in commercial or business environments. These
development methods and procedures have improved dramatically over the last ten years although it is only recently that these
have been employed in scientific and technological applications. Many of these implementations have been unsuccessful
because the design methodology has been divorced from the practical requirements of the industry in which the software
system is to operate. This paper discusses a modern approach to software development which directly relates to an
engineering environment and which is designed to satisfy practical criteria of acceptability of the software when delivered to
the petroleum engineer. Since all field developments nowadays rely heavily on associated software systems, the approach
presented here can lead to improved mechanical systems reliability and shorter development/design cycles.

1. Introduction and review of software development
procedures
This paper presents our recent developments in
the area of computer software production. In corn-
mon with many other successful endeavours, these
developments have come about as a result of tak-
ing a fresh look at some old (and some new)
problems, producing a solution which generalised
the specifics, and then discovering that the solu-
tion had much more potential than was initially
realised.
At the beginning of 1984 IPEC International
Petroleum Engineering Consultants had the rare
opportunity of starting with a completely “blank
sheet” upon which to develop software products
for the petroleum engineering Industry. From the
(large) set of published methods our choice of
software development procedures had to relate to
the industry which we service and to the nature of
the products that were then required and would be
required in future. In particular, we needed to
meet the dual requirements of long-term economic
(and hence profitable) software development to-
gether with the broader satisfaction of software-
user needs. In effect, we had to develop a con-
sistent and unchanging (sic) software framework
for our interactive Petroleum Engineering prod-
ucts. To put our approach in context we will
briefly review some of the existing procedures for
software development.
It is our contention that the major barrier to
successful software development is poor cornmuni-
cation. The oft described software development
cycle can be represented as a “handling over” or
translation of specifications from one stage to the
next in the production chain, culminating in a
series of tests that all too frequently demonstrate
that the pudding, having been eaten, is not proven.
Major pioneering work by Dijkstra, Constan-
tine and others in the 1960’s which defined sound
principles for software design, have, during the
70’s, been refined by others to produce a wealth of
alternatives for system and program design. Each
method inevitably has strengths and weaknesses,
largely associated with the environment within
which is applied, be it real time systems, tradi-
tional commercial data processing, or interactive
engineering and scientific work.
The methods of Constantine and Myers, de
Marco and Yourdon can broadly be grouped to-
gether in contrast with Jackson’s JSD (system de-
sign) and JSP (structure programming) methods.
The Structured Analysis and Design Technique
(SADT) has associated with it PSL/PSA (Problem
Statement Language/Problem Statement Analy-

0010-4655/85/$03.30 © Elsevier Science Publishers B.V.

(North-Holland Physics Publishing Division)
302 D.J. Browning et a!. / Software systems in petroleum engineering
sis). Many of these and related methods have
corresponding software aids to development, pro-
ject control and code generation. Whilst some of
these methods are still evolving, we would claim
that all fail in one or more respects in providing
effective tools for developing software. We should,
however, report that in order to derive our soft-
ware development environment, the initial product
framework was developed using a form of JSD.
The major weakness of these methods in our
industry is the fundamental lack of a requirement
specification language which would enable our
engineers and users to specify their requirements
in detail and then subsequently change them
without considerable disruption to the develop-
ment process. More importantly, the software sys-
tem design or program design can be difficult to
relate to the original requirement specification
without an appropriate design language which is
understood by the engineer. Of the better known
methods, we have found the Jackson methods to
have a notation which is most successful in this
role. However, we believe that none of the pub-
lished methods provide a direct link between what
a customer wants and what a software develop-
ment group might provide.
The system that is described in the following
sections has a proven track record and overcomes
many of thes’e difficulties, with added benefit.
2. Petroleum engineering industry environment
The Petroleum Industry is conservative in its
outlook. This is not because it is opposed to in-
novation, but because the gain from such innova-
tjon must be seen to be in excess of the cost of
introducing and providing the new technique or
product. This conservatism has meant that the
introduction of computer technology itself has been
slow particularly regarding the use of modern
techniques for writing technical software. Tradi-
tionally, the writing of such ‘applications’ software
has been the preserve of the working engineer
himself, and as such, many of the existing pro-
grams used by petroleum engineers are hand-
calculation methods written in FORTRAN 66 or
BASIC and implemented on a main-frame or,
nowadays, a micro computer.
Historically the Petroleum Industry has moved
from an era dominated by the large (batch-on-
ented) mainframes of the late sixties and seventies
such as IBM and UNIVAC, to the interactive
mini-mainframes commonly in use now, such as
the VAX series. This change, although offering a
wider range of service, has not necessarily been for
the better as far as the working engineer is con-
cerned. Once the limitations of a batch service are
well understood, the petroleum engineer usually
has a consistent computer resource on which to
execute his program. Thus if the turnaround (job
submission to receiving the final output) time was
known to be overnight, then the engineer would
schedule his own working day to accommodate
this. His main demand for increased computing
speed and memory size came, not so much from
requiring an instant turnaround, but more from
the size and nature of his petroleum engineering
problems — this is especially so in oil reservoir
simulation where the CRAY and CYBER 205
series of computers are now routinely used.
On the other hand, while the petroleum en-
gineer may be able to use a mini computer more
easily for interactive work, the low power of these
machines has meant that large jobs either run
slowly or take an unknown time to complete de-
pending on system usage, or must be run on a
suitably powerful batch processor. This alternative
is obviously the most time and cost effective. How-
ever the environment where more than one com-
puter system is being used places a new burden
upon the engineer who must ensure that he not
only knows the operating systems for each type of
computer and the communications protocols be-
tween the computers, but also that the various
programs he is using have compatible data for-
mats. Given that the petroleum engineer tradition-
ally wrote his technical engineering software him-
self, or if not it was written for a specific computer
or environment, he is rapidly finding that the
current computer environment of micros, minis
and powerful scientific processors is not compati-
ble with his existing software or concepts.
While it may appear to be a truism that such
recent innovations as local area networks (LAN’s)
improve the resource available to the user, unless
he can access these effectively then the more likely
 Di. Browning et a!. / Software systems in petroleum engineering
effect of their use is to reduce his efficiency. It has
been observed by some of the major oil companies
that as their networking of computers and systems
increases, their engineers spend more and more of
their time attempting to solve communications and
other ‘computer’ problems rather than having more
time to solve their engineering problems.
Moreover, it is no longer acceptable for the
engineering user to create and write his own soft-
ware. This task — once seen as a mere technical
activity is now more complex due to the need to
— software be usable. The term ‘usuable’ is clearly
ensure portability of programs between computers,
and also the need to take advantage of the interac-
tive capability of modern computer systems such
as high resolution graphics and screen addressing.
On the other hand, as each job or activity within
the petroleum engineering profession becomes
more specialised there is an increased demand for
software which supports each specialism and which
also can be used by other engineers whose own
expertise may lie elsewhere. The task of specifying
such programs is itself a difficult and time con-
suming activity.
3. User requirements
The petroleum industry has a strong need for
scientific applications software because it is now
moving away from the traditional central
mainframe and tending towards increased use of
individual workstations and local area networks. It
is pertinent to reconsider the question of what the
user requirements of applications software are.
Having asked and answered that question we will
discuss our formalised approach for satisfying these
requirements.
The petroleum industry has, in the past, suffered
greatly from ill-conceived, poorly designed and
incomprehensibly implemented software, simply
because there was nothing else available. It is only
more recently that better quality software has come
onto the market. However, it is our belief that the
user’s requirements have never changed; these are
predominantly reliability, usability and extendabil-
ity. This list is not exhaustive, but it does cover the
major areas.
A major user requirement for any software
303
product, particularly an interactive product, is that
it be reliable. In the petroleum industry it is not
uncommon for software packages to be used at
several different locations, some of which may be
geographically distant for maintenance support.
This demands that good design and thorough test-
ing are highly important considerations in any
proposed new software development for the oil
industry.
Another major user requirement is that the
open to many interpretations, and it is not dif-
ficult to see that usability from an engineering
standpoint does not necessarily correspond to the
definition of the term as seen from the designer’s
or implementary viewpoint. To ensure that the
software meets basic engineering usability require-
ments, it is crucial that the software is not devel-
oped in a vacuum, but that petroleum engineering
involvement exists at all stages of the develop-
ment, from conception, through the specification,
analysis, design implementation and testing phases.
This does not reduce the role of the software
engineer, but on the contrary enhances it, as is
illustrated by considering the third major user
requirement, extendability.
It is not uncommon at the specification stage of
a new software product to be presented with the
dilemma of knowing ‘in principle’ what the pun-
pose the product will fulfill or what particular
operation problems it will address, together with a
corresponding lack of clarity of the particular fea-
tunes and techniques that should be incorporated.
Historically, this has often been facetiously stated
as “The user never really knowns what he wants
until he has seen what he does not want”.
Clearly the software engineer has an important
role to play in determining from the user/engineer
what level of importance to associate with panticu-
lar features, and what degree of confidence to
associate with particular techniques, since he is
able to provide sensible measures of their impact
on the system development from the quantifiable
measure of design, analysis, implementation or
testing efforts required.
This stage is critical in a consulting environ-
ment where success is often achieved by quickly
providing reliable, usable but less extensive soft-
304 Di. Browning ci a!.
ware into a new market, whilst also ensuring that
the software has a “strong extendability” for fu-
tune upgrades.
Having analysed the criteria that can have
bearing on decisions about product development,
we will now describe more formally our software
development environment. Usability and extenda-
bility will now be dropped from development tech-
niques, since, although they are user requirements,
they are satisfied by strong software engineer—pet-
roleum or reservoir engineer interaction at the
product specification stage and through its total
development cycle,
4. The interactive applications framework
Given the trend in the Petroleum Engineering
Industry towards interactive engineering work-
stations, IPEC decided at the beginning of 1984 to
build a software framework which would be suita-
ble for all the interactive products that it would
develop. The specific requirements of this frame-
work were that it should:
(i) provide the user with easy and readily under-
standable access to the application-specific
soitware,
(ii) enhance the maintainability of the product;
(iii) be straightforward to add new analysis meth-
ods and other modules to existing application
k which is accessed by IPS to configure the specific
pac ages, . .
(iv) afford significant saving in cost and time of
developing a product;
(v) enhance the portability of software from one
computer to another.
The design of the framework broadly followed the
Jackson System Design method. The need for the
framework to be appropriate for all interactive
applications in petroleum engineering required the
formulation of a generalised model of an interac-
tive application. In any application the user may I
have a choice of data sources, to each of which he
may, in turn, apply a choice of analysis methods
and select one of a variety of means to display and
save the results. Thus the structure of data input,
analysis and output has a hierarchical infrastruc-
tune each branch of which terminates with an
/ Software systems in petroleum engineering
executable “process” such as one of the appli-
cation-specific analysis procedures. Each process
has associated with it status information and “at-
tributes” created by the execution of that process
and accessibly by other processes in the system.
So far we have described a model of an interac-
tive application which is simply structured as a
selection of processes. However, in general an
interactive application has more structure than
this. Subsets of processes frequently have a natural
sequence in which they have to be invoked and this
structure, too, must be reflected in the model. We
have, therefore, defined a concept of “antecedent
relationships” between processes such that one or
more processes may be specified as pre-cursors or
antecedents for any particular process in the sys-
tem. A trivial example of this is the need to
execute a “GET DATA” process before an “EDIT
DATA” process can be invoked.
The user-interface system is, simply, then an
interactive scheduler which enables the user to
activate any of the processes subject to the con-
straints defined by the antecedent relationships.
The resultant software framework is called the
Interactive Process Scheduler (IPS).
. .
Each interactive petroleum engineering product
will have its own topology of menus, sub-menus
and processes, further defined by the antecedent
. .
relationships. To satisfy the requirements of IPS,
. . .
listed above, this topology is specified as data
. . .
. application software. Thus the IPS software re-
mains unchanged from one product to the next.
.
The general structure is shown schematically in
. .
fig. 1. Each antecedent relationship is a sequenced
.
set of logical AND constructs. For example,
processes A. AND B. AND C. precede process D.
Situations in which logical ‘OR’ constructs natu-
rally arise (e.g. A. OR B. precedes C.) are handled
by requiring A. and B. to appear in the same
menu. As such, the antecedent relationships im-
pose a structure on the menus which has a high
degree of cohesion and low coupling.
The advantages that IPS gives to the user and
to the supply and maintenance of the product are
many. Moreover, the structured design of IPS, and
the application structure being defined as data to
IPS provide what is, in effect, a software develop-
 Di. Browning et a!. / Software systems in petroleum engineering 305

which is close to the “language” of the user;

Menu Definition (ii) is common to all our interactive products and
(selections)
ps thus enhances the maintainability of the
Antecedent ReIatio~J ~ delivered system;
(sequences) (iii) enables the system design to be evaluated
~ against the user requirements before the pro-
cess modules are designed.
(iv) results in fast product development.
I II I • • • I
(Applications Processes) 5. Software development techniques
Fig. 1. General Structure of the interactive process scheduler.
Given the IPS system framework described
above, the primary objectives underlying our ap-
ment environment. There is also a very tight rela- proach to software design and development are:
tionship between the user specification and the
1) reliability,
application design; before any of the process
software is written, the system can be configured 2) maintainability,
3) flexibility,
according to the user-specification, executed as the
4) comprehensibility.
user interface would appear, and easily re-config-
ured if found to be inappropriate. In order to achieve these objectives, the devel-
In our experience, for interactive applications, opment of a software system is divided into six
engineers/users specify the product requirements stages:
as a set of results that they want to obtain, each 1) specification statement of the problem to
preceded by a specification of the data and meth- be solved;
ods that should be used to achieve them. This 2) analysis establishment of the tech-
specification is, then, a set of sequences of activi- niques to be used to solve the
ties or processes, each of which can be directly
mapped onto the antecedent relationships, and problem;
3) design realisation of a software struc-
from which the menus may be structured.
The separation of the application-specific ture representing
solution an optimum
to the problem;
software into individual processes which corn- 4) implementation transformation of theinto
soft-
municate only via the process data areas enforces ware design structure a
an appropriately early definition of the data struc-
tures in the design process and enable the individ- working system via a pro-
ual process design and implementation tasks to be gramming
5) testing validation language;
of a system perfor-
sensibly allocated amongst the product develop-
ment team. The antecedent relationships also pro- mance;
6) documentation accurate user and mainte-
vide a natural sequencing of process development. nance reference document.
In addition, for complex interactive applications,
these relationships can be automatically analysed Considerable effort is expended in arriving at a
to generate a development schedule and critical complete and precise specification of the problem
path for project planning. to be solved, and where appropriate, this func-
In summary, the IPS System: tional specification will contain criteria for both
intermediate and final acceptance testing, together
(i) uses a data definition to configure the appli- with specific requirements, where for example, the
cations software, which relates directly to the target hardware configuration imposes particular
user-requirement and is structured in a way constraints.
306 Di. Browning et a!. / Software systems in petroleum engineering
Where established mathematical and en-
gineening techniques are to be employed, the anal-
ysis stage is generally straightforward. However, if
new techniques are to be derived, rigorous analyses
are presented where necessary.
The software systems design is accomplished
using IPEC’s approach to structured system de-
sign. This utilizes primarily those aspects of exist-
ing methods which have been found to be most
applicable,
The transformation of the system design into a
working system is performed using a high-level
programming language. In general, implementa-
tion is performed in FORTRAN 77, adhering to
the strict ANSI definition of the language in order
to ensure portability of software between different
manufacturers’ hardware. Hardware operations
which are device dependent such as video terminal
input/output are isolated from the hardware-inde-
pendent portions of the software in order to
facilitate portability by simple interchange of
module function libraries.
Following implementation, and where ap-
propriate at intermediate stages during imple-
mentation, the system operation is tested. The
successful completion of acceptance testing results
in the completion of the software system develop-
ment programme.
Documentation is performed as an integral
component of each of the primary development
stages and, upon completion, constitutes a corn-
plete record of the system development,
In concluding this section, we would like to
draw specific attention to the implementation
phase. Many design methods often define very real
problems as ‘implementation’ problems and then
dismiss them. Perhaps this again reflects the com-
mercial data processing origin of many of these
methods. We are particularly concerned that the
implementation results in a transportable product,
since this ensures primarily that multiple versions
of a product do not exist, and secondly that all
truly system dependent aspects are isolated. How-
ever, it is also imperative that a recognised stan-
dard (or a restricted subset of that standard) form
the basis of such an implementation since this
standard becomes a measure and reference for any
real installation difficulties. This, for example,
would allow us to identify whether in fact the
compiler or some other piece of the manufacturers
software was at fault if a package did not be-
nchmark correctly at a given installation site on a
particular machine. This is important since corn-
pilers are just software products, and as such
suffer from all the traditional design/implementa-
tion flaws. However, they have been exempted
from scrutiny previously due to the lack of an
independent standard syntactical definition of the
implementation language.
6. Example: RADPAC — A Reservoir Appraisal and
Development Package
RADPAC is a reservoir engineering package
which enables the user to describe and evaluate the
behaviour of oil and gas reservoirs. It comprises a
series of separate but logically complementary
processes that at the lowest level describe individ-
ual parameters of the reservoir system for exam- —
ple the pressure—volume—temperature (PVT) be-
haviour of the component reservoir fluids and at —
the highest level describe reservoir performance
for varying production strategies.
The processes describing the system may be
summarised as
— reservoir fluid and rock properties including
—
the PVT parameters;
— description of individual areas of the reservoir
and sets of these areas in terms of their poros-
ity, permeability and flow
flow into
structures;
— performance of fluid the well bore and
within the well tubing itself;
— production performance and behaviour of injec-
tion wells used as a strategy to increase produc-
tion;
and finally
— estimation of recovery volumes and field decline
and at which point economic limitations be-
come a factor.
The package is therefore a series of data manipu-
lation and calculation procedures performed upon
a clearly definable group of datasets. A process
may require only one input dataset based perhaps
on original experimental data, or alternatively may
 Di. Browning ci a!. / Software systems
require a group of datasets which themselves have
been generated by one or more previous processes.
Further, several versions of a given dataset may
exist reflecting user experimentation,
Under IPS each category of evaluation fluid — bounded or unbounded.
and rock properties etc. becomes controlled via
— A well test interpretation package, such as
a group of linked menus with the individual calcu-
lation process Gas PVT data for example as
— —
the lowest menu in a sequence. Once defined the
IPS antecedent definition file ensures the presence
of all required input datasets for a process and will
provide diagnostic information if they are not.
Required subsidiary procedures such as editing,
review or reporting of datasets are also provided in
the menu options. User selection of methods or
parameters within a process are handled by IPS
utilities and errors trapped and returned to the
user for correction.
RADPAC is used in an environment where
after initial data input and build up of datasets the
user will return to the package to make minor
adjustments to various values throughout the suite.
At this time the user will have acquired some
familiarity with the package, and the IPS keyword
definition system enables direct transfer to any
point in the structure by the entry of the ap-
propniate menu of process name.
As additional process requirements are defined
RADPAC incorporates them via simple modifi-
cation of the hierarchy definition files in IPS. It
follows from this that IPS has in no way imposed
limitations on the RADPAC user. The user may
create, delete or modify any dataset while being
guided by the IPS help framework or jump to any
section he requires. The individual interpretative
skills of the reservoir engineer are thus preserved,
7. Example: WIPER An Interactive package for
— 8. The future
performing welt test interpretation
Well testing is the measurement of reservoir
pressure in the well either during production from
a well or after production from a well has been
stopped. The analysis of a well test is concerned
with comparing this measured data with theoret-
ical pressure trends derived from solutions of the
radial flow equation in a porous medium with the
in petroleum engineering 307
appropriate boundary conditions (constant termi-
nal rate). The nature of these solutions is affected
by such factors as the proximity of faults (no flow
boundaries), or whether the drainage area is
WIPER, must allow the user to compare measured
pressure data with a variety of theoretical models
and quantitatively measure the “goodness” of each
comparison.
Typically, a user will select one or more theoret-
ical models to compare with his measured data.
The software environment which IPS imposes
on the application is particularly appropriate for
well test analysis for two reasons. Firstly, the
menu structure is a natural structure for this appli-
cation, because the application decomposes easily
into a number of well defined processes, from
which the user may then select the processes neces-
sary for the particular analysis required. Secondly
the anticedent logic present in IPS only allows the
user to execute a process when all its antecedent
processes have been successfully completed. For
instance, an analysis is only allowed once all the
measured data has been successfully entered, hence
preventing the user from proceeding with data
which is inappropriate.
Additionally, well test analysis, in common with
most other analytical methods in engineering, is
not a stationary art. New analytical techniques are
always being devised. The IPS software environ-
ment allows these new processes to be added to
WIPER simply by providing the software modules
to perform the new processes and by altering the
menu definitions file to reflect the existence of
these new processes.
To date we have had eight months experience
with IPS and have developed a numbers of IPS-
based products. We can see the possibility of
exploiting further levels of generality of IPS as
well as a number of directions in which IPS will
evolve.
We intend to develop further the requirement-
specification aspects of the data definition struc-
308 Di. Browning e a!. / Software systems in petroleum engineering

ture of IPS. We wish to reduce the scope for
ambiguity or gaps in the specification and misun-
derstanding on the part of the system designer.
It is a simple extension to IPS to enable it to
initiate processes on remote processors. Thus it is
possible to enhance the power of micro-computer-
based Petroleum Engineering work stations by
scheduling computationally intensive activities,
such as reservoir simulation on remote mainframes.
In this sense IPS can be regarded as an industry or
application-specific, portable “operating system”.
The industry trend towards engineering work-
stations will, we believe, result in companies
establishing Local Area Engineering Networks and
IPS is already structured to accommodate this
development.