Modeling the Architecture of Distributed Real-Time Systems - - PowerPoint PPT Presentation

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 1 Ericsson Eurolab Deutschland GmbH, Germany

Modeling the Architecture

• f Distributed Real-Time Systems

OMER-2, Herrsching am Ammersee, Germany, May 10-12, 2001

André Marburger Aachen University of Technology 52074 Aachen, Germany Dominikus Herzberg Ericsson Eurolab Deutschland GmbH 52134 Herzogenrath, Germany

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 2 Ericsson Eurolab Deutschland GmbH, Germany

System Architecture Modeling of Telecom Systems

ROOM/UML-RT OSI Reference Model

◆ SAP ◆ CEP

ISDN/GSM Reference Model

◆ Typed SAP

Conclusions (1) Layers are a key concept for abstracting distributed peer communication relations CEP (2) SAPs subsume layers (3) SAPs are more powerful than strict layering is (4) SAPs ≠ Ports (5) Planes are a key concept for separating concerns (6) Typed SAPs subsume planes (7) Typed SAPs are more expressive than planes are (8) Typed SAPs “>” SAPs

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 3 Ericsson Eurolab Deutschland GmbH, Germany

A Quick Primer on ROOM / UML-RT

Capsule Port Connector Protocol

Note: Protocol ≠ Protocol Note: Protocol ≠ Protocol

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 4 Ericsson Eurolab Deutschland GmbH, Germany

TISO2920-94/d10

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 5 Ericsson Eurolab Deutschland GmbH, Germany

Service Access Modeling according to OSI RM

Service Provider Service User [Identifier] SAP [SAPI, QoS] CEP [CEPI]

uses services provides services

Connection Service Provider

exchange

PDU SDU

exchange

SDU

exchange

CEP Connection Endpoint CEPI CEP Identifier SAP Service Access Point SAPI SAP Identifier Service User [Identifier]

exchange

PDU SDU Service Data Unit PDU Protocol Data Unit QoS Quality of Service

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 6 Ericsson Eurolab Deutschland GmbH, Germany

Interfaces of a Communication Layer Entity

n reliable, indestructible n QoS is not an issue n partner’s location is known n direct communication

Port

n unreliable, breakable n virtual connection n partner’s address is known

(not location)

CEP SAP SAP-1

intra-node peer-to-peer inter-node peer-to-peer inter-layer service provider inter-layer service user

print() send(from,to,print()) CEP Connection Endpoint SAP Service Access Point

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 7 Ericsson Eurolab Deutschland GmbH, Germany

service provisioning infrastructure Layer (N) Layer (N+1) Layer (N-1) = SAP = SAP-1 = CEP

OSI RM revisited [1/2]

SDUN-1(PDUN) QoSN-1, ToSN-1 QoSN, ToSN SDUN QoS’N-1 ToS’N-1 PDUN(SDUN)

SAPI CEPI

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 8 Ericsson Eurolab Deutschland GmbH, Germany

Layer (N) Layer (N+1) Layer (N-1) = SAP = SAP-1 = CEP

OSI RM revisited [2/2]

SDUN-1(PDUN) SDUN PDUN(SDUN)

SAPI CEPI

PDUN-1(PDUN) SDUN-1(PDUN) SDUN

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 9 Ericsson Eurolab Deutschland GmbH, Germany

Pattern: Integrating CEPs as Concrete Elements

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 10 Ericsson Eurolab Deutschland GmbH, Germany

Service Access Modeling according to ROOM (Selic et al.)

n SAP/SPP concept is confusing n Insufficient semantic preciseness ◆ How do ports differ from SAPs?

(layer bridges)

n Lack of proper notation n ROOM is strict on layering n SAPI, QoS, ToS? Layer (N) SAP (protocol P) SPP (protocol P*) Layer (N-1) upper layers lower layers peers Capsule/ Actor

Layer3 Layer2 Layer1 Co-

• rdinator

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 11 Ericsson Eurolab Deutschland GmbH, Germany

The ISDN/GSM Reference Model: Layers and Planes

n User Plane

transparent transfer of information among user applications; additionally, any information which controls the exchange of data within a connection [I.320]

n Control Plane

transfer of information for the control

• f user plane connections, e.g.

establishment of a connection, controlling an already established connection, providing supplementary services, resource allocation/deallocation [I.320]

n Management Plane Typical informal description of the architecture

Planes decompose services and separate concerns

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 12 Ericsson Eurolab Deutschland GmbH, Germany

Service Access Modeling according to ISDN Protocol RM

T1302850-94/d05

(N+1) Layer N-Service user ISDN Network Service according to X.213 N-Service provider N(c)-Service user N(c)-Service provider Synchronization and coordination function C-plane sub-N- U-plane sub-N- N(u)-Service user N(u)-Service provider C-plane sub-N-layer U-plane sub-N-layer N-Primitives N(c)-Primitives N(u)-Primitives

FIGURE 5/.320 Relationship of the Network Service to the service provided by C-plane sub-N-layer and U-plane sub-N-layer

n SCF (Synchronization and

Coordination Function) performs the C- and U-plane synchronization

n SCF does not handle PDUs n SCF is a component of the plane

management function

n The general principle of

accessing services according to OSI remains valid

n The general concept of SAPs

according to OSI remains valid

n but planes have to be

represented by different kinds of SAPs

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 13 Ericsson Eurolab Deutschland GmbH, Germany

Architecture Model based on ISDN

C C C C C U U U U U M M M M M M M M M

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 14 Ericsson Eurolab Deutschland GmbH, Germany

Architecture Model based on the MCS Framework

C C C C U U U U M M M M M C U M

MCS Modular Communication Systems (S. Boecking)

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 15 Ericsson Eurolab Deutschland GmbH, Germany

Architecture Model: CEPs, SAPs, and Ports

C C U U M M PC PU M C U M

Modeling the Architecture of Distributed RT Systems

OMER-2, Herrsching, Germany, May 10-12, 2001

Dominikus Herzberg, Slide 16 Ericsson Eurolab Deutschland GmbH, Germany

Summary & Conclusions

Formalization

The SAP concept is a standard concept in telecommunications

◆ CEP & SAP Layers (abstraction) ◆ Typed SAP Planes (separation of concerns)

Introduction

ROOM is an excellent candidate for modeling architectures

◆ SAP ≈ Port, but SAP ≠ Port ◆ minor language extensions required (semantics, notation)

Use

Precise and expressive architecture descriptions

◆ replaces informal diagrams ◆ basis for architectural patterns