An Annotational Extension of Message Sequence Charts to Support ...

An Annotational Extension of Message Sequence Charts to Support Performance Engineering  Nils Faltina, Lennard Lamberta, Andreas Mitschele-Thiela , Frank Slomkaa aFriedrich-Alexander-Universit¨ at Erlangen-N¨urnberg

Lehrstuhl f¨ur Informatik VII Martensstraße 3, 91058 Erlangen, Germany Email: fnsfaltin,ldlamber,mitsch,[email protected] With the development of complex systems based on SDL, performance issues often play a major role. However, this is neither reflected by the SDL methodology nor by the specification techniques suggested by the methodology, namely SDL and MSC. To remedy this problem, we propose Performance Message Sequence Charts (PMSC). PMSC represents an extension of MSC-96 to include performance aspects into the language. The extensions allow for the formal specification of various performance aspects, e.g. performance requirements, resource requirements and the specification of the available resources. In order to support the use of tools based on MSC-96, the language extensions are embedded in comments of the original MSC-96 language. PMSC allows for the co-specification of functional and performance aspects. This joint specification of functional and performance aspects eases the task of software engineers. It saves effort otherwise needed to maintain two different models. In addition, the co-specification based on MSC, rather than on SDL, supports the early evaluation of the performance of the system. 1. Introduction Performance issues play a major role in the software engineering process. Nevertheless, the integration of performance aspects in the software engineering process has not been well studied. Rather, software engineering and performance evaluation are being considered as two rather independent areas. Each world has its own specialists and uses its own models, methods and tools. Thus, different models are used to deal with different aspects of the system under development. The major drawback of the use of disjunct models is the extra effort needed to keep the models consistent. This extra effort necessary to derive a separate performance model in addition to the functional model is often avoided by putting off performance issues as long as possible in the engineering process. Considering performance as ”afterthoughts” is especially dangerous in the major application area of SDL. In the telecommunication sector, product families are offered which evolve over many years and which have to be maintained and updated for a period of 20 years or more. With such systems, the “afterthought approach to performance” often results in a gradual destruction of the system architecture. In order to quickly meet performance requirements of the system at  The research described is supported in part by the Deutsche Forschungsgemeinschaft under grant He 1408/2-1 and grant SFB 182, B3 and C1.

a stage where the system is already fully implemented and integrated, solutions are selected that are not in accordance with the system architecture (kernel bypasses, etc.). If this approach is taken for several iterations of a product line, complexity is gradually added to the system. This typically results in enormous cost and delays for system integration and testing. In the worst case, the system runs completely out of control due to its enormous complexity. In order to acknowledge the importance of performance issues, we propose its early and systematic integration into the development process. We propose the co-specification of functional aspects and aspects related to performance, i.e. the use of a consistent model that jointly describes functional as well as performance aspects. Our approach is based on Message Sequence Charts (MSC), a standardized technique heavily used in the telecommunication sector to specify use cases. So far, MSC only supports the functional reasoning about the system. The scope in which MSCs are typically employed ranges from the requirements specification down to the testing of the implemented system. This wide range for the usage of MSCs makes it a prime candidate for the specification of performance aspects. Thus, the performance information added to MSCs can be used in various phases of the development process. The extended MSC notation described in this paper can be employed to support performance evaluation in all phases in which traditional MSCs are used, i.e. from the early design phases down to detailed design and testing. For example, performance requirements identified during the requirements analysis and specified with the extended MSCs can be validated by model based performance evaluations during the design of the system and later on by means of measurements of the implemented system. In the paper, we describe an extension of MSC-96 [12] (see [17] for an introduction) to integrate performance aspects. This allows to employ MSCs for performance evaluation. The cospecification has several advantages. The use of a single model ensures the consistency between the functional and the performance model. This saves effort and valuable time. In addition, the use of a description technique that is employed during several phases of the development process allows to easily reuse information once it is specified. This motivates engineers to formally specify performance aspects and to employ performance evaluation. Other advantages of MSCs for performance evaluation result from its orientation towards use cases. This allows to concentrate on specific, important uses of the system. In addition, MSCs are highly deterministic even if they are used in early design stages. This eases the evaluation of the performance of the system. Especially the evaluation of the performance data for different use cases, e.g. response time figures, can be easily supported by our approach. In addition, the extension of MSC allows for the functional validation of the system in the presence of time. This is especially important to evaluate mechanisms to handle overload. The language extensions for MSC-96 described in this paper are based on earlier work on MSC-92 reported in [7] and [15]. An approach to extend MSC-92 by language constructs rather than by annotations has been described in [19]. [4] report on a language that has some similarities with MSC-96. The language is specifically designed to support performance simulation and supports structural and hierarchical modeling. Most approaches to support performance evaluation of SDL systems are based on extensions of the SDL language itself to specify various performance aspects. Extensions to SDL to specify performance requirements are described in [14] and [6]. In [13], the separate specification of performance requirements with a temporal logic is proposed. Most approaches known from the literature specify the resource requirements for the execution of the SDL system with extensions added to SDL itself (e.g. the approaches described in [1,2,5,6,14,19]). A hybrid approach to specify resource requirements in SDL and/or MSC has been presented in [7]. Available re-

sources of the system are typically specified by special constructs added to the SDL language, e.g. in [6], or separately specified in a simulation environment that also serves for the performance evaluation (e.g. [18]). Most approaches for performance evaluation of SDL systems are based on simulation, e.g. the approaches described in [6,5,14,18,3]. Performance evaluation of SDL systems based on numerical analysis is described in [1]. The paper is organized as follows: section 2 discusses the integration of performance aspects into the development process of systems based on SDL and MSCs. Our extensions to MSC-96 to support performance engineering are described in section 3. Section 4 concludes the paper and outlines the application areas of our extended MSC notation. 2. Performance Engineering 2.1. Traditional Development Process in the Context of SDL and MSC The use of SDL and MSC in the development process has been described in [10]. An update of the methodology is currently being devised [11] (see [16] for an overview). The documents focus on functional aspects of the system under development. Performance or other quantitative aspects are not considered. In addition, implementational issues are not dealt with in detail. Instead, the methodology is focusing on the requirements analysis and the design phases (draft design and formalization). The methodology suggests the use of an object-oriented method to classify the information derived during the requirements analysis. MSCs are employed to specify the functional requirements of the system. Thus, the typical and important use cases of the system to be developed are specified by respective MSCs. Once the use cases have been identified, SDL is used during draft design to specify the raw structure of the system. During the detailed design, the behavioral aspects of the system are subsequently added to the specification. This is also called formalization. For the formalization, the SDL specification and the MSC specification are concurrently refined. Thus, if details are added to the SDL specification, e.g. blocks are refined by processes, also the respective MSCs are refined to model the processes rather than the blocks. When the refinement is completed and the SDL/MSC specification has been checked for correctness, the implementation is derived from the SDL specification in a further step. The major advantage of the use of SDL and MSC for system specification is their support for functional validation. During draft design, SDL structures can be derived from the given MSCs. In addition, the check of consistency between the MSCs and the structural SDL specification is supported by tools. Once behavioral details have been added to the SDL specification during detail design, the SDL specification can be checked for functional correctness, e.g. for deadlocks, livelocks, reachability and unexpected arrivals. MSCs can be used to simulate the functional behavior of the SDL specification. Functional validation is supported by several commercial tools, e.g. SDT [20] and GEODE [21]. 2.2. Integration of Performance Aspects An important prerequisite for the integration of performance issues in the software engineering process is the identification and formal specification of all aspects relevant to performance. 2.2.1. Performance Aspects The performance aspects relevant for the design and implementation of the application are as follows: Performance requirements denote the requirements related to performance which are imposed on the implementation. Examples of performance requirements comprise the response time of the system for different arrivals or the system throughput, i.e. the number of arrival s that can be

handled within a given time period. Note that the requirements may change over time and that there may be different classes of performance requirements imposed on the application. Performance requirements can be hard or soft requirements. Hard requirements need to be enforced strictly to ensure the functional correctness of the system whereas the violation of soft requirements may be tolerable under certain conditions. Implementation alternatives describe the possible freedom of choice for the implementation (and the design). Implementation alternatives describe a set of implementation techniques that are applicable to the different parts of the SDL specification and specify how the SDL units can be mapped on the available resources. Examples of implementation alternatives are the possible assignments of the SDL units on the underlying runtime system and the possible implementation models.2 The description of implementation alternatives allow for the mapping tools to choose the most relevant implementation alternatives regarding all requirements and the preconditions imposed by the machine. The specification of implementation alternatives for the application opens a large possible solution space from which synthesis tools can choose the most appropriate solution. Note that the implementation alternatives are often given implicitly. For example, the alternatives to map SDL units on processors are not explicitly specified. Instead, only restrictions of the possible mappings are given. Note also that the selection of the implementation alternatives is a prerequisite for the evaluation of an implementation. Resource requirements specify the cost caused by the assignment or execution of the parts of the SDL specification on the available resources. The resource requirements of the implementation or parts hereof may depend on the selected implementation alternative. In this case, the resource requirements have to be derived for each implementation alternative either explicitly or implicitly. In the latter case, the cost are given in a parameterized manner from which the resource requirements can be derived. The resource requirements are given either a bsolutely (e.g. the delay time of a data transmission) or relatively (e.g. the volume of the transmitted information). The granularity of the parts for which the resource requirements are speci fied may differ. It may vary from the course-grain specification of the requirements of an SDL block down to the fine-granular specification of the execution cost per transition or even per single SDL statement. The available (limited) resources denote the units which are available for the application, i.e. the assignment of the load as well as its execution. The most important resources are the processors and the communication channels of the system. Further important resources concern the available memory. Besides the capacity of resources, their service strategies are of importance. The implementation decisions are an important prerequisite for performance evaluation. The implementation decisions determine which of the specified implementation alternatives are chosen for the realization of the system. This also influences the resource requirements of the parts of the system. The most important implementation alternatives are the choice of the implementation models for the different SDL units and the mapping of the code derived from the SDL specification on the system. The mapping determines how the units of the SDL specification with their resource requirements are distributed on the available limited resources of the system. The specification of performance aspects is typically done in a behavior-oriented fashion or use-case oriented. In the case of the behavior-oriented specification of performance aspects based on SDL, performance aspects are associated with the units of the SDL specification (blocks, processes, channels, transitions, etc.). In case of the use-case-oriented specification, performance aspects are associated with the description of execution sequences of the system. For this, mostly MSCs extended by special constructs are employed. 2 See

[9] for a description of different implementation models for SDL specifications.

validation (functional and performance) PMSC

validation (functional and performance)

conceptional design PMSC + SDL

detailed design PMSC + SDL implementation

Figure 1. Outline of the performance engineering methodology

2.2.2. Methodology for Performance Engineering Our methodology represents an extension of the methodology described in [11] to deal with performance issues in addition to functional aspects. The outline of our methodology for performance engineering is depicted in figure 1. In the figure, feedback areas are omitted for simplicity. Similar to the methodology described in [11], our approach is not limited to a specific development process model, e.g. the waterfall or spiral model. Our approach to performance engineering is based on the annotational extension of the MSC language to describe performance aspects. With our approach performance engineering is supported as follows: During the functional specification of the use cases with MSCs, the performance requirements of the system are also formally specified with the same MSCs. The most important examples of such performance requirements are response time and throughput requirements. With the traditional methodology, only functional aspects are validated during the design. We add the validation of performance aspects to the methodology. Thus, functional and performance validations are performed during the design of the system. Different from functional validation, there is no principle difference between the performance evaluation of the system during draft design and detailed design. This is because the performance validation is based on MSCs rather than on the SDL specification. The focus on MSC allows to support performance validation of the draft design already. The performance validation counterchecks the performance figures of the specified system with the performance requirements. In order to derive the performance figures, the following issues are of particular importance: First the resource requirements of the operations of the system as specified (executed) by the MSCs have to be identified. Second, the available resources to handle the resource requirements have to be identified. Third, the mapping of the parts of the application with its respective resource requirements on the available resources has to be defined. This comprises the decision on open design or implementation alternatives, the specific distribution of the load on the resources and the strategies to handle contention of the resources, e.g. the dynamic scheduling strategy.

The specification of the three aspects defines the system model. It allows to evaluate the temporal behavior of the system and to check if the performance requirements are met. Typically, performance engineering comprises the iterative evaluation and improvement of the system model to meet the requirements (functional as well as temporal). In each iteration of the optimization process all three aspects of the system, as described above, can be changed. For example, the SDL specification (or its intended implementation strategy) may be changed to reduce its resource requirements, the number or the capacity of the available resources may be changed, or the mapping of the resource requirements on the available resources may be modified. Changes to the system model corresponding to the available resources or the mapping can be automized. Thus, tools can be employed to automatically optimize the design. This is not the case if the SDL specification itself is modified. In this case, the modifications have to be done manually. However, the performance validation can still be supported by tools. 3. Performance Message Sequence Charts (PMSC) 3.1. General Issues In order to describe the performance aspects of a system, a description language is needed. Using this language as input, the performance of the system can be evaluated using analytical techniques, measurement or simulation. We have defined the description language Performance Message Sequence Chart (PMSC). PMSC extends MSC-96 [12] with performance aspects. The extensions are embedded in comments of the original language. At present we concentrate on a subset of MSC-96. As far as we know, this subset has the same expressive power as the original language. 3.1.1. Embedding Annotations One goal of the PMSC language is, that MSCs adjunct with performance information can still be processed by tools expecting input in the MSC-96 format. To accomplish this, all performance aspects are embedded in textual parts of the specification that have no formal meaning in MSC-96, but mostly serve for communication among human users. We will call the syntactical elements of MSC, that allow this embedding, host constructs. For PMSC, the following host constructs are used:     A is always attached to an object of the MSC specification, e.g. an action, an input event or an instance. Comments are used in PMSC to specify attributes of the object they are attached to. A is used for global annotations. Global annotations are annotations whose meaning do not depend on the place they are written, but contain all information within themselves. Global annotations may also be given as separate input files to an evaluation tool. An describes an internal computation within an instance. Annotations concerning the action can be placed directly inside the action. The is the only construct, that normally is invisible in the graphical representation of MSC. It is only visible, when it is used inside a textual part of an MSC diagram, e.g. a reference expression. A note is used in PMSC to annotate reference expressions. Performance annotations have to be given at the beginning of a host construct and may be followed by a regular user comment. The annotation part begins with a dollar sign and can contain

several annotations, separated by comma and enclosed in curly brackets. It has the following structure: $fannotation1, annotation2, ...g user comment

If for some reason a dollar sign can not be used, a user defined keyword can be defined to mark the beginning of the annotation part. This keyword has to be given as a parameter to the PMSC parser. 3.2. Functional Specification of System Behavior 3.2.1. MSC-96 in PMSC The functional specification describes which operations (instance events) the system performs. It describes precedence relationships and potential parallelism between operations and between MSCs. We use a subset of MSC-96 for functional specification. To specify performance aspects, we introduce performance annotations which are attached to MSC objects. The subset of MSC-96 used consists of plain MSCs, instance decomposition and reference expressions. Plain MSCs consist of instances and instance events, but do not contain or reference other MSCs. The only exception is that an instance may be refined by a sub-MSC. This refinement is called instance decomposition. In this case, the instance is a composite object and the sub-MSC defines how messages are processed within the object by computations and message exchange between the subobjects. A reference expression is a construct from MSC-96 that specifies the relation in between several plain MSCs. It models the system behavior on a higher level than the plain MSCs. Reference expressions logically form a tree with operators at the inner nodes and plain MSCs at the leaves (see figure 3 for an example). The following operators are used in PMSC. Sequence: A seq B specifies that subexpression A is executed before subexpression B. We use strict ordering semantics here, which means that the execution of A must be completed before B starts. Original MSC-96 uses a weak sequencing, where this ordering relation only must hold within each instance. To express that a subexpression A runs several times, the loop construct is used. The semantics is that of repeatedly using seq. MSC gives an upper and lower limit for the number of iterations. The parallel composition of two expressions means that the expressions can run truly in parallel as long as no other constraints apply, e.g. limited resources. If the system may proceed in two different ways, the alternative is used. A special case of an alternative is the optional construct. Here expression A is executed or nothing is done. 3.2.2. Transition Semantics for MSC MSC is mostly used to describe the message flow between SDL processes. An SDL process can only execute one transition at a time. A transition in SDL typically starts with an input and is followed by actions and outputs in any order. If MSCs are used to describe an SDL system, the use of this transition semantics when making a performance evaluation is an obvious choice. Figure 2 gives an example of an instance axis containing two transitions. Our definition of a transition semantics for MSC is as follows: 1. A transition is a sequence of events of a local MSC instance. 2. A transition starts with an input and ends before the next input. To cover all cases, an extra rule is defined: The first instance event begins a transition (even if it is not an input), the last event ends a transition. 3. All local instances (in several MSCs) with the same name form a global instance. Each global instance has its own input queue for incoming messages. If a PMSC system is sim-

A

TS1

MSG1

Transition 1

TS2

COMP

RefExpr1

RefExpr2

MSG3 MSG2

${required duration < 50 ms} ${required duration < 30 ms}

Transition 2

par

COMP

seq

MSG4

opt

MSG5

msc a

Figure 2. Transition definition

msc b

msc c

Figure 3. Traffic sources and duration times

ulated, messages can arrive in a different order than expected e. g. because of message overtaking. To allow processing in the correct order, a message will remain in the queue until the instance reaches the corresponding input. 4. A global instance executes a transition exclusively. Thus, while the transition is executed, no other events are processed by the same instance. 3.3. Performance Requirements 3.3.1. System Stimulation The performance model of PMSC consists of a number of reference expressions, each with an own traffic source. A traffic source generates service requests to be handled by the PMSC system. A reference expression describes how an PMSC system processes a service by employing instance processing and exchange of messages between the instances. Figure 3 shows a system with two services, described by RefExpr1 and RefExpr2. Requests are generated by the traffic sources TS1 and TS2. The structure of RefExpr1 is detailed graphically. The interarrival times of the service requests are deterministic. The user specifies a repeat count and a list of interarrival times. The traffic source will wait as long as the first time indicates and then produce a service request. It will then wait the next specified time interval and produce another service request until it has worked through the list. The whole procedure will be repeated the specified number of times. If no repeat count is given, it defaults to one. The name of a reference expression is defined by inserting a inside the reference expression. It contains the keyword name and the name of the expression. In the following example the traffic source will generate a service request for reference expression Ref1 at the times 2 ms, 5 ms, 7 ms, 10 ms, 12 ms and 15 ms. The name of the expression is defined inside the expression: ...

/* $fname Ref1g */ ...

The traffic source is specified somewhere as a global annotation: source for TS1 loop 3 interarrival det f2 ms, 3 msg

Each reference expression is implicitly started, when its service request arrives. There can be several executions of the same expression active at once, e.g. started shortly after each other by

A

C

B

COMP ${markbegin START} ${markend AFTER}

DATA

COMP

${markbegin BACK} ${required span (START, BACK) < 20 ms} DTR

DATA

${markend STOP} ${required span (START, STOP) < 50 ms}

Figure 4. The markbegin, markend and span annotation subsequent service requests. The traffic sources produce service requests independently of each other. Here too, the processing of requests from different traffic sources proceed in parallel. All these executions have to share the same MSC instances and the same resources. An MSC instance will only execute an input event, when the corresponding message has arrived. Because the sender of messages from the environment is not modeled directly, such messages are considered available when needed. The load imposed by the traffic sources constitutes an implicit performance requirement (throughput) because the system has to be able to handle this load. 3.3.2. Elapsed Time The elapsed time is the time that elapses between two defined events. The elapsed time is the sum of the computation time, transmission time and waiting time. All instance events, e.g. action, input and output, consume time in our model. It is possible to mark the beginning or the end of the instance event and thereby define a timestamp event and give it a name. Timestamp events are typically used by a simulation or measurement tool to record the time an event occurs. The beginning of an instance event is marked with the keyword markbegin, the end is marked with markend. With the function span(s,e) the elapsed time between the timestamp events s and e is specified. Timing requirements formulated with span() are typically written in a text symbol of a MSC or in a comment. Figure 4 shows several performance requirements for elapsed time between timestamp events. For example, the time between the sending of message DATA (timestamp event START) and the reception of DTR (BACK) has to be less than 20 ms. It is also possible to specify the elapsed time of the execution of a reference expression and of subparts of the expression (figure 3). Each subexpression corresponds to the operator, that binds it together. After the operator, a comment is added. Within this , the keyword duration is written. Duration and span are well suited to specify a response time requirement. Figure 3 states two requirements. The duration of the whole reference expression has to be below 50 ms and the duration of the subexpression (a seq b) has to be less than 30 ms. 3.4. Resource Requirements Resource requirements specify the amount of resources needed for an operation. The resource requirements are specified with abstract parameters by annotating the MSC. The absolute resource usage can be derived from the abstract parameters and the attributes of the resource the operation runs on. The available resources and their attributes are described in the machine

A

A

B

B

COMP ${service {CRC 200 SU, ADD 2 SU}}

${size 100 byte}

DATA

DATA CHECK

Figure 5. PMSC annotation of message size

${service {CRC 4 SU, MUL 3 SU, GET 1 SU}}

Figure 6. PMSC annotation for service usage of MSC actions

model. In PMSC the ressources needed for message transmission and computation can be specified. 3.4.1. Message Size For messages, only the message size in bytes is given. It can be annotated either at the corresponding input event or output event (figure 5). The message arrow cannot be annotated directly. This is because the arrow is only present in the graphical representation and does not have a counterpart in the phrase representation of MSC. A message size of 100 byte is defined by: size 100 byte

The sending and receiving of a message consumes processor time. If a message is transmitted over a communication link, it will use that link (resource) for some time. Both times depend on the message size, the processor characteristics and the link characteristics. Additionally, waiting time may be needed until the resources are available. 3.4.2. Service Usage In order to model that an operation needs computation time, the concept of services is used. An operation is an MSC action, that runs on a processor and uses services. Each operation states which services it uses. It also specifies for each service the amount it requires from the service. The service usage is annotated inside the action event or in a comment attached to it. An example is given in figure 6, where the action COMP computes a checksum (CRC) of a payload field of size 200 units and also makes two additions. The unit of a service usage is stated as su (service unit). It must be specified in the machine model which services are available and how long the execution of a service unit will take. Our model for resource usage is powerful enough to express different instruction mixes as well as the direct specification of the execution time. 1. Instruction mix. The processor usage is specified by stating how many basic processing instructions, e.g. addition, comparison and load/store are needed to perform the operation. For example, the instructions may correspond to statements in SDL, C or assembly language. In the simplest case, computing requirements are modeled by stating how many ”standard” instructions an operation needs. Then there is only one instruction type and thus only one service needed. 2. Runtime per processor. In this model, the runtime of each operation for each type of processor available is specified. For each processor type, a service is introduced. The service

unit corresponds to a time unit, e.g. microseconds. When there is only one type of processor in the system, only one service is needed. This approach can be especially interesting, when there is a sequential (non-parallel) prototype implementation available, which can be measured. These data can then be used to simulate a parallel implementation more accurately than with abstract service usage. 3.5. Machine Model The machine model describes the available system resources. It consists of processors, clusters and links. The machine model is well suited to model a parallel computer consisting of several processor clusters. Within a cluster, processes communicate via shared memory and in between clusters by message passing via communication links. In the following, we describe the resources, their attributes and how computation time of operations and communication time of messages are derived. The machine model may be given inside the MSC specification in a or as a separate document. 3.5.1. Processors and Clusters Processors are computing devices that offer services to operations. Each processor belongs to a processor cluster. The processors of a cluster dynamically share the load assigned to that cluster and can communicate without using a link. All processors in a processor cluster are equal, i. e. offer the same services at the same speed. A cluster can offer several services. The service set offered may differ from cluster to cluster. For each service and each cluster, the computation time per service unit (su) is given. The total computation time of an operation is obtained by adding up the service times of the operation. Each service time is calculated by multiplying the number of service units with the computation time per service unit. The number of service units is given in the resource requirements. A message transmission consists of an output event and an input event. As stated in section 3.4.1, both input and output events consume computation time on the processor they run on. The computation time (per event) depends on the message size and the two attributes latency and capacity of the cluster the processor belongs to. It is calculated according to the formula: computation time = latency + message size * capacity

The idea behind this is that the latency models the time needed for message transmission that is independent of the message size. If each byte of the message has to be processed in some way, e. g. copied in main memory, the time needed for each byte is expressed by the capacity. If the actual implementation does not have such a processing, the value can simply be set to zero (0 ns/byte). Using time per byte instead of byte per time also makes this model fit better with the service model used for determining computation cost. An example is a cluster C1 with two processors that offers the service of calculating a checksum at a speed of 20 nanoseconds per word and an addition at a speed of 10 nanoseconds per operand. For communication within the cluster it has a latency of 7 microseconds and a capacity of 10 nanoseconds per byte. cluster C1 processors 2 service fchecksum 20 ns/su,add 10 ns/sug latency 7 us capacity 10 ns/byte

3.5.2. Mapping and Scheduling A global MSC instance is statically mapped to a cluster. Each instance has its own input queue of messages waiting to be processed (Fig. 7). Once an instance has received an input message, it

MSC example

A

COMP

B

COMP

C

D

COMP

COMP

Instance A

Instance C

Instance B

Instance D

Cluster ABACUS

Cluster BEBACUS P1

P2

P3

P4

Link A

P5

P6

P7

P8

Figure 7. Mapping of instances to clusters

needs a processor and queues up in a ready queue shared by all processors of the cluster. So far we assume that the instances have static priorities specified with integer numbers. The smaller the number, the higher the priority. Once an instance reaches an input event, it can be descheduled. In PMSC, the mapping is described for each cluster as in the following example where the cluster ABACUS is assigned instance A with priority 1 and instance B with priority 2: mapping ABACUS contains fA 1, B 2g

3.5.3. Links A link is a bidirectional, reliable communication line connecting two clusters. It consists of two channels, one for each direction. Both have the same attributes. For each pair of clusters, a link must be specified. A message that travels from one cluster to another will use the link connecting the clusters. Messages will always be transmitted unfragmented. Only one message can use a channel at a time. Additional messages will wait in a FIFO queue. Message sending is asynchronous, i.e. processors are free to proceed when the message is in this FIFO queue. The transmission time over a link depends on the message size and the two attributes latency and capacity of the respective link: transmission time = latency + message size * capacity

An example for a link L1 connecting the clusters C1 and C2 with latency 2 milliseconds and capacity 100 nanoseconds per byte is: link L1 connects C1 C2 latency 2 ms capacity 100 ns/byte

Figure 7 gives an overview of the mapping principles. Local instances from different MSCs with the same name form global instances, each with its own input queue. Instances A and B

A

m1

${observe ob1 average number message_waiting_time}

Figure 8. Observing message waiting time are mapped to cluster ABACUS, instances C and D to cluster BEBACUS. Cluster ABACUS consists of four processors P1, P2, P3 and P4 that share a ready queue. Cluster ABACUS and BEBACUS are connected by the link A. 3.6. Observations For performance evaluation it is possible to define observations in PMSC. They provide the user with an insight into the system. Performance evaluation tools will observe the system behavior at these points and report an aggregated performance measure. Besides the observations declared by the user, the performance requirements stated in section 3.3 must also be observed and controlled by the evaluation tool. In the example of fig. 8 the user wants to know how long message m1 arriving at instance A has to wait in the instance input queue. Because the msc of fig. 8 is executed several times, there are also several arrivals of message m1 and thus several samples of message waiting time. The user is only interested in the average of the samples and the number of samples. Other result values that can be requested are the standard deviation and the list of samples. As the user may specify several observations, each one gets a unique observation name (here ob1), so the derived values can be identified in the output of the evaluation tool. The output format of the evaluation tool is not specified in PMSC, but an output line might look like this: observation ob1 average:

1.2 ms number:

16

To state that the observation object he wants to monitor is the message input, the user attaches a comment with the observation statement to it. If it is not possible to specify the object by attaching a comment, an at clause is used. This is the case when monitoring a communication channel, as in the following example. observe chan at channel c1 c2 value utilization

Here the utilization of the channel carrying messages from cluster c1 to cluster c2 is monitored. Even if several messages run over the channel, there is only one utilization value, so average, deviation, number and samples make no sense here. The observation point states what attribute of an object shall be monitored. The following types of observation points can be defined in PMSC: 1. The queue length of an instance. The length can be given in number of messages (queue length messages) or memory size of all messages including their parameters (queue length bytes). The is written in a comment attached to the instance head. 2. The queuing time of messages at the receiving instances. To observe the queuing time of all messages messages waiting time is written in a comment attached to the instance

head. To observe the queuing time of one specific message message waiting time is written in a comment attached to the corresponding message input. 3. The utilization and throughput of an instance or a channel. To observe an instance, the is written in a comment attached to the instance head. A channel is observed by specifying the source and the target cluster of the channel in an at clause. The observation itself is written as a global annotation. 4. The elapsed time between two defined timestamp events and the duration of a complete reference expression (see section 3.3). The observation for a reference expression is written in a note behind the operator of the subexpression to be observated. Observations of elapsed time with the span() function are written as global annotation. 4. Conclusions In the paper Performance Message Sequence Charts (PMSC), an extension of MSC-96 to include performance aspects into the MSC language, have been described. The language extension allows for the co-specification of functional and performance aspects. This joint specification of functional and performance aspects eases the task of software engineers. It saves effort otherwise needed to maintain two different models. PMSC supports the formal specification of a variety of aspects related to performance. This includes performance requirements (e.g. response time requirements and throughput requirements), resource requirements (e.g. the computat ional cost of MSC operations), the specification of the available resources as well as the specification of the mapping of the MSC instances on the available resources. The proposed language extensions are embedded in comments of the original MSC-96 language. Thus, standard tools based on MSC-96 can still be employed. The major advantage of PMSC is its support for early performance evaluation. Since MSCs are employed from the requirements specification down to detailed design and testing, it is a prime candidate for the integrated specification of performance aspects. The wide spectrum of use of MSCs allows to employ a single specification technique to specify and evaluate performance issues in various phases of the development cycle. Different from extensions to model performance aspects with SDL, PMSC supports the early performance evaluation of systems. This is because of the orientation of MSCs towards use cases, which allow for the early specification of specific, selected executions of the system. Thus, a highly deterministic and also accurate model is available at an early design stage, which is a valuable base for performance evaluation. PMSC especially supports the evaluation of the response time of the system under various loads in an early design stage. This rather deterministic evaluation of specific uses of the system at an early design stage is not possible with performance evaluations based on SDL. This is due to the orientation of SDL towards structural and behavioral aspects, rather than on use cases. Thus, performance evaluation based on extensions of SDL are typically based on probabilistic branching which prohibits the accurate evaluation of the response-time behavior of the system for different classes of services. We are currently working on a set of tools based on PMSC. A PMSC parser has been implemented.The parser is based on the Kimwitu tool [8] and supports the fast extension of the PMSC language to quickly include new annotations (performance constructs) as they are needed. In addition, we are working on a PMSC simulator that supports performance evaluation and validation. The PMSC simulator will support deterministic as well stochastic simulation. In case of a deterministic simulation, or the simulation with bounded times, the simulator will allow us to validate the performance requirements as specified in the PMSC description.

The PMSC language is also an integral part of the DO-IT toolbox. The DO-IT toolbox provides an integrated set of tools to support the early and systematic integration of performance aspects in the development process of SDL systems. The DO-IT toolbox is a joint project of the Universities of Erlangen and Cottbus and aims at the derivation of efficient code from SDL specifications. With the DO-IT toolbox, the implementation is derived in four steps: First, the cost for the execution of the different components of the SDL specification are analyzed. Second, a semantical analysis of the SDL specification determines where certain code optimization strategies can be applied and provides hints to the user where a modification of the SDL specification may result in the derivation of more efficient code. The derived information are described with the PMSC language. In the third step, an appropriate implementation design is derived for the available target machine. This is done based on the information derived in the first and second step and an abstract specification of the available machine. In order to evaluate different implementation designs, simple evaluation techniques as well as complex simulations based on the PMSC simulator currently developed may be employed. Next, the actual code is derived for the SDL specification. The code generator is in charge of implementing the design decisions made in the previous step. Last, the implementation is measured and the performance figures of the implementation are counterchecked with the performance requirements specified with the PMSCs. The techniques employed by the DO-IT toolbox to derive efficient code are described in [9]. The application of the DO-IT toolbox to implement a multimedia conference system has been described in [15]. Besides the implementation of pure software systems based on SDL, we are also working on a rapid prototyping system that supports the codesign of hardware/software systems based on SDL, PMSC and VHDL. REFERENCES 1. 2.

3.

4.

5.

6.

7.

F. Bause, P. Buchholz. Qualitative and Quantitative Analysis of Timed SDL Specifications. Kommunikation in Verteilten Systemen, Reihe Informatik aktuell, Springer, 1993. F. Bause, H. Kabutz, P. Kemper, P. Kritzinger. SDL and Petri Net Performance Analysis of Communicating Systems. Proc. 15. Int. Symp. on Protocol Specification, Testing and Verification (PSTV’95), P. Dembinski, M. Sredniawa (Ed.), June 1995. S. B¨ohmer, R. Klafka. A new Approach to Performance Evaluation of Formally Specified Protocols. Formal Description Techniques for Distributed Systems and Communication Protocols (FORTE), VIII, 1994. L. Braga, R. Manione, P. Renditore. A Formal Description Language for the Modelling and Simulation of Timed Interaction Diagrams. Joint Int. Conf. on Formal Description Techniques for Distributed Systems and Communication Protocols (IX) and Protocol Specification, Testing and Verification (XVI) (FORTE/PSTV’96), Gotzhein, Bredereke (Eds.), p. 245-260, Chapman & Hall, 1996. M. B¨utow, M. Mestern, C. Schapiro, P.S. Kritzinger. Performance Modelling with the Formal Specification Language SDL. Joint Int. Conf. on Formal Description Techniques for Distributed Systems and Communication Protocols (IX) and Protocol Specification, Testing and Verification (XVI) (FORTE/PSTV’96), Gotzhein, Bredereke (Eds.), Chapman & Hall, 1996. M. Diefenbruch, E. Heck, J. Hintelmann, B. M¨uller-Clostermann. Performance Evaluation of SDL Systems Adjunct by Queuing Models. SDL ’95 with MSC in CASE (Proc. Seventh SDL Forum), R. Braek, A. Sarma (Ed.), Elsevier, 1995. W. Dulz. A Framework for the Performance Evaluation of SDL/MSC-specified Systems. Proc. ESM‘96, Budapest, June 1996.

8. 9.

10. 11. 12. 13.

14. 15.

16. 17. 18.

19. 20. 21.

P. van Eijk, A. Belifante. The Term Processor Kimwitu, http://wwwtios.cs.utwente.nl/ doc/tp.man/tp.man.html, March 1993. R. Henke, H. Ko¨ nig, A. Mitschele-Thiel. Derivation of Efficient Implementations from SDL Specifications Employing Data Referencing, Application Level Framing and Activity Threads. Submitted to SDL-Forum ’97. ITU-T. Z.100, Appendix I. ITU, SDL Methodology Guidelines. ITU, 1993. ITU-T. SDL+ Methodology: Manual for the use of MSC and SDL (with ASN.1). Draft document, ITU, March 1996. ITU-T. Z.120, Message Sequence Chart. ITU, 1996. S. Leue. Specifying Real-Time Requirements for SDL Specifications – A Temporal Logic-Based Approach. Proc. 15. Int. Symp. on Protocol Specification, Testing and Verification (PSTV’95), P. Dembinski, M. Sredniawa (Ed.), June 1995. J. Martins, J. Hubaux. A New Methodology for Performance Evaluation Based on the Formal Technique SDL. Proc. Design and Analysis of Real-Time Systems (DARTS ’95), Bruessels, Nov. 1995. A. Mitschele-Thiel, P. Langend¨orfer, R. Henke. Design and Optimization of High-Performance Protocols with the DO-IT Toolbox. Joint Int. Conf. on Formal Description Techniques for Distributed Systems and Communication Protocols (IX) and Protocol Specification, Testing and Verification (XVI) (FORTE/PSTV’96), Gotzhein, Bredereke (Eds.), p. 45-60, Chapman & Hall, 1996. R. Reed. Methodology for real time systems. Computer Networks and ISDN Systems, 28, 16851701, 1996. E. Rudolph, P. Graubmann, J Grabowski. Tutorial on Message Sequence Charts. Computer Networks and ISDN Systems, 28, 1629-1641, 1996. C. Schaffer, R. Raschhofer, A. Simma. EaSy-Sim: A Tool Environment for the Design of Complex, Real-Time Systems. Proc. Int. Conf. on Computer Aided Systems Technologies, Innsbruck, SpringerVerlag, May 1995. C. Schaffer. MSC/RT: A Real-Time Extension to Message Sequence Charts (MSCs). Interner Bericht TR140-96, Institut f¨ur Systemwissenschaften, Johannes Kepler Universit¨at Linz, 1996. Telelogic Malm¨o AB: SDT 3.1 User’s Guide, SDT 3.1 Reference Manual. 1996. Verilog. ObjectGEODE – Technical Documentation, 1996.