four fold increase in productivity and quality
Download
Skip this Video
Download Presentation
Four-Fold Increase in Productivity and Quality

Loading in 2 Seconds...

play fullscreen
1 / 33

Four-Fold Increase in Productivity and Quality - PowerPoint PPT Presentation


  • 123 Views
  • Uploaded on

Four-Fold Increase in Productivity and Quality. —Industrial-Strength Functional Programming in Telecom-Class Products (http://www.erlang.se/publications/Ulf_Wiger.pdf) FEmSys 2001 Deployment on distributed architectures.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Four-Fold Increase in Productivity and Quality' - deva


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
four fold increase in productivity and quality

Four-Fold Increase in Productivity and Quality

—Industrial-Strength Functional Programmingin Telecom-Class Products(http://www.erlang.se/publications/Ulf_Wiger.pdf)

FEmSys 2001Deployment on distributed architectures

Ulf Wiger <[email protected]>Senior System ArchitectStrategic Product & System ManagementEricsson Telecom ABData Backbone & Optical Networks Division

the setting
The setting
  • 1995 PC Week Study of software projects:
    • 16% successful
    • 53% operational (but less than successful)
    • 31% cancelled
  • Butler Group 1997 on large software projects
    • 5 out of 6 large projects fail
    • In >$300M companies, 9 out of 10 large projects fail
  • How to approach this?
    • Use high-level modeling tools & generate code?
    • Raise the level of programming language?
    • Fight all causes for project failure!
the design of the axd 301 switch
The design of the AXD 301 switch
  • Situation 1996
    • Late entry into the ATM market
    • Needed to leapfrog the competition
    • Project members used to "traditional" large projects,wanted to try something new
    • No interesting 3rd party middleware platform
  • Target: a backbone ATM switch with "Telecom Profile"
executive summary
Executive summary
  • AXD 301: A Telephony-Class, scalable (10-160 GBps) ATM switchdesigned from scratch in less than 3 years
  • AXD 301 Success factors:
    • Highly pragmatic, holistic approach
    • Competent organisation
    • Efficient process
    • Excellent technology (e.g. Erlang/OTP)
  • More than just technology...
    • Consider all factors together from the start
    • Erlang was a perfect match for our approach
axd 301 in the marketplace
AXD 301 in the marketplace

ENGINE:

Migrating today\'s vertical networks

into a single multi-service backbone

  • Central component in Ericsson\'s ENGINE offering
  • Several major operators
    • British Telecom
    • Vodaphone
    • Worldcom
    • Telia
    • Diveo
    • ...
briefly about the term carrier class
Briefly about the term Carrier-Class
  • To us, "Carrier-Class", "Telephony-Class" and"Telecom Profile" are synonymous
  • The quality we\'ve come to expectfrom public telephony networks
  • The trend towards multimedia servicesrequires Carrier-Class in more systems
  • More than just duplication of hardware:
    • Fault-tolerant software
    • In-service hardware expansion
    • In-service software upgrade
    • Load tolerance
    • Flexibility (frequent changes + long service life)
  • Target: 99,999% ("five nines") availability, including planned outages

There\'s no such thing

as "almost Carrier-Class"!

telecom class system architecture

simple wire-speed logic

complex soft-real-time logic

ATB

ATB

ATB

ATB

Telecom-Class System Architecture

Control Processors

LineTermination

ATM Termination

CP

IO

ATM

Mandatory Mated Processor Pair

Switch Core

CP

IO

CE

FR

IO

CP

Optional Processors

Server Device

L3F

CP

IO

Clock &

Synchronization

Device Processor

on Each Board

fault tolerance distributed recovery
Fault tolerance: distributed recovery
  • Failover: one processor dies; its mate restarts the lost applications
  • Takeover: the failed processor returns; the O&M/Standbyapplications migrate

"Luke-warm" standby

sufficient to

maintain quality of service

O&M or Standby application

Call-handling application

load tolerance
Load tolerance

Call Handling Throughput

for one control processor

AXD 301 release 3.2Traffic Case: ATM SVC UNI to UNI

Call Troughput

in % of maximum sustainable

call handling (set-up + release)

capacity

Rejected

Calls

200 call set-up/s or

115 call/s sustained

100%

Load from handling

of rejected calls

95%

40%

Offered Load

in % of maximum

call troughput

1000%

100%

150%

history of erlang
History of Erlang

No language well suited

for telecom systems

development

1984:

Ericsson

Computer

Science Lab

formed

1998:

Open Source

Erlang

1991:

First fast

implementation

1987:

Early Erlang

Prototype projects

1984-86:

Experiments

programming

POTS with

several languages

1996:

Open Telecom Platform

(research on verification...)

1995:

Several

new projects

1993:

Distributed

Erlang

erlang highlights
Erlang Highlights

Functional programming language

High abstraction level

Pattern matching

Concise readable programs

  • Declarative
  • Concurrency
  • Soft real-time
  • Robustness
  • Distribution
  • Hot code loading
  • External interfaces
  • Portability
erlang highlights1
Erlang Highlights

Either transparent or

explicit concurrency

Light-weight processes

Highly scalable

  • Declarative
  • Concurrency
  • Soft real-time
  • Robustness
  • Distribution
  • Hot code loading
  • External interfaces
  • Portability
erlang highlights2
Erlang Highlights

Response times in the

order of milliseconds

Per-process garbage collection

  • Declarative
  • Concurrency
  • Soft real-time
  • Robustness
  • Distribution
  • Hot code loading
  • External interfaces
  • Portability
erlang highlights3
Erlang Highlights

Simple and consistent

error recovery

Supervision hierarchies

"Program for the correct case"

  • Declarative
  • Concurrency
  • Soft real-time
  • Robustness
  • Distribution
  • Hot code loading
  • External interfaces
  • Portability
erlang highlights4
Erlang Highlights

Explicit or transparent distribution

Network-aware runtime system

  • Declarative
  • Concurrency
  • Soft real-time
  • Robustness
  • Distribution
  • Hot code loading
  • External interfaces
  • Portability
erlang highlights5
Erlang Highlights

Easily change code in a

running system

Enables non-stop operation

Simplifies testing

  • Declarative
  • Concurrency
  • Soft real-time
  • Robustness
  • Distribution
  • Hot code loading
  • External interfaces
  • Portability
erlang highlights6
Erlang Highlights

"Ports" to the outside world

behave as Erlang processes

  • Declarative
  • Concurrency
  • Soft real-time
  • Robustness
  • Distribution
  • Hot code loading
  • External interfaces
  • Portability
erlang highlights7
Erlang Highlights

Erlang runs on any UNIX,

Windows, VxWorks, ...

Supports heterogeneous

networks

  • Declarative
  • Concurrency
  • Soft real-time
  • Robustness
  • Distribution
  • Hot code loading
  • External interfaces
  • Portability
erlang examples 1

Definition

Implementation

-module(ex1).

-export([factorial/1]).

factorial(0) ->

1;

factorial(N) when N >= 1 ->

N * factorial(N-1).

1

n*(n-1)!

n = 0

n 1

n! =

Eshell V5.0.1 (abort with ^G)

1> c(ex1).

{ok,ex1}

2> ex1:factorial(6).

720

Erlang Examples 1

Basics - Factorial function

erlang examples 2

Eshell V5.0.1 (abort with ^G)

1> c(ex2).

{ok,ex2}

2> ex2:qsort([7,5,3,8,1]).

[1,3,5,7,8]

Erlang Examples 2

A few very high-level constructs - QuickSort

-module(ex2).

-export([qsort/1]).

qsort([Head|Tail]) ->

First = qsort([X || X <- Tail, X =< Head]),

Last = qsort([Y || Y <- Tail, Y > Head]),

First ++ [Head|Last];

qsort([]) ->

[].

"all objects Y

taken from the list Tail,

where Y > Head"

erlang examples 3

Eshell V5.0.1 (abort with ^G)

1> c(ex3).

{ok,ex3}

2> ex3:send_after(1000, self(), hello).

<0.42.0>

3> flush().

Shell got hello

ok

Erlang Examples 3

Concurrency - Simple timer

-module(ex3).

-export([send_after/3]).

send_after(Time, Receiver, Message) ->

spawn_link(fun() ->

receive

after Time ->

Receiver ! Message

end

end).

Anonymous function

passed as input

argument

erlang examples 4
Erlang Examples 4

Concurrency - Finite State Machine

Selective receive

ringing_a(A, B) ->

receive

{A, on_hook} ->

back_to_idle(A, B);

{B, answered} ->

A ! {stop_tone, ring},

switch ! {connect, A, B},

conversation_a(A, B)

after 30000 ->

back_to_idle(A, B)

end.

back_to_idle(A, B) ->

A ! {stop_tone, ring},

B ! terminate,

idle(A).

Asynchronous send

Optional timeout

erlang examples 5

One for one supervision:

If any child dies

it is restarted

1

One for all supervision:

If any child dies, all children

are terminated and all are

restarted

1

a

a

P1

Pn

1

P2

P1

P2

Pn

...

...

a

1

Erlang Examples 5

Supervision tree:

Process links

+ special supervisor processes

The infrastructure

handles recovery

- program for the correct case

"let it crash!"

erlang otp
Erlang/OTP
  • Open Telecom Platform
  • Middleware for Erlang development
  • Designed for fault tolerance and portability
  • Behaviors: A formalization of design patterns
  • Components
    • Error handling, reporting and logging
    • Mnesia, distributed real-time database management system
    • CORBA
    • IDL Compiler, Java & C Interface Support
    • HTTP Server
    • SNMP Agent
    • ...
otp behaviors
OTP Behaviors
  • "A formalization of design patterns"
    • A behavior is a framework + generic code to solve a common problem
    • Each behavior has built-in support fordebugging and software upgrade
    • Makes it easier to reason about the behavior of a program
  • Examples of OTP behaviors
    • application defines how an application is implemented
    • supervisor used to write fault-tolerant supervision trees
    • gen_server for writing client-server applications
    • gen_event for writing event handlers
    • gen_fsm for finite state machine programming
project highlights
Project Highlights
  • Early phases under one roof
  • Powerful architecture team
  • Clear chain of command
  • Rapid decisions (within days)
  • Organize according to product structure
project structure
Project Structure
  • Different forums for technical and project Issues
    • But partly the same people
  • System Management = “glue”
    • “Owners” of the architecture
    • Keeps a system perspective
    • Writes design rules
    • Holds seminars
    • Profiling Task Force
    • Acts as Designer Help Desk
  • Human Interaction Essential
  • Proximity = “Under One Roof”

Product Council

Techn Mtg AXD

Proj Mgmt Mtg

System

Management

Profiling

Task Force

Techn Mtg Subsyst

Subsyst Proj Mgr

Block Responsible

process highlights
Process highlights
  • "Lightweight" development process
  • Careful functional decomposition
  • Formal change management of interfaces
  • Incremental design
  • Prototyping of critical parts
  • Only essential documents
identify subsystems

Project

Process

Tools

ATS

LSS

FRS

AVS

AHS

NGS

Narrowband

Services

for

AXE

Dynamic

Trunking

Label

Switch

Routing

Frame

Relay

ATM Signalling

and call control

Basic Connection

Control Support

ATM resource

Management

PVC Control

CPS

OMS

SWS

Switch Control

and Maintenance

OAM

support

Operating

System

Identify Subsystems

Add-on Services

Not released as part of AXD 301

Base Services

Add-on Services

identify block structure

Project

Process

Tools

Real-time critical

Identify Block Structure

Non-real-time critical

ATS

LSS

AVS

ATSD

AVSD

LSSD

PROXY

UNI

ILMI

LDP

TRH

IISP

AINI

PNNI

LIM

OSPF

RIP

DTC

VPNA

PNNIR

BICI

SPVC

GSMP

IPS

FIM

CHG

ANA

SYS

RCM

EVA

WMS

CNH

PRM

SWSD

FTM

DPC

NSY

PRSW

EQM

CPM

MCNC

PERF

STO

SAAL

REH

ABR

DNA

CECP

DPS

CPC

OTP

LMS

OMSD

CAC

SCBDP

CLKDP

ATBDP

ET622DP

ET155DP

SWM

CSS

CPO

ET45DP

ET34DP

ABRDP

ET2CEDP

DPG

CPS

OMS

SWS

CPSD

DPOS

documentation
Documentation
  • Documentation must evolve with the incremental design
  • Focus on a few vital document types, e.g.:
    • Requirement Specification
    • Implementation Proposals
    • Function Specifications
    • Block Descriptions
    • Interface Descriptions
  • Highly readable programs reduce the need for documentation(...but do not eliminate it)
programming languages control system
Programming languages (control system)
  • Erlang: ca 1 million lines of code
    • Nearly all the complex control logic
    • Operation & Maintenance
    • Web server and runtime HTML/JavaScript generation
  • C/C++: ca 500k lines of code
    • Third party software
    • Low-level protocol drivers
    • Device drivers
  • Java: ca 13k lines of code
    • Operator GUI applets
experiences from axd 301 sw design
Experiences from AXD 301 SW Design
  • Using Erlang in Complex Systems
    • Fits very well with the incremental design method
    • High programmer satisfaction
    • Outstanding support for robustness and concurrency
    • Very few side-effects  easier to add/change single components
    • Small directed teams can achieve impressive results
  • Productivity estimates
    • Similar line/hour programmer productivity
    • 4-10 fewer lines of source code (compared to C/C++, Java, PLEX)
      • 4-10x higher programmer productivity
    • Similar number of faults per 1000 lines of source code
      • 4-10x higher quality
ad