Pipe System Domain Models

(1)

1

Pipe System Domain Models ^∗

Examples of Informal and Formal Descriptions Research Notes

Dines Bjørner

DTU Informatics, Techn.Univ.of Denmark bjorner@gmail.com, www.imm.dtu.dk/~db

May 18, 2012: 17:01

Abstract

Oil and gas pipe lines are being increasingly monitored and controlled by computerised systems involving sensors and actuators attached to the pipe line units: wells, pumps,compressors, pipes,valves,forks,joins and sinks of the pipe lines, with these units possibly being powered by solar systems and able to communicate data to and

from satellites and with these communicating with computers. In this paper we shall 2

try bring a new area of computer science and software engineering in closer contact with researchers of fluid mechanics and engineers designing pipe lines, including their IT systems. The paper is evolving. Today we just present one of three models of pipe

lines. In Sect. 1 we formulate the problem of describing a domain of pipe systems 3

for liquid and gaseous systems. In Sect. 3 we describe the non-temporal aspects of pipe lines. The description is both informal and formal. In this paper we use the RAISE[34] specification languageRSL[33]¹. Sect. 6 is presently absent. It shall show how we extend the description of Sect. 3 with temporal properties. For that we use theDuration Calculus [38]. It then behooves us to show that the temporal model

integrates with the model of Sect. 3. Sect. 8 is presently missing. It shall show how 4

we extend the description of Sects. 3 and 6 with fluid dynamics properties. The formal description is a simplification in terms of a set of Bernoulli (etc.) differential equations². It now behooves us to show that the fluid dynamics model integrates with the models of Sects. 3 and 6. In Sect. 9 (Conclusion) we sketch a programme of research aimed at bridging the integration gaps between the temporal model of Sect. 6 and the standard model of Sect. 3, and the fluid dynamics models of Sect. 8 and the models of Sects. 3 and 6.

∗/home/db/2012/pipsys/pipes

1See also [1, 2, 3]

2http://www.efm.leeds.ac.uk/CIVE/CIVE2400/

http://www.google.dk/url?sa=t&rct=j&q=fluid%20dynamics%2C%20pipe%20lines&source=web&cd=4&ved=0CE4QFjAD&url=h

(2)

2 Pipe System Domain Models

I A Basic Model 14

5 A Basic Model 14 5.1 Units, Oil and Monitoring & Control System . . . 14

5.2 Pipeline Unit Parts . . . 15

5.2.1 Connectors and Connections . . . 16

(3)

Examples of Informal and Formal Descriptions 3

5.2.2 Routes . . . 17

5.2.3 Wellformedness . . . 18

5.2.4 Fluid . . . 19

5.2.5 Flows and Leaks . . . 20

5.2.6 Laws of Flows and Leaks . . . 21

Unit Flow . . . 21

Connection Flow . . . 22

5.2.7 Attributes . . . 22

5.3 Actions . . . 22

5.3.1 Starting and Stopping Pumps . . . 22

5.3.2 Opening and Closing Valves . . . 23

5.3.3 Discussion . . . 23

5.4 Events . . . 23

5.5 Behaviours . . . 23

5.6 Discussion. . . 23

II A Temporal Model 23

6 Temporal Properties 24

III A Process Model 24

7 A CSP Process Model 24 7.1 Preliminary Notions . . . 24

7.2 Overview of Processes . . . 24

7.3 Overview of Channels . . . 25

7.4 Process Definitions . . . 25

7.4.1 System Process . . . 25

7.4.2 Well Processes . . . 26

Signature . . . 26

Definition . . . 26

Discussion . . . 26

7.4.3 Pump Processes . . . 27

Signature . . . 27

Definition . . . 27

Discussion . . . 27

7.4.4 Pipe Processes . . . 28

Signature . . . 28

Definition . . . 28

Discussion . . . 28

7.4.5 Valve Processes . . . 29

Signature . . . 29

Definition . . . 29

Discussion . . . 29

(4)

7.4.6 Fork Processes . . . 30

Signature . . . 30

Definition . . . 30

Discussion . . . 31

7.4.7 Join Processes . . . 31

Signature . . . 31

Definition . . . 31

Discussion . . . 32

7.4.8 Sink Processes . . . 32

Signature . . . 32

Definition . . . 32

Discussion . . . 32

7.4.9 Monitor & Control Process . . . 33

Discussion . . . 34

7.5 Discussion. . . 34

IV A Fluid Mechanics Model 34

8 A Fluid Mechanics Model 34 8.1 Some Preliminary Thoughts . . . 35

9 Conclusion 35 10 Bibliographical Notes 35 10.1 The Notes . . . 35

10.1.1 Domains: Methodology and Theory Papers . . . 35

10.1.2 Experimental and Explorative Domain Descriptions. . . 36

10.1.3 Lecture-oriented Notes on Domain Engineering . . . 37

10.2 References . . . 37

(5)

1 The Problem

⁵

1.1 The Setting

These are the pipeline units that we consider: wells,pumps,compressors,pipes,valves,forks, joins and sinks of the pipe lines, with these units possibly being powered by solar systems and able to communicate data to and from satellites and with these communicating with

computers. ⁶

Figure 1: The planned Nabucco pipeline: http://en.wikipedia.org/wiki/Nabucco Pipeline The first “thing” one is informed about when a new pipeline is contemplated is a “picture”

like Fig. 1. The next “thing” IT-specialists are informed about is the main structure of ⁷ the comtempated control system, see Fig. 2.

Figure 2: Pipeline Diagrams

1.1.1 But Pictures Lie ⁸

But Figs. 1–2 give a false impression of the computerisation problem. They focus on “what can be seen” of the problem. But the overall system software which links vastly distributed sensors and actuators with satellites and to more-or-less distributed somputers. does not map easily onto such figures. Fig. 1 shows nothing of the complexity of pipeline nets. And producers of pipeline monitoring and control software, cf. Fig. 2, usually wishes to develop their software for more than the one specific pipeline for which they got a first order.

(6)

1.1.2 Generic Software ⁹

So the “one-of-a-kind” software system “quickly” emerges into what is thought of a generic software, i.e., a product line. Differences in pipeline net layouts, their units, their sensors and actuators, in the communication system and in the topology of the distributed computers soon emerge into ad hoc patches in the “product line”.

1.2 Our View on Proper Software Development for Pipelines

¹⁰

To develop monitoring & control, maintenance, and other software for pipelines to us means: to research and develop an “as generic as possible”, both informal, narrative, and formal, mathematical, description of an “as large as possible” pipeline domain; to study and develop a variety of requirements for a similar variety of pipeline IT systems; and from these design the various software packages, all fitting into some base softare for pipelines.

11

In this document we shall cover only the domain descrption phase of the above-sketched development cycle. Section 3 presents a basis for generic descriptions of pipelines. To do a proper description of pipelines involve visits to pipelines, interacting with pipeline engineers, both construction engineers and mechanical (fluid dynamics) engineers, and studying the literature, initially some introductory texts, viz., [32, 36, 37] The present document has resulted only from some rudimentary studies of papers and Internet-based documents on pipelines. We apologise. But we are rather sure that a proper engineering, i.e., a full-scale domain description can take advantage of the start made here.

1.3 The Structure of This Report

¹²

First we note that this report is preliminary. It is not yet complete, not even its Part I.

And Parts II–III are missing: yet to be worked out. The report is structured around three major parts: Part I models pipelines in a model-oriented (computing science) specification language [33]. Part II adds to the model of Part I temporal notions using the Duration Calculus temporal logic language [38]. Part III is hoped to model pipeline units using classical notions such asBernoulli Equations. Sections 3–4 cover some prelinary pipeline notions.

1.4 The Research Aspect of This Report

¹³

To give a domain description of pipelines in terms of some model-oriented (computing science) formal specification language, such as RSL[33] (Part I), fails, even when extended with temporal logic formulas (Part II). Only when also described using such mathematical apparatus as Bernoulli equations (Part III) may we succeed to a best possible description today, May 18, 2012. Herein lies the research problem: To “merge” model-oriented

14

(computing science) formal specifications (which lack continuity and hence can not be differentiated nor integrated) with (classical) mathematical analysis — that is our aim.

(7)

2 Project Plan

¹⁵

This report outlines a project currently under way. It first started in the fall of 2008 as a student project for PhD students during my lectures at the Technical University of Graz, Austria. It was then briefly revived during my stay at Edinburgh University in Sept.–Oct., 2009, with the aim of show colleagues at Edinburgh an example of “real-life” real-time, safety critical embedded IT systems. I have now, Spring/Summer 2012 taken it up as (one of) my research project(s) at my “return” to DTU Informatics as an Emeritus Professor.

I hope with this, the “pipeline system” project, to engage with other DTU institutes and with industry.

2.1 Dines Bjørner’s Work

¹⁶

Basic Model

Temporal Model

Process Model

Model Fluid Dynamics

Figure 3: A “Pipeline System” project graph

17

From the point of view of research that I intend to pursue reference is made to Fig. 3.

Fig. 3 currently shows four boxes. The Basic Modelbox refers to the research and development of a domain description for pipelines expressed sˆolely in RSL, the Raise Specification Language[33]. TheTemporal Modelbox refers to the research and development of a domain description for pipelines which expresses temporal properties. The specification notation is that of RSL“extended with” DC, the Duration Calculus [38]. The Process Model expresses, notably using the CSP, Communicating Sequential Pprocesses [35], features of RSL, the research development of a domain description for pipelines as systems of concurrent pipe unit behaviours. The Fluid Dynamics Model box express the research and development of a description of pipeline units in terms of the mathematics conventionally used by fluid

dynamics scientists and engineers. ¹⁸

The status (May 18, 2012) of the research is as follows. Currently we could be said th have “completed” essential parts of theBasic Model. Working out the essential parts of the Temporal Model, it is hoped, would involve one of the creators of DC, my colleague Michael

(8)

Reichhardt Hansen [38]. That work may be started over the summer of 2012 and last the rest of 2012. Simultaneously the work on the Process Model can be absolved over the Summer of 2012. The research and development of the Fluid Dynamics Model is expected to commence early Fall 2012. It is hoped that this R&D would involve colleagues at DTU Fluid Dynamics. First contacts will be made before the end of June 2012.

2.2 Goals of the Planned Pipeline System R&D

¹⁹

The overall aims of the planned research is twofold. One, aresearchgoal, is to understand what pipelines are, in general. A part of this goal is to reconcile the model-oriented computing science models such as expressed by the Basic, the Temporal and the Process discrete model descriptions with the continuous time fluid dynamics models. The other

20

goal is a moreexperimental, engineering goal. It is to build a demo, a simulator [16], of pipeline monitoring & control software, where this software can be used to “test” ideas of pipeline units, in particular their design and their monitoring & control.

2.3 Student Projects

²¹

It is hoped that students, having followed Dr. Anne E. Haxthausen’s Spring 2012 course could be interested in one or another facet of the Pipeline System project: (i) “completion”

of the Basic Model, (ii) “completion” of the Temporal Model, (iii) “completion” of the Process Model, (iv) contributions to the Fluid Dynamics Model. (v) contributions to the Pipeline System Demo & Simulator, etcetera. Some such projects could be in the form of term projects, or pre MSc thesis projects, M Sc. Thesis projects, or even PhD projects.

3 A Simple Pipe System

²²

This is the first section in which we exemplify combinations of informal (narrative) and formal (mathematical) description of, in this case, pipelines. The section is organised as follows: First, Sect. 3.1, we bring an informal only rough sketch. Then we illustrate examples of pipeline units: wells, pumps,compressors, pipes, valves,forks, joins and sinks

3.1 An Informal Rough Sketch

²³

We shall discuss Fig. 4 on the next page.

24

Figure 4 on the facing page shows two wells, to the left, each with one output connector (•), two sinks, to the right, each with one input connector, twenty four pipes, each with one input and one output connector, four pumps, each with one input and one output connector, one valve with one input and one output connector, one fork with one input connector and two output connectors, and one join with two input connectors and one out connector; for a total of thirty five one pipeline units and thirty three connections.

25

(9)

W F

W

S

W Well, ^S Sink, Pump, Valve, ^F Fork, J Join, Pipe, J

Connection

Figure 4: An example pipeline net

The pipes between wells and (as here) pumps usually consists of a few pipe units. The pipes before sinks usually consists of fewer pipeline units than shown. Pumps “to the left” usually serve to drain the wells. Pumps “to the right” usually serve to fill the sinks.

Other pumps usually server to force the liquid or gaseous material “uphill” over hills and mountains. Valves serve to close flow of liquid or gaseous material. ²⁶

So we conclude this first rough-sketch analysis by observing that a pipeline system centers around anetof pipeline unitsof different kinds: wells(Sect. 3.2.1),pumps(Sect. 3.2.2), compressors (Sect. 3.2.3 on page 11), pipes (Sect. 3.2.4 on page 11), valves (Sect. 3.2.5 on page 11),forks (Sect. 3.2.6 on page 13),joins (Sect. 3.2.7 on page 13) and sinks(Sect. 3.2.8 on page 13)

3.2 An Aside on Pipeline Units

²⁷

3.2.1 Wells 28

3.2.2 Pumps ²⁹

Figure 5: Gear, Lobe, Rotary Vane and Screw Pumps

30

(10)

A pump displaces a volume by physical or mechanical action. A positive displacement pump causes a fluid to move by trapping a fixed amount of it and then forcing (displacing) that trapped volume into the discharge pipe. Positive displacement pumps, unlike centrifugal or roto-dynamic pumps, will in theory produce the same flow at a given speed (RPM) no matter what the discharge pressure. Thus, positive displacement pumps are ”constant flow machines”. However due to a slight increase in internal leakage as the pressure in- creases, a truly constant flow rate cannot be achieved. A positive displacement pump must not be operated against a closed valve on the discharge side of the pump, because it has no shut-off head like centrifugal pumps.

The power imparted into a fluid will increase the energy of the fluid per unit volume.

Thus the power relationship is between the conversion of the mechanical energy of the pump mechanism and the fluid elements within the pump. In general, this is governed by a series of simultaneous differential equations, known as the Navier-Stokes equations.

However a more simple equation relating only the different energies in the fluid, known as Bernoulli’s equation can be used. Hence the power, P, required by the pump:

P = ∆P Q η

where ∆P is the change in total pressure between the inlet and outlet (in Pa), and Q, the fluid flowrate is given in m³/s. The total pressure may have gravitational, static pressure and kinetic energy components; i.e. energy is distributed between change in the fluid’s gravitational potential energy (going up or down hill), change in velocity, or change in static pressure. η is the pump efficiency, and may be given by the manufacturer’s information, such as in the form of a pump curve, and is typically derived from either fluid dynamics simulation (i.e. solutions to the Navier-stokes for the particular pump geometry), or by testing. The efficiency of the pump will depend upon the pump’s configuration and operating conditions (such as rotational speed, fluid density and viscosity etc.).

∆P = v²2−v1²

2 + ∆zg+∆pstatic ρ

∆P is the difference, P2 −P1, between the outlet and the inlet. v2 and v1 are the respective velocities.

For a typical ”pumping” configuration, the work is imparted on the fluid, and is thus positive. For the fluid imparting the work on the pump (i.e. a turbine), the work is negative power required to drive the pump is determined by dividing the output power by the pump efficiency. Furthermore, this definition encompasses pumps with no moving parts, such as a siphon.

31

(11)

Examples of Informal and Formal Descriptions 11 Main Applications ISO 13709 / API 610 type BB1,

Heavy duty pump for upstream and downstream petroleum, petrochemical, and power generation applications

Maximum Speed of rotation 5,000 rpm

Discharge sizes 150mm to 750mm (6 to 30 inches) Capacity up to 10,200 m3/h (up to 45,000 usgpm)

Head up to 500 m (up to 1,650 ft) Maximum pressure up to 125 bar (up to 1,800 psi)

Materials API 610 Material Classes:

S-4, S-5, S-6, S-8, C-6, A-8, D-1, D-2, 317L Bearing Options Ball/Ball, Sleeve/Ball, Sleeve/Pivot Shoe

Lubrication Ring oil, optional purge mist, pure mist or pressure fed Temperatures -29 - 205^oC (-20 - 400^oF)

3.2.3 Compressors 32

33

Figure 6: Gas Compressor

3.2.4 Pipes ³⁴

Oil pipelines are made from steel or plastic tubes with inner diameter typically from 4 to 48 inches (100 to 1,200 mm); most pipelines are typically buried at a depth of about 3 to 6 feet (0.91 to 1.8 m); the oil is kept in motion by pump stations along the pipeline, and usually flows at speed of about 1 to 6 metres per second (3.3 to 20 ft/s). ³⁵

For natural gas, pipelines are constructed of carbon steel and vary in size from 2 to 36

60 inches (51 to 1,500 mm) in diameter, depending on the type of pipeline. The gas is pressurized by compressor stations and is odourless unless mixed with a mercaptan odorant where required by a regulating authority.

3.2.5 Valves 37

There are basically two kinds of valves: block valve and regulator stations.

(12)

Figure 7: Pipes

Block valve stations These are the first line of protection for pipelines. With these valves the operator can isolate any segment of the line for maintenance work or isolate a rupture or leak. Block valve stations are usually located every 20 to 30 miles (48 km), depending on the type of pipeline. Even though it is not a design rule, it is a very usual practice in liquid pipelines. The location of these stations depends exclusively on the nature of the product being transported, the trajectory of the pipeline and/or the operational conditions of the line.

38

Figure 8: Block Valve Stations

Regulator stations: This is a special type of valve station, where the operator can release some of the pressure from the line. Regulators are usually located at the downhill side of a peak.

39

(13)

3.2.6 Forks ⁴⁰

3.2.7 Joins ⁴¹

3.2.8 Sinks 42

Sinks are final delivery stations. They are known also as outlet stations or terminals, and is where the product will be distributed to the consumer. It could be a tank terminal for liquid pipelines or a connection to a distribution network for gas pipelines.

4 A Preliminary Analysis

⁴³

4.1 Parts

We informally analyse further attributes of pipeline units.

4.1.1 Unique Unit Identifiers

In order to distinguish among the many well, pipe, pump. valve, fork, join and sink units we endow each with a unique identity, π : Π. However we otherwise formalise the pipeline units we say that we can observe the unique unit identifier from units. We do not mandate any representation of these unique unit identifiers.

4.1.2 Connectors ⁴⁴

Connectors can be thought of as non-physical in the sense that they do not “occupy” space ! We then see that wells and sinks have one output, respectively one input connector; pipes, valves, and pumps each have both an input and an output connector; forks have one input connector and two output connectors; and joins have two input connectors and one output connector. Connections are seen as pairs of connectors. Connectors and connections are ⁴⁵ distinct kinds of concepts. Connectors and connections are not considered to be physically existing parts. We choose to represent connectors by the pipeline unit to which they are

“associated”. And we choose to represent connections by pairs of connectors, that is, by pairs of unique unit identifiers, one is the output connector of one unit, the other is the input connector.

4.1.3 Routes of Nets ⁴⁶

Pipeline systems are created, by liquid or gaseous material companies, in order to trans- port liquid or gaseous materials over usually great distances. Therefore pipeline units are connected such as to form routes from wells to sinks. A route is any connected sequence of zero or more adjacent units. We define routes so as to allow circular, but, in fact, undesirable routes. We then constrain nets to not contain circular routes.

(14)

14

4.1.4 Wellformedness of Nets ⁴⁷

The way in which we describe how units form nets require that we express a number of constraints on the attributes of pipeline units.

4.1.5 Part Attributes ⁴⁸

Pipeline units have attributes. One attribute is a unique unit identifier. Each unit has its own distinct, hence unique unit identifier. Another attribute prescribe how units are connected. And then there are the unit properties. There are the geometrical properties of units. Then there are the cadestral properties of units: their absolute location in some spatial system: an (X, Y, Z) or a spherical coordinate system (r, θ, φ). And there are the flow and leak properties of units. There may be many additional properties such as we shall see next.

4.1.6 Flows and Leaks ⁴⁹

The whole purpose of a pipeline system is to ‘flow’ liquid or gaseous material from one point to another. Each unit participates in this flow. So flow characteristics, laminar and turbulent, static and dynamic, of units are properties of these. So are leaks of liquid or gaseous material from a unit: the maximum allowable normal leakage, a quantity expected to be well below the laminar flow; the laminar flow (maximum); the minimum flow that causes turbulence; etcetera.

4.2 Actions

⁵⁰

4.3 Events

⁵¹

4.4 Behaviours

⁵²

53

Part I

A Basic Model

5 A Basic Model

⁵⁴

5.1 Units, Oil and Monitoring & Control System

1. The overal system, ∆, consists of three sets of parts:

a there is the aggregation, PS, of pipeline units,

(15)

15 b there is the liquid (gas or oil), and

c there is a monitoring & control system.

type 1. ∆, PS value

1a. obs PLS: ∆ →PS

The liquid is seen as part of then therefore composite units ofPS. The monitoring & control system will not be covered in this part.

5.2 Pipeline Unit Parts

⁵⁵

2. From a pipe system one can observe a set of pipeline units.

3. A pipeline unit is either a well (Well, We), or a pump (Pum, Pu)³, or a pipe (Pipe, Pi), or a valve (Valv, Va), or a fork (Fork, Fo), or a join (Join, Jo), or a sink (Sink, Si).⁴^,⁵

56

type 2. PS value

2. obs PLUs: PS → PLU-set type

3. PLU = Well|Pum|Pipe|Valv|Fork|Join|Sink 3. U = We|Pu|Pi|Va|Fo|Jo|Si

3. We, Pu, Pi, Va, Fo, Jo. Si value

3. Well == mkWe(u:We) 3. Pum == mkPu(u:Pu) 3. Pipe == mkPi(u:Pi) 3. Valv == mkVa(u:Va) 3. Fork == mkFo(u:Fo) 3. Join == mkJo(u:Jo) 3. Sink == mkSi(u:Si)

3We model only pumps. The modelling of compressors for gaseous pipe lines follows that of the modelling of pumps for fluid pipelines.

4As a technicality, to ensure that each of these seven [eight] kinds of pipeline units are distinct we define each of them by amake-constructor.

5Attributes of each of the seven kinds of pipeline units will be outlined as we unfold the description.

(16)

16

5.2.1 Connectors and Connections ⁵⁷

4. To deal with the concept of connection and, in general, to make sure that all pipeline units are uniquely distinguishable, we introduce the notion of unique pipeline unit identifiers, Π.

5. With each pipeline unit we associate two mereology functions:⁶^,⁷

a one mereology observer, uid Π, observes the unique identifier of the pipeline unit,

b the other mereology observer,mer io Π, observes the pair, (ips, ops), of identities of the pipeline units which provide inputs to, respectively accept outputs from the observed unit.

c We can then define separate functions which extract i. the input connectors, respectively

ii. the output connectors of any unit.

58

type 4. Π

5. ioΠs = Π-set× Π-set value

5a. uid Π: (PLU|U) →Π 5b. mer ioΠ: (PLU|U) → ioΠs 5c. xtr iΠ: PLU → Π-set 5c. xtr oΠ: PLU → Π-set

5(c)i. xtr iΠs(u) ≡ let(ips, )=mer ioΠ(u) in ipsend 5(c)ii. xtr oΠs(u) ≡ let( ,ops)=mer ioΠ(u) in ops end

59

6. Observer mer ioΠ is subject to some constraints: for every pipeline unit a its unique identifier is not in its pair of io unique identifier sets and b these have no unique identifiers in common;

c a well has one output.⁸^,⁹;

6Mereology functions are a form of observers. They contribute to observing the mereology of the net:

how it is composed from pipeline units, how they connect to one another.

7The oberserver functions apply to bothPLUs andUs.

8A well can connect to one pipeline unit, usually a pump (or a pipe)

9We shall deal with the meaning and means of connection later and with the constraint of only con- necting to specific kinds of pipeline units later.

(17)

17 d a pump has one input and one output;

e a pipe has one input and one output;

f a valve has one input and one output;

g a fork has one input and two outputs;

h a join has two inputs and one output; and i a sink has one input.

60

axiom

6. ∀ u:PLU^•

6. let(ips,ops) = mer ioΠ(u) in 6a. uid Π(u) 6∈ ips∪ ops ∧ 6b. ips∩ ops = {} ∧ 6. (card ips,card ops) = 6. caseu of

6c. mkWe(we) →(0,1), 6d. mkPu(pu) → (1,1), 6e. mkPi(pi) →(1,1), 6f. mkVa(va) → (1,1), 6g. mkFo(fo)→ (2,1), 6h. mkJo(jo) → (1,2), 6i. mkSi(si) →(1,0), 6. end end

5.2.2 Routes ⁶¹

7. The observed pipeline units of a pipeline system define a number of routes (or pipelines):

a Any one pipeline unit, u, with unique identifier π, of a pipeline system forms a route, hui, of length one.

The null sequence of no units is a route.

b Let r_ibhuii and hujibr_j be two routes of a pipeline system.

c Let πi and πj be the unique identifiers ui, respectively uj.

d If one of the output connectors, oci, of ui isπj – in which case one of the input connectors, icj, ofuj isπi – thenribhui, ujibrj is a route of the pipeline system.

62

(18)

18 type

8. R = PLU^ω value

8. routes: PLS→^∼ R 8. routes(pls) ≡

8. letplus = obs PLUs(pls) in

8a. letrs = {hi} ∪ {hui|u:PLU^•u∈ plus} ∪ 8d. ∪{ribhuiibhujibrj

8b. |ribhuii,hujibrj:R ^•{ribhuii,hujibrj}⊆rs 8d. ∧uid Π(uj)∈ xtr oΠs(ui)

8d. ∧uid Π(ui)∈ xtr iΠs(uj)}

8. rsend end

5.2.3 Wellformedness ⁶³

8. The observed pipeline units of a pipeline system forms a net subject to the following constraints:

a unit output connectors, if any, are connected to unit input connectors;

b unit input connectors, if any, are connected to unit output connectors;

c there are no cyclic routes;

d nets has all their connectors connected, that is, “starts” with wells and “ends”

with sinks.

64

value

8. wf Net: PLS →Bool 8. wf Net(pls) ≡

8. letplus = obs PLUs(pls) in 8. ∀ u:PLU^• u ∈plus ⇒

8. let (ips,ops) = met ioΠ(u) in 8. axiom 6.–6i.

8a. ∧ ∀π:Π^•π ∈ ips⇒

8a. ∃ u^′:PLU^•u^′6=u∧u^′ ∈ plus∧uid Π(u^′)=π ∧ π ∈ xtr oΠs(u^′) 8a. ∧ ∀π:Π^•π ∈ ops ⇒

8a. ∃ u^′:PLU^•u^′6=u∧u^′ ∈ plus∧uid Π(u^′)=π ∧ π ∈ xtr iΠs(u^′) 8b. ∧ ∀r:R^•r∈ routes(pls) ⇒

8b. ∼∃i,j:Nat^•i6=j∧{i,j}∈ inds r∧r(i)=r(j) 8c. ∧ ∃we:We ^• r(1) = mkWe(we)

8c. ∧ ∃si:Si ^• r(lenr) = mkSi(si) 8. end end

(19)

19

5.2.4 Fluid ⁶⁵

A pipeline system, besides the pipeline system units and the monitor & controller, consists, for each pipeline system unit, of liquids. That is, liquid (either gas for all units or oil for all units, is part of any unit. Since liquids are continuous in form and shape and comes in any volume we shall accept that although we can observe, from any unit, its contents of liquid, that contents may be zero, or it may be as large as the volume of that unit. We leave it as an attribute of the entire pipeline system as to what kind of liquid it transports:

oil (and then which kind of oil) or gas (etcetera). ⁶⁶

9. One can observe from any pipeline system unit its volume of liquid.

10. Attributes of liquids are a temperature, b velocity,

c viscosity, etcetera.

We think of these attribute functions as applying to pipeline system units.

11. There are two auxiliary “measurers” which applies to pipeline system units and yields a the internal volume of pipeline system, respectively units, and

b the current volume of liquid in pipeline system units.

12. The current liquid volume of any pipeline unit is at most that of the internal volume of the pipeline unit.

67

type

9. O, Temp, Velo, Visc, Vol value

9. obs O: (PLU|U) →O

10a. attr Temp: (PLU|U) → Temp | {na}

10b. attr Velo: (PLU|U) →Velo | {na}

10c. attr Visc: (PLU|U) → Visc | {na}

11a. mea int Vol: (PLU|U) → Vol 11b. mea liq Vol: (PLU|U) → Vol axiom

12. ∀u:(PLU|U)^• 0≤ mea liq Vol(u)≤ mea int Vol(u)

(20)

20

5.2.5 Flows and Leaks ⁶⁸

Flow and leak are measured in terms of amount of mass transferred across a plane boundary (an area) per unit of time. Fluid material mayFlow into and out from pipeline units. and Leak from the pipeline units. We identify, cf. Fig. 9, where flows and leaks can be observed:

• flow and leak at each unit input,

• leak from within a unit and

• flow and leak at each unit output.

We (perhaps arbitrarily) decide not to observe flow within units but to observe leak from units.

69

F F

Pipe Valve Pump L L

F

F L L

L ι

ι

ο ο

F L

F L L

Fork Join

F L

ο1 ι1

ο2 ι2

ι2 F

ι1 ο

ι ο ι

ο1

ο2 L

u u u

L

Figure 9: Flow and Leak observation points

70

13. We distinguish between Flow and Leak values set by the manufacturer of pipeline units and the actual (dynamic) Flow and Leak values.

14. And we locate flow and leak values to the inputs, respectively outputs of pipeline units as designated by respective input, respectively output connectors.

15. Thus we postulate, for every pipeline unit, u:PLU, a number of observer functions:

• flow into an input (Fi,i1,i2), flow from an output (Fo,o1,o2),

• leak at an input (Li,i1,i2), leak at an output (Lo,o1,o2) and

• leak from a unit (Lu).

71

type

13. M

value

13. obs M: PLU → M

14. attr F^ι,attr F^o: Π× PLU → M

(21)

21 14. attr Fι,attr Fo: Π× PLU → M

14. attr L^ι,attr L^o: Π× PLU → M 14. attr Lι,attr Lo: Π× PLU → M 15. attr L^♭: PLU → M

15. attr L♭: PLU→ M

Manufacturers of pipeline units set values for standard flows and leaks: maximumFlow below which laminar flow can be expected and maximumLeak above which serious seepage occurs.

5.2.6 Laws of Flows and Leaks ⁷²

Unit Flow

16. The (combined) flow out of a unit equals the a flow into the unit inputs,

b minus the leak at unit inputs,

c minus the leak from the unit body and d minus the leak from the unit outputs.

73

axiom

16. ∀ pls:PLS ^•

16. letplus = obs PLUs(pls) in 16. ∀u:PLU ^• u∈ plus

16. let (ips,ops) = met ioΠ(u)in 16. flow Fo(ops,u)

16a. = flow Fι(ips,u) 16b. − leak Lι(ips,u) 16c. − leak L♭(u) 16d. − leak Lo(ops,u) 16. end end

74

value

flow Fo, flow Fι, leak Lι, leak Lo: Π-set× PLU → M 16. flow Fo(ops,u)≡ U

{attr Fo(π,u)|π:Π^•π ∈ ops}

16a. leak Fι(ips,u) ≡U

{attr Fι(π,u)|π:Π^•π ∈ips}

16b. leak Lι(ips,u) ≡ U

{attr Lι(π,u)|π:Π^•π ∈ips}

16d. leak Lo(ops,u) ≡ U

{attr Lo(π,u)|π:Π^•π ∈ ops}

16c. leak L♭: PLU → M 16c. leak L♭(u) ≡ attr F♭(u)

75

(22)

22

Connection Flow

17. The flow across the input and output connections of a pipeline unit,u, is as follows:

a what flows properly into the one or two connections of a pipeline unit,u, equals b what flows out of the output connections of the one or two pipeline units, uo₁

(and possibly uo₂) connected to the input pipeline unit u c minus what uo₁ (and possiblyuo₂) leak

d minus what is leaked at u’s input connection(s).

76

axiom

17. ∀ pls:PLS ^•

17. letplus = obs PLUs(pls) in 17. ∀u:PLU ^• u∈ plus ⇒

17a. let (ips, ) = mer Πs(u)in 17b. flow Fι(ips,u)

17c.

17d.

17. end end

5.2.7 Attributes ⁷⁷

18.

19.

20.

21.

22.

23.

24.

5.3 Actions

⁷⁸

5.3.1 Starting and Stopping Pumps ⁷⁹

25.

26.

(23)

23 27.

28.

25.

26.

27.

28.

5.3.2 Opening and Closing Valves ⁸⁰

29.

30.

31.

32.

29.

30.

31.

32.

5.3.3 Discussion ⁸¹

5.4 Events

⁸²

5.5 Behaviours

⁸³

5.6 Discussion

⁸⁴

85

Part II

A Temporal Model

The basic model did not express any tmporal properties such as the time it may take for a valve to open fully from a fully closed position, or the time it may take for a pump to pump fully from a fully non-pumping state, or the time it may take for a volume of fluid to be moved from one “upstream” position in an open route of a pipeline to another, “downstream” position. ConjoiningDC:

Duration Calculus, a continuous time interval, temporal logic to RSLenables us to describe some such temporal properties.

(24)

24

6 Temporal Properties

⁸⁶

87

Part III

A Process Model

A process model of pipelines emphasise the interaction between pipeline units.

That interaction centers around the movement and seapage of fluids from one unit to the next (two if the former unit is a fork unit) as controlled by the opening and closing of valves and pumps (or compressors for gases).

The interaction, for a pipeline system, also includes themonitoringof the states of pipeline units. That monitoring is here modelled by a central monitor.

You may think of the controlling of pipeline units as excerted by the central monitor, now a general central monitor & controller.

7 A CSP Process Model

⁸⁸

7.1 Preliminary Notions

33. Letpls:PLS denote a pipeline system.

34. Letplus:PLU-setdenote the set of all pipeline system units.

35. Letpluis:PI-setdenote the set of all the unique unit identifiers of the pipeline system.

value 33. pls:PLS

34. plus:PLU-set = obs PLUs(pls)

35. pluis:

`

^PI^-set ⁼{uid Π(u)|u:PLU^•u∈ plus}

7.2 Overview of Processes

⁸⁹

36. To every pipeline unit we associate a distinct process.

value

36. well, pump, pipe, valve, fork, join, sink

We shall give the signatures of these processes in Sects. 7.4.2–7.4.8.

37. To the pipeline system we associate a monitoring & control process.

value

37. mac: Unit → in,out {mac[ uid Π(u) ]|u:PLU^•u ∈ plus} Unit

(25)

25

7.3 Overview of Channels

⁹⁰

38. To every pair of output/input connectors (πo, πi) such that the output connector πo

of some unit is connected to the input connector πi of some other, distinct unit we associate a channel.

39. To every pipeline unit we associate a channel between that unit process and the monitoring & control process.

40. For the time being we shall leave the types of the channel messages undefined.

channel

38. {uu[{o,i}]|u:PLU,i,o:Π^•u idin plus∧{i,o} ∈ iops(u)}:uuM 39. {mac[π]|π:Π^•π ∈ pluis}:umM

type

40. uuM, umM

7.4 Process Definitions

⁹¹

7.4.1 System Process

41. The pipeline system behaviour is modelled as

a the parallel composition of the pipeline unit behaviours b with the monitor & control behaviour.

value

41. system: Unit → Unit 41. system() ≡

41a. k {unit(u)|u:PLU^•u ∈ plus}

41b. k mac()

92

42. The unit function expands into either of the unit processes.

42. unit: PLU → Unit

42. unit(u:mkWe(we)) ≡ well(uid Π(u))(mkWe(we)) 42. unit(u:mkPu(pu)) ≡ pump(uid Π(u))(mkPu(pu)) 42. unit(u:mkPi(pi)) ≡ pipe(uid Π(u))(mkPi(pi)) 42. unit(u:mkVa(va)) ≡valve(uid Π(u))(mkVa(Va)) 42. unit(u:mkFo(fo)) ≡ fork(uid Π(u))(mkFo(fo)) 42. unit(u:mkJo(jo)) ≡ join(uid Π(u))(mkJo(jo)) 42. unit(u:mkSi(si)) ≡ sink(uid Π(u))(mkSi(si))

(26)

26

7.4.2 Well Processes ⁹³

Signature

43. Thewellprocess is indexed by the unique identifier of the well unit and evolves around a well state we where the well unit u=mkWe(we).

44. It offers output (i.e., fluids) on a single channel uu[uid Π(u),t] where t is the unique identifier of the only target unit.

45. It accepts inputs (sensing requests and controls) from and offers output (sensor read- ings and control responses) to the monitor and control process.

46. The unit u is in the set of all pipeline well units.

value

43. well: π:Π → u:mkWe(we) →

44. out uu[ uid Π(u),t ] where t:Π^•{t}=xtr oΠs(u) 45. in,out mac[ uid Π(u) ] Unit

46. pre: u ∈ plus ∧π = uid Π(u)

94

Definition 47.

48.

49.

50.

51.

43. well(π)(mkWe(we)) ≡ 47.

48.

49.

50.

51.

95

Discussion The well process abstracted above is a rather naive, i.e., wishful model of real well processes. For just an indication of possible, yet still abstract models of wells we refer to:

(27)

27

7.4.3 Pump Processes ⁹⁶

Signature

52. The pump process is indexed by the unique identifier of the pump unit and evolves around a pump state pu where the pump unitu=mkPu(pu).

53. It accepts input (i.e., fluids) on a single channeluu[f,uid Π(u)] where f is the unique identifier of the only source unit of the pump.

54. It offers output (i.e., fluids) on a single channel uu[uid Π(u),t] where t is the unique identifier of the only target unit of the pump.

56. The unit u is in the set of all pipeline pump units.

52. pump: π:Π → u:mkPu(pu) →

53. inuu[ f,uid Π(u) ] where f:Π^•{f}=xtr iΠs(u) 64. out uu[ uid Π(u),t ]|t:Π^•{t}=xtr oΠs(u) 55. in,out mac[ uid Π(u) ] Unit

97

Definition 57.

58.

59.

60.

61.

52. pump(π)(u:mkPu(pu)) ≡ 57.

58.

59.

60.

61.

98

Discussion

(28)

28

7.4.4 Pipe Processes ⁹⁹

Signature

62. The pipe process is indexed by the unique identifier of the pipe unit and evolves around a pipe state pi where the pipe unitu=mkPi(pi).

63. It accepts input (i.e., fluids) on a single channeluu[f,uid Π(u)] where f is the unique identifier of the only source unit of the pipe.

64. It offers output (i.e., fluids) on a single channel uu[uid Π(u),t] where t is the unique identifier of the only target unit of the pipe.

66. The unit u is in the set of all pipeline pipe units.

36. pipe: π:Π → u:mkPi(pi) →

100

Definition 67.

68.

69.

70.

71.

value

62. pipe(π)(pi) ≡ 67.

68.

69.

70.

71.

101

Discussion

(29)

29

7.4.5 Valve Processes ¹⁰²

Signature

72. The valve process is indexed by the unique identifier of the valve unit and evolves around a valve stateva where the pump unitu=mkVa(va).

73. It accepts input (i.e., fluids) on a single channeluu[f,uid Π(u)] where f is the unique identifier of the only source unit of the valve.

74. It offers output (i.e., fluids) on a single channel uu[uid Π(u),t] where t is the unique identifier of the only target unit of the valve.

76. The unit u is in the set of all pipeline valve units.

72. valve: π:Π → u:mkVa(va)→

103

Definition 77.

78.

79.

80.

value

72. valve(π)(u:mkVa(va)) ≡ 77.

78.

79.

80.

104

Discussion

(30)

30

7.4.6 Fork Processes ¹⁰⁵

Signature

81. The fork process is indexed by the unique identifier of the fork unit and evolves around a fork state pu where the pump unit u=mkFo(fo).

82. It accepts input (i.e., fluids) on a single channeluu[f,uid Π(u)] where f is the unique identifier of the only source unit of the pump.

83. It offers output (i.e., fluids) on two channels {uu[uid Π(u),t^′],uu[uid Π(u),t^′′]}, where t^′,t^′′ are the unique identifiers of the two target units of the fork.

85. The unit u is in the set of all pipeline fork units.

81. fork: π:Π→ u:mkFo(fo) →

82. inuu[ f,uid Π(u) ] where f:Π^•{f}=xtr iΠs(u) 83. out {uu[ uid Π(u),t ]|t:Π^•t ∈ xtr oΠs(u)}

84. in,out mac[ uid Π(u) ] Unit 85. pre: u ∈ plus

86. assert: u ∈plus ∧π = uid Π(u)∧ card xtr oΠs(u)=2

106

Definition 86.

87.

88.

89.

90.

91.

81.

87.

88.

89.

90.

91.

107

(31)

31 Discussion

7.4.7 Join Processes ¹⁰⁸

Signature

92. Thejoinprocess is indexed by the unique identifier of the join unit and evolves around a join state jo where the pump unitu=mkJo(jo).

93. It accepts inputs (i.e., fluids) on two channels{uu[f^′,uid Π(u)],uu[f^′′,uid Π(u)]} where f^′,f^′′ are the unique identifiers of the two source units of the join.

94. It offers output (i.e., fluids) on a single channel uu[uid Π(u),t] where t is the unique identifier of the only target unit of the join.

96. The unit u is in the set of all pipeline join units.

92. join: u:mkJo(jo)→

93. in{uu[ f,uid Π(u) ]|f:Π^•f ∈ xtr iΠs(u)}

94. out uu[ uid Π(u),t ] where t:Π^•{t}=xtr oΠs(u) 95. in,out mac[ uid Π(u) ] Unit

96. pre: u ∈ plus

??. assert: card xtr iΠs(u)=2

109

Definition 97.

98.

99.

100.

101.

92.

97.

98.

99.

100.

101.

110

(32)

32

Discussion

7.4.8 Sink Processes ¹¹¹

Signature

102. Thejoinprocess is indexed by the unique identifier of the sink unit and evolves around a sink state jo where the sink unitu=mkSi(si).

103. It accepts input (i.e., fluids) on one channel uu[f,uid Π(u)] where f is the unique identifier of the only source unit of the sink.

105. The unit u is in the set of all pipeline sink units.

102. sink: u:mkSi(si) →

103. in uu[ f,uid Π(u) ] where f:Π^•{f}=xtr iΠs(u) 104. in,out mac[ uid Π(u) ] Unit

105. pre: u ∈ plus

112

Definition 106.

107.

108.

109.

110.

102.

106.

107.

108.

109.

110.

113

Discussion

(33)

33 7.4.9 Monitor & Control Process ¹¹⁴

111. The monitor and control behaviour is abstracted in the form of the monctrl process state and its behaviour. We do not say anything in particular about this state.

112. The monctrl behaviour communicates with all the pipeline system units.

113. The monctrl behaviour alternates, non-deterministilllay internally, between

a assessing its own state, thereby possibly changing it in preparation for external actions;

b non-deterministically, externally accepting (sense or control response) input from any pipeline unit

i. using this to update its state; or

c offering, to a chosen unit, some sensor or control request, with this choice re- flected in a changed state,

i. as output whereupon the monitoring and control behaviour resumes.

114. Assessment changes the state.

115. Update likewise, based on sensor or control responses.

116. Choice updates the state while yielding a target unit and the sensor or actuator (i.e., control) request.

115

type

111. Σ [ monitor and control state ] value

112. monctrl: Σ →in,out {mac[π]:π:Π^•π ∈ pluis} Unit 113. monctrl(σ)≡

113a. monctrl(assess(σ))

113b. ⌈⌉ ⌈⌉⌊⌋ { letsocr = mac[π] ? in

113(b)i. monctrl(update socr(socr)(σ)) end 113b. | π:Π^•π ∈ pluis }

113c. ⌈⌉ let (π,sroc,σ^′) = choose sroc(σ) in 113(c)i. sroc ! mac[π] ; monctrl(σ^′) end 114. assess: Σ → Σ

115. update socr: SoCR → Σ→ Σ 116. choose sroc: Σ → (Π ×SRoC × Σ) type

115. SoCR [ sensor or control response ]

116. SRoC [ sensor requeat or control command ]

116

(34)

34

Discussion

7.5 Discussion

¹¹⁷

118

Part IV

A Fluid Mechanics Model

A fluid mechanics model of pipelines describe the flow of liquids in from well, through pipes, past valves, pumps or compressors, forks and joins and into sinks.

Previous models were expressed in basically the discrete mathematics and mathematical logic (formal) specification languages.

Thus they did not handle continuity, one could not integrate or take the derivative of their expressions.

Fluid mechanics models are usually expressed as partial differential equations (PDEs).

8 A Fluid Mechanics Model

¹¹⁹

Fluid mechanics is the study of fluids and the forces on them. (Fluids include liquids, gases, and plasmas.) Fluid mechanics can be divided into fluid statics, the study of fluids at rest; fluid kinematics, the study of fluids in motion; and fluid dynamics, the study of the effect of forces on fluid motion. The mathematical modelling of fluid dynamics is in particular influenced by the Dutch-Swiss mathematician Daniel Bernoulli [1700–1782]

epitomised by his book Hydrodynamica [1734], and by the French engineer and physicist Claude-Louis Navier [1785–1836] and the Irish mathematician and physicist George Gabriel Stokes [1819–1903].

From Wikipedia:

The NavierStokes equations are the set of equations that describe the motion of fluid substances such as liquids and gases. These equations state that changes in momentum (force) of fluid particles depend only on the external pressure and internal viscous forces (similar to friction) acting on the fluid. Thus, the NavierStokes equations describe the balance of forces acting at any given region of the fluid.

The NavierStokes equations are differential equations which describe the motion of a fluid. Such equations establish relations among the rates of change of the variables of interest. For example, the NavierStokes equations for an ideal fluid

(35)

35 with zero viscosity states that acceleration (the rate of change of velocity) is proportional to the derivative of internal pressure.

Bernoulli’s equations for fluid dynamics can be derived from Navier-Stokes’ equations.

8.1 Some Preliminary Thoughts

¹²⁰

9 Conclusion

¹²¹

10 Bibliographical Notes

¹²²

10.1 The Notes

10.1.1 Domains: Methodology and Theory Papers

There are now a number of published papers on domain science & engineering from the point of view put forward in this report. In the reverse order of publication (latest first) we begin with a bracketed pair: [#,file.pdf] where # refers to the References below and file.pdfis to be prefixed by http://www.imm.dtu.dk/~dibj/ in order to create an appropriate access URL.

• [17, urbino-p.pdf] examines the relationship between the philosophical and logic notion of mereology and model-oriented treatments of parts (as here: pipeline nets and units).

• [18, human-p.pdf] examines possible bases for the research into and development of IT systems that, when developed from sound models of domains, may meet a number of ‘humanity’-related criteria.

• [16, maurer-bjorner.pdf] examines domain models as the basis for the development of domain demos, domain simulators, and domain monitors & controllers. The present paper, in its quest for domain demos etc., relies on the observatio made in [16].

• [13, 14,kiev-p1.pdf, kiev-p2.pdf] In the first of these references we methodically unravel a domain description, showing most facets of domain engineering. In the second of these papers we report on an emerging theory of domain descriptions.

• [20, db-psi09-paper.pdf] This paper posits that requirements engineering pursued without a prior phase of domain engineering from which significant parts of the requirements can be systematically “derived” may be the wrong way to develop software, cf. the next reference.

• [5, montanari.pdf] This paper outlines some of the stages and steps of domain engineering and some of the stages and steps of rquirements engineering — all around a common example.

(36)

36

• [15, bsm.pdf] This paper reviews the practical software engineering management notions of process assessment and process improvement as these notions are to be interpreted in the context of domain and requirements engineering.

• [21, wpdr.pdf] This paper, like [17], provides some insight into possible theoretical foundations for domain descriptions.

• [4,ictac-paper.pdf] This paper reviews salient aspects of domain engineering and posits a number of research topics suggested for further study.

• [12,facs-domain.pdf] This paper overviews stages and steps of domain engineering.

10.1.2 Experimental and Explorative Domain Descriptions 123

We list a number of URLs to reports that tackle individual domain descriptions. Except for the last entry below, the prefixhttp://www.imm.dtu.dk/~dibj/ should be put in front of the teletype identifiers given below in order to retrieve these reports from the Internet.

• Financial Service Industry(fsi.pdf) This 170+ page, incomplete draft report sketches varipus aspects of banking and securities trading.

• Stock Exchanges(tse-1.pdf) This 74 page report overlaps with the above but specif- ically models the Tokyo Stock Exchange Tading Rules.

• Container Line Industry (container-paper.pdf) This almost 100 page draft report models a comprehensive set of a container line (like, f.ex. the Danish Maersk Lines, http://www.maersk.com).

• Logistics(logistics.pdf) This draft document models some of the aspects of logistics.

• The Market: Consumers, Retailers, Wholesaler and Producers (themarket.pdf) This published paper models “a supply-chain market”.

• Window Systems, Web and Transaction Protocols(wfdftp.pdf) This incomplete report models what it (might) mean[s] to be a window system (of recursively defined windows [icons may reveal windows]), an extended SQL system, and how window editing may involve a number of [say Internet] shared “window”-like databases being updated according to the Two-phase Commit Prototocol.

• License Languages (license-languages.pdf) This paper (appearing first as [23] in [19]) models, as script languages, the commands required for (i) the downloading, editing, sub-licensing, etc. of electronic media; (ii) the creating, editing, copying, reading and trashing of public administration documents; and (iii) the computerised support of patient hospitalisaton whose actions involve anamnese, analysis, diagnos- tics, creation of treatment plans, treatments, etc.

(37)

37

• IT Security (it-security.pdf) This paper (appearing first as [31] in [19]) suggests a model for the concept of IT Security Management as described in ISO Standard ISO/IEC 17799.

• The Railway Domain (http://www.railwaydomain.org/) This Web page was estab- lished around 2003. It was intended as a focal point for acadmic R&D efforts in one or another aspect of formal software development related to one or another kind of railway and train software. Interest in this “focal point”, unfortunately, never really

“took off”.

We refer to Toward a TRain Book (http://www.railwaydomain.org/PDF/tb.pdf) as illustrating fragments of a domain model for railways systems.

10.1.3 Lecture-oriented Notes on Domain Engineering ¹²⁴

There are a number of Internet-based sets of lecture note slides on Domain Science &

Engineering. We refer to:

• 2012: Towards a Theory of Domain Descriptions – a gentle introduction: tadt-s.pdf

• 2009: From Domains to Requirement. The Triptych Approach to Software Engineering:

de+re-s.pdf

10.2 References

[1] D. Bjørner. Software Engineering, Vol. 1: Abstraction and Modelling. Texts in Theoretical Computer Science, the EATCS Series. Springer, 2006. See [6, 9].

[2] D. Bjørner. Software Engineering, Vol. 2: Specification of Systems and Languages. Texts in Theoretical Computer Science, the EATCS Series. Springer, 2006. Chapters 12–14 are primarily authored by Christian Krog Madsen. See [7, 10].

[3] D. Bjørner. Software Engineering, Vol. 3: Domains, Requirements and Software Design.

Texts in Theoretical Computer Science, the EATCS Series. Springer, 2006. See [8, 11].

[4] D. Bjørner. Domain Theory: Practice and Theories, Discussion of Possible Research Topics. InICTAC’2007, volume 4701 of Lecture Notes in Computer Science (eds. J.C.P.

Woodcock et al.), pages 1–17, Heidelberg, September 2007. Springer.

[5] D. Bjørner. From Domains to Requirements. In Montanari Festschrift, volume 5065 of Lecture Notes in Computer Science (eds. Pierpaolo Degano, Rocco De Nicola and Jos´e Meseguer), pages 1–30, Heidelberg, May 2008. Springer.

[6] D. Bjørner. Software Engineering, Vol. 1: Abstraction and Modelling. Qinghua University Press, 2008.

(38)

38

[7] D. Bjørner. Software Engineering, Vol. 2: Specification of Systems and Languages.

Qinghua University Press, 2008.

[8] D. Bjørner. Software Engineering, Vol. 3: Domains, Requirements and Software Design.

Qinghua University Press, 2008.

[9] D. Bjørner. Chinese: Software Engineering, Vol. 1: Abstraction and Modelling. Qinghua University Press. Translated by Dr Liu Bo Chao et al., 2010.

[10] D. Bjørner. Chinese: Software Engineering, Vol. 2: Specification of Systems and Lan- guages. Qinghua University Press. Translated by Dr Liu Bo Chao et al., 2010.

[11] D. Bjørner. Chinese: Software Engineering, Vol. 3: Domains, Requirements and Software Design. Qinghua University Press. Translated by Dr Liu Bo Chao et al., 2010.

[12] D. Bjørner. Domain Engineering. In BCS FACS Seminars, Lecture Notes in Computer Science, the BCS FAC Series (eds. Paul Boca and Jonathan Bowen), pages 1–42, London, UK, 2010. Springer.

[13] D. Bjørner. Domain Science & Engineering – From Computer Science to The Sciences of Informatics, Part I of II: The Engineering Part. Kibernetika i sistemny analiz, (2), May 2010.

[14] D. Bjørner. Domain Science & Engineering – From Computer Science to The Sciences of Informatics Part II of II: The Science Part. Kibernetika i sistemny analiz, (2), May 2010.

[15] D. Bjørner. Believable Software Management. Encyclopedia of Software Engineering, 1(1):1–32, 2011.

[16] D. Bjørner. Domains: Their Simulation, Monitoring and Control – A Divertimento of Ideas and Suggestions. InRainbow of Computer Science, Festschrift for Hermann Maurer on the Occasion of His 70th Anniversary., Festschrift (eds. C. Calude, G. Rozenberg and A. Saloma), pages 167–183. Springer, Heidelberg, Germany, January 2011.

[17] D. Bjørner. A Rˆole for Mereology in Domain Science and Engineering. Synthese Library (eds. Claudio Calosi and Pierluigi Graziani). Springer, Amsterdam, The Netherlands, 2012.

[18] D. Bjørner. Domain Science and Engineering as a Foundation for Computation for Human- ity. Computational Analysis, Synthesis, and Design of Dynamic Systems. CRC [Francis &

Taylor], 2012. (eds.: Justyna Zander and Pieter J. Mosterman).

[19] D. Bjørner. Domain Engineering: Technology Management, Research and Engineering. A JAIST Press Research Monograph (# 4), March 2009. This Research Monograph contains the following chapters: [22, 24, 25, 26, 27, 28, 29, 30, 31, 23]. Bjørner will post you this 507 page book (with 77 fine photos of “all things Japanese”, in full colours, taken by Dines in 2006) provided you e-mail your name and address and post international reply postage coupons (http://en.wikipedia.org/wiki/International reply coupon) toDines Bjørner, Fredsvej 11, DK-2840 Holte, Denmark in the total amount of: Denmark 60.50

(39)

39 Kr., Europe 126.00 Kr., elsewhere 209.00 Kr. [Postal prices are going up.] You should also be able to obtain it from Prof. Kokichi Futatsugi, kokichi@jaist.ac.jp.

[20] D. Bjørner. The Role of Domain Engineering in Software Development. Why Current Requirements Engineering Seems Flawed! InPerspectives of Systems Informatics, volume 5947 ofLecture Notes in Computer Science, pages 2–34, Heidelberg, Wednesday, January 27, 2010. Springer.

[21] D. Bjørner and A. Eir. Compositionality: Ontology and Mereology of Domains. Some Clarifying Observations in the Context of Software Engineering inJuly 2008, eds. Martin Steffen, Dennis Dams and Ulrich Hannemann. In Festschrift for Prof. Willem Paul de Roever Concurrency, Compositionality, and Correctness, volume 5930 of Lecture Notes in Computer Science, pages 22–59, Heidelberg, July 2010. Springer.

[22] Dines Bjørner. [19] Chap. 1: On Domains and On Domain Engineering – Prerequisites for Trustworthy Software – A Necessity for Believable Management, pages 3–38. JAIST Press, March 2009.

[23] Dines Bjørner. [19] Chap. 10: Towards a Family of Script Languages – – Licenses and Contracts – Incomplete Sketch, pages 283–328. JAIST Press, March 2009.

[24] Dines Bjørner. [19] Chap. 2: Possible Collaborative Domain Projects – A Management Brief, pages 39–56. JAIST Press, March 2009.

[25] Dines Bjørner. [19] Chap. 3: The Rˆole of Domain Engineering in Software Development, pages 57–72. JAIST Press, March 2009.

[26] Dines Bjørner. [19] Chap. 4: Verified Software for Ubiquitous Computing – A VSTTE Ubiquitous Computing Project Proposal, pages 73–106. JAIST Press, March 2009.

[27] Dines Bjørner. [19] Chap. 5: The Triptych Process Model – Process Assessment and Improvement, pages 107–138. JAIST Press, March 2009.

[28] Dines Bjørner. [19] Chap. 6: Domains and Problem Frames – The Triptych Dogma and M.A.Jackson’s PF Paradigm, pages 139–175. JAIST Press, March 2009.

[29] Dines Bjørner. [19] Chap. 7: Documents – A Rough Sketch Domain Analysis, pages 179–200. JAIST Press, March 2009.

[30] Dines Bjørner. [19] Chap. 8: Public Government – A Rough Sketch Domain Analysis, pages 201–222. JAIST Press, March 2009.

[31] Dines Bjørner. [19] Chap. 9: Towards a Model of IT Security — – The ISO Information Security Code of Practice – An Incomplete Rough Sketch Analysis, pages 223–282. JAIST Press, March 2009.

Pipe System Domain Models