the performance and reliability modelling language mosel and ... - ijssst

AL-BEGAIN et al. THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL . . .

THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL AND ITS APPLICATION





K. AL-BEGAIN , J. BARNER , G. BOLCH , A.I. ZREIKAT Networking and Performance Engineering Research Group, Department of Computing, University of Bradford, BD7 1DP, Bradford, UK


Department of Comupter Science, University of Erlangen-N¨urnberg, Martensstr 1, D-91058, Erlangen, Germany 



k.begain, a.i.zreikat  @bradford.ac.uk, barner, bolch  @cs.fau.de

Abstract: In this paper we demonstrate the applicability of the new and powerful high-level modelling language MOSEL (MOdeling, Specification and Evaluation Language) using examples from queueing networks with finite capacity, retrial systems, and mobile networks. MOSEL allows the modelling of the functional and temporal behaviour as well as the specification of complex performance and reliability measures of many real-world systems in a straight and simple way. The core of MOSEL consists of a set of constructs to specify the possible states and state changes of the system. Additional syntax is dedicated to the description of the conditions under which transitions are allowed or prohibited. In order to model the temporal behaviour of the system properly, possible state changes can either occur immediately or after an exponentially distributed delay. In contrast to many specification languages of existing performance modelling and analysis tools, which often tend to be too verbose, most MOSEL specifications are compact but anyhow easy to understand. Moreover, MOSEL provides means by which many interesting performance or reliability measures and the graphical presentation of them can be specified straightforwardly. It is especially easy to analyse a model with different sets of system parameters. The benefit of MOSEL – especially for the practitioner from the industry – lies in its modelling environment: A MOSEL model is automatically translated into various tool-specific system descriptions and then analyzed by the appropriate tools. This exempts the modeller from the time-consuming task of learning different modelling languages. The presented examples originate from different application areas: First, we investigate models of queueing networks with finite capacity which are very important in the performance modelling of computer and manufacturing systems. Then we model a retrial system, which for example is suitable to describe the situation at airports when aircrafts are waiting for landing permission. Next, we specify a reliability model for a multiprocessor system. As a fourth example we present a model of a real system from wireless communications: The call admission control protocol in a Third Generation (3G) wireless mobile network. In all examples, the interesting performance and reliability measures are calculated after a Continuous Time Markov Chain (the underlying stochastic process of the MOSEL model) has automatically been generated and solved by standard numerical solution methods. The graphical representations of these results were created by the utility IGL (Intermediate Graphical Language) which is part of the MOSEL modelling environment. Keywords: MOSEL, system description language, GSPNs, IGL, retrial systems, finite capacity queueing networks, multiprocessor system, performance, reliability, modelling, mobile networks.

1

Introduction

cooperate in order to fulfil a common task; they can be distributed and may react to stimuli which are triggered by the system’s environment.

Performance and reliability evaluation and prediction plays a major role in the design, development, testing and maintenance of systems in many application areas. These include computer systems, communication systems and networks, manufacturing systems and various others. In many cases the following properties are characteristic for the real-world systems under investigation: Their dynamic evolution proceeds from one discrete state to another at arbitrary moments in time. Often they are composed of smaller subsystems which run in parallel and I.J. of SIMULATION Vol. 3 No. 3-4

One of the most frequently used techniques to model and evaluate the performance of such a system at the dynamic level is to represent it by a stochastic process which – roughly speaking – consists of all system states and all possible transitions between them. For an important class of stochastic processes, known as Continuous Time Markov Chains (CTMCs) [10], standard numerical algorithms can be used to compute the state probabili66

ISSN 1473-804x online, 1473-8031 print

AL-BEGAIN et al. THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL . . . ties. From these the interesting performance and reliability measures of the system can then be derived.

a mixture of methods towards the generation and solution of the underlying CTMC.

For systems whose dynamics can be described by only a few states, an experienced modeller is able to deduce the underlying stochastic process directly by inspection. Unfortunately, this is impossible for many interesting realworld systems since they tend to posess a large number of states at the stochastic process level.

These packages usually have their own textual or graphical specification language which depends largely on the underlying modelling formalism. The different syntax of the tool-specific modelling languages implies that once a tool has been chosen it will be difficult to switch to another one as the model has to be rewritten using a different syntax. On the other hand the solution of the underlying stochastic process is performed in most tools by the same standard numerical algorithms.

In this case, the investigator has to resort to a formal description technique (FDT) which is based on some mathematical theory and allows to express some or all of the system properties mentioned above at a static level. The underlying stochastic process can then be generated automatically from the static system description. Moreover, the formal description techniques facilitate the specification of the measures of interest themselves.

Starting from these observations the development of MOSEL is based on the following idea: Instead of creating another tool with all the components needed for system description, state space generation, stochastic process derivation, and numerical solution, we focus on the formal system description part and exploit the power of various exisiting and well tested packages for the subsequent stages.

In the last decades, several modelling formalisms have been developed and used for performance and reliability modelling in various problem domains. Among these, Generalized Stochastic Petri Nets (GSPN) [1] and Stochastic Process Algebras (SPA) [14] turned out to be especially useful as they allow a combined description of the functional and temporal system behaviour including the specification of phenomena like priorities, synchronization and preemption. Queueing Network Systems [19] is another widely used modelling formalism which does not reach the expressiveness of GSPN and SPA but instead supports solution algorithms by which the desired performance measures can be calculated extremely fast.

MOSEL [5] is a modelling environment which comprises a high-level modelling language that provides a very simple way for system description. In order to reuse existing tools for the sytem analysis, the environment is equipped with a set of translators which transform the MOSEL model specification into various tool-specific system descriptions. Figure 1 gives an overview of performance and reliability modelling and analysis using the MOSEL-environment: 1. The modeller inspects the real-world system and generates a high-level system description using the MOSEL specification language. He also specifies the desired performance and reliability measures using the syntax provided by MOSEL. He passes the model to the environment which then performs all following steps without user interaction.

GSPN and SPA are high-level modelling formalisms in which the modeller gives a static description of the system structure and behaviour using a textual (SPA, GSPN) or graphical (GSPN) syntax. In order to analyse the functional and temporal behaviour of the system the set of dynamic system states – the state space – has to be generated out of the static model. This is accomplished in both formalisms by a set of semantic rules which is used to derive the complete state space from a start state given in the high-level description. Once the state space has been generated it can be automatically transformed into a stochastic process, which in most cases forms a CTMC. The analysis of the system is then completed by solving the sytem of linear equations which is given by the generator matrix of the CTMC.

2. The MOSEL environment automatically translates the MOSEL model into a tool-specific system description, for example a CSPL-file suitable to serve as input for SPNP. 3. The appropriate tool (i.e. SPNP) is invoked by the MOSEL-environment. 4. The state space of the model is generated by the tool according to the semantic rules of its modelling formalism out of the static model description.

Fortunately, there exists a variety of (freeware and commercial) tools which are based on one of the high-level modelling formalisms mentioned above: SPNP [24], GreatSPN [11] and WebSPN[9] are based on GSPNs, whereas TIPP [13] and PEPA [15] are built around the SPA modelling formalism. Other packages, for example PEPSY [18] and QNAP2 [25] favor the queueing theoretical approach, whereas SHARPE [21] and MOSES [10] use I.J. of SIMULATION Vol. 3 No. 3-4

5. The semantic model is mapped onto a stochastic process. 6. The stochastic process is solved by one of the standard numerical solution algorithms which are part 67

ISSN 1473-804x online, 1473-8031 print

AL-BEGAIN et al. THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL . . . of a retrial system in section 4 and specify a reliability model for a multiprocessor system in section 5. Finally, we present a sophisticated model of a 3G mobile communications network in section 6. The paper is concluded at the end with some remarks.

of the tool. The results of the numerical analysis are saved in a file with a tool-specific structure. 7. The MOSEL-environment parses the tool-specific output and generates a result file (sys.res) containing the performance and reliability measures which the user specified in the MOSEL system description. If the modeller requested graphical representation of the results, a second file (sys.igl) is generated by MOSEL.

2

Real System

In this section we explain the structure of the MOSEL model specification and demonstrate the application of the language constructs using a simple queueing network model.

2

1 High Level sys.msl System Description

sys.tn

sys.c

sys.m

MOSEL

sys.?

3

TimeNET SPNP MOSES

2.1

???

The model structure

4

A MOSEL model consists of five parts. Each part is dedicated to the description of a different aspect of the performance and reliability model by means of appropriate language constructs [5]:

Semantic Model (State Space)

5

1. Parameter declaration part

Stochastic Process

2. Component definition part 6

Results

3. Transition definition part 7

tool

specific

results

4. Result part (optional) sys.{res,igl}

5. Picture part (optional) Figure 1: The modelling and analysis process in the MOSEL environment

Parameter Declaration Part: In this part constants and variable system parameters can be declared. The ENUM construct allows the definition of a set of constants. The possibility of declaring a list of values in the PARAMETER construct is a powerful feature of the language, since this makes experimenting with the model very easy. The MOSEL-environment automatically analyzes the specified system for any combination of system parameters.

At present the MOSEL environment is able to translate models into system descriptions for the GSPN-based packages SPNP and TimeNET [26] and for the tool MOSES, whose model description language is a predecessor of MOSEL. The connection of other other performance modelling packages to the MOSEL-environment is projected. During the recent integration of TimeNET [8] we revised and enhanced the MOSEL syntax to support a set of nonexponential distribution types for the system state transitions. MOSEL models containing non-markovian transitions can now be analysed by the Discrete Event Simulation components of either SPNP or TimeNET. Moreover TimeNET offers numerical solution methods for a restricted class of systems with non-exponentially distributed transitions.

CONST pi = 3.14159265358979; PARAMETER lambda = 0.25, 0.30, 0.35; ENUM cpu_states = {idle, user, kernel, driver};

Component Definition Part: This part consists of the NODE part and the ASSERT part. NODE Part: This part specifies the components (nodes) of the model. Each node can hold an integer-valued number of jobs (or token) up to its capacity. For every component in the model a name and the capacity has to be given. As an example we consider:

The paper is organized as follows. In section 2 we give a brief description of the MOSEL language by means of a simple example. In section 3, we model a queueing network with blocking. We continue with a MOSEL-model I.J. of SIMULATION Vol. 3 No. 3-4

NODE N1[k] = k; /* range: 0..k */ NODE cpu[cpu_states]; /* range: 0..3 */

68

ISSN 1473-804x online, 1473-8031 print

AL-BEGAIN et al. THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL . . . ASSERT Part: This construct can be used to specify the prohibited system states. Most frequently, the ASSERT statement is used to express the seclusiveness of the modelled system. For a closed system, we have to assure that the total number of token in the nodes which are used to model the job-flow is always constant, which is expressed by the following line:

Picture Part: In this optional part the user can determine which values should be plotted. With the following construct the mean queue length defined in the result part is plotted as a function of lambda with the values of lambda specified in the declaration part: PICTURE "Mean Queue Length" PARAMETER lambda CURVE mean_queue_length

ASSERT N1 + N2 + N3 == K;

with special keywords the appearance of the curves can be changed and improved. Transition Definition Part: In this part the transitions that determine the behavior of the system are specified. The transitions are called rules in MOSEL. Each rule consists of a global part and, optionally, a local part.

2.2

As a first example for a complete model specification in MOSEL we consider an open tandem queueing network with two M/M/1-FCFS nodes:

FROM node_1 TO node_2 WITH mue_1; IF (cpu_control == idle) FROM node_1 WITH mue_1 THEN { TO node_2 WEIGHT p_12 ; TO node_3 WEIGHT p_13 ; }



The first rule consists of a local part only and specifies a transition from node_1 to node_2 with rate mue_1. The keyword WITH indicates that the transition is exponentially timed. The second example shows how rules containing a local part can be used to model probabilistic branching. The timed transition mue_1 emanating from the component node_1 is split up into two branches which lead to the components node_2 and node_3. The branches have weights p_12 and p_13 which of course have to be defined in the parameter declaration part of the model. Each branch is probabilistically selected according to its weight and the selection is assumed to happen immediately. The condition IF (cpu_control == idle) in the global rule part is used to model synchronization. Jobs can leave node_1 only if node cpu_control is in state idle. Otherwise the transition is disabled.





Figure 2: Open tandem queueing network and get the following simple MOSEL model: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

Result Part: In this section of the system specification the modeller can define the performance and reliability measures in which he is interested in. In the following example the mean value MEAN, utilization UTIL and the distribution of jobs DIST for node_1 is specified: RESULT N_1 = MEAN (node_1); RESULT rho_1 = UTIL (node_1); RESULT DIST node_1;

If the probability that a component of the system is in certain states is required the keyword PROB can be used, e.g.:

// Tandem network // Parameter declaration part PARAMETER K := 1, 2, 3, 4, 5, 6, 7, 8, 9, 10; CONST lambda := 0.25; CONST mue1 := 0.28; CONST mue2 := 0.22; // System component part NODE N1[K] = 0; NODE N2[K] = 0; NODE num[K]; // Transition part FROM EXTERN TO N1, num WITH lambda; FROM N1 TO N2 WITH mue1; FROM N2, num TO EXTERN WITH mue2; // Result part PRINT PRINT PRINT PRINT

rho1 = UTIL (N1); rho2 = UTIL (N2); throughput = rho2 * mue2; WIP = MEAN (num);

// Picture part PICTURE "utilization" PARAMETER K CURVE rho1 CURVE rho2;

In the parameter declaration part the constant arrival rate lambda as well as the two rates mue1 and mue2 for the servers are defined. The system is analyzed assuming that the maximum overall number of jobs in the System K varies from 1 to 10. This implies that during the

RESULT p_working = PROB (working > 0); RESULT rho_cpu_kernel = PROB (cpu == kernel AND cpu_state == up);

I.J. of SIMULATION Vol. 3 No. 3-4

Simple MOSEL Model of a Tandem Network

69

ISSN 1473-804x online, 1473-8031 print

AL-BEGAIN et al. THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL . . . performance analysis the MOSEL-environment automatically generates a sequence of ten high-level system descriptions (e.g. CSPL-files) and as well invokes the appropriate tool (i.e SPNP) for each variant. The results of the experiment (the set of analysis runs performed by the tool) are collected in a single file by the MOSELenvironment. The same applies to the graphical representation of the results.

general blocking networks can only be obtained by simulation or by the generation and numerical solution of the underlying CTMC. In this section we show how easy this can be accomplished with the MOSEL-environment. In [20] three different types of blocking are introduced: Blocking after service, blocking before service and repetitive blocking. In the following we will restrict us to the case in which jobs are blocked after service, as shown in Fig. 3:

In the component definition part the two nodes N1, N2 representing the queues and the auxiliary node num are defined. Each node is capable of holding up to K jobs. The num-node is needed for keeping track of the overall number of jobs in the system which is important to derive the WIP (Work In Progress) measure as specified in the result part. In the transition part the possible transitions of jobs between the nodes are defined using the rates and values specified in the parameter declaration part. The special node EXTERN is used to model arrivals and departures of jobs from and to the environment. In the result part the utilizations (probability that the queue is not empty) of the nodes N1 (rho1) and N2 (rho2) are defined using the keyword UTIL. Moreover, the throughput of the second server is specified as the product of rho2 and the service rate mue2. Using the keyword MEAN the mean total number of jobs in the system (WIP) is specified. The keyword PRINT at the beginning of each line of the result part indicates, that all specified results are going to be saved in MOSEL result file. Intermediate results, which often are used to compute complex measures and which need not be stored in the result file, can be specified by using the keyword RESULT at the beginning of the line.

Job blocks station

Station

is full



With this type of blocking, station is blocked when a job completing service at station wishes to join station  that is already full. This job then has to remain in the  server of station and blocks it until a job leaves station . This kind of behaviour can often be observed in production line systems or in external I/O devices [2, 10]. In the literature, this type of blocking has been referred to by a variety of different terms such as Type-1 blocking, transfer blocking, production blocking, and non-immediate blocking.

3.1

Tandem network with blocking after service

We consider an open tandem queueing network with blocking after service (Fig. 3) where the second station of type M/M/1/N-FCFS has a finite capacity queue. In order to express the blocking behaviour adequately in the MOSEL model we append an additional node BLOCK to the node N1, which models the first station in the network. Node N2 specifies the finite capacity queue of the second station. For technical reasons we introduce an auxiliary node num to the model, which can be used to obtain global performance measures and assures the finiteness of the resulting system state space. The complete MOSEL model is listed below:

Modelling Queueing Networks with Finite Capacity Queues

In a queueing network with infinite capacity queues a job that leaves a station will always find an empty place in the queue of the next station. But in the case of finite capacity queues, blocking can occur and jobs can be rejected at a station if the queue is full. Queueing networks that contain stations with finite buffer capacity are called blocking networks. Blocking networks are not only important for modelling and performance evaluation of computer systems and computer networks, but also in the field of production systems. Exact closed form results exist only for small networks. For larger networks only approximate closed form results are available. Exact results for I.J. of SIMULATION Vol. 3 No. 3-4



Figure 3: Tandem network with blocking after service

The picture part contains the definition of a plot showing the utilizations rho1 and rho2 as a function of the variying system parameter .

3



1 2 3 4 5 6 7 8 9 10 11 12 13

70

// Blocking after service CONST K := 20; PARAMETER capacity := 1, 2, 3, 5, 7, 10; CONST lambda := 1.0; CONST mue1 := 1.2; CONST mue2 := 1.4; NODE NODE NODE NODE

N1[K] = 0; N2[capacity] = 0; BLOCK[1]; num[K];

ISSN 1473-804x online, 1473-8031 print

AL-BEGAIN et al. THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL . . .

14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

3.2

FROM EXTERN TO N1, num WITH lambda; FROM N1 TO BLOCK WITH mue1; IF (N2 < capacity) FROM BLOCK TO N2; FROM N2, num TO EXTERN WITH mue2; PRINT PRINT PRINT PRINT PRINT

Suppose that we have saved our MOSEL-model in a file named blocking_after.msl. We are now ready to invoke the MOSEL-environment on the command line via

rho1 = PROB (N1>0 OR BLOCK == 1); rho2 = PROB (N2 > 0); throughput = rho2*mue2; blockprob = PROB (BLOCK == 1); WIP = MEAN (num);

PICTURE "utilizations" PARAMETER capacity CURVE rho1 CURVE rho2;

>> mosel -cs blocking_after.msl The option-c denotes that we requested that our MOSEL specification should be translated into a set of CSPL files (C based Stochastic Petri net Language), which serve as input for the GSPN-based tool SPNP. Because we also used the s option (s  “start appropriate tool automatically”) the MOSEL-environment will now perform the rest of the model analysis and result-postprocessing steps automatically using the SPNP package for state space generation, derivation of the underlying CTMC and numerical solution (cf. Fig. 1).

PICTURE "throughput" PARAMETER capacity CURVE throughput; PICTURE "blockprob" PARAMETER capacity CURVE blockprob; PICTURE "WIP" PARAMETER capacity CURVE WIP;

Upon completion of the analysis, the MOSELenvironment creates two files named blocking_ after.res and blocking_after.igl which contain the requested performance measures of the system in numerical and graphical form. Below we show a compressed form of the result file blocking_after.res:

In the parameter declaration part the maximum number of jobs in the system K, the capacity of node N2, the arrival rate and the service rates are specified. In the component definition part four nodes are declared as explained above. Lines 14 – 17 of the MOSEL-model contain the rules which describe the flow of jobs through the queueing network. The first rule models the exponentially timed arrival of jobs from outside (FROM EXTERN). Arriving jobs are routed to node N1 and for bookkeeping purposes also to the auxiliary node num. The second rule states that jobs leave N1 and enter BLOCK after an exponentially distributed delay which is determined by the service rate mue1. The next rule describes the transition to the second queue which is only possible if node N2 contains less than capacity jobs. If enabled, the transition of jobs from BLOCK to N2 takes place immediately, since no rate is specified in the rule. It is interesting to note that the explicit declaration of the condition (IF (N2 < capacity)) in this rule is unnecessary, since MOSEL automatically assures that a node cannot be populated by more jobs than specified by its capacity, thereby implicitly disabling rules which would lead to a prohibited system state. The last rule models the departure of jobs from the system after they have been serviced by the server of the second station with rate mue2. In the result part five performance measures are specified. The utilizations rho1 and rho2 of the servers, the throughput, the probability that a job blocks the first station and the “work in progress” (mean total number of jobs in the system) are defined. A graphical presentation of the performance measures depending on the variable parameter capacity is specified in the picture part. I.J. of SIMULATION Vol. 3 No. 3-4

Analysis of the blocking after service model with the MOSEL-environment

=================================================== Stationary analysis of "blocking_after.msl" by SPNP =================================================== Parameters: | Parameters: capacity = 1 | capacity = 2 | Results: | Results: rho1 = 0.995835 | rho1 = 0.966408 rho2 = 0.612107 | rho2 = 0.671654 throughput = 0.85695 | throughput = 0.940316 blockprob = 0.28171 | blockprob = 0.182812 WIP = 15.4889 | WIP = 11.7287 | =================================================== Parameters: | Parameters: capacity = 3 | capacity = 5 | Results: | Results: rho1 = 0.937231 | rho1 = 0.873552 rho2 = 0.713968 | rho2 = 0.703997 throughput = 0.999555 | throughput = 0.985596 blockprob = 0.120877 | blockprob = 0.0522217 WIP = 9.55455 | WIP = 7.5334 | =================================================== Parameters: | Parameters: capacity = 7 | capacity = 10 | Results: | Results: rho1 = 0.848551 | rho1 = 0.833494 rho2 = 0.706741 | rho2 = 0.707804 throughput = 0.989437 | throughput = 0.990925 blockprob = 0.0240205 | blockprob = 0.00772334 WIP = 6.97348 | WIP = 6.73484 | ===================================================

As expected the blocking probability, the utilization of station 1 and the work in progress (WIP) decrease if the capacity of station 2 increases while the utilization of 71

ISSN 1473-804x online, 1473-8031 print

AL-BEGAIN et al. THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL . . .



node 2 and the throughput increase. The textual result file is very helpful if we are interested in exact values of the performance measures for a specific value of the variable system parameter which was given in the model specification. The graphical representation of the results provides insight about how the performance measures depend on a variable system parameter over an interval. The graphical result file can be viewed and postprocessed with the IGL-utility, which is part of the MOSELenvironment. In Fig. 4 we show an IGL-generated plot of the utilizations rho1 and rho2 as a function of the capacity of station N2. It is interesting that the utilization of station N1 decreases if the capacity of station N2 increases.

rho1 rho2

Figure 5: A basic retrial system In this section we consider a simple M/M/1 retrial system with exponentially distributed interarrival, service, and repeating or delay times. To get the MOSEL model for this simple type of retrial system we introduce the delay node D (see Fig 5) for the rejected requests. This node is of the type M/M/  -IS. This means that there is no queue and the service rate of this node is the repeating rate. The MOSEL model is as follows:

rho1

0.75 0.7

rho2

0.65 0.6

//

0.55 1

2

3

5



capacity

7

10

// Component definition part NODE server[status] = idle; // server initially idle NODE D[N-1]; // delay node contains maximal N-1 req. NODE num[N]; // counts total number of requests // Transition part IF (server == idle) { FROM EXTERN TO server, num WITH lambda; FROM D TO server WITH D*mue; } IF (server == busy) { FROM EXTERN TO D, num WITH lambda; FROM D TO D WITH D*mue; FROM server, num TO EXTERN WITH nue; }

Modelling of a Retrial System

Retrial systems or retrial queues (or queues with repeated calls, returning customers, repeated orders etc.) exhibit the following characteristic behaviour [4, 12]: A customer arriving when all servers are busy leaves the service area but after some random time repeats his request. This feature plays a special role in some computer and communication systems, in telephone systems in supermarkets or at airports when aircrafts are waiting for landing permission.

// PRINT PRINT PRINT PRINT

rho K = Q = T =

Result part = UTIL (server); MEAN (num); MEAN (D); K/lambda;

// // // //

Server utilization Mean number of requests Mean queue length Mean system time

// Picture part PICTURE "Mean Queue Length" PARAMETER lambda CURVE Q;

In general a retrial system may be described as follows. There are a number servers at which requests arrive. These requests are called primary requests. If an arriving primary request finds a free server, it immediately occupies this server and leaves the system after completion of service. If all servers are busy then the request is rejected and forms a source of repeated requests (retrials). Every such source sends repeated requests until it finds a free server, in which case it is served and the source is eliminated. The fundamental model of a retrial system is shown in Fig. 5: I.J. of SIMULATION Vol. 3 No. 3-4

M|M|1_Retrial System

// Declaration part PARAMETER lambda := 0.01, 1, 2, 5, 8, 9, 9.5, 9.9; PARAMETER mue := 0.01, 0.1, 1, 1000000; CONST nue := 10; ENUM status := { idle, busy }; CONST N := 100; // Maximum number of requests

Figure 4: Server utilizations in the tandem network with blocking after service

4





utilizations

0.85 0.8

yes

no



1

0.95 0.9

Server idle?

PICTURE "Utilization" PARAMETER lambda CURVE rho;

In the declaration part the variable sytem parameters arrival rate lambda and delay rate mue as well as the constant service rate nue are given. Because the component which represents the single server can assume the two states idle and busy, we explicitly define them as 72

ISSN 1473-804x online, 1473-8031 print

AL-BEGAIN et al. THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL . . . members of an ENUM-list. Although it would be possible to specify the model without the explicit naming of the server states, the possibility to refer to the status of a system component by a name improves a lot on the readability of the model.

=================================================== Stationary analysis of "mm1.retrial.msl" by SPNP =================================================== ... Parameters: lambda = 0.01 mue = 0.01

| Parameters: | lambda = 9.9 | mue = 1 | Rsults: | Results: rho = 0.001 | rho = 0.908255 K = 0.002002 | K = 90.806 Q = 0.001002 | Q = 89.8977 T = 0.2002 | T = 9.17232 =================================================== Parameters: | Parameters: lambda = 0.01 | lambda = 9.9 mue = 0.1 | mue = 1e+06 | Results: | Results: rho = 0.001 | rho = 0.984317 K = 0.0011011 | K = 41.6014 Q = 0.000101101 | Q = 40.617 T = 0.11011 | T = 4.20216 ===================================================

Since the retrial sysem is not closed, the number of total jobs in the system is principally unbounded. In order to assure that the underlying stochastic process of the model which we generate during the analysis contains a finite number of states, we limit the the maximum number of jobs to a finite value N, thus losing the possibility of obtaining exact results for the M/M/1 retrial queue. For inrceasing N the error introduced by the bounding of jobs decreases, setting the value of N to 100 will yield good approximate results. In the component definition part the three nodes for the server (server), the delay node (D), and the auxiliary node num are defined. The capacity of node server is 1, since the the ENUM-list status contains the two elements idle  and busy  . In the transition part the rules which describe the possible state changes of the system are specified. Since the behaviour of the system depends mainly on the status of the server we define two sets of transitions. The first block of transitions is enabled when the server node is in state idle: Primary requests arrive from outside with rate lambda and occupy the server, repeated requests try to enter the server node from the delay node D at rate D * mue. Note that a node name in the rate definition part of a rule stands for the actual number of jobs in the node. Each primary request which enters the system is also counted in the auxiliary num node. When the server node is in state busy the following transitions are possible: Primary requests are directly routed to the delay node with rate lambda since the server is not free. Repeating requests find the server busy and are rerouted to the delay node D. The request which occupies the server leaves the system at rate nue.

...

As the MOSEL-specification contains a picture part, a .igl-file containing the graphical results is generated by the MOSEL-environment. Figure 5 shows one of the plots after it was postprocessed by the IGL-utility. 100

!90 80

%70 $60 50 #40 "30 20 10

0 0.01

1

2



8

!9 !9.5!9.9

Figure 6: Mean queue length Q as function of the arrival rate lambda and the delay rate mue (const. service rate nue = 10, N = 100)

In the result part the utilization of the server rho, the mean number of requests in the system K and the mean queue length Q are defined. The mean system time T (mean response time) can easily be calculated from the mean number in the system K using Little’s law. In the picture part two pictures are defined.

proc1

proc16 switch

mem1

After we saved our model specification in the file mm1.retrial.msl, we start the MOSEL-environment with “mosel -cs mm1.retrial.msl” on the command line which – for all 32 different combinations of system parameters – translates the MOSELspecification into a corresponding CSPL description and let SPNP perform a steady state analysis of the 32 Stochastic Petri Nets. The results obtained by the SPNP runs are collected in the result file mm1.retrial.res and is partly shown below: I.J. of SIMULATION Vol. 3 No. 3-4



5 lambda

mem16

Figure 7: A multiprocessor system

5

Reliability Modelling of a Multiprocessor System

In this section we show how easy the mean time to failure (MTTF) of a multiprocessor computer system can be 73

ISSN 1473-804x online, 1473-8031 print

AL-BEGAIN et al. THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL . . . that the system is working. The picture part contains one declaration – the probability that the system is working should be plotted over the time interval 2 & 5'6'7' 3 )) . As the result of the transient analysis of the model by the MOSEL-environment two files are generated. The result file multiproc.res contains the requested value for the MTTF as well as the probability of the system being operational for each of the specified time points:

evaluated using a reliability model specified in MOSEL. Figure 7 schematically shows the architecture of a multiprocessor system consisting of 16 processors, 16 memory modules and an interconnection network (switch) through which each processor can access any of the memory modules. We assume that the components of the system fail with rates procfail & (' )*)*+),)- , memfail & ' *).).0/1 and switchfail & (' )**.)*.0/ per hour. These values have been measured in [23] for a real system. We assume that the whole system is operational if at least four processors, four memory modules, and the switch are working. Otherwise the system is considered to have failed and is powered off, which means that we do not consider a possible repair of failed components in the MOSEL-model below.

Transient analysis of "multiproc.msl" by SPNP (Evaluated for times 0..5000, step width 500) Durations: mttf = 3613.37 Results: prob_sys_up = 1 0.903752 0.816768 0.738142 0.666914 0.60167 0.54024 0.480111 0.419491 0.358164 0.297535

// Multiprocessor reliability model CONST proc_no = 16; // number of processors CONST mem_no = 16; // number of memories CONST switch_no = 1; // number of switches // failure rates of the components CONST proc_failure = 0.0000689; CONST mem_failure = 0.0002241; CONST switch_failure = 0.0002024;

(time (time (time (time (time (time (time (time (time (time (time

0) 500) 1000) 1500) 2000) 2500) 3000) 3500) 4000) 4500) 5000)

The file multiproc.igl contains the data for the plot shown in Fig. 8.

// node part (initially all components are up) @{ NODE #_up[#_no] = #_no; } @{ NODE #_down[#_no]; }

Legend

1

COND sys_failed := (proc_up < 4 OR mem_up < 4 OR switch_up < 1);

prob_sys_up

0.9

// the rules describing the evolution of the system @{ FROM #_up TO #_down WITH #_up * #_failure; }

0.8

0.7

// time values for the transient analysis TIME 0..5000 STEP 500;

0.6

// results: mean time to failure and prob. that // system is up PRINT mttf := TIME TO sys_failed; PRINT prob_sys_up := 1 - PROB (sys_failed);

0.5

0.4

0.3

PICTURE "system is working probability" PARAMETER TIME CURVE prob_sys_up;

0.2

The number of components and the failure rates are declared first. In the component definition part we make use of the macro declaration feature of MOSEL which we describe in more detail in section 6. The set of nodes needed for modelling the up- and down-states of the three types of components in the model are declared in a single line. The COND-statement specifies the set of system configurations which correspond to a failure of the system itself. In the following rules part the failure of the components is specified, again using a macro declaration. Since we are interested in the evolution of the multiprocessor system over a time interval after power-on, we have to give the information needed for the transient analyis using the TIME-constuct below the rules part. The system is analyzed from power-on (2 &  ) up to 2 &43 *) every 500 time units (hours). In the result part we declare the desired reliablity measure MTTF and the probability I.J. of SIMULATION Vol. 3 No. 3-4

TIME 0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

Figure 8: Probability for the system being operational over time The presented reliability model can easily be enhanced by rules which model the repair of failed components. We then assume that the system is not powered off when it reaches a non-operational state because it can continue to work after enough components are repaired. Depending on the number of working processors and memory modules the system offers different levels of service which can expressed in the MOSEL-model using reward functions which are based on the number of jobs in the nodes. The result part can then be extended by rewardbased measure specfications. The resulting performability model can be used to answer questions about the combined performance and availability/dependability of the system. 74

ISSN 1473-804x online, 1473-8031 print

AL-BEGAIN et al. THE PERFORMANCE AND RELIABILITY MODELLING LANGUAGE MOSEL . . .

6

I M

Modelling of Mobile Networks using MOSEL

and node N

to be 1, the maximum distance between UE and has been derived in [7] as:

C The last example used in this paper is to model a modern system from mobile communications. The traditional 2G mobile networks are in their nature similar to the traditional telephone switch system where the system has a fixed number of channels. This system can be adequately modelled by a trivial M/M/c/c loss system. The situation changes substantially when we consider third generation mobile systems since these have a dynamic capacity that depends on the interference levels in the covered area and the number of active users. Moreover, the used coding system in the Universal Mobile Telecommunication System (UMTS), the 3G system in Europe, implies that the received power at the base station is crucial to be equal to all active users. This implies that the distance of the mobile user from the base station is also an important factor because of the signal fading [16]. In [22], capacity bounds have been derived based on interference levels for both maximum number of active users and maximum distance covered by the base station. The most important formulae are given in the following.

6.1

W

6.2

4. If C new orC step 5.

(1)

8 ;POLQTR