Flow Measurement

Investigating Domain Model Integration Processes Arnoud Vermeij Masters Thesis Version 1.0 Index
Index 1 Overview of Figures 4 1. Introduction 5
1.1 Introducing the problem 5
1.2 Main Question 6
1.2.1 Problem Area 6
1.2.2 Problem Definition 6
1.2.3 Research Questions 7
1.3 Method 8
1.3.1 Literature 9
1.3.2 Empirical Data 9
1.4 Structure of this thesis 10 2. Theoretical Framework 11
2.1 Introduction 11
2.2 Game Theory 12
2.2.1 Components of a game 12
2.2.2 Game form 14
2.2.3 Types of Two Person-games 15
2.2.4 Strategies 17
2.2.5 Solutions and equilibriums 20
2.3 Negotiation 23
2.3.1 Negotiator's profile 23
2.3.2 Negotiation strategies 24
2.3.3 Emotion 28
2.3.4 Studying negotiation 29
2.4 Domain Modeling and Digital Architecture 30
2.4.1 Systems, Models and the Application Landscape 30
2.4.2 Modeling Styles and Strategies 31
2.4.3 Modeling Processes 31 3. Domain Description: Flow Measurement 33
3.1 Metering 33
3.2 Pressure 33
3.2.1 Pressure metering 34
3.3 Temperature 35
3.3.1 Temperature metering 36
3.3.2 Stream metering 37
3.4 Flow Units 37
3.4.1 Reynolds Number 38
3.5 Flow Meters 38
3.5.1 Differential producers 38
3.5.2 Linear Flow Meters 39
3.5.3 Calibration 42
3.6 Flow Computers 43
3.7 Supervisory Systems 44
3.7.1 Redundancy 45
3.8 Products 46
3.8.1 Gas 46
3.8.2 Liquids 49 4. eXLerate - Modeling Oil and Gas Metering Systems 51
4.1 Introduction 51
4.2 Displays 52
4.3 Database and Communication 56
4.3.1 Query and Protocol Table 57
4.3.2 Tag Database 57
4.4 Animations and Graphics 59
4.4.1 Animations 59
4.4.2 Editing 60
4.4.3 Alarms 60
4.4.4 Events 61
4.4.5 Other Features 61
4.5 Calculations 61
4.6 Reports 63
4.7 Internal calculations 64 5. Data Analysis 65
5.1 Introduction 65
5.2 Where not to start 65
5.3 How to get started 66
5.3.1 Analytical versus pragmatic 67
5.3.2 Creating a Family Tree 67
5.3.3 Early negotiations 68
5.3.4 No negotiation required? 69
5.3.5 Negotiation with an External Party 70
5.3.6 Concluding the first phase 71
5.4 The actual modeling process 72
5.4.1 Making Models 73
5.4.2 Testing Models 73
5.4.3 Communication 74
5.4.4 Concluding the process 74
5.5 Integrating Models 75
5.5.1 An iterative-incremental process 75
5.5.2 Techniques for integration 78
5.5.3 Communication and negotiation 79
5.6 Model Integration - Light Version 81
5.6.1 Begin 82
5.6.2 Middle 82
5.6.3 End 83
5.6.4 Communication 83
5.7 Integrating two equal models 84
5.8 Integration with higher/lower level models and systems 85
5.9 Additional Information 87
5.9.1 Easy elements 87
5.9.2 Difficult elements 87
5.9.3 Suggestions and observations 89
5.10 Wrap up 91 6. Conclusions 92
6.1 Introduction 92
6.2 Answers to the support questions 92
6.2.1 How do the participants experience the process of model
integration? 92
6.2.2 Which roles can be distinguished during the collaboration? 93
6.2.3 Does a general model really represent the described domain or
does some significant part of the domain information get lost during the
model integration? 93
6.2.4 What are the most difficult activities and bottlenecks in the
process? 94
6.2.5 Is the chosen modeling method appropriate for model integration?
94
6.3 The Main Question 95
6.4 Suggestions for improvement and further research 96 References 98 Overview of Figures
Fig. 1: The principle of a manometer 34
Fig. 2: Schematic overview of the functionality of a deadweight tester 35
Fig. 3: The principle of an orifice plate 39
Fig. 4: The principle of a venturi tube 39
Fig. 5: The principle of a turbine flow meter 40
Fig. 6: the principle of an ultrasonic time-of-flight meter 41
Fig. 7: no obstacles in the meter cause no overall loss of pressure 42
Fig. 8: the Flow-X/P by Spirit IT is the latest type of flow computer. It
offers room for up to 4 stream modules. Each module itself is a small
flow computer and represents one stream. 44
Fig. 9; Architecture of a functional model made with eXLerate 2003 52
Fig. 10: Example of a stream's overview in eXLerate 2003 53
Fig. 11: System Overview in eXLerate 54
Fig. 12: Trending overview 55
Fig. 13: System settings example 56
Fig. 14: An example of a Query and Protocol Table 57
Fig. 15: An example of a Tag Database 58
Fig. 16: An example of the xAnimations table 60
Fig. 17: An example of a Calculation Sheet 63
Fig. 18: An example of a (Daily) Report 64
Fig. 19 Schematization of the model integration process 96
Introduction In this chapter the problem is introduced, specified, cut down in pieces
and expressed in terms of applicable questions that describe the problem.
Furthermore, ideas of how to answer the main research question are raised
via a description of the used methods. The structure of this thesis is also
described here. 1 Introducing the problem
During the development of an information system, the domain in which
the system is about to function should be investigated properly. This can
be done in several ways, for example by interviewing or observing domain
experts, by partaking in activities in the domain or by studying available
sources. The result of this investigation may be that several visions on
the domain, formulated from different perspectives, may be constructed.
These visions, for example a technical vision or a business vision, may be
expressed via a domain model. Domain models have, especially if represented
via a graphical notation, a strong communicative function, which should
make it less difficult for a systems architect to communicate about the
specific domain with other people, related to either the system under
construction, or the domain under investigation.
Domain models can be approached at basically four levels of ambition
(Hoppenbrouwers et al. 2005). The first level is described as the singular
level. At this level a domain can just be described as 'domain', which
means from one perspective only. A domain is considered a non-problematic
and static environment. At the second level, the elusive level, a domain
modeler acknowledges that domain knowledge is not static, but dynamic, and
that modeling is an iterative process, in which growing insight in a domain
leads to an constantly changing and (hopefully) improving domain model. At
the third level, the pluriform level, a domain modeler acknowledges that a
domain is not just one entity, but something complex that should be
described from several points of view to gain a more in-depth insight. This
should lead to several domain models, written from several points of view.
Finally, at the evolving level, a domain modeler also recognizes the fact
that domains are evolving constantly, so that new concepts may be
introduced and existing concepts may be changed or even cease to exist.
At this moment, all of the know domain modeling methods and
techniques, like, for example, ORM (Halpin, 2001) and UML (Booch et al,.
1999) are to be positioned at the singular level. This does not mean that
they are unusable for higher levels of ambition. It is very well possible
to create several models of one domain, all from different perspectives.
Communication about a domain can be more difficult than it seems at
first sight. This is especially caused by conflicting conceptions of a
domain by different people. For mutual understanding between the
stakeholders and to obtain their support for the system, it is necessary
that some consensus about one general vision on a domain is reached. To
achieve consensus about a domain, some negotiations are unavoidable. These
negotiations should eventually lead to one general domain model.
The focus of this Master's thesis lies with this process of model
integration. To be more precise: the process of model integration as
experienced by human actors. This excludes automated model integration. At
this moment, it is quite unclear and not yet described what this process of
integrating several models into one general model looks like, or if there
is even such a thing as 'the' process. The purpose of this Master's thesis
is to observe some integration processes and to link these observations to
knowledge about both modeling, negotiating and group collaboration.
Since these observations can be best made in a concrete environment
with real models and systems, the thesis itself will focus on one specific
case domain: the domain of oil and gas metering. 2 Main Question In this area the problem area is introduced and the main question is set,
as well as several supportive questions.
1 Problem Area The problem area considered here is mainly the field of information
modeling. It involves various types of actors, namely information system
designers, domain modelers, domain experts and other relevant stakeholders
who are involved in the information system development process of a certain
system.
These actors may play different roles in different situations. At this
point, two possible types of group are identified: the homogeneous group
and the diverse group. The homogeneous group consist of just one type of
actor. For example: if a group of arch