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

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

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

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)

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