Formal Service-Oriented Development of Fault Tolerant Communicating Systems

Linas Laibinis, Elena Troubitsyna, Johan Lilius, Qaisar Malik (Åbo Akademi)

Sari Leppänen (NOKIA)

Motivation Telecommunication systems –

distributed software-intensive systems providing variety of services

Software development of such systems is inherently complex and error-prone

Communication failures – intrinsic part of the system behaviour. Hence fault tolerance mechanisms should be integrated into the system design

Approach Formalisation of UML2-based service-

oriented methodology Lyra developed in the Nokia Research Center

In Lyra the system behaviour is modularised and organised into hierarhical layers

Distributed network architecture is derived from functional system requirements via a number of model transformations

Lyra Development Phases Lyra consists of 4 phases

Service Specification – services provided by the system to the external users

Service Decomposition – logical architecture of the system-level services

Service Distribution – service components are distributed over the given network

Service Implementation – low-level implementa-tion details are added and platform-specific code is generated

Formalisation of Lyra

The B Method – the development methodology based on stepwise refinement

We formalise Lyra by proposing a set of formal specification and refinement patterns reflecting essential models and transforma-tions of Lyra

Lyra development steps are validated by the corresponding B refinement steps

Example: Positioning System The Third Generation Partnership Project

(3GPP) provides a positioning service for calculating the physical location of user equipment (UE) in a UMTS network

Positioning is based on determining the geographical position of the UE by measuring radio signals

Communication between all network elements is done by using predefined signalling protocols

System Architecture

SAS

RNC

Basestation

Basestation

PCAPcommunication

UE

LMU

LMU

Services and Interfaces In terms of its services and

interfaces, the system consists of several layers representing it at different levels of detail

The top layer describes system’s interaction with an external user: what services the system provides, what signals it sends and receives

Service Specification

<<ServiceSpecification>> Positioning

aPositioning : Positioning

aUser : User

<<usecase>>PositionCalculation

Idle serving

I_From PositioningI_ToPositioning

pc_req

pc_cnf

pc_fail_cnf

I_user

Formal Development We single out a generic concept of a

communicating service component and propose patterns for specifying and refining it

In the refinement process a service component is decomposed into service components of smaller grannularity according to the same pattern

Formal Development (cont.)

ACC = ACM + ACAM The basic idea: the communicating

components are created according to a certain pattern -- Abstract Communicating Component ACC

Component consists of a “kernel”, i.e., the provided functionality --

Abstract Calculating Machine ACAM “communication wrapper”, i.e., the

communication channels via which data are supplied to and consumed from the component – Abstract Communicating Machine ACM

Behaviour of Abstract Communicating Component

input output

calculate

inp_chan out_chan

Layer 2 The second layer describes how the

positioning service is decomposed into several subservices of smaller granularity. Each of subservices is provided by an external service component responsible for its execution

The positioning service consists of four subservices: DB Enquiry, UE Enquiry, LMU Measurement, and Algorithm Invocation

Service Decomposition

<<ServiceDecom position>> Positioning

() () ()

I_From PositioningI_ToPositioning

I_User

I_ToUE

I_From UE

I_From DB

I_ToDBI_DB I_LM U I_ToLM U

I_From LM U

I_AlgorithmI_ToAlgorithm

I_From Algorithm I_UE

Service Decomposition (B Model)

Layer 3 The third layer describes how service

components are distributed over the given network

Service component responsible for the positioning service is distributed between RNC and SAS network elements

ServiceDirector is also decomposed into two parts – RNC_ServiceDirector and SAS_ServiceDirector

Service Distribution

Service Distribution (B model)

RNC

SAS

Service Director

Service DirectorDB UE

LMU ALG

Service Distribution (B Model) Service Distribution phase of Lyra

corresponds to one or several B refinements

Refinement steps introduce separate B components modelling external service components

All new B components are specified according to the same (ACC) pattern

Fault Tolerance External service components can fail –

unreachable, too busy, internal failure etc During refinement steps we incorporate

simple fault tolerance mechanisms into service directors

After analysing an error message and other data received from a service component, a director ”decides” what recovery action is possible

Fault Tolerance (cont.) Some simple recovery

mechanisms: ’reasking’ – sending additional

requests to the same component redirecting the request to an

alternative service component ’holding on’ a service ...

Failure of Positioning Service If any of subservices unrecoverably

fails, the whole positioning service is considered as failed. ServiceDirector then sends the corresponding error message to the user

Conclusions We propose an approach to formal

modelling of communicating distributed systems

We define specification and refinement patterns that can be used to automate the development process

Simple fault tolerance mechanisms are incorporated into the system design

Future work: addressing concurrency, verification of temporal properties of communication protocols etc