330 likes | 476 Views
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.
E N D
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 <ulf.wiger@ericsson.com>Senior System ArchitectStrategic Product & System ManagementEricsson Telecom ABData Backbone & Optical Networks Division
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 • 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 • 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 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 • 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"!
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 • 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 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 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 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 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 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 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 Highlights Explicit or transparent distribution Network-aware runtime system • Declarative • Concurrency • Soft real-time • Robustness • Distribution • Hot code loading • External interfaces • Portability
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 Highlights "Ports" to the outside world behave as Erlang processes • Declarative • Concurrency • Soft real-time • Robustness • Distribution • Hot code loading • External interfaces • Portability
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
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
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"
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 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
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 • 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 • "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 • Early phases under one roof • Powerful architecture team • Clear chain of command • Rapid decisions (within days) • Organize according to product 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 • "Lightweight" development process • Careful functional decomposition • Formal change management of interfaces • Incremental design • Prototyping of critical parts • Only essential documents
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
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 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) • 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 • 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