ISSN: 1023-7151Issue: 018January 1995

Use Word 6.0c or later to

view Macintosh picture.

NEWSLETTER

CONTENTSEditorial:Years of Experience 2SDL combined with ASN.1 3

What is ASN.1 3Applicaton areas for Z.105 3Introduction to Z.105 4Restrictions on ASN.1 and SDL 6Tool support 6What can Z.100 learn from Z.105 7Operators on ASN.1 types 7

SDL Bookshelf 10Z.100 Corrections Masterlist (Oct.94) 11Change Request Form 14BSDL - Semantic Issues for SDL 15

Motivation 15Semantics of SDL-92 16Using the Semantics 17BSDL: One Step Further 18Using BSDL 20Status & Future Plans 21

Q.6/10 meeting (10/94) 22

Use Word 6.0c or later to

view Macintosh picture.

ISSN 1023-7151 Newsletter Nº 18 – January 1995 Page 2

CET-IN ESSI project 23Newsletter and other sources 27Seventh SDL Forum 28

Nº 18 January 1995

Use Word 6.0c or later to

view Macintosh picture.

ISSN 1023-7151 Newsletter Nº 18 – January 1995 Page 3

Editorial

Years of ExperienceIt is the beginning of January 1995 as I write this editorial: usually the time to review the year that has past and to plan for the next twelve months. The SDL highlights of 1994 are: the publication in May (at last) of the ITU-T book for SDL-92 and the corresponding methodology guidelines, the approval by ITU-T Study Group 10 of a proposed new Recommendation Z.105 for the use of SDL with ASN.1, and continued growth of the SDL community.

For the long term, the increased use of SDL is probably the most important. It is a now a recommended language within the aircraft industry so that Boeing and other aeronautical companies are investing in SDL expertise. As an example I recently found out Aerospatiale of France are evaluating SDL and MSC for their "Future Air Navigation System" (FANS). The initial application is to specify data communication between the ground and aircraft. ARINC (Aeronautical Radio Inc.) is the organization in charge of aeronautical standards and norms and is beginning to send out some protocol specifications using SDL. By contrast, I recently visited an organisation in Loughborough, England that produces systems for printing and packaging. For new systems the control will be engineered with SDL. I am sure there are many other examples of non-telecommunications uses of SDL, as well as increased use within the telecommunications industry.

The unfulfilled expectations for 1994 are: the unavailability of tools to support SDL-92, lack of general acceptance that SDL can be “simplified”, and the slow progress on the definition of a common interchange format (CIF) for graphical information between SDL tools. Fortunately results are expected in 1995 for both SDL-92 tools and CIF. As far as simplification is concerned, the scope and objectives are under review and the current focus is on language stability. The plan to revise the SDL standard (ITU-T Z.100) has been rescheduled from 1996 to 1998 at the earliest, so that the revision has been called “SDL 2000”. By the time of the Seventh SDL Forum, 25-29 September Oslo, there should be new tools, an agreed CIF and at least an outline plan for SDL 2000. The Forum is an excellent opportunity to establish the user needs for SDL and its tools in the future. It is a requirement that modifications or extensions to SDL are supported by a substantial user community as described in the SDL Newsletter 17 - May 1994. For your convenience the change request form is repeated in this edition.

Expectations for 1995 include the ITU-T publication of the the Z.105 standard, SDL combined with ASN.1. It is hoped that tools to support this standard will follow rapidly as the work on the standard was produce to meet user requests.

Since the publication of SDL Newsletter 17, another change that has happened in 1994 is the registration of an International Standard Serial Number (ISSN) for the SDL Newsletter. The main advantages are: ease of reference to articles in the Newsletter, archive copies at the British Library, and better protection of copyright for authors. I hope that this will encourage contributions.

Rick Reed, January 1995.

The SDL Newsletter is prepared under the auspices of ITU-T and this issue is distributed free of charge by SISU, Oslo, Norway. The newsletter is published irregularly, currently once or twice per year. Contributions and comments are requested and should be sent to the editor:Rick ReedTSE Ltd., 13 Weston House18-22 Church Street, LutterworthLeicestershire, LE17 4AW, United Kingdom

e-mail: rick.reed@eurokom.ieTel: +44 14 55 55 96 55Fax: +44 14 55 55 03 96

© Telecommunications Software Engineering Limited.The SDL Newsletter is copyrighted to protect the rights of contributors. However, you may copy the whole Newsletter or any complete article within it provided this is not done for profit or gain.

SDL combined with ASN.1

Louis Verhaard, Telia Research AB, SwedenTel. +46-40 10 50 00, Fax +46-40 10 51 00,

Email Louis.Verhaard@malmo.trab.se

A new ITU standard is on its way: Recommendation Z.105. This standard allows the combined use of SDL and ASN.1, a language for data specification. This article gives a brief overview of Z.105.

This article starts with a brief introduction to ASN.1. Then it is discussed in which areas Z.105 can be applied most fruitfully. A short introduction to Z.105 is given, with some small examples. The main restrictions on SDL and ASN.1 are listed and a prediction about tool support for Z.105 is given. An annex contains an overview of the operators that are available on ASN.1 data types.

What is ASN.1

ASN.1 is a language for the specification of data. ASN.1 stands for Abstract Syntax Notation 1. Curiously enough, there exist two ASN.1s. The first ASN.1 is defined in ITU Recommendation X.208, the second in ITU Recommendations X.680 - 683 that are ultimately expected to replace X.208, but for the time being they co-exist.

ASN.1 is very popular for the specification of data in telecommunication protocols and services, especially in higher (= application oriented) layers. For example ASN.1 is used in X.400, X.500, and all protocols (there are many of them) based on ROSE [ROS] or TCAP [TCAP]. ASN.1 is also used as the data language in the test notation language TTCN [TTCN], and also in GDMO [GDMO], a language for specifying managed objects used in OSI management standards.

Seen from a computer scientist view ASN.1 is not an elegant language. It is rather “bits and bytes” oriented. But it has the right constructs for practical applications. The same is unfortunately not true SDL: for example the ASN.1 CHOICE construct, the possibility to have optional fields in a SEQUENCE and the many subtyping constructs (also with size constraints) are very often used in protocol/service specification, but are not built-in contructs in SDL.

Another strong point of ASN.1 is that there are encoding rules that define for any ASN.1 data value how that value is encoded to bits. There are several different sets of encoding rules. Most well-known are the Basic Encoding Rules, but also Packed Encoding Rules, Canonical Encoding Rules and many other ones exist, all having their own advantages and disadvantages.

ExampleExampleRecord ::= SEQUENCE {

a INTEGER,b BOOLEAN }

The above ASN.1 type definition is the ASN.1 way of specifying a record of two fields.The value { a 5, b TRUE } can be encoded with the Basic Encoding Rules as (hexadecimal) 30 06 02 01 05 01 01 01.

Applicaton areas for Z.105

The most obvious application area for Z.105 is the specification and development of telecommunication systems, since both SDL and ASN.1 are widely used for this purpose. Z.105 can be fruitfully applied in both standardisation and product development.

Both SDL and ASN.1 are quite popular in telecommunications. For example there are many telecommunication standards that use both SDL and ASN.1. But since it was not possible to combine the two languages, the SDL diagrams in such standards often do not contain any data at all! Here Z.105 gives opportunities for more complete use of SDL in telecommunication standardisation.

Since SDL is also used as a programming language, Z.105 is also useful in product development where interfaces of the product are described with ASN.1. With Z.100, one had to do the following:

• Respecify the ASN.1 data using corresponding SDL data constructs• Map these SDL data constructs manually to the corresponding ASN.1 data (so ASN.1

coding/decoding functions can be used) or write coding/decoding functions.

With the right tool support (i.e. support for encoding rules) for Z.105, it will be possible to generate code directly from SDL, including the encoding and decoding functions.

Also the automatic generation of conformance tests from SDL specifications is made easier: the reason is that standard notation for describing conformance tests, TTCN, is also based on ASN.1. Current test generation tools have to convert SDL data to the corresponding ASN.1 data (which is not always possible). This conversion is not needed if ASN.1 data is also used in the SDL description.

Another application area is the specification of behaviour of managed objects (GDMO). Currently the behaviour of managed objects is described using natural language, while the interfaces are described with ASN.1. Z.105 enables formal behaviour description of managed objects.

Introduction to SDL combined with ASN.1

Learning SDL combined with ASN.1 is quite easy, if you know ASN.1 and SDL. Basically, ASN.1 can be used at the places where SDL data normally can be used.

Z.105 is based on SDL-92 and on ASN.1 as defined in X.680, which is in some details different from the older ASN.1 in X.208. The new concepts that are defined in X.681-X.683 are not (yet) supported by Z.105.

The rest of this section gives some examples of SDL with ASN.1. For more extensive examples, guidelines, and an overview of the syntax, the reader is referred to Z.105, that contains some tutorial-like appendices.1

Including ASN.1 modules in SDL

The ASN.1 module corresponds to the SDL package concept: it is a container for type and value definitions. A module can be imported into an SDL diagram by putting the ASN.1 IMPORTS construct in a text symbol, as shown in figure 1below. The imported data types can then be used in the SDL diagram.

Use Word 6.0c or later to

view Macintosh picture.

Figure 1: including an ASN.1 module in SDL

1 Z.105 as approved by Study Group 10 in 1994 has been distributed by the ITU as COM 10-10. To obtain a copy contact your local ITU representative.

Definition of ASN.1 data types in SDL

It is also possible to define ASN.1 data types directly in SDL by putting the type definitions in a text symbol. Note that the type definition must be ended with a semicolon. An example is given in figure 2.

Use Word 6.0c or later to

view Macintosh picture.

Figure 2: defining ASN.1 types directly in SDL

An extra feature is that it is possible to use “inline” datatyping: for example it is possible to declare a variable of type INTEGER(0..21) as in figure 3 below.

Use Word 6.0c or later to

view Macintosh picture.

Figure 3: inline typing

Z.100 does not support inline typing, so with Z.100 an extra type definition would have to be introduced as shown in figure 4.

Use Word 6.0c or later to

view Macintosh picture.

Figure 4: corresponding type definition in Z.100

Definition of ASN.1 values in SDL

Besides the possibility to define data types, ASN.1 also has concepts to define particular values of a type. For example

yes BOOLEAN ::= TRUE

ASN.1 values correspond to SDL synonyms.

ASN.1 values can be either imported from ASN.1 modules, or defined directly in SDL, similar to data type definitions. Figure 5 shows an example of ASN.1 value PI that is directly defined in SDL.

Use Word 6.0c or later to

view Macintosh p icture.

Figure 5: ASN.1 value defined directly in SDL

Use of operators on ASN.1 data

ASN.1 has no operators on data. For example, ASN.1 has the type INTEGER, with values 0, 1, -1, etc., but no “+” to add two integers! This may seem strange, but the original purpose of ASN.1 is only to define data types for protocols and services. There is no need to describe how values of data types can be manipulated.

However, in SDL operators on data are needed. Therefore Z.105 defines a set of predefined operators on ASN.1 types. Most of these operators are exactly the same as the operators on the corresponding SDL predefined data. For example the SDL Integer operators are available for ASN.1 INTEGER, for ASN.1 SEQUENCE the SDL operators (Make!, ..Extract!, etc.) for STRUCT are used.

New operators have only been introduced for the ASN.1 types for which no direct SDL counterpart is present. In the annex an overview of the operators on ASN.1 data is given.

Restrictions on ASN.1 and SDL

There are some restrictions in Z.105, both on ASN.1 and on SDL.

The most serious restrictions on the use of SDL are:• Names may not contain the characters {, }, [, ], or |, since these characters have special

meaning in ASN.1.• New keywords are introduced, which may not be used as names.

The most serious restrictions on ASN.1 are:• The ASN.1 concepts as defined in X.681-683 are not supported. The reason is that most

of these concepts are very difficult to combine with SDL. Because of the urgency of Z.105 they were left out. A future version of Z.105 may support these concepts.

• The dash in ASN.1 names is not supported, since the dash is the minus operator in SDL. Underscores should be used instead.

• ASN.1 type or value definitions must be ended with a semicolon.• Z.105 is case insensitive, whereas ASN.1 is case sensitive. However it is allowed to use

the same name in different entity classes, for example the following is allowed:SameName ::= INTEGER { sameName(0) }sameName SameName ::= sameName

• Macros are not supported, so neither is the popular OPERATION macro of the Remote Operation Service [ROS]. Instead of the operation macro, signal definitions can be used.

• Encoding rules are outside the scope of Z.105, because they are implementation dependent. However, tools may support encoding rules.

Tool support

There is already a tool that can handle ASN.1 in combination with SDL, viz. the tool developed at the Humboldt University. The author guesses that the first commercial tools will appear around the end of 1995. However, this guess is not based on official statements of tool vendors!

What can Z.100 learn from Z.105

It is not likely that ASN.1 will be the “core” data language for SDL-2000. Although ASN.1 is very suitable for the specification of “real” interfaces, it is too much implementation oriented to be suitable for the specification of more abstract systems.

However, the author thinks that some concepts of Z.105 should also be incorporated in Z.100 some way or another:

• a union data type like the ASN.1 CHOICE (badly needed!)• the possibility to have optional fields in SDL structs like (also really missing in SDL)• more flexible enumerated types (with succ and pred operators)• syntypes with size constraints• inline data typing (see figure 3)• a kind of object identifier for SDL packages like in ASN.1 to ensure world-wide

uniqueness of references (the name of a package may not be enough!)

Conclusions

Z.105 allows ASN.1 to be used in combination with SDL, thereby giving new possibilities in telecommunications protocol/service standardisation and product development. It is easy to master SDL combined with ASN.1, since the languages are combined in a straight-forward way. Of course SDL combined with ASN.1 becomes first really attractive when commercial tools appear become available.

References[GDMO] ITU Recommendation X.722 (01/92): Guidelines for Definition of Managed Objects.[ROS] ITU Recommendation X.229 (1988): Remote Operations: Protocol specification.[TCAP] ITU Recommendations Q.771-775: Transaction Capabilities.[TTCN] ITU Recommendation X.292 (09/92): The Tree and Tabular Combined Notation.

Annex: operators on ASN.1 types

This annex gives an overview of the supported ASN.1 types, and operators that are available in SDL for these types.

For every type, at least two operators are present: = (equality) and /= (unequality).

BOOLEAN

Operators: same as SDL Boolean

INTEGER

Operators: same as SDL Integer

ENUMERATED

Operators:... = ..., ... /= ..., ... < ..., ... > ..., ... <= ..., ... >= ...,

/* comparison operators (based on supplied numbers) */num (...) ,

/* gives the integer value associated with an enumerated value */pred (...), succ (...)

/* give predecessor and successor of an enumerated value (pred of first element and succ of last element result in error) */

REAL

Operators: same as SDL Real, and additional:exp (..., ...),

/* exponential operator. The arguments are integers. E.g. exp(2, -1) = 0.5 */

BIT STRING

For BIT STRING, a new type BIT is introduced with values 0 and 1, and all BOOLEAN operators.

Operators:... = ..., ... /= ..., Length (...), Mkstring(...), SubString(..., ..., ...), ... // ... , ...(...) ,

/* same as the operators on SDL String */not ..., ... and ..., ... or ..., ... xor ..., ... => ...

/* bitwise not, and, or, xor, => operators */

OCTET STRING

For OCTET STRING, a new type OCTET is introduced.

Operators for OCTET STRING:... = ..., ... /= ..., Length (...), Mkstring(...), SubString(..., ..., ...), ... // ... , ...(...) ,

/* same as the operators on SDL String */BITSTRING (...),

/* OCTET STRING to BIT STRING conversion */OCTET STRING (...)

/* BIT STRING to OCTET STRING conversion */

NULL

Operators:... = ..., ... /= ...,

SEQUENCE

Operators:... = ..., ... /= ..., ...!<identifier> ,

/* gives the value of one component, e.g. s!field1 = 8, s!field2 = 7, s!field3 results in a dynamic error */

present_<identifier> (...) /* for optional components: indicates whether the identifier is

present or not: present_field3 (s)=FALSE */

where the examples are based on the ASN.1 definitionsS ::= SEQUENCE {

field1 INTEGER,field2 INTEGER DEFAULT 7,field3 BOOLEAN OPTIONAL}

s S ::= {field1 8}

SEQUENCE OF

Operators:... = ..., ... /= ..., Length (...), Mkstring(...), ... // ... , SubString(..., ..., ...), ...(...)

/* same as the operators on SDL String */

SET

See SEQUENCE

SET OF

The examples are based on SET OF INTEGER

Operators: ... = ..., ... /= ..., ... < ... , ... > ..., ... <= ..., ... >= ...,... and ..., ... or ..., ... in ..., Incl (..., ...), Del (..., ...), Length (...)

/* same as on SDL Powerset, but note that in the ASN.1 SET OF, the number of occurences is important, for example {3, 3} /= {3}, {3, 3} > {3}, {1, 2} = {2, 1} ,Del (2, {2, 3, 2}) = {3, 2}, Length ({1, 1, 2}) = 3 */

CHOICE

The examples are based on

C ::= CHOICE {field1 INTEGER, field2 BOOLEAN}, c C ::= {field1:5}

Operators :... = ..., ... /= ..., ...!<identifier> ,

/* field selection, e.g. c!field1 = 5, c!field2 results in a dynamic error */

present_<identifier> ,/* indicates whether the identifier is present,

e.g. present_field1(c) = TRUE, present_field2(c) = FALSE */...!present ,

/* indicates which identifier was chosen in a value by giving its identifier,e.g. c!present = field1 */

... < .../* ASN.1 selection type, e.g. field1 < C gives type INTEGER */

OBJECT IDENTIFIER

A special type Object_element is introduced that has as values all positive integers. Operators = and /= are available for Object_element.

Operators on OBJECT IDENTIFIER:... = ..., ... /= ..., Length (...), Mkstring (...), ... // ..., Substring (..., ..., ...)

/* same operators as on SDL String */

Character string types

Operators:... = ..., ... /= ..., Length (...), Mkstring(...), ... // ... , SubString(..., ..., ...), ...(...) ,

/* same operators as on SDL String */Num (...)

/* returns canonical number of a character */

Useful types

As for all types, operators = and /= are defined on the useful types. There are no special operators for these types: the useful types are defined with help of other ASN.1 types.

Subtypes

All subtyping mechanisms are supported. A subtype has exactly the same operators as its parent type.

Tagged types

Tagged types are allowed to be used, but the tags are completely ignored. A tagged type has exactly the same operators as its base type.

_________________________________

SDL BookshelfRick Reed, TSE Ltd.

One of the frequently asked questions about SDL is “What books are available?”. The following is a list of reference and text books that I have in my collection. I have not included SDL Forum books.

1. Z.100 CCITT Specification and Description Language, ITU-T (03/93), Geneva.

2. Z.100 Annexes C and D, ITU-T (03/93,) Geneva.

3. Z.100 Appendices I and II, ITU-T (03/93,) Geneva.

4. Z.120 Message Sequence Chart, ITU-T (03/93,) Geneva.Items 1-4 can be ordered direct from the ITU-T Sales Section with payment by credit card

Place des Nations CH-1211 Geneva 20 Switzerland. tel:+41 22 730 5285. fax:+41 22 73 5194.

5. SDL with Applications from Protocol Specification,Ferenc Belina, Dieter Hogrefe, Amardeo Sarma, BCS Practitioner Series - Prentice Hall 1991 ISBN 0-13-785890-6.

6. Engineering Real Time Systems, Rolv Bræk & Øystein Haugen, BCS Practitioner Series - Prentice Hall 1993 ISBN 0-13-034448-6.

7. Using Formal Description Techniques, Edited by Kenneth J. Turner, John Wiley and Sons 1993 ISBN 0 471 93455 0.

8. Telecommunications Systems Engineering Using SDL, Roberto Saracco, J. R. W. Smith, Rick

Reed, North Holland 1989 ISBN 0 444 88084 4.

9. Systems Engineering Using SDL-92, A. Olsen, O. Færgemand, B. Møller-Pedersen, R. Reed, J.R.W. Smith, North Holland 1994 ISBN 0 444 89872 7.

Items 5 to 9 can be obtained through a good book seller or direct from the publishers.

As an author of two of the books I am, of course, biased and therefore cannot make any specific suggestions which books to buy. Personally I refer to all the books, including Z.100 and the parts written by my colleagues of the books that I co-authored.

Z.100 corrections Masterlist (Oct 94)The master list of changes shown here is the output of the second SG 10 meeting from 19 - 27 October, 1994, in Geneva and incorporates all earlier changes and has been approved by ITU-T SG 10.

Corrections and Clarifications are effective immediately. The corrections are given in full to be applied to the ITU-T publication Z.100 (03/93).

Modifications, Decommitted features and Extensions are agreed by SG 10 as candidates to be included in a revision of Z.100, but are subject to the full ITU approval procedures and only take effect when new or revised Recommendations are approved by the ITU.

Open items and Closed items record the current status of study issues.

Corrections and Clarifications§2.2.2 Change the production rule for <path item> on page 19 for the concrete textual grammar

adding the option of “<operator name> <exclamation>“:

<path item> ::= <scope unit kind> { <name> | <quoted operator>| <operator name> <exclamation> }

§2.2.2 Add in Semantics at the end of the section before the last two paragraphs:

The following clarifies the visibility rules for procedures, services and service types (at the end of p. 19):a) Procedures, services and service types defined locally to a process can freely access and

use the variables and signals of that process.b) Globally defined procedures, services and service types must not use any variables

defined in the calling context.c) To access and use entities defined locally to the calling process, corresponding context

parameters must be used.

§2.4.5 Modify the last line of the second last paragraph of the Concrete textual grammar (p. 38, 2nd line) to:

An exported procedure defined in the enclosing process must be mentioned by an input or save in exactly one service.

§2.4.5 In the service text area, <valid input signal set> has been omitted. This is included in the textual representation and in the corresponding graphical representation for process diagram (<process text area>). The corrected production rule is:

<service text area> ::=<text symbol> contains {

[ <valid input signal set> ]{ <variable definition>

.... | <macro definition> } *

}

§2.4.6 In the procedure body, the textual representation has an error, whereas the graphical representation has the intuitively correct production. The correct production should be:

<procedure body> ::= [ <start> ] { <state> | <free action> } *

§2.7.5 The first paragraph after the productions for the concrete textual grammar on page 68 for Decision should be changed to (changes underlined):

An <answer part> or<else part> in a decision or an option is a terminating <answer part> or<else part> respectively if it contains a <transition> where a <terminator statement> is specified, or contains a <transition string> whose last <action statement> contains a terminating decision or option. A <decision> or <transition option> is a terminating decision and terminating option respectively, if each <answer part> and <else part> in its <decision body> is a terminating <answer part> or<else part> respectively.

The first paragraph of the Model on page 69 for Decision should be changed to:

If a <decision> is not terminating then it is derived syntax for a <decision> wherein all not terminating <answer part>s and the <else part> if not terminating have inserted at the end of their <transition> a <join> to the first <action statement> following the decision or if the decision is the last <action statement> in a <transition string> to the following <terminator statement>.

§4.2 The model of priority input is modified. The sixth sentence of the second paragraph on page 105 is changes as follows (changes underlined):

Priority inputs to the original state are connected to the first state, while all inputs, including priority inputs are connected to the second state (State 2). All inputs other than priority inputs are saved in the first state.

§4.14 The nonterminal <end> is removed in the corrected production (page 113):

<remote procedure save area> ::=<save symbol> contains {[ <virtuality> ] procedure <remote procedure identifier list> }

§5.3.1.11 the rule for <inheritance list> should be

<inheritance list> ::=<inherited operator> { , <inherited operator> }*[ , noequality ]

§5.3.1.11 (p.139) in the Example of Model the axioms part should be (delete a “)”)

axiomsExor (a,b) == (a and (not b)) or ((not a) and b);

§5.3.2 the word extended should be deleted at 7 different places.

In the <operator definition> rule (4 times),In the <textual operator reference> rule (1 time),In the <operator heading> rule (2 times).

§5.3.2 (p.147) the nonterminal <sort> replaces extended sort in the following:

<operator result> ::=returns [ <variable name> ] <sort>

§5.3.3.6 the word ground should be deleted at 3 places in the last paragraph.

§5.4.6 the rule for <external properties> should be

<external properties> ::=alternative

<external formalism name> [ , <word> ] <end><external data description>

[ endalternative ] <end>

§6.1.2 (type expression) in the Semantics list of cases, the words “or view definition” of the fourth item should be deleted as it does not apply.

§6.2 Change 2nd last paragraph of the concrete textual grammar (p.178) to:

The binding of an actual variable or synonym context parameter to its definition is not resolved by context but by using the visibility rules.

§6.3.2 Z.100 defines where virtual types are allowed inside a virtual block, and the implicit constraint for every case. Some unclear situations have been pointed out. To clarify this issue, the following two sentences are proposed as additions to Section 6.3.2.

Addition to the static conditions of the concrete textual grammar

If both inherits and atleast are used then the inherited type must identical to or be a subtype of the constraint.

In the case of an implicit constraint, redefinition involving inherits must be a subtype of the constraint.

Modifications

None (October 94).

Decomitted features

None (October 94).

Extensions

None (October 94). The alternative graphical comment agreed in April 1994 was not discussed at the October 1994 SG 10 meeting and therefore is listed as an open item.

Open Items

An open item is a concern identified but not yet resolved. An open item may be identified either by a Change Request, or by agreement of the Study Group as requiring further study.1. Handling of error in the data model.2. Extended alphabet for SDL.3. Channels and signal routes looped back to the same process.4. Support of union data sorts (“data types”).5. Support of optional values in data sorts (“data types”).6. Built-in data type conversion feature.7. Renaming literals and operators of parameterized data sort (“data type”)8. Extension of operator set for strings.(e.g. rtail,tail)9.. Allow algorithmic operators with external data.10. Extension of operator set for Pid.(e.g. operator take to get a Pid from a PId set).11. DescriptionTerms and Expressions by the same syntax. 12. Virtual and polymorphic sort types (“data types”)13. Operators returning sets of values (multivalued operators).14. Procedures with multiple exits and acting like states.

Closed Items

An closed item is a concern considered which the Study Group has decided is not currently a candidate for further study. The purpose of this list is to avoid repeated discussion of items which are unlikely to lead to any result.

There are no closed items. (October 1994)

Use Word 6.0c or later to

view Macintosh picture.

Change Request Form

Please fill in the following details

Character of change: q error correction q clarification

q simplification q extension

q modification q decommission

Short summary of change request

Short justification of the change request

Is this view shared in your organisation q yes q no

Have you consulted other users q yes q no

How many users do you represent? q 1-5 q 6-10

q 11-100 q over 100

Your name and address

please attach further sheets with details if necessary

Amardeo Sarma, Telekom FTZ, Postfach 100003, D-64276 Darmstadt, Germany. Fax: +49 6151 83 4590, e-mail: sarma@fz.telekom.de, Tel: +49 6151 83 2579

A Short Note About BSDL2

- Semantic Issues for SDL -Joachim Fischer, Stefanie Lau, Andreas Prinz

Humboldt-Universität zu BerlinInstitut für Informatik

Lindenstr. 54a, Psf 1297D-10099 Berlin

{fischer,lau,prinz}@informatik.hu-berlin.de

In this article an introduction into the language BSDL is given. From an analysis of the current semantics some problems and shortcomings are identified. The suitability of BSDL to solve these problems is shown.

1 Motivation

SDL is a formal specification and description language. From its history it is obvious that it is suitable for specifications and descriptions of dynamic systems (e.g. telecommunication systems).

Formal Semantics of SDL-88

SDL has a formal semantics, which was added later, starting from SDL-88. What is gained by this label of formality? Since 1988 SDL belongs to another class of languages, namely the formal languages. Besides this rather formal3 aspect the formal semantics provides a clear distinction between true and false not resorting to the rather vague natural language descriptions that were used before. So there is always exactly one proper interpretation of a specification and the static requirements for proper specifications are stated unambiguously. This way all tool vendors do exactly know, what to do.

Unfortunately, so far the semantics is not used that way. Firstly, the formal semantics [5] is “only” an annex to Z.100 so that most users think that it can be overruled by the natural language description in [11]4. Secondly, if the formal description is used, normally the English annotations are used instead of the real formal definition.

Another aspect of a formal semantics is to provide means to prove certain properties of the specification. This kind of proof is very difficult to do using the current SDL semantics. The reason is mainly the complexity of the formal definition, where moreover different calculi are used together (see section 2 for more details).

Formal Semantics of SDL-92

Following the tradition of SDL-88, also SDL-92 does have a formal semantics. The main difference here is, that the underlying language has changed. SDL-92 is object-oriented. This new feature of the language was not built into the semantics. Instead, all the object-oriented features were transformed into plain constructs. So the object-orientation of SDL-92 is resolved on a syntactic level and not mapped into the semantic base.

This approach is rather straightforward, since the object-orientation in SDL-92 itself is not very homogenous. For instance data types are still plain, i.e. not object-oriented.

2 read BaseSDL

3 Note the different semantics of formal and formal.

4 This is in fact not true. An annex to an ITU-T Recommendation is an integral part of the standard. In the case of SDL the language should comply with both the natural language and the formal definition. If the natural language and the formal definition are not consistent then there is in fact an error in Z.100.

Future Development

From all these reasons we felt the need to define a new formal semantics for SDL. This new semantics should be such, that the above problems can be solved easily. Moreover, it makes no sense to adjust a new semantics to an old language. So the semantics was designed with some extensions/simplifications to SDL in mind. In this sense the semantics is designed for a new SDL. For that reason this semantics has to provide means to express semantic properties of SDL and also for modern concepts that will be present in a new SDL5. The approach taken is to define an abstract language that can serve as a base for the semantics. BSDL is this language.

The design of BSDL is strongly connected to SDL in its intuitive semantics. The semantics of SDL could be easily mapped into BSDL. BSDL is itself object-oriented, has processes, communication, concurrency and a distinction between data and processes. The semantics of BSDL is defined using Object-Z [3]. It is a true concurrency semantics (not interleaving) and not based on another formalism (it is self-contained). BSDL is small and concise, so it allows for proofs of properties.

One additional aspect of the design of BSDL is the need to define behavioural semantics for some other description techniques, e.g. GDMO [10], the OMA architecture [9] and the OMG CORBA IDL [7]. BSDL should be usable to define a semantics also for these cases. For us, the major need to discuss these issues arose out of ODP [6]. We found out several deficiencies of SDL-92 and tried to build modern extensions to solve these problems into BSDL. This way BSDL could well serve as a base language for the semantics of ODP.

2 A Closer Look at the Semantics of SDL-92

In this section, the Z.100 approach to the definition of the SDL-92 semantics will be explained in some detail. The semantics is basically divided into two parts: static semantics and dynamic semantics. The static semantics part normally describes some restrictions to the formal syntax like “All identifiers have to be declared before use”. The dynamic semantics then gives a meaning to syntactically correct programs. The static semantics part of SDL-92 describes a transformation from AS06 into AS1. This transformation includes several validity and consistency checks (e.g. declaration of used identifiers) that are commonly known as static semantic checks. This AS1 is then used to give SDL a dynamic meaning. This is done by decomposing AS1 processes into some basic processes.

Static Semantics and Transformation into AS1

In [5] the static semantics has more than 400 pages. Within theses pages, the actions of an abstract static semantics checker for SDL-92 are described using Meta-IV [2]. This approach is very convenient when one has the construction of a static semantics checker in mind. However, it is very difficult to find the proper place to look at, if a concrete question of static semantics arises. The static semantics check described in [5] does not only define static correctness. It also describes the process of transforming SDL-92 (here: its Meta-IV representation called AS0) into a very simple process scenario called AS1. The static semantics amounts more or less to the restrictions encountered in this transformation.

5 Somehow one has to predict the future.

6 A language that represents in an abstract way the input syntax.

What Happens to BLOCKs and the Like?

The transformation into AS1 has the aim, to use as much as possible of the semantics that once was given for SDL-88. Thus, all the new constructs of SDL-92 have to be mapped into “old” constructs. In doing so, the language of reference (here: AS1) can be small and need to express only few constructs. So all the structuring features, the object-oriented features and the shorthand forms are transformed into basic features of AS1. This means, that the static semantics transformation process does unwrap all the types and at the level of AS1, this information is not needed any longer.

AS1: A Short Description

The idea of AS1 is to restrict SDL to a few very simple constructs. These constructs are mainly processes and channels. The functionality of the processes themselves are EFSMs in the sense of SDL-88. All the structuring of the original specification is omitted in AS1, we have only connected processes. The communication between AS1 processes is SDL communication, i.e. asynchronous via the channels. All processes have an input buffer to stack the received signals for later consumption.

Simple Semantics of AS1

The semantics of AS1 processes is mapped to Meta-IV processes. Every AS1 process is decomposed into several Meta-IV processes. These processes communicate with each other to achieve the same result as the original process. Moreover, there are some system processes that co-ordinate the other processes. These will mainly look at the creation and deletion of processes. Channels are also mapped into Meta-IV processes, so at this level of abstraction we only deal with Meta-IV processes.

Communication in AS1

The communication between the AS1 processes is done via the channels. Since the channels now are modelled as Meta-IV processes one could think that the communication problem is solved. However, this is not the case. The communication problem is only postponed, now we have to deal with the communication between channel and process7. Also the communication between the several Meta-IV processes within one AS1 process will have to be considered. This communication is synchronous and no longer asynchronous. It is modelled with an approach like CSP [8]. The asynchronous behaviour comes from the input buffers of the processes and the properties of the channels.

Time in AS1

In AS1, timers are still present. Also expression that refer to the global time are allowed. The approach of the semantics to model time is to introduce a special (system) time process. This process manages a global clock variable (NOW) which is advanced due to tick events coming from the environment. This way the timing concept is somehow decoupled from the semantics and left to the environment. There is still some informality here, since we do not specify how and when the environment has to issue ticks.

Data Types

Data types are expanded in the static semantics, i.e. the transformation process to AS1. This is done similar to the idea in [4]. Here, the construction of an initial term algebra is described. This is not always possible, so this construction is very descriptive and to a lesser amount constructive.

7 This communication is not even mentioned in Z.100, although it has to be described there, too. The dynamic semantics helps in this case as it is defined there precisily.

3 Using the Semantics

This section will try to evaluate the semantics of SDL-92. This is only possible in relation to its use. For the purpose of this paper we will consider only three possible uses. Use of the semantics for building a static semantic check tool, for building an interpreter and for proofs.

Static Semantics Checker

The first part of the semantics is pretty much the abstract specification of a static semantics checker. So all that is necessary is to concretise this description as needed. Apart from the data type part, this should be an easy task. However, this quite strict outline of a static type-checker does severely restrict the freedom of the programmer to do the things the way she wants to do.

Interpreter

Let’s for this task assume the existence of a static semantics checker that transforms SDL-92 into AS1 as described in the static semantics of SDL-92. Then the task of building an interpreter amounts to realising the dynamic semantics which is given to AS1.

This is also fairly straightforward. The processes are decomposed into Meta-IV processes that in turn are easily implemented in any implementation language. The communication is synchronous according to a CSP model - this also does not pose too severe problems. The semantics of time is left to the environment. i.e. the programmer in this case.

Proofs

There are several kinds of proofs that may be needed for a specification. First, there are general properties like deadlock freedom that can be applied to any system. Secondly, there are special, application dependent properties to prove. Here mainly safety and liveness properties come into play. Safety properties state, that something bad does not happen, e.g. “The protocol will not transfer invalid data.” Liveness properties state, that something good will eventually happen, e.g. “Finally, the protocol will transfer all data.”

All these properties are not easily verified in the SDL setting. The semantics is given in a rather complex way involving lots of transformation steps. The final semantics of an SDL specification is not easily derived, because it involves a transformation into AS1 followed by a decomposition. This not being enough, the semantics of AS1 is then composed of at least three sources: Meta-IV processes, CSP communication and time coming from the environment. These concepts are difficult to merge, at least their connections are hardly studied.

4 BSDL: One Step Further

The problems with proofs mentioned in the previous chapter led to the development of BSDL. This language should provide a semantics for the basic functionality of SDL in a uniform manner. The semantics of SDL could then be mapped into this basic framework.

Syntax

BSDL is intended to be an abstract language. So no concrete syntax is necessary since the language should be used for providing a semantics to SDL-92 or later releases of SDL. The syntax is already that abstract, that there are no identifiers. All references are direct such that identifiers could be omitted. This approach simplifies the (static) semantics of BSDL, but adds complexity to the transformation from SDL to BSDL, since here identifiers have to be transformed into direct references.

Structure in BSDL

One reason to think about BSDL was the complexity of SDL. There are so many constructs in this language, and some of them are very similar. We had the idea to map all these constructs to some

simple but expressive features. The semantics of these features could then be simpler than the semantics of all the parents. There are several constructs for structuring in SDL, SYSTEM, BLOCK, PROCESS and SERVICE. In BSDL, there is only one construct for all of these, namely process. To allow for all of the uses of the above constructs, processes may contain other processes and they may control their interaction.

Another way to structure SDL-92 specifications is object-orientation. The new object-oriented features allow to express relations between parts of the specification and to use similarities between subparts. As stated in below, these relations are lost during the transformation process into AS1. In BSDL, however, object-oriented concepts belong to the basic language. They are not transformed, but form an essential part of the language. This way the structure of the system can be expressed fairly directly even at the semantics level of BSDL. In the scope of BSDL object-orientation should also allow to express refinement relations between several stages of the design of a specification. Then the refined part will be a descendent of the general one adding the refinements.

Communication

After having provided an understanding of the kind of processes, that exist in BSDL, we now want to look a bit closer at the communication of these processes. Should this be synchronous or asynchronous? From the experience of AS1, a synchronous communication between channel and process will be necessary anyway, so we decided to take synchronous communication into the core of BSDL and make asynchronous communication a derived concept. This may even be a class in the BSDL sense, such that this concept is easily expressed in BSDL.

Object-Oriented Semantics

One of the aims of BSDL was to define the semantics of a construct at one place and not to spread the information too far away. This is done using an object-oriented technology for describing the semantics. The semantics of a single language construct is described as a class. The syntax amounts to the constituents of the class, the static semantics amounts to restrictions on the admissible components and the dynamic semantics is a distinguished attribute of the class. A concrete instance of the construct is then an object of the appropriate class. So an SDL specification corresponds to an object of the class corresponding to the syntactic category “SDL specification”.

Static Semantics

As pointed out above, the static semantics of BSDL is described as a set of restrictions to the constituents of the construct in question. There is no transformation into a more simple language necessary, because BSDL already is the basic language. So the static semantic rules are only well-formedness rules and do not involve transformations. From an SDL perspective, this static semantics is not complete, since identifiers are not handled here. The transformation from SDL into BSDL has then also to handle this part of the static semantics.

Dynamic Semantics

For the dynamic semantics of BSDL, it had to be decided whether to map the language to some well-known domain of semantics of concurrent programs (e.g. Petri nets, temporal logic, CCS) or to build a semantics without reference to these sources (but probably in the same spirit). The worst problem was the interpretation of SDL data types. None of the known (to us) semantic techniques for concurrent systems had equally good support for data types and concurrency. Another issue is time, that is also only respected by few of the techniques. So finally the decision was taken to build a self-contained semantics.

The semantics has to model concurrency and non-determinism. For concurrency, the true concurrency concept was considered better than an interleaving approach, because it is more general. So what is the semantics (of a process/system)? The semantics is a DAG (directed acyclic graph), where branching is used to model concurrency. A path from node A to node B means a causal dependency from A to B, i.e. A was causally before B. In the scope of SDL, branching will

occur when new processes are created. Two edges will lead to one node in the case of communication, where also two edges will go out of this node.

But what about non-determinism? This is modelled as sets of DAGs. So the semantics is not one single DAG (but could be), but a set of all possibilities according to the non-determinism involved (e.g. sequence of the signals received).

Time

For the dynamic semantics to be complete, a timing part is needed. This is done using time labels for the nodes of the DAGs. These time labels then represent the actual time of the processing of the node (something like NOW). Of course, the time labels have to be in correspondence with the causal ordering imposed by the DAG.

The time labels have to come from the time domain (Time). From our experience, there are several uses of the SDL time model. Sometimes, one may want to explore the specification in a qualitative time model, where only before/after relations play a role. Sometimes, one may want to use a quantitative model instead, where exact times are used. There could be a central clock (NOW), or a separate clock for each of the different processes. It seems clear, that for every special application domain the time model could be different. So we decided not to take any specific time model, but to take an abstract data type Time for all of these models. Every time model fitting the requirements of this abstract type are admissible for timing8. For a concrete implementation one would provide some useful timings as default.

Data Types

Data types in BSDL provide functionality. The ACT ONE concept of SDL did not prove useful, so now there are different ways of declaring data types. However, the applications of ACT ONE data types used to define the SDL basic types are still possible.

BSDL incorporates two kinds of abstractness - value abstractness and state abstractness. Value abstractness amounts to values of a data type, that are not completely determined, but only restricted due to some restriction predicate. This is achieved in BSDL with an extended assignment statement. The extended assignment statement allows expressions on the left hand side and tries to find admissible values for the variables in order to make the values equal. If the right hand side is a single variable, the extended assignment reduces to the ordinary assignment.

State abstractness means, that the structure of the data type is not known, only the operations and some restrictions for their results (this is the approach of ACT ONE). To achieve this kind of abstractness, there is a special ABSTRACTSTATE type, that is semantically equivalent to a sequence of operation calls. This type can then be replaced by a more concrete type. This approach allows at least for the inclusion of all the predefined data type definitions of Z.100.

5 Using BSDLStatic Semantics Checker

A static semantics checker is not very difficult to derive from the definition of BSDL. It suffices to transform the restrictions for the subparts of the syntactic entities into executable statements. Here only a check is necessary, so the result of this static semantic check is not a transformed specification, but only “yes” or “no”. The dynamic semantics can then take it for granted that the specification is statically well-formed.

Interpreter

The construction of an interpreter is also not too difficult with this semantics. One run of a

8 Note, that these different time models represent different levels of abstraction, not different semantics.

specification amounts to the construction of one admissible DAG from the set of DAGs belonging to the semantics of the entity in question. The construction of these DAGs is fairly explicit in the semantics. Special care has to be taken to avoid DAGs that are not feasible due to timing restrictions. The timing restrictions are difficult to see from the construction of the DAGs and provide a certain level of complexity for the interpreter.

Proofs

The semantics of BSDL is small, concise and self-contained. So the derivation of proofs should not be too difficult. However, the case studies to use this property are not finished yet and we cannot say too much about this issue. The results derived so far look promising.

6 Current State and Future Plans

Currently, release 0.1 of BSDL is ready. This means that this language is not complete yet, many details have to be filled in. However, the basic constructs are clarified and the intuitive semantics is clear. Even the syntax is more or less stable.

This work will proceed to complete BSDL - syntax and semantics. Meanwhile we try to map the constructs of SDL-92 into BSDL in order to prove its usefulness. Also its applicability for proofs will be studied in case studies.

The next step ahead is to look for the relations between BSDL and a new release of SDL to come (SDL-2000). This new SDL will be somewhere in-between SDL-92 and BSDL, but the question is, if it is more in the spirit of SDL-92 or in the spirit of BSDL. We hope, that BSDL will in any case be sufficient to model the semantics of this new language.

References [1] TD-65 (Source Humboldt-University Berlin). BSDL the language - version 0.1. In

ITU SG 10 Meeting in Geneva, 1994. [2] D.~Bjørner and C.B. Jones. The Vienna Development Method: The Meta-Language,

volume~61 of LNCS. Springer Berlin, 1978. [3] Roger Duke, Paul King, Gordon Rose, and Graeme Smith. The Object-Z

specification language (version 1). Technical report, SVRC, The University of Queensland, 1991.

[4] Hartmut Ehrig and Bernd Mahr. Fundamentals of Algebraic Specification. Springer, 1985.

[5] Z.100:~Annex F. Specification and Description Language (SDL) - SDL formal definition. ITU, 1993.

[6] Joachim Fischer. Contributions for the formal specification of the ODP trader using SDL-92 and ASN.1. Informatik-Bericht~37, Humboldt-University Berlin, 1994.

[7] Object~Management Group. The Common Object Request Broker, Rev. 1.2. OMG, 1993.

[8] C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985. [9] ISO/IEC. Open Distributed Management Architecture, first working draft. ISO/IEC,

1994. [10] Recommendation X.722. Information Technology - Structure of Managed

Information - Part 4: Guidelines for the definition of managed Objects. ITU-T, 1991.

[11] Z.100. Specification and Description Language (SDL). ITU, 1993.

Q.6/10 meeting (10/94)Rick Reed, TSE Ltd.

This is a brief report on the key points of the ITU-T Study Group 10 Question 6 (Maintainance of SDL) meeting that took place in Geneva 20-26 October 1994.

The new Z.105 Recommedation was approved. There were a few corrections and clarifications to the draft made during the meeting that were subsequently incorporated into the master document. This was distributed by ITU-T as COM 10-10 in December. The normal voting procedures for a standard are now in progress and the first reply from members has to be returned by the 6 March 1995.

Progress was made towards a Common Interchange Format so that SDL/GR from one tool can be transferred to another tool so that the diagrams are “recognisably the same”. It has been decided to continue the work in three phases:1. Decide what information will be represented. There was a goal to complete this step by early

1995. 2. Define how to represent the information together with completeness/incompleteness rules.3. Define the exact syntax.

The intention was to have a draft CIF available by March so that it could be input to the ITU-T meeting in April 1995. The CIF has been given the Recommendation number Z.106. Users who have a keen interest in this work should contact the SDL rapporteur, Amardeo Sarma.

The general revision of the SDL Methodology Guidelines to become the “SDL Methodology” is still in progress. A rough draft of the new methodology was prepared and circulated based on the existing guidelines and the rapporteurs knowledge of work done within ETSI on a methodology for protocol and service specification using SDL. Although the existing guidelines are useful the new document is intended to be more coherent and provide a clear framework that can be elaborated to meet the needs of specific cases. It is generally agreed that the Methodology needs to contain both examples and procedures for the production of specifications. Other inputs to the methodology work as using SDL with ASN.1 to describe the behaviour parts of GDMO, the relationship with testing methods and the potential impact of Open Distributed Processing on SDL.

There has been collaborative work with ITU-T study group 11 on a revision of the “3 stage methodology” that uses SDL in the specification of supplementary services for telecommunications. The revision is to take account of the so called “Intelligent Network” (IN) approach (actually the network is as dumb as ever). The main issue is how to use SDL in the method and separate out various “Service Implementation Blocks” that provide simple functions from which the a service (such as number diversion) can be built. A key feature of IN is the separation of service control from basic call control.

The maintainance of the SDL formal semantics was discussed. There was no doubt among the SDL experts group the the formal semantic model is a valuable way of achieving a high quality language definition. This does not, of course, necessarlity convince individuals that they should tackle this difficult task or prgnaistions that they should fund the work. It was agreed that the formal semantics should if possible be made• more understandable;• more maintainable;• provide better support for dynamic analysis.

The BSDL that is further described in this Newsletter was considered as a possible basis of future work. The main objective is to be able to animate the formal model and therefore “debug” the language. Ideally this capability should be available for work on “SDL-2000”.

SDL-92 for CET - IN Extract from Initial Report (Dec 94)

ESSI Project Number: 10702Prime contractor: TELECOM PORTUGAL, SA-DCID/CET

Abstract

The ESSI programme of the European Community funds “application experiments” in the use of advanced software technology in industry. The purpose of this report is to provide an overview of the experiment “SDL-92 for CET - IN” at end of the start-up phase of the experiment. This edited version of the report in the SDL Newsletter is for interested parties in industry.

The CET - IN project is an experiment in the application of SDL-92.

CET   -   IN: The application experiment is the development of an interface to support a package of telecommunications services (e.g. Credit Card Calling, Account Card Calling, Freephone, Universal Personal Telecommunications, Universal Access Number and Virtual Private Network) from the IN (Intelligent Network) services defined in the ETSI CS-1 (Capability Set 1) standard. An available commercial hardware/software platform (HP 9000/827) at CET (Portugal Telecom Research & Development) is used to implement a “Virtual Service Switching Point” (VSSP). The software in the application experiment implements an interface from standard messages from a normal telecommunications switching system (Message Transfer Part - MTP of ITU-T Signalling System No 7). This is interfaced to the Service Control Function (SCF) and the Service Resource Function (SRF) controlling an Intelligent Peripheral (IP) connected to the switching system.

Results: IN standards are emerging, but the SDL specifications in standards need to be improved and validated for implementation. The experiment has several areas of potential interest: the application of SDL-92; feedback to ETSI and ITU-T on the use of SDL-92 in standards; feedback to ETSI and ITU-T on the evolving IN standards. Although the application is particular to the telecommunications industry, the general feedback on the use of SDL-92 should be applicable to any system which is essentially real-time with discrete message interfaces.

Introduction

The new object oriented version of ITU-T SDL (SDL-92) is used. The new methods recommended by ITU-T for use with SDL-92 enhanced by additional publicly available material from RACE SPECS, RACE ARISE, Norwegian SISU and the ETSI methodology projects adapted to the engineering organisation within CET. The application experiment is to provide the technology transfer to CET of latest version of SDL, together with the new methods and the new tool. All three of these have yet to be fully proven in an industrial environment. The tool and methods cover the complete engineering cycle and therefore covers documentation, analysis, simulation, code generation and testing. The new approach of the experiment should enable CET to deliver higher quality products to the market more quickly, but for the application experiment itself there is the cost of adoption of new technology. The chosen application is a VSSP for Intelligent Network (IN) services as specified in ETSI CS1 standard. The VSSP is developed for the HP 9000/827 platform to be coupled with equipment in regular use in the national telecommunications network. The product itself will improve the telecommunications infrastructure in Portugal and the developed software in SDL has potential for sales to other organisations in other territories.

An overview of the VSSP architecture is shown in figure 1. The VSSP is part of a service control point (SCP) implemented on the HP platform. The incoming calls to the general public network that invoke services handled by the SCP are routed to “bi-directional” circuits associated with the SCP and signalling information is sent to the SCP using SS7 ISUP. The circuits are looped back in to the public switch and the signalling for the “incoming” end of the circuits is initiated by the SCP.

The VSSP part of the SCP communicates with the SCF and SRF functions of the SCP that in turn control the IP that is also connected to the public switch. The VSSP handles the recognition of “trigger points” in the call progress of the signalling (see ITU-T Q.1200 series Recommendations) and communicates these “points of initiation” (POI) with the SCF and waits for a “point of return” (POR) to be invoked by the SCF. The communication with the SCF is by the TCAP protocol through MTP locally on the SCP.

Use Word 6.0c or later to

view Macintosh picture.

Figure 1

Project plan for the experiment

Although the ESSI contract has a start date of June 1994 and a termination date of November 1995, the project plan is for most of the work under the project to be done in the period October 1994 to June 1995.

The project has three implementation phases: • an initial implementation of the VSSP using SDL as a design and implementation language

(VSSP V1.0);• a reuse of parts of the signalling software from the VSSP in an enhanced IP that supports the

SS7 signalling protocol (IP);• a re-engineering of VSSP V1.0 using SDL-92 to provide additional functionality (VSSP V2.0).

Associated with the plan of work are three reports:• Initial Report: This report giving an overview of the project and the project plan.• Interim Report: A report on assessment methods, the initial assessment and the experience

from VSSP V1.0.• Final Report: A report on the completed project.Figure 2 gives an overview of the schedule for tasks.

Use Word 6.0c or later to

view Macintosh picture.

Figure 2: Plan of Work

Software Engineering at CET

The prime contractor in the project is the research and development sector of Portugal Telecom that carries out both research and development of products and applications for the Portuguese network at the Aveiro site of the experiment. This site has approximately 200 engineers of whom about 60 (electrical, electronics, computer science and telecommunications) are involved in software development. Approximately 10 of these engineers are involved in the application experiment directly or indirectly.

The subcontractors provide the technology transfer consultancy.

Most of the software previously developed in CET follows a structural design approach and some computer tools are used mainly at the design phase.

Until three years ago, CET had used the VAX/VMS editor, adapted to perform some SDL-like diagrams. In 1991 CET began to use a tool that implements the SDL-88 graphical support for the specification and design phase only (based on personal computers). This led to recognition of the

need for a formal language that enables the analysis, simulation, test and code generation and to handle the problems that occur in every phase of the software development for large and complex systems.

At the specification phase the (often informal) use of languages like SDL either from international or European standards or internal descriptions based on these, gives a good basis for the subsequent engineering of systems. However, CET recognises some weaknesses in the remaining phases of the software development life cycle. The anticipated improvements in the application experiment are for specific activities (code generation and optimisation, simulation, testing, version control and maintenance) and higher overall quality, performance and reliability.

Anticipated benefits

The new approach provides the basis for building a component library for telecommunications applications. It should be possible to prepare a plan including targets for the percentage of components for new products which are re-used components from existing products.

It is anticipated that there can be a market for SDL-92 components produced at CET and licensed to other telecommunications organisations. It is also possible that CET may find it cost effective to licence components from other vendors. The investigation of the potential for this market is part of the experiment.

The experiment generates practical information on the introduction of SDL-92 and associated methods into an industrial environment. Since SDL-92 is new, this information does not exist for industrial studies. Subsequent users of SDL-92 will find the availability of the case study material invaluable in their assessment of the methods and tools. The potential for the use of SDL-92 is any type of product for which a distributed, message passing system is appropriate and therefore is not limited to the traditional telecommunications sector.

The quality, time scale and cost benefits of applying the SDL-92 approach are expected to be derived from:• the good support of SDL as an international standardised technique with supporting tools,

methodology, courses and published materials.• the formal basis of SDL which facilitates analysis and the generation of tests.• the fact that SDL can be applied as a broad spectrum language which can be used from

requirements capture to implementation with the support of the SDT tool.• the specifications and implementation of re-usable objects.The results of the experiment as input to ETSI both for improved IN standards and the ETSI use of SDL-92.Improvements suited to the creation of services in an object oriented way. This has application in general in Open Distributed Processing Systems.Validation of the methodological research work on the object oriented use of SDL.Case study results on the use of SDL-92 where none were available before.

Measurements

An estimate is made in the first phase of the project for the time and effort required to develop the application using the existing techniques in use at CET. The expected quality of the product using existing techniques is predicted from historical record for the number of faults found in previously delivered software. Both these estimates are given a confidence figure based on the amount of historical data available and the similarity of previous product to the planned product. Criteria for success of the experiment are defined during the initial phase based on these predicted figures.

Size of the delivered product and associated documentation is recorded.

The number of faults found during the experiment are recorded together with a classification of the source of the fault (requirements, specifications, design, test design error, implementation error, external problem, miscellaneous) and the resources required to correct the problem. The product is put into service for at least one month and the number of residual faults found is compared with the predicted fault level from the above estimates.

The time and effort spent by CET on the experiment is categorised into:• learning about tools and techniques.• designing and recording of engineering process.• preparation of reports and other dissemination material and activities.• engineering of the IN services subcategorised into (at least): requirements, specification, design,

test design, implementation, test execution, product acceptance, product delivery, post delivery support. The total of this time and effort is compared with the time and effort predicted using existing techniques.

• rework of the designed objects for use in a re-use library.• other.

The number of problems found with SDL-92, methods and tools is recorded and categorised.

Contact point for further informationEngineer José Neto,PORTUGAL TELECOM,SA - DCID/CETRua Engº José Ferreira Pinto BastoAveiro, 3800 , PortugalTelephone: + 351-34-381831Fax: + 351-34-24960 email: neto@cet.pt

_________________________________

Newsletter and other sourcesRick Reed, Newsletter editor.

The SDL Newsletter is currently free on request and published approximately twice per year. To become a “subscriber” it is only necessary to contact me to put you on the list. The editorial costs are covered by TSE Ltd. Printing and distribution costs are covered by volunteer sponsors. There are currently about 250 names on the list. So that a sponsor does not have to mail several copies to one location, the copying and further distribution of the Newsletter is specifically permitted (see copyright on page 2). As the editor I need to find a sponsor for each issue. The Newletter can only remain free if I can continue to find sponsors. Please contact me if you think your organisation can help.

My editorial policy is currently to publish anything that I receive, except explicit advertising (other than for SDL related open events such as the Forum). I do exercise the right to add notes and make editorial corrections. Contributions and comment on the content of the Newsletter are most welcome.

The Newsletter is not, of course, the only source of information on SDL. There is an electronic mailing list that I also maintain that contains general information on SDL, such as summaries of ITU-T Q.6/10 meetings. To be put on this list make a request to me at rick.reed@eurokom.ie. To

send a contribution to the electonic mailing list, also send it to me. I moderate the mailings.

Finally there is now a World Wide Web SDL home page at http://www.tdr.dk/public/SDL/SDL.html.

Seventh SDL ForumCall for participation

The seventh SDL Forum will take place in Oslo, Norway, September 25-29, 1995. Organised by ITF, NR and SINTEF in cooperation with the SISU project. The Forum is sponsored by ABB, Alcatel Telecom Norway, NFT Ericsson Communications, Telenor, Telox, Verilog, Telelogic and Siemens.

Session Topics

Object orientation, Design issues, Testing, Use in Telecoms, CASE Experience, Validation and Verification, Industrial Use, MSC, Tools, Methods with other languages. The panel session will discuss "Long Term SDL - or is there a life after '92". Ove Færgemand will moderate, with major tool vendors, major users of SDL, and ITU representatives in the panel.

Tutorial

The tutorial day is Monday 25 September. The tutorial will give newcomers to SDL and MSC a brief introduction to languages, state-of-the-art methodology and tools. More experienced SDL and MSC users may want to attend the tutorial to become updated on the latest developments.

• Quick repetition of SDL basics (Rolv Bræk)• SDL-92 (Amardeo Sarma)• Z.105 (Louis Verhaard)• MSC (Ekkart Rudolph)• MSC Formal Semantics (Annexes B and C) (Sjouke Mauw)• Testing SDL systems (Dieter Hogrefe)• Methodology for Real Time Systems (Rick Reed)• Tools (Kong Eng Cheng)

Workshops

Workshops will be held Wednesday evening 27 September at the Grand Hotel from 18.00 - 20.00.

• MSC - quo vadis? (Øystein Haugen),• Methodology (Rolv Bræk)• SDL and other notations (Anders Olsen).

Exhibition

An exhibition of commercial and non-commercial tools will be held during the Forum. Participants may visit the exhibition from 12.00 on Tuesday through 13.00 on Friday.

Venue and fees

The Forum will be held at Folkets Hus on Youngstorget square at Youngsgate 11 in central Oslo. Fee for regular delegates at the Forum is NOK 3.800 if registered before 1 August 1995. After 1 August the fee is NOK 4.500. The tutorial fee is NOK 1.200. The student fee for the Forum is NOK 2.200. Fees include the conference proceedings, exhibition, workshops, banquet, and lunch and coffee breaks each day except Friday. Extra banquet tickets cost NOK 450. For delegates registering after 1 August accommodation cannot be guaranteed. Likewise, proceedings might not be available at the conference.

Accommodation

Folkets Hus is within walking distance of the two hotels reserved for the delegates. Hotel Stefan costs NOK 645 per night in a single room and NOK 765 per night in a double room. Grand Hotel is NOK 975 per night in a single room and NOK 1235 per night in a double room. Both hotels include breakfast in the price. Accommodation can be booked via the Secretariat but will be paid for by the delegates directly to the hotel.

Contact addresses for further information

Further information may be found via the World Wide Web: http://www.nr.no/presentations/SDL

Questions and correspondence should be addressed to the Secretariat via:

Email: SDL95@si.sintef.no Fax: +47 22 06 73 50Telephone: + 47 22 06 74 15

Postal address: SDL Forum ´95 c/o Kim Davis SINTEFP.O. Box 124 Blindern0314 Oslo, Norway.

Registration form

Important! Registration will not be confirmed until proof of payment is received. Before date applies only if payment is received before 1 August . In the event of cancellation of booking, fees cannot be reimbursed. Payment should be received by the Secretariat no later than 15 September 1995.

Delegate informationDelegate Name: (to be used on badge): ...............................................................................................................

(Last/family) (First)

Is delegate author/committee/chair/exhibitor/other (circle one)

Organisation:..............................................................................................................................................

Address:.....................................................................................................................................................

Telephone:..........................Telefax.........................email..............................................................................

Special requirements: diet............................ wheelchair access other..................................................

AccommodationThe Secretariat cannot guarantee any hotel reservations made after 1 August 1995.

Sun.24-25

Mon.25-26

Tues.26-27

Wed.27-28

Thurs.28-29

Fri.29-30

Sat. 30-31

Grand Hotel Single room: NOK 975 per nightDouble room: NOK1235 per night

Hotell Stefan Single room: NOK 645 per nightDouble room: NOK 765 per night

Single room: yes no Double room: yes no if yes, sharing with.....................................................

Accommodation can be booked via the Secretariat but will be paid for by the participants directly to the hotel.

Forum/Workshop Registration

RegularBefore Aug. 1

Regular After Aug. 1

Student Extra banquet tickets

Total

Tutorial (25. September) NOK 1200 NOK 1200Forum (26-29 September) NOK 3800 NOK 4500 NOK 2200 NOK 450Number

PaymentPayment for the various activities may be made in several ways however all bank cost must be paid for by the delegate.All payments must be marked with SDL Forum, name of delegate and project no.: 402269.02

credit card (circle one): VISA, Europay, MasterCard, Eurocard, American Express, Diners Club

Total amount:................... Card No................... Signature:......................................................

bank transfer (bank/postgiro) in NOK to account no. 8601 06 22451, using swift, mentioning swift code FOK BN 022

Seventh SDL Forum: provisional programme

Tuesday 26 Sept. Wednesday 27 Sept. Thursday 28 Sept. Friday 29 Sept.09:00 Conference Welcome

Keynote Speaker

Object OrientationBirger Møller-Pedersen, NR

A development method for SDL-92 specifications based on OMTDorota Witaszek , Eckhardt Holz, Maciej Wasowski, Stefanie Lau and Joachim Fischer ,Humboldt, University of Berlin

Design IssuesLouis Verhaard, Telia

Description for Hierarchical Processing in SDL DesignYoshiaki Shigeta , Watru Tanaka and Haruo Hasegawa, OKI Electronic Industry Co., Ltd.; Japan

TestingAnders Olsen, TDR

Partial Order Simulation of SDL SpecificationsJens Grabowski, Dieter Hogrefe and daniel Toggweiler, University of Berne, Switzerland

09:30 Translation of OMT to SDL-92Fuyin Guo and Thomas W. MacKenzie BNR Canada

Modifying and using SDL to specify ODP based telecommunications servicesBo Michel Nørbæk and Mikael Jørgensen, Tele Danmark Research, Denmark

Test case specification based on MSCs and ASN.1Jens Grabowski, Dieter Hogrefe, Univarsität Bern, Daniel Toggweiler, Andreas Spichiger, Siemenns-Albis AG, Switzerland

10:00 Coffee break Coffee break Coffee break Statistical usage testing using SDL

10.30 Use in TelecomsAmardeo Sarma, FTZ

Industrial experience using SDL in IskraTELMilenko Alcin, Matjaz Dolenc, and Ana Robnik, IskraTEL, Slovenia

CASE ExperienceRick Reed, TSE

A methodology for modeling large and complex systems, used on an advanced transport telematics architectureTorbjørn Frotveit, NTH, Norway

Validation & Verification

Dieter Hogrefe, Uni. BernGOAL: Observing SDL behaviors with GEODEBernard Algayres, Y. Lejeune and F. Hugonnet, Verilog S.A., France

Per Runeson, Johan Brantestam Q-labs, Anders Wesslén, Stefan Sjøstedt Lund University, Sweden

Coffee break

11:00 A distributed SDL-based intelligent networks laboratoryPeter Csurgay, Finn Arve Aagesen NTH, Norway

High quality design using SDL TechnologyZenya Koono, Saitama UniversityJapan

Performance Evaluation of SDL Systems Adjunct by Queuing ModelsM. Diefenbruch, J. Hintelmann, Bruno Müller-Clostermann, University of Essen E. Heck, University of DortmundGermany

Industrial UseRolv Bræk, SINTEF

SDL-based software development in Siemens A/S - experience of introducing rigorous use of SDL and MSC, Geir Amsjø andAstrid Nyeng, Siemens AS, Norway

11:30 SDL-92 support for re-use in protocol system specifications - some early experienceAmanda Sinton and Michael Crowtherr, BT Laboratories, Great Britain

Software Process Improvement with SDLKristofer Kimber an , High Definition Sytems AB, Geir Opsahl, Ericsson AS, Sweden

MSCs to express service requirements as properties on an SDL model: application to service interaction detectionCombes, Pierre, S. Pickin. and Beatrice Renard CNET, F. Olsen, Télecom Paris, France

The application of SDL to control systems for industrial machinesTim Morley, Loughborough University of Technology, England

12:00 Lunch Lunch Lunch Use of SDL to specify Airbus future

13:00 MSC IEkkart Rudolph, Siemens

Using MSC-92 effectivelyØystein Haugen, Norwegian Computing Center, Norway

ToolsJoachim Fischer, Uni. Humboldt

Design issues of RASTA SDL-92 Translator Nikolai Mansurov, Russian Academy of Sciences, Russia

Methods with other languages

Lennart Månsson, TeliaIntegrating SDL and a configuration language to model variability and automate system building, Jacqueline Floch, SINTEF DELAB, Norway

air navigation systemFrancois Goudenove, Aerospatiale Laurent Doldi, Verilog S.A., France

Closing remarks

13:30 Generating tools for message sequence chartsSjouke Mauw and Emma van der Meulen Eindhoven University of Technology, The Netherlands

A generic, high capacity computing platform for SDL systems executionGeir Millstein, Telenor Research,Arne Sommerfelt and Eivind Strøm , SINTEF, Norway

Development of SDL Specifications in FocusKetil Stølen, Technische UniversitätMünchen, Germany

14:00 Syntax Requirements of Message Sequence ChartsMichel A. Reniers, Eindhoven University of Technology, The Netherlands

Tool-aided understanding of SDLLars Tufvesson,Telelogic AB, Sweden

Integrated Use of SDL and GDMO Antonella Bartocci and A. Ferrero, CSELT, Centro Studi e Laboratori Telecommunicazioni, Italy

14:30 Coffee break Coffee break Coffee break15:00 MSC II

Øystein Haugen, NRMessage sequence chart: composition techniques vs. OO-techniquesRudolph, Ekkart, Peter Graubman, Siemens AG, Germany, Jens Grabowski University of Berne, Switzerland

Exhibition Panel session

"Long Term SDL - or is there a life after ´92"

15:30 An ASN.1 exchange format for MSC graphicsMária Töró , Ta Manh Dung, Susan Boja-Harangozó, KFKI Research Institute for Measurement and Computing Science, Hungary

Reception Workshops Banquet

Even-ing

The reception will be held at the Technical Museum. Sponsored by Telenor

MSCMethodologySDL and other notations

Gamle Logen