Senin, 24 Juni 2013

PENGENALAN CORBA



What is CORBA?
• CORBA adalah sebuah standard untuk interoperabilitas obyek
• Mendukung bahasa yang berbeda
• Mendukung platform yang berbeda
• Komunikasi pada jaringan
• Service tambahan ( misalnya : sekuritas )
• CORBA didefinisikan oleh OMG (Object Management Group)
• OMG berdiri sejak 1989, bertujuan untuk memperkenalkan teori dan
praktek dari teknologi obyek dalam sistem komputer terdistribusi
• CORBA 1 diluncurkan pada1991
• Sekarang sampai pada CORBA 3
• Informasi : http://www.omg.org
• CORBA adalah komponen dari OMA (Object Management Architecture)
• Desain CORBA berdasar atas OMG Object Model
OMG Object Model
• OMG Object Model mendifinisikan semantik umum untuk menspesifikasikan
karakteristik eksternal yang visibel dari object dalam suatu standard dan dengan
cara implementation-independent. Dalam model ini, clients meminta service dari
objects ( yang juga disebut servers ) melalui interface yang telah didefinisikan.
Interface ini dispesifikasikan dalam OMG IDL (Interface Definition Language).
Sebuah client mengakses sebuah object dengan melakukan request ke suatu
object(s). Request merupakan suatu event yang membawa informasi termasuk
sebuah operasi, object reference dari pemberi service dan parameter actual ( jika
ada ). Object reference adalah nama sebuah nama object yang dapat diacu.
What is OMA?
OMA adalah spesifikasi standar ( yang saling berhubungan ) yang mendefiniskan
cakupan yang luas mengenai layanan dalam mengembangan aplikasi terdistribusi.
OMA terdiri atas, empat komponen yang dapat dibagi menjadi dua bagian :
komponen berorientasi (Object Request Brokers and Object Services dan
komponen berorientasi aplikasi (Application Objects and Common Facilities).
• Object Request Broker adalah salah satu bagian dasar dari OMA dan mengatur
semua komunikasi diantara komponen-komponennya. ORB memungkinkan
objects berinteraksi secara heterogen, dalam lingkungan/sistem tersebar,
independen dari platform dimana objects ini berada dan teknis yang digunakan
untuk mengimplementasikannya. Dalam menjalankan tugasnya, OMA berdasar
atas Object Services yang bertanggung jawab secara umum untuk manajemen
object seperti membuat object, acces control, meengontrol object yang
dialokasikan, dsb. Common Facilities danplication Objects adalah komponenkomponen
yang dekat dengan user dan dalam fungsinya, mereka membangkitkan
service pada komponen-komponen sistem.

Common Object Request Broker Architecture (CORBA)
• Standarisasi untuk sebuah ORB (Object Request Broker)
• IIOP (Internet Inter-ORB Protocol) : standarisasi yang digunakan untuk
komunikasi
• Mendefinisikan interface bahasa dan tool-tool
• Object Services ( service umum )
• Service inti yang dibutuhkan untuk mengembangkan arsitektur
terdistribusi
• Naming : membolehkan client untuk menemukan object berdasar namanya
• Trading : membolehkan client untuk menemukan object berdasar
propertinya
• Lainnya: Security, Transactions, event notification, lifecycle management,
dsb.
• Common Facilities ( high-level services )
• Layanan ini berguna untuk aplikasi terdistribusi dalam beberapa kondisi
pada aplikasi bersangkutan. Dua kategori umum Common Facilities
adalah horizontal dan vertical; dimana menentukan aturan kerja sama
komponen bisnis yang dibutuhkan agar bekerja secara efektif. Fasilitas
yang ada dalam Common Facilities adalah : Distributed Document , User
Interface, Information Management, System Management, Task
Management.
• Misalnya, Distributed Document Component Facility (DDCF) -- OpenDoc
• Allowing for the presentation and interchange of objects based on
a document model facilitating the linking of a spreadsheet object
into a report document
• Domain Interface
• Antar muka ini lebih berorientasi langsung pada domain aplikasi. Sebagi
contoh, salah satu OMG RFP yang ada adalah untuk Product Data
Management ( PDM ) yang digunakan untuk industri manufaktur. Selain
OMG tersebut diatas ada beberapa yang akan dikembangkan untuk bidang
telekomunikasi, medis dan keuangan.
• Application Interface
• Antar muka ini dikembangkan khusus untuk aplikasi diinginkan. Karena
antar muka ini bergantung kepada aplikasi yang akan dikembangkan dan
juga karena OMG tidak mengembangkan aplikasi tetapi hanya spesifikasi
aplikasi sehingga interface ini tidak mempunyai standar baku.
Some ORBs
• CORBA Software (http://www.infosys.tuwien.ac.at/Research/Corba/software.html)
– Orbix (IONA)
– VisiBroker (Inprise)
– ObjectBroker (BEA)
– PowerBroker (Expersoft)
– ORB Plus (HP)
– ORBacus (Object-Oriented Concepts, Inc.)
– NEO/JavaIDL (SunSoft)
Why CORBA?
• Need to share information and resources within and across diverse computing
enterprises
– CORBA is a Middleware Standard
– CORBA is a “Software Bus”
– CORBA is a Distributed Object Architecture
CORBA is a Middleware Standard
• Sebelum CORBA, middleware didominasi oleh vendor yang dikeluarkan pembuat
tools
Secara umum, ada lima kategori middleware yang dikelompokkan berdasarkan
standar signifikan atau produk di pasaran, yaitu :
1. Data Access, konektivitas ke basis data
2. Remote Procedural Call ( RPC ), invokasi antar aplikasi secara jauh dan
procedural
3. Transaction Processing Monitor, manajemen transaksi pada sistem tersebar
4. Message Oriented Middleware ( MOM ), komunikasi asynchronous antar
sistem
5. Distributed Object, invokasi object antar aplikasi di sistem tersebar.
CORBA ORB Architecture
Fungsionalitas dasar yang disediakan oleh ORB terdiri dari passing request dari client ke
implementasi object. Untuk membuat request, client dapat berkomunikasi dengan ORB
Core melalui IDL stub atau melalui Dynamic Invocation Interface (DII). Stub
merepresentasikan pemetaan diantara bahasa untuk implementasi dari client dan ORB
Core. Kemudian client dapat ditulis dalam sembarang bahasa asalkan implementasi dari
ORB mendukung pemetaan ini. ORB Core kemudian mentransfer request ke suatu
implementasi object yang menerima request sebagai up-call melalui IDL skeleton atau
sebuah dynamic skeleton.
Komunikasi diantara implementasi object dan ORC core dipengaruhi oleh Object
Adapter (OA). OA menangani service seperti pembangkitan dan interpretasi dari object
references, method invocation, securitas dari interaksi, aktivasi dan de-aktivasi
implementasi object, mapping reference sesuai dengan implementasi object dan registrasi
dari implementasi. Di masa datang diharapkan akan ada banyak object adapter khusus
yang berbeda untuk memenuhi kebutuhuan sistem yang khusus ( sebagai contoh
basisdata ).
OMG mendefinisikan empat aturan dimana OA dapat menangani aktivasi implementasi
object :
Shared Server Polic : Banyak obyek yang aktif share server/program yang sama. Server
melayani request dari banyak client. Server akan tetap aktif sampai server dimatikan.
Unshared server Policy : Hanya satu object yang aktif di server. Server akan mati ketika
client yang menyebabkan aktif keluar.
Server-per-method Policy : Setiap request menghasilkan
Persistent server Policy : Implementasi object secara konstan aktif ( jika tidak, maka
akan dibangkitkan Exception ).
Jika sebuah request dibangkitkan selain berdasar policy diatas, object akan diaktifkan
oleh OA dalam policy khusus. Untuk melakukannya, OA membutuhkan akses ke
informasi tentang lokasi object dan lingkungan yang ada. Basisdata yang berisi informasi
tersebut disebut Implementation Repository dan merupakan komponen standar dari
arsitektur CORBA. Informasi didapat dari sana oleh OA pada aktivasi object..
Implementation Repository dapat juga berisi informasi lain mengenai implementasi
service, seperti debugging, versi dan administrasi informasi.
Interface ke object dapat dispesifikasikan dalam dua cara : OMG IDL atau dapat
ditambahkan ke Interface Repository. Dynamic Invocation Interface membolehkan client
untuk melakukan request ke object yang definisi dan interfacenya tidak diketahui pada
waktu kompilasi client. Untuk menggunakan DII, client harus menyusun sebuah request
termasuk object reference, operasi dan daftar parameter. Spesifikasi ini ( dari objects dan
services yang disediakan ) di-retrieve dari Interface Repository, sebuah basisdata yang
menyediakan penyimpanan tetap dari definisi interface object. Interface Repository juga
berisi informasi mengenai tipe parameter-parameter, informasi debugging tertentu, dsb.
Analogi server side dari DII adalah Dynamic Skeleton Interface (DSI), dengan
menggunakan interface ini, operasi tidak lagi mengakses melalui sebuah operationspecific
skeleton, yang dibangkitkan dari spesifikasi interface IDL, malahan operasi
dicapai melalui sebuah interface yang menyediakan akses ke nama operasi dan
paramater-parameter ( seperti DII, diatas, informasi dapat didapat dari Interface
Repository). Sehingga DSI adalah sebuah cara untuk mengantarkan request dari ORB ke
sebuah implementasi object yang tidak mempunyai pengetahuan waktu kompilasi dari
suatu object yang sedang diimplementasikan. Meskipun pertama kali sekilas terlihat
bahwa situasi ini tidak sering terjadi, dalam kenyataannya DSI adalah sebuah jawaban
untuk tools software development yang interaktif berbasis interpreters dan debuggers.

How Does CORBA Work?
• Langkah 1 : Tulis sebuah spesifikasi untuk setiap object menggunakan IDL
(Interface Definition Language)
• Langkah 2 : Compile IDL untuk membangkitakn client stub dan kode server
skeleton
• Langkah 3 : Tulis kode aplikasi client
• Langkah 4 : Tulis kode object server
• Langkah 5 : Kompile kode client dan server
• Langkah 6 : Hidupkan server
• Langkah 7 : Jalankan aplikasi client
IDL ( Interface Definition Language )
IDL adalah bahasa yang digunakan untuk mendefinisikan interface diantara komponen
aplikasi. IDL bukan bahasa procedural; IDL hanya dapat mendefinisikan interface, bukan
implementasi. Programmer C++ dapat menganalogikan definisi IDL sebagai header file
untuk class-class; sebuah header file biasanya tidak berisi berisi implementasi dari suatu
class, tetapi hanya mendeskripsikan interface class. Kemungkinan programmer Java lebih
menyukai definisi IDL untuk mendefinisikan interface Java.
Spesifikasi IDL bertanggung jawab untuk menjamin pertukaran data diantara bahasa
yang berbeda. Sebagai contoh, tipe long pada IDL adalah 32-bit signed integer, yang
dapat dipetakan ke C++ long (tergantung pada platform ) atau int Java. Hal ini
merupakan tanggung jawab dari spesifikasi IDL dan kompiler IDL yang
mengimplementasikan untuk mendefinisikan tipe data dalam language-independent.
Daftar Pustaka
http://www.omg.org
http://developer.java.sun.com/developer/onlineTraining/corba/corba.html
A Brief Tutorial on CORBA Kate Keahey, Indiana University :
http://www.cs.indiana.edu/hyplan/kksiazek/tuto.html
http://www.cs.indiana.edu/~kksiazek/tuto.html
http://www.cs.wustl.edu/~schmidt/corba.html
http://www.cs.wustl.edu/~schmidt/PDF/corba4.pdf
http://courses.cs.tamu.edu/cpsc608/hohin/summer00/notes/corba.ppt
Dokumentasi Java j2sdk-1_4_1 ( Dapat didownload di http://java.sun.com atau email
dana@stttelkom.ac.id)
Teach Yourself CORBA In 14 Days : Sams' Teach Yourself CORBA in 14 Days
Jeremy Rosenberger
Client/Server Programming with Java and CORBA : Robert Orfali and Dan Harkey.
1997, John Wiley and Sons, Inc.

Minggu, 14 April 2013

Crossbar Switching Systems



by Peter Walker
Peter Walker gave a talk on Crossbar switching at the THG’s AGM in 2000. He has now converted the talk into print. In this article, Peter describes the principles of Crossbar switching and the history of the system.
Fig 1: Crossbar photo








Crossbar switching is a very old technique. The term arises from early manual switchboards that used a set of overlapping brass bars at right angles to each other forming a set of rows and columns. By placing a brass plug through a hole at an intersection of the bars, a connection could be made from any inlet to any outlet. This crosspoint switching principle is used not only in crossbar switching systems, but all matrix switching systems, including the reed-electronic systems, such as TXE2 and TXE4.
Fig 2: Crosspoint











Except for the very smallest PAX systems, matrix switches on their own are not large enough to provide a complete telephone exchange and it is neither economic nor practical to keep increasing the size of the matrix, so crossbar switches are usually connected together in a form known as Link Trunking. The outlets of the first stage of switching are connected to the inlets of a second stage. By careful design of the links, it is possible to provide an overall switching matrix that provides degrees of concentration or expansion and different blocking probabilities. By blocking, we mean the possibility of their being no available path between a given inlet and a required outlet, i.e. the Grade of Service.
Fig 3: Link Trunking















One way to create a matrix switch would be to employ a relay at every crosspoint, but this would be expensive and the number of relays goes up as a square law. Nevertheless, as we shall see, all-relay systems were built. Indeed, the reed-electronic systems TXE2 and TXE4 used one reed relay per crosspoint, though the switch matrices were kept fairly small. A crossbar switch is an electromechanical switch that aims to create a matrix switch without needing a relay at each crosspoint. Instead, while having a set of relay contacts at each crosspoint, they are operated by an electromagnetic coil associated with each column and each row.
The first principle to understand is how to make a set of contacts operate conditionally; that is, they will operate when the right combination of coils are energised. The principle is best understood by considering how this principle might work with a single relay.
Fig 4: Principle of crossbar operation










In figure 4(a) we see a relay where the lifting comb is not in contact with the armature as would normally be the case. If the armature operates, the contacts will not move. In (b) we see how a stiff wire (known as a ‘finger’) is inserted in the gap between the armature and the lifting comb. In (c) we see that if the finger is in place, then operation of the coil will result in the lifting comb moving and the contacts are closed.
In a real crossbar switch, the coil, associated with the ‘vertical’, would have an extended armature, known as the operating bar, which can potentially operate a number of spring-sets in the column. By introducing a finger into one or more of these spring-sets, it is possible to select which contacts will be operated. The fingers are introduced by swinging them into position by a horizontal bar operated by an electromagnetic coil associated with the ‘row’. In fact, to gain even greater economies, each horizontal bar can be swung up or down, so only one bar is needed for every two rows. Fig 5 shows the detail of how a real crossbar switch crosspoint is operated.
Fig 5: Crossbar detail










In Figure 5 we can identify several important components. The vertical assembly (or ‘bridge’) is associated with the switch inlets and these are commoned across all the contact sets. The vertical is operated by the bridge magnet (not shown) which has the effect of driving the operating bar into a slot in the contact sets. Only if a finger is swung between the operating bar and the spring-set, will the latter be operated. The fingers are connected to the horizontal or ‘select’ bar and these can be swung up or down according to which select magnet is operated. So a particular spring-set is actuated by first operating the appropriate select magnet to introduce the fingers into the upper or lower position in front of the spring-sets in that ‘row’ and then operating the bridge magnet for the ‘column’. This traps the finger between the operating bar of the bridge and the spring-set such that when the select magnet subsequently releases and the horizontal bar returns to normal, the finger is held. In order for this to work, the fingers are made of flexible spring steel. A consequence of the spring-like nature of the fingers is that when the horizontal bar is operated or released, the fingers oscillate and incorrect selection might result, so a damper is fitted to control this. It is the noise of these dampers rattling on the fingers that gives crossbar switches their characteristic tinkling noise when operating.
Fig 6: Typical trunking diagram of a crossbar exchange








Crossbar exchanges come in many different shapes and sizes, but Figure 6 shows a typical layout of a crossbar local exchange. The line unit is a two-stage link-trunked sets of crossbar switches designed to concentrate the subscriber lines (about 500 on each) onto a smaller number of trunks with control relay-sets, from which the registers are accessed and dial tone returned. For an originating call, the line unit plays a similar role to line-finders in a Strowger system. Calls are set up across the group unit (two or more crossbar stages) to an appropriate outgoing junction or the line unit associated with the called party’s line. Unlike Strowger which has separate final selectors and line-finders, the line units perform both roles and are bi-directional. The control relay-sets between the line and group units perform all the line supervision functions, i.e. transmission bridge, current feeding and ringing. Each line and group unit will have a common control marker, which has the job of setting up calls one at a time, identifying an appropriate free path through the link-trunked switches. The precise arrangements of markers and other items varies between systems as does the terminology for the line & group units and the control relay-sets.

The history of crossbar

The first crossbar switch was designed in 1913 by J. N. Reynolds, an engineer with Western Electric in the USA. Although it was patented in 1915, it was never exploited. It used a system of cams and rollers to operate the crosspoints, see Fig 7.
Fig 7: Reynold’s crossbar switch











Betulander






Around this time, two engineers at the Swedish PTT (Televerket),  Betulander and  Palmgren, were experimenting with the idea of producing exchanges using relay crosspoint technology. They found that using relays at each crosspoint was too expensive for large exchanges but did develop a small-sized all-relay exchange. But their most important innovation was the use, for the very first time, of both link trunking and common-control markers for call set-up.
PalmgrenTeleverket were interested in deploying automatic exchanges and, like the British GPO in the 1920s, decided to order some pilot switches. However, the Great War intervened and trial exchanges were not in place until 1921. This delay had great significance, since by this time, Betulander had realised the need to reduce the relay count in his system and had come across Reynold’s patented crossbar switch. By abandoning the cams and rollers for the simpler finger system described above, Betulander designed a new crossbar switch in 1919 which became the model for all subsequent types.

Fig 8: Betulander’s crossbar switch of 1919






So, by 1921, the Televerket competition was between four systems:
Siemens & Halske of Germany offered a step-by-step system;
Western Electric offered the Rotary system from their Antwerp factory;
L.M. Ericsson offered two systems: Hultman & Kảell’s 500 point system and a crossbar system based on Betulander’s new switch.
It was no surprise that Televerket reflected the national interest and chose an Ericsson system, but the course of history was changed because they chose the rotary-style 500 point system, rather than the new and unproven crossbar system. Jacobaeus, a Swedish switching expert, later said:
“The technicians of that time considered the link-connection technique strange and complicated. And that prejudice was natural enough because there was no scientific and reliable method of calculating the traffic handling capacity of link-connected systems. They also feared that occasional relay faults in the common markers would cause total stoppage of operations, a condition that was all the more critical because it was a matter of choosing a system for exchanges with a large number of lines.”
Later, Jacobaeus himself produced the definitive mathematical approach to the design of link-trunked systems. It should be no surprise that modern crossbar systems have always used duplicated markers to avoid the security problem.
At this point it is worth mentioning that Betulander’s all-relay system was deployed for a number of installations. The first 100 line subscriber demonstration exchange was exhibited at Marconi House in London in 1913. Televerket kept the rights to the system in Sweden but sold the overseas rights to an English firm, The Relay Automatic Telephone Co Ltd. Public exchanges were installed in London (1916), Fleetwood, Lancs (1922 and worked for around 30 years), India and France. But on the whole, the system was restricted to PABX use.
After the Televerket trials, history might have consigned crossbar to the dustbin, along with its link-trunking and marker control. In fact, the crossbar switch was given a consolation prize by being used by Televerket in a rural switching system, initially at Sundsvall in 1926. However, due to the concerns about link-trunking and common control, these rural exchanges worked in step-by-step mode, each switch playing the role that a Strowger selector would normally do. Later on, manufacturing constraints meant that Ericsson were asked to supply the switches. By 1944, some 1100 such exchanges had been installed in rural Sweden. This meant that Ericsson gradually refined the design of the switch and it was even deployed as a register within the 500 point system when long distance dialling was implemented.

Crossbar in the USA

However, the next part of the history is on the other side of the Atlantic. In 1930, while Bell Labs engineers were trying to produce their own design of matrix or ‘coordinate’ switch, they sent a study mission to Sweden to see the rural crossbar system and ordered a few switches for analysis. Working secretly over many years, they gradually developed what became known as “Xbar #1” and this was first introduced in 1938 in Brooklyn (Troy Avenue), closely followed by Manhattan (East 30 Street). But Bell Labs had published nothing about their new system until as late as 1937 and these articles caused a considerable stir. Analysis of the system showed that not only was the crossbar switch remarkably similar to the Swedish design, but of even more importance was the fact that Bell Labs had used Betulander and Palmgren’s link-connection principle with register and marker control, ideas that had been largely forgotten elsewhere. The Crossbar No 1 system was designed for large city exchanges, where AT&T was looking to Crossbar to provide a better big city switch than the expensive and flawed Panel system. It proved a major success and by 1978 some 6M lines were in use.
Fig 9: Bell Labs Crossbar switch







Fig 10: Crossbar #1










In 1943, the Crossbar #4 system was introduced for toll (tandem) use and 177 had been deployed by 1976. The general purpose Crossbar #5 was introduced in 1948 for local exchange and small tandem applications. By 1978, 28M lines had been deployed in the Bell system with another 17M lines in Canada and the US independents.
All this activity did not go unnoticed by the Swedes. L.M. Ericsson quickly went ahead developing a series of systems with link trunking and marker control to exploit their now well-refined crossbar switch. But as so often, the initial deployments were abroad, as Televerket was initially quite content with its 500 point system. Key dates were:
1950 ARF50 at Helsinki (small local, for the 1952 Olympic Games)

1952 ARM10 at Rotterdam (tandem)

1953 ARF10s in Jutland and Copenhagen (large local)

1953 ARM20 Aarhus (large trunk)
Fig 11: Ericsson ARF exchange at Viborg, Denmark
















 
In 1954, deployments started in Sweden. The rest as they say is history… Ericsson went on to export and licence the system widely across the world and crossbar became one of the world’s major switching systems in the 1950s-1970s.

Other crossbar systems

Many smaller manufacturers jumped on the bandwagon that Bell Labs and Ericsson had started and several minor systems appeared, produced by Kellogg in the USA, Bell Telephone Manufacturing of Antwerp and Standard Electric Lorenz in Germany. Behind the iron curtain, cut off from western exports, a crossbar system was designed in Russia and widely deployed in Eastern Europe. The Japanese were granted a licence for the Bell switch but quickly designed their own ‘copy-cat’ version. In Britain, only one system was designed – the 5005 from AT&E, which will be described in Part 2 of this series of articles.
The only other system of worldwide significance was the Pentaconta system produced by ITT, which used a massive crossbar switch with 22 vertical bars and 14 horizontals. First delivered in 1955, it was exported and licensed in many parts of the world. The Pentaconta system used a novel form of link trunking which featured ‘entr’aide’ or Inter-Aid. Should there be no free path available through the two-stage crossbar unit, extra Inter-Aid links were provided between adjacent switches in the first stage, thereby providing alternative pathways, albeit needing a three switch connection. Pentaconta was used for the PO TXK3 and TXK4 systems, which will be described in Part 3 of this series.
Fig 12: Pentaconta crossbar switch






In concluding this review of crossbar systems, it is worth mentioning that some manufacturers, including those in Japan, developed the basic switch to be more compact, see Figure 13. On the whole, however, the main crossbar suppliers kept to the traditional large sized switches.
Fig 13: Mini Crossbar Switch









Crossbar in the UK

As is well known, the GPO had chosen the Strowger system in the 1920s. It had been refined and standardised and by the 1950s there were 5 firms producing all the kit that the GPO needed: GEC, AT&E, Ericsson Telephones, ST&C and Siemens Brothers. The GPO was convinced that a fully electronic exchange system was just around the corner and felt that it would be a distraction to introduce a system like crossbar into the UK network, even though the advantages of precious metal contacts over the sliding base metal used in the Strowger system were well established. So confident were they of this that when Subscriber Trunk Dialling was planned in the 1950s, it used all Strowger technology. But the utter failure of the Highgate Wood all electronic Pulse Amplitude Modulation exchange created a major set back. Development largely switched to exploiting reed relay exchanges with electronic control, finally producing TXE2 and TXE4 many years later. Some work continued on electronic switching and this led to the Empress PCM digital tandem exchange, along with STC’s private venture PCM tandem at Moorgate.
But there was a problem. AT&E, at least, felt that being tied to the GPO’s Strowger programme meant that it could never compete in the world export market, so started designing its own crossbar system, the 5005 system. It wanted to use the UK network as its showcase and lobbied the GPO to accept it. On the GPO side, it was becoming obvious that a fully electronic exchange was some way off. TXE2 was limited to smaller local exchanges and TXE4 was only really going to be economic for large local exchanges. In any event, TXE4 was years behind schedule, after initial trials of TXE1 and TXE3 showed their various inadequacies. This left nothing other than Strowger to meet the demands for medium sized locals and the trunk network. The 2-wire Strowger  GSCs were not fit to complete the STD programme for which an overlay 4-wire transit network was urgently needed. The London trunk network was reaching saturation and a radical decentralisation programme was needed. In hindsight, many have concluded that the GPO should have adopted crossbar for the whole STD programme, but that would have been heresy at the time.
In the end, the Post Office relented and allowed UK manufacturers to offer their proprietary crossbar designs. Since they would need adaptation to the UK network, it was agreed that procurement would be against a set of functional requirements, known as Post Office Requirements (PORs). In practice, the production of PORs was a farce. With headquarters staff too imbued in Strowger precedent to think ‘outside the box’, many PORs were written alongside the development of the systems and some were actually completed after they had entered service.
The next section of this article describes a little about each of the UK crossbar systems. The systems were all given codes beginning TXK, because the more logical TXC sounded too much like TXE.

The AT&E/Plessey 5005 crossbar system TXK1

As mentioned above, AT&E started developing their crossbar system for the export market. They were a late entrant into the crossbar market. Their switch was almost identical to the Ericsson crossbar switch, for which I believe they had a licence to exploit, but their chosen control mechanisms were quite unlike any other previous crossbar system. These features were ‘Self-Steering’ and ‘Mass marking’. With a normal crossbar marker, a free path is chosen by analysing which links are busy. This requires a lot of control wires between the switching units and the Markers. With ‘Self-Steering’, a free outlet is chosen and all possible paths back through the switching stages are marked using relays associated with each switch. At each switch, one mark from all competing marks is chosen and horizontal bars are operated. When a mark finally arrives at the required inlet, the successful path is established by operating the bridge magnets and releasing all the horizontal bars. ‘Mass Marking’ is a further refinement of this technique in that on outgoing junction calls, marking is started from all free junctions on the route. The impact of these features is that markers in TXK1 are very compact, compared to, say, an Ericsson marker which might be a whole rack of relays. Other novel features were the adoption of high capacity 501-type comb relays and wire-wrapping of joints.
In the 5005 system, the line units were known as Distributors, the group units were called Routers and the control relay sets were called Transmission Relay Groups (TRGs).
The first 5005 deployment was in the Plessey factory at Edge Lane, Liverpool in 1963; AT&E having by this time combined with Ericsson Telephones and Plessey into one company. The same year saw the first overseas deployment of a 100 line international exchange in Sydney, the 4-wire 5005T system. Having persuaded the Post Office to accept a pilot 5005A local exchange, this was brought into service in 1964 at Broughton, Lancs. 1965 saw another international exchange in Hong Kong, while in 1966, the Post Office approved the TXK1 for deployment as an ‘interim’ system. The first production TXK1 entered service at Bacup in 1968.
Fig 2.1: TXK1 exchange










GEC had no crossbar system of their own, so licensed the 5005 system and joined Plessey in rolling out some 1300 TXK1s. The first TXK1 in the London Region was at Upminster in 1970 and was notable for replacing London’s last manual local exchange.
GEC were not just a licensee of the system. They further developed the TXK1 for use as a GSC and for the 7 London Sector Switching Centres (SSCs), for which stored program control was introduced via the GEC Mark 1c processor. This processor took over the functions of the register, coder, MF2 sender/receivers and part of the Router Control. SSCs were deployed first at Ilford in 1972 followed by the other units at Wood Green, Colindale, Ealing, Kingston, Croydon and Eltham. Each site actually had three exchanges: an incoming trunk unit, an outgoing trunk unit and a local tandem. CSS1 Manual Boards were also fitted. The trunking of the SSCs, being a large trunk exchange, was different from the TXK1 locals. The switchblock comprised a 2-stage Router, a 1-stage Office Router and a 1-stage Junction Router. Routes were terminated on the Router, Office Router or Junction Router according to size.
In contrast, the GSC was more conventional, being entirely electro-mechanical. The main development work was the introduction of the all the specialist GSC signalling functions, including ISD, transit access etc. The first was installed at Brentwood in 1972. Like Strowger GSCs, there was almost always a local component to act as the local exchange for the locality, so the trunking was similar to the local TXK1, a 2-stage Router and a 2-stage Distributor for the local subscribers. Many TXK1 GSCs replaced the very last manual GSCs, such as at Dover and Hastings. One interesting early TXK1 GSC was at Mid-Yell, in Shetland, which comprised just one Router and one Distributor – one of the smallest ever TXK1s, though another later TXK1 GSC at Strontian  had only 65 subscribers as against Mid Yell’s 89. It similarly had the minimum complement of transit and ISD equipment.
Some TXK1 GSCs were installed as extensions to an existing Strowger GSC. They would share outgoing routes and special 3-wire TRGs were developed for the TXK1 for this purpose. They were designed so that if a junction was seized simultaneously by the Strowger and crossbar units, the Strowger would be allowed the call and the TXK1 forced to do a repeat attempt. Well, it wouldn’t be feasible the other way round, would it?

The TXK2 system

Following the introduction of international subscriber dialling in 1962, international traffic increased dramatically. The sole Strowger era International Exchange at Faraday was based on the use of back-to-back Motor Uniselectors and its capacity was limited (about 1500e, I recall). Plessey, having delivered two small international exchanges in Sydney and Hong Kong were invited to supply a massive ISC which would ultimately have 5000 incoming and 5000 outgoing circuits. Ericsson of Sweden tried to bid for the job as well, but were told that they were still not eligible to re-enter the UK market under the deal whereby they relinquished all connection with Ericsson Telephones of Beeston after the war.
However, the design of a 4-wire switch to carry so many circuits required something quite different from that deployed in Sydney and Hong Kong. The trunking comprised a 3-stage Great Router and 2-stage Outgoing Office – 5 switches in all across the switchblock. But the International Telephone Services Centre (ITSC), as the whole complex was known, comprised more than just the switch. There was a cord manual board (International Control Centre, ICC), a computer called the International Accounting and Traffic Analysis Equipment (IATAE), an International Maintenance Centre with some pretty fancy kit, including such items as the Call Progress Indicator which used CCTV to pipe displays to each maintenance position. On the ground floor was a large International Repeater Station. The whole project went disastrously late and the first part of Wood Street didn’t enter service until April 1971, though most histories say 1970. I’m sure we all appreciate the difference between RFS and BIS dates!
By this time, it was all too late. Faraday was creaking at the seams and congestion was rife. Occupancies on circuits to the USA often exceeded 98% and stayed that way all day. In a desperate bid to plug the gap, Plessey air-freighted the Sydney ISC they had installed in 1963 back to the UK and re-installed it in Wood Street, where it re-entered service in June 1970 as the Wood Street Relief Unit. The TRGs were quickly modified for UK 4-wire loop disconnect signalling and put to work on London’s IDD traffic. All that just to gain another 100 international circuits! Sydney didn’t need the unit anymore, as they had the joys of a brand new Ericsson ARM20 international crossbar exchange.
Fig 2.2: TXK2 Crossbar switches – as with TXK1, these could be 
hinged forward to access the rear of the switches









As well as having a unique trunking arrangement, the original TXK2 had a bizarre signalling configuration. The registers didn’t have separate sender/receivers to cope with all the signalling permutations found at an ISC. Instead, they all had in-built senders for signalling continental AC4 (CCITT4) and intercontinental MF1 (CCITT5). So on incoming calls, the registers signalled MF1 across the switchblock, where the outgoing national Line Relay Groups (LRGs) had access to outgoing registers that converted the MF1 to the requisite LD4, AC9 or MF2. For AC9 and LD4 working via Faraday Trunk Non-Director, outgoing coders were needed to provide the Strowger translation digits.
Another odd feature was that each incoming LRG only had access to a maximum of three registers from the total pool of registers. When the unit was busy (which was most of the time), if all three registers were busy, the affected incoming loop disconnect circuits from London were back busied to prevent calls arriving. Now these junctions were already very busy, but the London traffic recorders at the Strowger trunk units measured the traffic by looking for an earth on the P-wire. Unbeknown to the traffic planners in London, the back-busied condition, which caused an earthed P wire, was measured as occupied traffic, which made the high occupancy circuits appear even higher. So more circuits kept being added. This made matters worse, as there were no corresponding international circuits on the other side to take the extra traffic and this made the exchange registers even busier.
Another side effect of this odd arrangement was that the back busy was given as a full line reversal. When the registers became free again, the A relay was once again presented to line the normal way round and it met the capacitor on the line across the 2-wire/4-wire terminating transformer at the London trunk unit. (It should be remembered that the pulsing took place over the phantom of these 4-wire junctions.) This caused the A relay to ‘flick’ causing the IATAE computer to register a short call of about ¼ second. All these ‘ineffective’ calls made the unit’s performance appear even worse. The solution to this problem was much simpler: make the back busy merely a disconnection of the battery, not a full reversal.
The next ITSC was to have been at Mondial House, also in the City of London, but the novel design of building ran late and, in another famous panic, an old aircraft factory at Stag Lane, Edgware was quickly acquired for the installation of no less than two new ISCs, the DeHavilland TXK2 and Mollison TXK5 (of which more in Part 3). The former was very similar to Wood Street, except that it didn’t have an associated Manual Board (ICC), all operator controlled calls coming in over AC11FT/MF3 junctions from London, Leicester and Glasgow. Once DeHavilland came into service – again late – in 1975, the run-down of Faraday ISC could begin.
Fig 2.3 (mondial1) General view of Mondial TXK2














Fig 2.4 (mondial2) Control equipment for TXK2, showing 
wire-wrapped terminals.
















A third TXK2 was ordered for Mondial House and involved considerable redevelopment. With a third signalling system, R2, being needed, the whole register system was redeveloped, with separate groups of sender/receivers, which obviated the need for the outgoing registers and coders. The limited availability of registers was also designed out. Some of the national LRGs were redesigned as plug-in modules so they could be rebuilt with different signalling as the mix changed from operator controlled AC11FT/MF3 and AC9 to AC11/MF2. As far as I recall, however, this feature was never actually exploited. Mondial had no loop disconnect circuits, so even calls from London trunk units came in on MF2. During its relatively short life, Mondial ISC was redeveloped by my own staff with electronic microprocessor coders, to replace the 8 massive electromechanical coders that were constantly being rejumpered.

The STC BXB system: TXK3

The STC BXB system: TXK3






STC also took advantage of being able to supply proprietary Crossbar systems to the Post Office. As part of the ITT group, they had ready access to the Pentaconta system and set up a manufacturing plant in East Kilbride to make it. To avoid it being seen as a ‘foreign’ system, it was branded as the BXB system (British X-Bar). The BXB 1112 system was a 2 wire local exchange system and coded as TXK3 by the PO. It was used for Director exchanges and the very largest Non-Director areas, such as at Newcastle. However, the PO ‘powers that be’ in Northern Ireland decided that there would only be one Crossbar system in the province; so if TXK3 was needed for Belfast City, it would be used everywhere! This led to some bizarre exchanges where TXK3s replaced UAXs. It is said that the standing current load of the TXK3 exceeded the busy hour load of the UAX it replaced.
The TXK3 was a fairly conventional Crossbar system, with a 2-stage line unit and 2-stage group unit. However, one novel feature of BXB was that all communication between registers and markers took place over a common bus circuit called the ‘Information Path’, something we now take for granted in the computer era, but quite unusual in relay technology. All junction and control relay sets were known as junctors, a word clearly derived from the French juncteur. The circuit diagrams departed from normal PO practice and looked odd. Of note was that relays were coded with lower case letters, which of course soon became known as ‘French letters’. U-links were known as ‘cavaliers’, which means ‘rider’ in French.
The first TXK3s came into service, again much later than intended, at North Cheam in Surrey and Liberton in Edinburgh in 1971. I can’t recall how many in all were installed, it might have been around 300.
The TXK3s had their teething troubles too and of note were problems at Marylebone, where the design hadn’t taken sufficient account of the traffic in the summer to the cricket score line!
The Pentaconta system was not well designed at the circuitry level. Unlike Strowger and the 5005 Crossbar systems, STC didn’t seem to believe in any spark-quenching of relay contacts and a lot of operational problems were caused by this. At worst, the Information Path could get seized up and the whole exchange stopped working. It was reported that if you took all the relay set covers off and turned out the lights, a Pentaconta exchange provided some spectacular fireworks. For a time, my home telephone line was on a TXK3 (Winchmore Hill) and I found it quite a reliable system. Like several other common control exchanges, TXK3s used a burst of immediate ringing before breaking into the ringing cycle, so this distinguished them from Strowger.

The TXK4 system

The plan to complete the STD programme required the installation of a 4-wire overlay transit network, since the 2-wire GSC connections could not provide the requisite transmission performance. The PO had designed a transit switching system based on the same concept as Faraday ISC, namely back-to-back Motor Uniselectors (MUs). During the hard negotiations between the PO and STC over the supply of Crossbar – well, over a few glasses of sherry I believe – STC senior management confidently told the PO that STC could supply a much better transit exchange using their marvellous BXB stuff, don’t you know old boy?
Only after the contract was signed did STC realise that a 4-wire switch was wanted and it must use the transit signalling systems, MF2 with either AC11, AC12 or DC3 line signalling. They had no idea how to develop these complex systems using the quirky Pentaconta relays. So the PO came to the rescue and handed over all the AT series relay set diagrams that were intended for the MU transit system and that is why many of the TXK4 junctors came to be built with 3000-type relay technology.
The project ran late (where have we heard that before?) and the first transit exchange entered service in Birmingham in 1972. The BXB 1121 system, as STC called it, featured a 2-stage Group Unit on which high traffic routes were terminated, while a second Group Unit was used for lower traffic routes. In order to cater for the various control functions, 8 wires were switched across the switchblock.
37 units were installed in all. 27 were at District Switching Centres (DSCs), 8 at Main Switching Centres (MSCs) and 2 at the London MSC/SPU. The latter unit, at Southbank, comprised 2 units, one for incoming traffic and another for outgoing. Unlike all the other MSCs, there was no transit traffic, in line with the policy to keep transit traffic out of Central London. Crawley and Cambridge MSCs provided transit services in the South East instead. The job of the Special Purpose Unit (SPU) was to aggregate traffic to and from provincial GSCs that justified a direct route to London, but not to each of the 7 SSCs. The junctions between the SSCs and the SPU were specially set up to provide the same transmission loss as if a direct route had been provided.
Once the transit network was fully installed, the STD programme was completed in the sense that anyone could dial automatically to everyone else. We take this for granted now, but it took until 1976 to achieve it!

The TXK5 system

By the time the Wood Street TXK2 ISC was in service, it was already severely congested. Wood Street, its Relief Unit and Faraday were all working flat out. Busy hour occupancies on the USA route frequently topped 99%. A crash programme was needed and the next TXK2 already being ordered looked as if it was going to be, once again, too little too late. On top of that, with the construction of the Mondial building running late, everything would have to be installed at Stag Lane, Edgware, in an old aircraft factory. To get the thousands of circuits up to Edgware and often back again, lots of 24 channel PCM systems were deployed. (This led, bizarrely, to PCM cards for DC3 signalling to be produced!!). Plessey were already working flat out, so the Post Office finally turned to Ericsson of Sweden, whose long period of purdah in the UK had finally come to an end. A contract was placed in 1972 for two massive ARM20 Crossbar ISCs. Both would be of simple design, one incoming, one outgoing, with no transit traffic, and no operator controlled traffic either. Mollison ISC, as it was called, had a total capacity of 8000e; at the time the largest international exchange in the world. The system was designated TXK5 by the PO.
In order to ensure that Ericsson’s designs would be compatible with the UK network, a ‘Test Model’ exchange (without any switches) was installed in Armour House in 1973. I arranged for circuits to be brought in from every conceivable kind of UK exchange type to prove interworking. During these tests, I even found some flaws in the design of Strowger GSC equipment which would have made them vulnerable to the ‘phone phreaks’.  Just before the exchange entered service, I worked night shifts carrying out further System Appraisal tests and more problems were ironed out. But there was one interworking problem we couldn’t solve. We couldn’t place any calls to the UAX at Sissinghurst. The problem was that Mollison could only signal to the provinces using AC11/MF2 signalling - it had no AC9 - which meant that calls entered the parent GSC using the Type 10 incoming MF2 register translators. But at this GSC, Sissinghurst was trunked on a level which needed 3 routing digits, and the Type 10s could only provide 2. Sissinghurst did eventually get regraded.
A peculiarity of the international signalling systems at Mollison was that the CCITT4 and 5 line signalling receivers didn’t use the guard band circuitry that the PO had always used. Such circuitry is intended to prevent speech signals from misoperating the line receivers. Instead, the CCITT4 receivers would often be heard chattering away during calls carrying the old Group 2 fax and I often wondered if any false signals or line splits were thus generated.

The two Mollison units were not identical. The incoming unit switched 5 wires, while the outgoing unit, requiring more control of the outgoing international relay-sets, switched 10 wires. The trunking was a pair of 2-stage group units. At 4000 erlangs each, both units were actually over the maximum size that an ARM20 could be built. So each unit was actually two identical units, called predictably ‘twins’. Full availability between all incoming to all outgoing circuits was provided by link circuits out of the first group unit of Twin A into the front end of Twin B. Markers in the two units could communicate with each other to set up these complex 6 switch calls.
The Stag Lane complex was single storey, so you got a much better appreciation of the awesome size of the exchange than if it had been spread over several floors as most other large exchanges would have been.
Mollison finally got on top of the endemic congestion once it was introduced in 1974, for once an international exchange that arrived on time. In the second phase, the first R2 circuits were delivered. This allowed the rundown of Faraday ISC including its last complement of AC7 (CCITT3) circuits to France.
TXK5 had a quite different personality compared to TXK2. Like all 5005 exchanges, DeHavilland TXK2 was fairly quiet, as the equipment was mounted behind plastic covers and the common equipments, such as Router Controls, were spread out with the router switches they controlled. TXK5 was quite different. The relay sets were in metal cans, similar in a way to Strowger technology, while the switches had glass at the front of their covers. The Route Markers and Markers were all centralised in suites, so this area of the exchange was very noisy in the busy hour. You could tell from the sound that a Route Marker made whether the call had been successfully switched across the exchange.
Because of the hurry to install Mollison, the PO accepted a lot of basic auxiliary equipment which had lower functionality than the TXK2 ITSCs. The accounting equipment, called the AVR, (using an Ericsson UAC1610 computer) was fairly basic and didn’t do any traffic recording. For that, a very simple device called the MET2 was used, although this was later replaced by the OMT system.














Soon after Mollison entered service, another pair of TXK5s was ordered for the Thames ISC, to be installed in Mondial House alongside the third TXK2. However, Thames was a more complex exchange, as we will see in the next section. The Thames TXK5s differed from Mollison in that they were single units, not the twin system described above. A better computer system was provided for the international accounting and it used the familiar title of the International Accounting and Traffic Analysis Equipment (IATAE). The TXK5s were also modified to provide some specialised tie routes to and from the bothway TXK6 unit, described below.

The TXK6 system

The TXK6 system
In the mid-1970s, the IDD annual growth rate hit 35%. Thames ISC was not only going to provide yet more IDD capacity, but would also provide the first service use of the new CCITT6 common channel signalling system, a forerunner of the now near-ubiquitous CCITT7. CCITT6 signalling had been subject of an international field trial as far back as 1972 on the Wood Street TXK2, but it was a long time before it was introduced for live service in 1979. By its nature, a common channel signalling system requires a computer controlled exchange, so alongside the pair of 2500e TXK5s, the PO ordered a 5000e Stored Program Controlled AKE132 switch from Ericsson. This used code switches, rather than traditional Crossbar switches and all switching and control functions were handled by an APZ150 processor. It was therefore more ‘electronic’ than a TXE4 and I argued that it should be coded in the TXE series. But the TXE4 people were horrified and it ended up being called TXK6.
The trunking of the code switches was a pair of 2-stage Group Units, called ‘600 groups’, as they had capacity for 600 trunk circuits. Code Switches are rather like miniature Crossbar switches, but they had the unusual feature that they were mechanically latching, so the vertical magnet had to be pulsed at the end of the call to release the call. The TXK5 units were usually called Thames 1, while the TXK6 was Thames 2, but some PO forms required units to use letters rather than numbers, so for traffic planning they were called Thames A and Thames B.
Like all SPC systems, sometimes the exchange software would crash and this meant that the exchange lost memory of what calls were set up. Since the code switches were latching switches, this meant that every vertical unit in every code switch needed to be pulsed to clear down all the calls in the exchange. If this was done all at the same time, then the exchange fuse would have blown, so the processor went round the switches in a rapid sequence, which sounded just like machine gun fire.
There was to have been a second TXK6 installed in Keybridge House, but the order was switched to the newer digital AXE system, which happened also to save BT around £6M. Thames 2 was the last analogue ISC in the BT network and was withdrawn in 1992. The march of digital technology meant that all the Crossbar ISCs had short lives. Faraday, the Strowger era switch, had lasted from c1955 to 1975. Wood Street thrashed itself to bits and was withdrawn in 1984; 12 years of mass marking had started to cause fatigue failures in the Outgoing Office switches. Stag Lane followed in 1988, where Mollison ISC had paid for its £14M cost hundreds of times over. Mondial TXK2 was replaced by an AT&T 5ESS exchange a few years later.
The last Crossbar unit I saw working was the TXK1 at Lea Valley when it was changed over to System X in 1993. The very last Crossbar exchange was at Droitwich and was withdrawn in 1994.

Crossbar came late to the UK and was never loved like Strowger was, except for those of us whose careers were closely associated with it. Late delivery and teething troubles added to the woes. But at its peak, Crossbar was carrying a significant proportion of all the UK traffic and allowed the manufacturers to start the rundown of Strowger production. Exchanges like the processor controlled SSCs showed what Crossbar could have been, had it been deployed in a more rational way. Crossbar, when bedded in, delivered a higher quality of service than Strowger ever could and without it, the growth of IDD in the 1970s could never have happened. Sadly, very little Crossbar has been preserved in the UK.