uva-dare (digital academic repository) the building …...

UvA-DARE is a service provided by the library of the University of Amsterdam (http://dare.uva.nl)

UvA-DARE (Digital Academic Repository)

The building block method. Component-based architectural design for large software-intensive product familiesMüller, J.K.

Link to publication

Citation for published version (APA):Müller, J. K. (2003). The building block method. Component-based architectural design for large software-intensive product families Amsterdam

General rightsIt is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s),other than for strictly personal, individual use, unless the work is under an open content license (like Creative Commons).

Disclaimer/Complaints regulationsIf you believe that digital publication of certain material infringes any of your rights or (privacy) interests, please let the Library know, statingyour reasons. In case of a legitimate complaint, the Library will make the material inaccessible and/or remove it from the website. Please Askthe Library: http://uba.uva.nl/en/contact, or a letter to: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam,The Netherlands. You will be contacted as soon as possible.

Download date: 15 Jun 2018

http://dare.uva.nl/personal/pure/en/publications/the-building-block-method-componentbased-architectural-design-for-large-softwareintensive-product-families(fb479953-7f8d-48a5-8c27-345ebf6b5098).html

Thee tss Product Family 195 5

Appendixx A The tss Product Family y

Thiss appendix contains an introduction to the digital Telecommunication Switch-ingg System (tss), which was the main source of inspiration in designing the BBM.. However, this appendix is not an introduction to telecommunications in general,, nor to switching systems and telephony. Rather, it is a description of a specificc telecommunication system, containing only a brief motivation of its designn decisions related to the BBM.

Forr the design of the tss product family the specialised method for centrally-controlledd distributed systems (see chapter 10) has been used. However, the BBMM is only used for the design of the software of the central controller. The appendixx does not repeat the method descriptions given throughout the rest of thee thesis but describes the usage of the architectural concepts.

A.ll tss Introductio n

AA telecommunication switching system is part of a telecommunication network. Thee main connections a switching system has, are to subscribers, and to other switchingg systems (so-called trunks), see figure 75.

Forr all the connections of a switch specific communication protocols are defined.. Some of the protocols are internationally standardised, while others are definedd by national authorities or private parties. Many of the international standardss have national adaptations. Switching systems, as part of the public tele-communicationn infrastructure, have to be reliable. Telecommunication is an essentiall service for life saving and order preserving agencies. Degradation of thiss service is undesirable and complete loss unacceptable. Switching systems aree configured per site in functions and capacity.

1966 The tss Product Family

subscriberr lines 3|g?? SJgP =JgF

mm m

Telecommunication n Switchingg System

mm m

Telecommunication n Switchingg System

'trunkk lines X X FigureFigure 75: Switching Systems in Context

Thee tss product family, developed at Philips Kommunikations Industrie (PKI) Nurembergg (now Lucent Technologies) since the middle of the eighties, is based onn a platform approach for telecommunication infrastructure systems. The prod-uctt family was designed for niche markets with a high variety of features. A key requirementt was to achieve a reasonable price even with a low sales volume. Productss from the family include public telephony exchanges, GSM radio base stations,, technical operator service stations, operator-assisted directory services andd combinations of the aforementioned.

Thee tss product family was built to meet the requirements of a cumulative downtimee not exceeding one hour per year. This included repair and upgrading actions.. A key design element to meet this requirement is the use of hardware redundancyy and graceful degradation. On the other hand, requiring that the sys-temm looses its capability to establish new calls not longer than a few seconds and neverr cancelling existing calls leads to very complex and expensive designs. The tsss system is not based on hot stand-by redundancy for the whole of the system andd does not provide stable-call-saving. The system is designed to minimise downn time and to remain never in an inconsistent state. It autonomously handles firstt faults (single error assumption) in critical central components such that servicee is resumed or continued without degradation.

Thee tss product family is modular, both in hardware and software. Customer visiblee modularity serves to replace erroneous or adapted components and to extendd the system with new functionality. Each tss system contains a database forr configuration data and other parameters. Changes to configuration data and


parameterss are done in transactions with the associated roll-back if the transac-tionn cannot be finished.

Dataa about typical sizes and performance of tss systems are given in section A.5. .

A.22 System Architectur e

Thee hardware architecture is based on a distributed network of printed circuit boards,, many containing microprocessors. A central processor is responsible for centrall control of the switching system. The software in the peripheral hardware areass (switching matrix and peripheral groups) (figure 76) handles routine tasks, off the kind that occur during call setup/cleardown and digital switching.

A.2.11 Hardwar e Components

Thee hardware of the tss system comprises the following main components: the centrall processor, the switching matrix, the peripheral groups and the operation andd maintenance terminals (figure 76). The central processor contains the sys-tem'ss main intelligence. It is a controller of the other hardware components, whichwhich act according to the directives of the central processor. It comprises two processorr planes (section A.2.2) and some common units. The switching matrix actuallyy switches telephony lines. The connections, which have to be set up or givenn up, are decided by the central processor at the subscriber's request. The peripherall groups consist of collections of multi-functional peripheral units (PU) controlledcontrolled by a peripheral group controller (PGC). In cases where the peripheral groupp consists only of a single PU there is no PGC. Each PU is of one of three classes.. The first class consists of trunk cards which handle connections to other switches.. The second class consists of subscriber cards which handle speech and/ orr data connections to subscribers and private branch exchanges. The third class consistss of service function cards which generate special announcements or tones,, or support special services such as conference calls. To unburden the cen-trall processor, much of the processing is moved into the peripheral groups. The speedd of the central processor determines the system's call capacity, i.e. the numberr of connections the system can setup (usually measured in busy hour call attemptss (BHCA)). The operation and maintenance terminals support system managementt tasks.

198 8 Thee tss Product Family

Peripherall Module Channel

Peripherall Module Channel

Operationn and Maintenance e

Terminals s

FigureFigure 76: tss Hardware Architecture

Thee central processor, the switching matrix and the peripheral groups com-municatee via a bus, called the peripheral module channel (PMC). It carries data andd control information. The switching matrix is directly connected to both the centrall processor and the peripheral groups. The communication between the centrall processor and the peripheral groups is always relayed through the switch-ingg matrix in the same way that speech and data are exchanged between periph-erall groups. The central processor and the terminals communicate via terminal connectionn units, which have direct connections to the terminals themselves. The terminall control units are among the common units in the central processor.

Thee central processor and the switching matrix both have clocks. The clock off the central processor acts as a real-time clock used to implement timestamps andd absolute timers, and gives triggers to the software. The triggers are used by


thee process management BB and by the BB which implements relative timers. Thee clock of the switching matrix is used to synchronise the tss system with the publicc network.

Inn figure 77 three peripheral groups are shown. The first and the third consist off only one card each. The first is the speech announcement card (SAG) which is aa service function card. The third group is the digital trunk group (DTG) which is aa network interface card. The second group consists of the peripheral group con-trollerr (PGC) and a set of circuit cards, e.g. analog subscriber card (ASC), digital subscriberr card (DSC) and three wire analog subscriber card (TSC). There are aboutt 20 different types of circuit cards. All circuit cards are connected to the universall peripheral slot bus (UPS).

ASC C

UPS S

ASC C

SAG G

DSC C

PGC C

DSC C TSC C

DTG G

PMC C

FigureFigure 77: Three Peripheral Groups

A.2.22 Redundancy

Thee central processor contains two identical planes, viz. plane 0 and plane 1 (fig-uree 76). This is to improve the reliability and availability of the switching sys-tem.. Each plane consist of a microprocessor (called central controller (CC)), disk controllers,, a memory and communication hardware. One of the planes performs thee operational software tasks while the other performs tests in cold stand-by mode.. When the operational plane fails, the planes are interchanged with only a shortt down-time. Three processor control switches in triple modular redundancy decidee whether the planes must be interchanged. The decision is taken via major-ityy voting upon special messages from the processor planes. The two planes sharee a collection of common units consisting of the processor control switches, thee real-time clock, the disk units and the terminal control units.


Al ll common units are doubled in the central processor. The common units havee connections to both processor planes. The real-time clocks are synchro-nisedd and they can be connected to an external reference clock. This external clockk may be the synchronisation clock of the switching matrix or a clock trans-mittedd through a radio connection.

Partt of the switching matrix, viz. the part dealing with time stage switching, hass triple modular redundancy. Voting upon output data is used to detect and cor-rectt errors. The synchronisation clock within the switching matrix is doubled. Thee clocks are synchronised with a reference clock obtained from the network itself.. In special cases, e.g. during testing, the synchronisation clock may run in freee mode, i.e. without a reference clock. The remainder of the switching matrix doess not have hardware redundancy.

Servicee functions in the peripheral groups have redundancy in order to enable gracefull degradation after failures. The trunk cards have redundancy through the configurationn of the network. Alternative service function cards and trunk cards, whichh are connected to alternative trunks, are connected to different cards of the switchingg matrix. There is no redundancy of the subscriber cards.

Off all of the SW in the CC only some part of the extended operating system andd the handling of the message channels between central processor and the switchingg matrix are aware of the HW redundancy. The active plane runs the actualactual SW while stand-by plane runs test SW.


A.2.33 Software Architectur e

Servicee Management (SM)

Logicall Resource Management (LM)

Equipmentt Maintenance (EM)

Extendedd Operating System (EOS)

FigureFigure 78: Layered Subsystems

Thee software of the tss systems is based on the hardware shown in figure 76 and figuree 77. The software of the tss system is layered as shown in Figure 78. Note thatt the term subsystem is used here in the sense of horizontal subsystems. They aree the extended operating system, equipment maintenance, logical resource managementt and service management. Each subsystem uses only functionalities inn lower-layer subsystems.

Thee subsystems are distributed over the entire hardware configuration tree. Thiss is shown in Figure 79. Layered peer-to-peer communication (section 7.4.3.4)) crosses hardware boundaries. The figure also shows the internal struc-turee of the equipment maintenance subsystem. The equipment maintenance sub-systemm of the CC mirrors its controlling hardware configuration. The same holds forr the equipment maintenance of the PGC. The figure shows PUs which have lines,, e.g. network interface cards and subscriber cards.

A.33 The SW Architectur e of the CC

Thee BBM is applied in the S W design for the central controller (CC) of the tss systems.. The peripheral SW is designed using compile-time modules only. This sectionn describes the application of the different methodical steps of the BBM.


09 9 s s SI I 9 9

"a a TO TO TO TO

7 7 I I

-a a TO TO TO TO

n n

K K 3 3 TO' TO' O O

5' ' 3 3

= o 33 o o»» 3 && 3 err 3 err o' GG g

$$ 3

88 § OO g) PII a" 33 V5

<< *< OO ft ft t 3 3

0 0 I II 0 111 3 11 5 III —

99'' 1

3 -- i f tt 1

33 1

O O Mll S

3 3

~'~' I I

m m 2 2

-o o C C

TJ J

c c

13 3 f t t - t t

T J J 3 " " f t t -1 1 03 3

C C 3 3

'" "

TJ J

O O

- 0 0 f t t

T J J 3 --f t t

O O O O C C

T J J

O O O O 3 3

er r 0 0

n n O O

o o 3 3 £* *

3 3 0 0 0 0 3 3

0 0

n n -t -t

4 4 o o

n n 0 0

er r 0 0

"~ ~

m m 0 0 3" " r t t H H 0) )

1 1 RpCD D

a a P P

3 3

- i i

m m

r r 2 2

-o o O O O O

c/3 3 J J


A.3.11 Object Design

Thee SW architecture of the CC is based on object modelling of the application domain,, of the peripheral units (PU) and of the hardware of the CC (figure 80). Layerss are used for identification of objects. The layers serve the purpose of real-izingg stability in the object structure. Layers of managed objects of the applica-tionn domain (SM + LM) are built on top of a layer of managed objects reflecting thee hardware.

ecu u Software e

FigureFigure 80: Mapping of Objects to Layers

Thee object model is on the one hand used as a basis for the design of the BBs, on thee other hand it is used to determine configuration data (see section A.4.3). Instancess of objects are kept in instance tables that can be viewed and updated fromm the system management interface. For a more systematic introduction of objectt design see chapter 4.

A.3.22 Functionality of the CC Subsystems

Thee CC software is structured into four layered subsystems and consists of the followingg functionality:

Thee extended operating system (EOS) contains amongst others the run time kernel,, timer services, exception handling, the data base, recovery mecha-nisms,, the BB binary administration, the message transfer service to and from thee peripheral areas, file handling and memory management of the central controller. .


Thee equipment maintenance (EM) subsystem consists of the control layer for thee switching matrix, the peripheral hardware and its interconnection struc-turee which is controlled by the central hardware. It handles aspects of e.g data distribution,, recovery of peripheral software and fault handling of the periph-erall hard ware.Together with the extended operating system it forms the dis-tributedd operating infrastructure that constitutes the basis for the applications.

Thee logical resource management (LRM) subsystem provides a management layerr of logical resources for the higher-level subsystem. Logical resources cann be roughly divided into two classes. The first consists of abstractions of hardwaree objects and constitutes the basis on which the application process-ingg is performed. The second class has to do with non-hardware-related logi-call objects, for example data for signalling, logical lines, and facility data.

Thee service-management subsystem comprises all the services of the applica-tion,, that is, it handles calls, call signalling and call facilities such as call for-wardingg and automatic call distribution.

A.3.33 Aspect Design

Thee actual or operational functionality of a telecommunications system is usu-allyy only a small part of the total functionality (ca. 20%). Other parts of the func-tionalityy deal with e.g. service of the system, or with fault handling. Aspects are thosee functionality which crosscuts (almost) all (hardware and domain) objects. Thee functionality of the product family is also structured according to aspects. Forr a more systematic introduction of aspects see chapter 5.

A.3.3.11 tss SW Aspects

Wee shall give the list of SW aspects of the tss system [Bau95]. These aspects are eitherr designed to meet the requirements or a consequence of the system archi-tecturee (see section 10.1.1 and section A.2):

systemsystem management interfacing

Thee system management interfacing aspect concerns the system's external control.. This may be a man-machine interface including formatted input and outputt or a message-based interface.

Thee system management interfacing aspect is a consequence of the require-mentss that most of the objects need to present specifically formatted informa-tionn via the system management interface and accept input from it.

recovery recovery

Thee tss Product Family 205

Thee recovery aspect relates to the system's proper initialisation. A recovery is initiatedd by either an operator or the error handling aspect.

Thee recovery aspect wil l be present in most product families; recovery is complexx enough to factor functionality out into a recovery aspect.

configurationconfiguration control

Thee configuration control aspect relates to the impact of changes in the phys-icall (hardware) and/or logical configuration. Changes may be induced by fail-uress or reconfigurations via system management.

Thee configuration control aspect constitutes the software implementation of thee configuration management system aspect (see section 5.2.2).

datadata replication

Thee data replication aspect relates to the replication of data across processor boundaries.. Configuration data from the central controller (controlling equip-ment)) are replicated whenever a peripheral device (controlled equipment) requiress a local copy of part of the configuration data.

Thee data replication aspect is an example of a software aspect which is a con-sequencee of the distributed system architecture.

testtest handling

Thee test handling aspect comprises built-in functions that either run periodi-callyy or are invoked following specific events in order to detect and identify internall or external hardware faults or corrupted data. Test functions do not generatee a resulting event unless to indicate a fault.

Thee test handling aspect is a consequence of the fact that generic test func-tions,, which could be localised somewhere in the system, are not sufficient. Manyy of the objects require their own test functions.

errorerror handling

Thee error handling aspect is accessed when a failure occurs. The functions concernedd take the appropriate actions following a failure. In particular this includess damage confinement and fault localisation.

Thee error handling aspect constitutes the software implementation of the fault managementt system aspect (see section 5.2.2).

diagnostics diagnostics


Functionss of the diagnostics aspect are invoked by

testt handling, as part of preventive maintenance, in order to detect hidden faults, ,

errorr handling in order to localise hardware faults,

configurationn control in order to verify the repair or correct re-configura-tionn of physical or logical objects.

Thee diagnosis aspect is a consequence of the fact that generic diagnostic functions,, which could be localised somewhere in the system, are not suffi-cient.. Many of the objects require their own diagnostic functions.

performanceperformance observation

Thee performance observation aspect relates to the collection and processing off data for statistics and quality measurement purposes.

Thee performance observation aspect constitutes the software part of the per-formancee management system aspect (see section 5.2.2).

debugging debugging

Thee debugging aspect covers the functions required to interactively debug the on-linee software in test-floor operation as well as field operation.

Thee debugging aspect is a consequence of the fact that generic debugging supportt which could be localised somewhere in the system is not sufficient. Manyy objects must provide their own functionality for debugging.

overloadoverload control

Thee overload control aspect implements the functionality to prevent the sys-temm from malfunctioning in overload conditions. If in a situation external requestss are exceeding system capabilities, the system will internally still be withinn the margins of the specified quality of service.

Thee overload control aspect is a consequence of the fact that different objects needd to take different measures to defend themselves from exceeding requests. .

operational operational

Thee operational aspect has a specific character. It represents the system's functionall behaviour, i.e. in the case of a switching system the ability to han-dlee calls.


Thee tss software aspects make reference to the system management functional areass (see section 5.2.2). However, the areas accounting management and secu-rityy management are not regarded as aspects. The reason is that accounting man-agementt and security management can be localised in functional packages. Accountingg management is implemented as a set of BBs in the logical resource managementt layer and security management is implemented generically via loginn procedures and user profiles in the operation and maintenance terminals.

A.3.3.22 The System Quality Reliabilit y in tss

Thee implementation of the system quality reliability in tss is given (see appendix A.2.2)) to illustrate a more complex mapping of a system quality. Reliability is realisedd in the following ways:

nott in software:

thee central processor is duplicated with one of them operating in cold stand-byy mode;

thee switching matrix executes in triple modular redundancy with majority voting, ,

thee following holds for the three classes of peripheral cards, subscriber cards,, trunk cards and service cards:

specificc service cards are configured in load sharing or hot stand-by for dynamicallyy allocated resources,

redundancyy of trunk cards is handled by the network of switching sys-temss which has alternative routes configured in case one fails.

subscriberr cards are not redundant

inn software:

byy the system management interfacing software aspect: changes in the cardd configuration, states of card and logical objects and parameters thereoff made by the operator occur either completely or not at all (transac-tionss and roll-back),

byy the configuration control software aspect: persistence of the configura-tionn is realised in a database,

byy the error handling software aspect: fault management concepts are implementedd for card faults to maintain the system in a consistent state.


A.3.3.33 The tss State Model

Wee present the tss state model as an example of functionality of a software aspect.. It is the core part of the configuration control aspect, which is used for managingg physical and logical resources. The state model is small and distin-guishess between persistent and dynamic states. Persistent states survive system crashess by being handled by the system configuration database. Dynamic states aree reset after a crash. All managed objects in the system controller implement thiss state model.

Thee state model consists of three states taken from the ITU standard [X731]: thee administrative state, the operational state and the usage state.

Thee operational state reflects the actual state of a real resource, for instance a hardwaree board. The usage state applies to a resource which is used by other resources.. The operational and usage states have dynamic values since they reflectt the dynamic state of equipment or other resources. The administrative statee reflects actions of the operator and has, therefore, persistent values. The threee states have the following values (figure 81):

administrativee state: not managed, locked, unlocked, broken

Thee actual names used by tss are: not installed, out of service, in service and error, respectively. .

operationall state: disabled, enabled

usagee state: idle, active, busy

Thee administrative state values have the following meaning:

Thee value not managed means that a data item representing a physical device iss present in the system controller data base, but no action is taken to connect itt to the actual equipment.

Thee value locked means that the equipment should be completely prepared to startt its operation and already supervise for errors. Operation, however, may nott be started.

Thee value unlocked means that the equipment starts its operation or is in operation. .

Thee value broken means that an error in the equipment cannot be corrected by thee system itself. Without intervention of the operator the system does not do anythingg with the failed equipment.


administrativeadministrative state:

not t managed d

i i

movee to nott managed ^

broken n

operationaloperational state:

movee to not mar

movee to locked

movee to not mgd̂

\ o # ^ ^ ^

movee to unlocked

fatall error

disabled d

crash h ïaged d

. . auto o reco o

1 1

enabled d

matic c very y

locked d disabledd -> enabled

movee to locked d

movee to unlockec c

unlocked d disabledd -> enabled

idle/active/busy y

usageusage state:

/ /

/ /

active e

idle e y y

\ \ * *

busy y

FigureFigure 81: tss State Model

Connectingg operational state with administrative state is straightforward. If a devicee has the value locked or unlocked in the administrative state, the system wil ll automatically try to bring the device to the operational state enabled via an automaticc recovery. A crash wil l bring the device in the operational state disa-bled,bled, an operator command move to not managed will also bring the device to thee operational state disabled.

Thee values not managed and broken of the administrative state are extensions too the standard for allowing good coupling of administrative and operational states.. The operational state always has the value disabled if the administrative statee has either the value not managed or broken.

Thee usage state shows whether a resource is idle or in use. The active value meanss that a resource is partially used, while the busy state indicates full use. A resourcee which does not provide for multiple usage does not have an active value.. The transitions are made by allocating and releasing resources. As shown inn figure 81, the usage state only has meaning when a system is unlocked.

2100 The tss Product Fam i 1y

A.3.3.44 The tss Recovery Model

Wee shall now describe the tss recovery model as a further example. It is the core off the recovery aspect. The recovery model describes the standardised part of the recoveryy aspect.

AA simple recovery model distinguishes only between a recovery phase and an operationall phase. During recovery, equipment is started and configuration parameterss are initialised with values from a configuration database. Operation startss when the whole system is initialised.

Thee tss recovery model is an extension of this simple model. It is based on twoo concepts: recovery levels and recovery phases. The intention is to make operationall actions very efficient and perform initialisation and preparation actionss during recovery only.

Recoveryy Levels

Recoveryy of the central processor is realised according to a specific recovery level.. Recovery levels define the actions taken to bring the system (back) into operation.. There are two types of recovery levels:

System-initiatedSystem-initiated recovery levels are recovery levels which are set by the sys-temm itself to perform a recovery. They comprise the recovery levels: restart withoutwithout persistent data reload, restart with persistent data reload and reload. System-initiatedd recovery levels are initiated after a recoverable error has beenn detected in the system.

Operator-initiatedOperator-initiated recovery levels are recovery levels set by an operator. Theyy comprise the recovery levels new version load, new version load with newnew DB scheme and initial load.

Thee following recovery levels are defined in terms of the affected classes of data: dynamicc data, persistent data or binaries.

RestartRestart (or restart without persistent data reload): Thiss is the weakest recovery level. The operational work is stopped and dynamicc data are re-initialised. Then the application processes are started and operationall work resumes.

ReconstructionReconstruction (or restart with persistent data reload): Inn the reconstruction recovery level, the persistent data are reconstructed. Thiss is done by loading the data base tables from persistent back-up memory too the in-memory database and re-executing the logged data base transac-


tions.. Then, dynamic data are initialised, application processes are started and operationall work resumes.

Reload: Reload: Hardd data (BB binaries) are restored from the system disk and the actions of thee reconstruction recovery level are executed.

NewNew version load: AA new version of BB binaries is loaded from the system disk, and the actions off the reconstruction recovery level are executed.

NewNew version load with new DB scheme: Thee back-up database is updated with the logged database transactions. A neww version of BB binaries is loaded from the system disk, dynamic data are initialisedd and persistent data from the previous version are transformed into thee new data base scheme. Then the actions of the reconstruction recovery levell are executed.

InitialInitial load: Thee binaries are loaded from the floppy disk, dynamic and persistent data are initialised.. A minimum set of persistent data necessary for the system to be ablee to run consistently, is provided. Journalling files are created. This recov-eryy level is intended to be executed only once in a system's life time because itt initialises all data including journalling files.

Recoveryy Phases

Thee recovery levels are implemented by a number of recovery phases. Each recoveryy level is an ordered selection from the set of all the recovery phases. The phasess have been standardised for all the BBs. Each BB can provide methods for eachh recovery phase. The recovery phases constitute the second step in a series off three recovery steps:

Thee first step is the loading of a BB executable into memory. This step is per-formedd only if necessary for the recovery level.

Thee second step is based on the loaded BBs. Each BB provides a set of initial-isationn methods for the recovery phases. Each phase has its own semantics, whichh the recovery methods may not violate (see below). These methods are executedd in the predefined order of recovery phases (see below). The actions off the recovery phases comprise all the recovery actions of the BBs.


Thee last step is the starting of the application processes. This step is imple-mentedd as the last recovery phase and starts the running of the system, i.e. it is aa transition from recovery to operation.

Thee recovery methods of a BB must ensure that a proper recovery is performed forr each recovery level. The recovery phases are ordered in a specific sequence. Duringg system recovery the recovery methods of one recovery phase are exe-cutedd for all the BBs before the recovery methods of the next phase are executed. Itt is important to note that a recovery method of a specific BB may rely on the initialisationn of another BB, which therefore must be done in an earlier phase.

Thee tss recovery model allows a BB to be loaded incrementally, but the recovery phasess are executed for all BBs. Extending the recovery model to allow new applica-tionss to be loaded while the system is running requires a different strategy. The recov-eryy phases would be executed per BB, except the last phase, i.e. the starting of the applicationn processes. BBs may in their initialisation methods rely on the fact that recoveryy methods of BBs of lower layers have been executed. After all the BBs have beenn initialised, the application processes are started. To be able to extend a running systemm it must be cared for that no process enters the code of an initialising BB beforee initialisation is finished. It is more difficult to reduce a running system becausee all resources held by the respective BBs have to be freed and there may be noo running processes inside these BBs, nor may other BBs depend on them.

Thee execution sequence of initialisation methods in one recovery phase is arbi-trary.. Each recovery method is executed only once during a recovery. The mean-ingss of the different recovery phases are as follows:

PostPost Load Bind phase (PLB): Bindingg of references (linking) between BB binaries during recovery.

TeRminateTeRminate Bind phase (TRB): TRBB is inverse to the PLB phase; it is used for unbinding and is intended for thee unloading of single BBs while the system is operational.

Thee term binding is used for registration of call-back methods during recovery (see section 7.2.4) )

InitialisationInitialisation of dynamic data (DatO): Thiss phase is equivalent to the data initialisation realised by the runtime sys-temm usually generated by the compiler. The tss system did not rely on this fea-turee of the compiler.

Datl: Datl: Initialisationn of persistent data to non-existent in the sense of database man-agement. .


recoveryrecovery levels newnew new ver. . . . ,

reconst-reconst- , , , , initial mnemonicmnemonic restart . reload version loadw. ,

ructionruction , __ load loadload new DB

e e X X

e e c c u u t t i i o o n n

o o r r d d e e r r

TRB TRB

PLB PLB

DatO DatO

Datl Datl

Dat2 Dat2

NewDB NewDB

DBRec DBRec

ILD ILD

Dat3 Dat3

PP roc Act

FigureFigure 82: Recovery Phase Hierarchy

Thiss is necessary for the proper functioning of the DB handler's persistent dataa reconstruction mechanism.

Dat2: Dat2: Initialisationn of dynamic data similar to DatO, but to be used if expression evaluationn requires values generated during the execution of DatO and/or Datl. .

NewNew DB scheme (NewDB): Thee functions of this phase are executed in a new version load with a new DB scheme.. Examples are new tables filled with default values. DB transforma-


tionss from an old database scheme to the new one are executed. BBs with filesfiles perform possible fil e transformations.

ReconstructionReconstruction of the data base (DBRec): Tabless of the in-memory database of BBs are reconstructed.

InitialInitial Load phase (ILD): Thee functions of this phase are executed only in an initial load. An example is thee creation of journalling files. Another action is the construction of a mini-mall version of the database in memory. An initial load deletes all history informationn and therefore all actions which have to be performed only once aree to be executed in the initial load phase.

Dat3: Dat3: Initialisationn of dynamic data similar to Dat2. To be used if expression evalu-ationn requires persistent data values generated during DBRec or ILD execu-tion.. Examples are transformations of tables for fast access.

ProcessProcess Activation phase (ProcAct): Thiss is the last recovery phase. After the execution of this phase the system is recovered. .

Figuree 82 shows the recovery phases executed per recovery level.

A.3.44 Concurrency Design

Concurrencyy design maps the functionality of a system to processes and threads too allow for parallel execution and timeliness. This section describes the concur-rencyy design of the tss systems. For a more systematic treatment see section 6.2.

Thee concurrency design of tss differentiates between thread types (called process)) and thread instances and is guided by the following principles:

autonomouss external behaviour is represented by a thread internally, e.g. each operatorr session and each call has its own thread instance;

eachh communication channel arriving at a hardware unit is handled by one threadd instance;

taskss which have different priorities are represented by thread types for each priority; ;

setss of tasks that require fixed amounts of time and should not be delayed becausee of processor contention are implemented on different real or virtual processors. .


Thesee principles lead to few thread types and relatively large numbers of process instances.. Programming of process synchronisation is limited while the dynamic behaviourr profits from the number of independent working process instances. Designn of the process types can be carried out as if working in a single instance environment. .

Onee very important fact is the independence of object design and concur-rencyy design. The designer is free to carry out the concurrency design without consequencess the other dimensions.

Thee guidelines for the concurrency design as given above actually are an extension to thee MO view of the world (see section 10.2.1): MOs reflect static physical or logical entitiess of the real world (with types and instances). The processes as implicitly definedd above reflect dynamic entities of the real world (human beings like operators orr speaking subscribers or microprocessors communicating via message channels) alsoo with types and instances.

Thee system infrastructure generic Process Management (see section 7.5.4) deals withh processes. Any Building Block containing threads is a specific of Process Management.. Process Management supports the concept of a virtual processor [LM97]] called thread category in tss.

AA thread category realises a virtual processor with a certain percentage of processor time.. A thread category has priorities. Two important attributes of a thread are its cat-egoryy and its priority. There are four different thread categories. A main category, an MMII category, a debugging category and a background category. Almost all threads aree allocated to the main category. Threads for system management interfacing are allocatedd to the MMI category, the debugging threads are allocated to the debugging categoryy and a background thread might be allocated to the background category. All categoriess are configured to receive 10% of the real processor time, except the main categoryy which receives 70%. In the case of underflow, i.e. no ready to execute threadd in a category, the processor time is given to the main category. System man-agementt interfacing threads and debugging thread execute with predictable perform-ancee independent of system load. A background thread which needs to make progress evenn in a maximum load situation is allocated to the background category, all other backgroundd threads are allocated to the main category.

Basically,, there are the following mechanisms applied in the tss system to ensure dataa consistency for concurrent data accesses:

criticall regions for real-time critical accesses, and

transactionss for data base modifications


Thee concurrency design of the entire application functionality (Equipment Main-tenance,, Logical Resource Management, and Service Management) is based on onee address space and comprises six process types.

tsss service management performs call processing. A single thread instance receivess the call-initiating messages from the peripheral cards. A call thread iss started to handle a new call. The call threadd type has instances for the max-imumm number of parallel calls allowed in a system, e.g. several thousands.

tsss equipment management and logical resource management perform control processingg in two thread types. They go along aspects and cross many objects.. A fault handler covers the operational, recovery and fault manage-mentt aspects, while a configuration handler covers configuration control and dataa replication. A separate thread instance is used for each equipment instancee at the peripheral bus.

AA further thread type covers the system management interfacing aspect of all threee layers. It is instantiated per user instance.

Thee entire incoming and outgoing communication is handled via one central BBB that handles the bus connection. A singleton thread type covers the incomingg direction, while for the outgoing direction functions are provided whichh run under the budget of the sending process. The incoming messages aree distributed from this single process to the process representing equipment instances.. It polls an incoming message buffer and thus determines the speed off the internal processing. The respective BB is part of the extended operating system. .

A.3.55 Buildin g Block Design

Buildingg Blocks are software components (see chapter 7). This section explains BBss of tss from a technical point of view. For a more systematic treatment see chapterr 7.

BBss usually follow the object dimension, that is, a BB is a cluster of objects. However,, this is no restriction. A BB can follow the other dimensions as well, or evenn encapsulate arbitrary parts of the three design dimensions. The main crite-riaa are configurability and incremental integration, as wil l be outlined in this sec-tion. .

AA BB is a unit of design and deployment. It consists of provides and requires interfacess (see section 7.2). The dependency relation between BBs is uni-direc-tionall (see section 7.4). To allow communication from the lower BB to the


higherhigher BB, the higher BB registers call-back methods with the lower BB (see sectionn 7.2.4). Uni-directional layering is used as a basis for incremental inte-gratabilityy and incremental testability of the system. Each BB is designed such thatt contains sufficient behaviour to be tested independently. Furthermore, genericc functionality of the product family is separated from specific functional-ityy of particular products and embodied in generic and specific BBs, that is, com-ponentt frameworks and plug-in components (see section 7.5).

A.3.5.11 The tss Component Model

Thee component model of the tss system comprises the component identity of BBss and the way in which interfaces of a BB are accessed.

BBB Access

Inter-BBB calling of tss always uses just one indirection. In the case of the call of thee service interface the indirection is in a BB descriptor (see below). For call-backss the indirection takes place via a procedure variable (see below).

Thee tss component model works without a system registry. A BB has a descriptionn of all other BBs to access. References to BBs which may vary for differentt installations are always handled by a generic BB (see below). Refer-encess to exported procedures in the BB descriptor are linked statically. The pro-videss interfaces of used BBs are also known. The only place where knowledge aboutt the entire BB configuration is present is the configuration file of the BB loader.. The BB loader is responsible for loading the BBs from disk into the memory. .

Interfacess are not separate units, they are part of BBs. Interfaces which are independentt of BBs may be described at the design level but not at the imple-mentationn level.

Thee tss BB Identit y

Thee BB identity used within the tss system is closely linked to the memory addressingg scheme. The central processor uses a 32 bit addressing scheme. The resultingg virtual memory address space of 4 GB is translated by the MMU to the physicall memory. BBs are statically located in the virtual address space. Each BBB is given a unique number during design to enable its identification. This BB numberr is mapped to a fixed memory location in the virtual address space. The linkerr uses the BB number to resolve all BB internal addresses. The loader pro-gramss the MMU before it transfers a BB from the disk into the RAM.


Thee 32 bits of an address are interpreted as follows (see figure 83):

100 bits for the BB number

44 bits for the BB relative sections

188 bits for the relative segments.

0 0 9 9 1 1 0 0

1 1 3 3

1 1 4 4

3 3 1 1

^^ J \ ; <s ?

BBB section segment

FigureFigure 83: tss Addressing Scheme

AA tss system can consequently handle a maximum of 1024 BBs. Since a typical productt family had less than 1024 BBs, the BB number was assigned to the entiree product family. The address space of 22 bits per BB was also sufficient. If necessary,, a more dynamic scheme could have been used to allow a maximum of 10244 BBs per product. The sections are used for different types of data, such as thee BB descriptor (see below), code, persistent data or dynamic data.

Thee Provides Interface

AA BB is accessed from other BBs through its provides interface, which is describedd in the BB descriptor. The BB descriptor contains a table of exported proceduress of a BB (figure 84). The BB descriptor is generated during linking andd is placed in a specific section of a BB. If the interface of a BB does not change,, or is conservatively extended, a using BB will be left unchanged. A new implementationn of a BB wil l be loaded without recompiling the using BB. Many off the errors in a deployed system requiring a SW update can be handled via this mechanism.. If the order of procedures in the descriptor or parameters of proce-duress change, the using BBs wil l have to be updated.

Proceduree calls from outside BBs are indirected via the BB descriptor (Figure 84).. A calling BB is compiled and linked to the descriptor of the called BB. The actuall address of the called procedure is determined at runtime. (This is compa-rablee to a C++ virtual table call.) Each exported procedure is given a number. Besidess the signatures of the exported procedures, the export specification of a BBB contains their assigned numbers. To be able to optimise BB internal code, the compilerr needs to know whether a call is a local call or a call to another BB. Tablee 7 shows the translation scheme for both situations.


BBB descriptor section

"get_data" "

"sett data"

"registeruser" "

codee section

^^ pet Hata

" ** set_data....

FigureFigure 84: Service Interface of a BB descriptor

sourcee code

assemblerr code

BBB internal procedureprocedure call

getdataa (...);

"movee parameters to stack"; ;

jsrr get_data;

BBB external proceduree call

getdataa (...);

"movee parameters to stack"; ; movee getdata A jsrr A;

TableTable 7: Procedure Call Translation Scheme

Up-Calls s

BBss are restricted to have only unidirectional relations. A BB importing a pro-videss interface of a second BB is said to reside in a higher layer (see section 7.4). AA call-back is always a call to a procedure in a BB of a higher layer. These pro-ceduress are called up-call procedures and are registered with the lower-layer BB (figuree 85). In the implementation, arrays are used to store procedure references.

Thesee arrays with procedure references are statically allocated in the tss com-ponentt model. This poses two types of restrictions: first, the number of different BBss that can bind themselves to the generic BB is fixed at compile-time, and, secondly,, BBs cannot be used by more than one application (cf. dynamic link library).. This can be avoided by using dynamic data structures to store procedure references. .


higher-layerr BB

SYNunSYNun = 5 unique e user r value e

registered d procedure e

PROCPROC alpha (.....)

ENDEND PROC

PROCxyzPROCxyz (.....)

register_userregister_user ( un, alpha);

ENDEND PROC

Layerr n+m (m > 0)

Layerr n lower-layerr BB

RANGERANGE User_Type =\0 .. 7

PROCPROC register user (st:User_Type, v:v: Procedure _Value )

ENDEND PROC

CB B

, ,

value e range e

registration n procedure e

call-back k table e

FigureFigure 85: Call-back Registration

AA specific registration procedure writes a procedure reference of a using BB too the array. In the example static registration is assumed, that is, a using BB has aa constant value to identify itself with respect to the lower-layer BB. The lower-layerr BB exports the registration procedure as part of its provides interface.


Recoveryy Interface

BBB descriptor sec

rec.. phase TRB

rec.. phase PLB

rec.. phase DatO

rec.. phase...

FigureFigure 86: Recovery Interface of the BB descriptor

AA BB is recovered by the recovery manager, a low-level BB of the extended operatingg system. After loading a BB, the recovery manager wil l activate the ini-tialisationn procedures of the BB. (For the tss recovery model see section A.3.3.4).. Since recovery is the first activity of a BB, the BB cannot register its recoveryy procedures with the recovery manager. The solution chosen is to put the recoveryy procedures in the BB descriptor (figure 86). The recovery manager receivess the BB number of a loaded BB from the loader and accesses the recov-eryy procedures at their pre-defined location. One recovery phase is the bind phasee in which registration procedures are executed to establish a binding betweenn BBs.

AA possible extension of the BB descriptor is to generally support other infra-structuree BBs (so-called SIGs; see below) as well. Most BBs need to register withh them anyway. Call-backs from these infrastructure BBs would rely only on thee BB number and would find the appropriate procedures in the BB descriptor. Thiss reduces the code size of these infrastructure BBs by making the table with call-backk references superfluous.

Implementationn Languages

Thee tss system was programmed using three different programming languages. Mostt of the system was programmed in C. The call processing software was pro-grammedd using the ITU programming language CHILL. Core parts of the extendedd operating system were programmed in Assembler. Compilers for these threee languages were adapted to support the tss component model.

m m codee section


A.3.66 Generics and Specifics

Theree are several types of generic BBs (component frameworks) in the tss sys-temss (see section 7.5.4). Note that to be a generic is a role of a BB. It is perfectly possiblee for a BB to have several (different) generic roles.

A.3.6.11 Abstraction Generics

Ann abstraction generic shields the differences of its specifics by providing a commonn interface towards the users of the generic. In addition, it implements commonn functionality. Figure 87 is a picture of an abstraction generic and its specifics.. A use interface of the generic is used by the specifics to access the commonn functionality provided by the generic.

Specificc S1 Specificc S2

X X requires s A A requires s

use e T T

Specificc S3

JT T requires s

Generic c

FigureFigure 87: Generic and Specifics with Interfaces

Exampless of abstraction generic include file handling, I/O device handling, digit analysis,, call handling, etc. File handling includes the operations open, close, writee and read. Specifics of file handling have specialised handlers for different filefile types such as sequential or indexed files. I/O device handling includes the operationss mount, dismount, assign and de-assign. For the handling of different devicee types such as PCs, printers and disks I/O device handling has separate specific.. Digit analysis has as input digit strings and specifics for different desti-nationn types such as analog or digital subscribers or other switching systems. Calll handling contains the basic call model and is extendable towards different signallingg handlers.


A.3.6.22 System Infrastructur e Generics

SystemSystem infrastructure generics build an operating infrastructure for all Building Blockss in the system, i.e. all Building Blocks are potential specifics of them. Systemm infrastructure generics administer system resources such as processor time,, memory usage and standardise system functionality such as the man-machinee interface (MMI ) supporting generics. Since these generics offer very genericc functionality, they are located low in the system, i.e. they are part of the operatingg system.

Onee characteristic of system infrastructure generics is that their specific func-tionalityy is parametrised by data. Thus all the algorithmic parts reside in the genericss themselves and the specific parameters reside in the specifics. Figure 88 showss a Building Block together with three system infrastructure generics (SIGs).. Despite the fact that the Building Blocks contain the data for a system infrastructuree generic, they access such data through the system infrastructure generic. .

Buildingg Block

use e EZJJ XZ3 use e use e

SIG G SIG G SIG G

FigureFigure 88: System Infrastructure Generics

Onee example is the Exception Handling generic. This generic defines the standardisedd functionality such as possible severity of the exceptions, whereas thee actual severity, output formats and texts for the man-machine interface are locatedd in the specific Building Block.


Usingg a generic to implement such a system function, as e.g. exception han-dlingg is an alternative to a case statement where each case alternative represents aa specific instance of an exception. Maintaining lists of case alternatives for an evolvingg system leads to frequent changes in the source code of the exception handler.. This is a potential source of errors. In contrast to this a generic is not changed.. The list of different exceptions in a specific product is automatically builtt by the configuration of selected Building Blocks in the product.

Thee use of the system infrastructure generic reduces the code of the specific Buildingg Blocks considerably. Furthermore, this standardisation allows code generation.. There is a data definition database (DDD) tool where the specific dataa of the system infrastructure generics are globally administered. Because of theirr relevance of the whole system these data can be easily reviewed and changedd without going into the code of the system. Furthermore, the DDD pro-videss a variety of backend generators supporting the code generation, customer manuall creation and the product configuration processes. Part of the production off a Building Block is the code generation for all relevant system infrastructure generics.. An implementer of a Building Block may not even be aware that some off the system infrastructure generic data of his Building Block is part of the Buildingg Block. (See also section A.4.2)

Exampless of other SIGs are process management to handle threads, memory pooll handling, data base handling for persistent handling of instance data, the messagee transfer system to send and receive messages from the peripheral units, operatorr report handling, recovery handling (section A.3.3.4) and management interfacee string handling

A.3.6.33 Resource Generics

AA resource generic is a generic designed to encapsulate a pattern that models a staticc communication path between Building Blocks. Within the control software itt reflects the existence of a hardware bus, connector or plug. A resource generic (figuree 89) administers the plugs or the slots of the bus. Thus, if a hardware mod-ulee controls a bus and another is plugged into the bus, their controlling software moduless communicate via the resource generic. The Bus Generic in figure 92 is ann example of a resource generic.

AA resource generic guards the supply and allocation schemes of so-called abstractabstract resources, e.g. the bus slots. Physical resources, such as printed circuit boardss and a logical resource, such as a line, are to be distinguished from abstractt resources.


Resourcee Supplier Resource Customer

Resource e Generic c

FigureFigure 89: Connectable Resource Generic and Resource Flow

AA resource generic has two types of specifics, viz. suppliers and customers; seee figure 89. The suppliers supply the (abstract) resources, whereas the custom-erss allocate these resources. The resources are said to flow from the supplier to thee customer via the resource generic. The generic reduces the mutual knowl-edgee of suppliers and customers to that of a resource. Supplier and customer Buildingg Blocks know only their respective interfaces of the generic. Note that theree is a bidirectional communication flow between suppliers and customers, mediatedd through the resource generic.

Thee resource generic standardises parts of the supplier interface and parts of thee customer interface. Additionally it provides an internal resource administra-tion.. Besides this standardisation, each resource generic provides abstract inter-facess for sending information from the supplier to the customer and vice versa. Thee resource generic does not actually deal with the information sent through the connection.. An example is a configuration data change in a customer Building Blockk (see example in section A.3.8). Such a change has to be communicated to thee controlled hardware component. The information goes from the customer via thee resource generic to the supplier. The supplier sends it via a communication pathh to its controlled equipment, which then in turn sends it via the physical con-nectionn to the controlled equipment of the customer.

Alsoo in the other direction the resource generic mediates information. Sup-posee that the supplier receives the information that its controlled equipment is


nott available for operation any more. Then it has to inform the customers that theirr equipment cannot be reached any more either. Thus makes it possible that controllingg Building Blocks are not informed separately about failures via mes-sages.. Instead, one message is enough to signal the failure of a whole subtree. Notee that this kind of communication direction is always a reversed one concern-ingg the actual hardware and the mirrored software structure.

Sincee hardware buses and other plugs are quite common in the structuring of hardware,, the standardisation of software handling in the form of resource gener-icss is an example of a domain-specific design pattern [GHJ*94].

Thee UPS Generic is a resource generic which handles the slots of the univer-sall peripheral slot bus (UPS) (figure 92). The TS Generic is a resource generic whichh administers the timeslots of the peripheral module channel (PMC) (see figuree 76 on page 198). The PMC Handling is implemented as a usual generic nott making use pattern of a resource generic out of historic reasons. The CGR Genericc is a resource generic dynamically administering pools of timeslots of the PMCC statically allocated with the TS Generic. The PG Feature Generic adminis-teredd call handling resources for PUs. Call handling applications could supply resourcess which PU administration BBs could allocate. The resources were then sendd by the PU administration BBs to the PUs.


A.3.6.44 Layer Access Generic

specificc generic I service and binding Buildingg Block <-- - ^ Building Block I relationships

C77 ^ Layer Access Generic

FigureFigure 90: Layer Access Generics

Thee interfaces of the conceptual layers, i.e. the subsystems, consist of interfaces off the generics only; these layer access generics enhance the configurability withinn layers. All kinds of generics may act as layer interface generics. Changes withinn one layer that do not affect these generics keep the layer interface stable. Layerr access generics are brokers for the subsystem functionality.

Thee interface between the equipment maintenance (EM) subsystem and the higherr layer subsystems is build by the CCT Generic offering the allocation cir-cuitss of the PU to the line administration BBs, the TS Generic offering PMC timeslotss to connect the circuits of the PU to the switching matrix, the CGR Genericc offering pools of timeslots in case the timeslot allocation is to be deter-minedd dynamically and the PG Feature Generic allowing the supply of call han-dlingg resources for PUs.


A.3.77 Self-Describing Components

Al ll resource usage of a Building Block is defined by the Building Block itself, e.g.. the use of processes, memory, etc. Resources are administered by system infrastructuree generics of which a Building Block must be a specific if it needs thee resources. Installing a new Building Block (or removing one) claims (frees) resources.. A BB is self-describing.

Ass an example, the Process Management generic administers all processes of thee system. A process is defined locally in a Building Block. The Process Man-agementt starts and handles the processes according to data such as category, pri-ority,, dispatch time or dynamic stack size, which is determined in the Building Blockk itself.

Considerr the addition of some Building Block to the system. No recompila-tion,, re-linking or reloading of the Process Management is necessary. Instead, thee Building Blocks defines its own processes and makes them known to the Processs Management via the bind (registration) mechanism described above. Afterr adding the Building Block, the system wil l have an adapted list of proc-esses. .

Theree are thus no separate configuration files or global include files in the system.. Instead, a BB which owns specific data registers it. Therefore, a BB reg-isterss itself with all relevant system infrastructure generic and with some of the otherr generic to be coupled to its direct operational context.

Thee only exception to the rule of having no global files is that there is a load sett fil e that lists for a particular product all Building Blocks that have to be loaded. .

A.3.88 EM Layer Structure

Ass an example of applying the architectural concepts we describe the main struc-turee of the equipment maintenance (EM) conceptual layer.

Controll Structure

Inn this section we describe the concepts for dealing with hardware configura-tions.. To be able to have a flexible hardware system, backplane bus systems are usedd throughout tss. The absence of closed communication loops (only star-type busess and tree-type hardware dependencies are used) reduces the overall system complexity.. The central controller (CC) controls the complete system. This leads too a tree-type hardware dependency graph. Leaves of the graph are the peripheral


unitss (PU). Intermediate processing units are the Peripheral Group Controllers (PGCs);; see figure 91. The products of the tss family have either 30 or 122 peripherall groups, many of them being PGCs. Such intermediate processing unitss are responsible for the monitoring of their subordinate hardware boards. Thee tree structure defines the controlling - controlled equipment relationship wheree peripheral group controllers have the double role of being controlled equipmentt and controlling equipment at the same time.

Theree are exceptional cases within a tss system which violate the pure tree structure andd make it a directed graph, that is, equipment may be controlled by more than one controller.. Therefore, the term control hierarchy is used instead of 'control tree'. In thesee exceptional cases cables may connect two otherwise independent PUs. The log-icall connection between these PUs is visible as part of both PUs. This connection has too be administered by the controlling equipment. Explicit knowledge of the status of thee connections is available in each piece of controlling equipment that oversees both endd points, upwards in the control hierarchy.

Ass a consequence of the control structure the CC forms a processing bottleneck off the systems. Allocation of functionality takes this fact into account and all processingg which has no coordinating character is allocated to the periphery.

controllingg equipment

controlledd equipment controllingg equipment

controlledd equipment

FigureFigure 91: Tree-Type Control Structure

EMM Structurin g

Ann important point in the equipment maintenance is the structure of the control softwaree in the controlling equipment. Changes within a component low down in thee control hierarchy have consequences for the control software of components higherr up in the control hierarchy. When a card type is added or removed, the correspondingg control software must be adapted to the new situation, e.g. by just

UJUJ CPU J (PU J T P U J


peripherall HW

PUa a

UPS S

PUa a PUb b

PGC C

PUb b PUC C

Centrall Control I Jnit

Buildingg Blocks

PGC C

PUa a PUb b

__ \ ^

PU-Generic c

UPS-Generic c

PUC C

FigureFigure 92: System Structure with HW Mirroring in EM

addingg or removing Building Blocks. The configuration-to-minimum condition off the control software means that the control software contains only the soft-waree that is needed for the controlled hardware. This is supported by the concept, thatt the hardware topology is mirrored in software, see figure 92. Control soft-waree modules have the same interconnection structure as their controlled hard-waree counterparts. Each hardware module type, viz. PGC, PUa, PUb and PUC, is representedd by one or more Building Blocks. Each level of hardware modules in thee control hierarchy is represented by a generic control Building Block and a specificc control Building Block for each hardware module type. For the situation off figure 92 there is a generic control Building Block, PU-Generic and corre-spondingg specifics PUa, PUb and PUc. The PU-Generic, contains the standard-isedd hardware handling, the specific control modules contain the specific deltas. Furthermore,, each hardware bus is represented by a corresponding generic, the Bus-Generic.. Instances of hardware modules are represented by data instances in


thee instance tables of the corresponding Building Blocks. In particular, both PUa andd PUb have two instances for the corresponding boards, and PUc only one. In additionaddition the PU-Generic has 5 entries for the same peripheral boards.

Whenn a new hardware board is added, the software running on the board is addedd to the system as well. The remainder of the system has to be adapted to the neww situation. This adaptation can be executed by adding a new control Building Blockk for the new hardware board within the controlling software. The config-urabilityy of the hardware thus imposes a corresponding requirement on the con-figurabilityfigurability of the software.

A.3.99 The Use of Heuristics Withi n tss

Inn this section we give some comments about the application of the BBM heuris-ticss in the tss product line.

Listt of Heuristics

Heuristicss of Object Design

HeuristicHeuristic 1: Use application domain objects and relationsrelations to generate an initial object model of the productproduct family by mirroring them in the software sys-tem. tem.

HeuristicHeuristic 2: Remove objects, attributes and rela-tionstions which do not describe required system function-ality. ality.

HeuristicHeuristic 3: Adapt the functionality of domain-inducedinduced objects to the required perspective of the sys-tem. tem.

HeuristicHeuristic 4: Create one object per replaceable HW unit. unit.

HeuristicHeuristic 5: Refactor domain-induced objects to objectsobjects of an application layer and an infrastructure layer. layer.

tsss Application Comment

Thee tss project did not do explicit domainn modelling, however func-tionalityy of SM and LRM mirrors applicationn domain objects.

seee above

seee above

Thiss is the object structure of EM and,, consequently, the BB structure off EM.

Thee separate subsystem SM and LRMM result from the application of thiss heuristic.

TableTable 8: Application of Heuristics in tss


Listt of Heuristics

HeuristicHeuristic 6: Re/actor large collections of applica-tiontion objects to objects of a basic application layer and anan advanced application layer.

HeuristicHeuristic 7: Design objects which will be imple-mentedmented by an operating system layer independent from anan additional middleware layer.

HeuristicHeuristic 8: Design messages which are sent betweenbetween threads and processes in separate objects.

HeuristicHeuristic 9: Design objects which hold message objectsobjects such as mailboxes, buffers, queues as separate objects. objects.

HeuristicHeuristic 10: Design protocol implementations as objects. objects.

HeuristicHeuristic 11: Group interfaces of several domain-inducedinduced objects to one interface abstraction.

HeuristicHeuristic 12: Limit the visibility of attributes and operationsoperations of domain-induced objects behind interface objects. objects.

HeuristicHeuristic 13: Model registration functionality as a separateseparate design object.

HeuristicHeuristic 14: Use container objects for explicitly handlinghandling instances of a class in lists and queues.

HeuristicHeuristic 15: Use separate objects to model aspects withwith large amount of functionality.

Heuristicss of Aspect Design

HeuristicHeuristic 16: Take the complete functionality as the firstfirst aspect called operational aspect.


Thee SM subsystem is substructure*! intoo basic call handling and into calll facilities.

Genericc functionality is factored outt into EOS.

Donee as part of concurrency design. .

Eachh thread had one or more mes-sagee buffers.

Calll signallings are separated into theirr own BB, local variants even furtherr separated into a generic BB andd specifics.

Interfacess of different PU handling BBss are abstracted and access via a genericc interface.

Donee via interfaces of generic BBs.

AA circuit (CCT) is an example of suchh an extra object.

Noo 00 programming is used, lists aree handled per BB.

Noo OO programming is used, often onee file per aspect is used.

Nott used, useful for new projects.



Listt of Heuristics

HeuristicHeuristic 17: Look for common behaviour of domain-induceddomain-induced objects. Allocate similar cross-cutting behaviourbehaviour to one aspect.

HeuristicHeuristic 18: Use lists of architectural concerns fromfrom design of similar systems for analysing the requiredrequired functionality for the identification of aspects.

HeuristicHeuristic 19: Use lists of aspects from other sys-temstems as starter sets for aspect identification.

HeuristicHeuristic 20: Select only those aspects which are relevantrelevant for the complete product family as SW aspects. aspects.

HeuristicHeuristic 21: Support identified product-specific crosscuttingcrosscutting functionality through the design of a genericgeneric BB during composability design.

HeuristicHeuristic 22: Limit the number of different design conceptsconcepts per aspect to increase conceptual integrity.

HeuristicHeuristic 23: Weigh the smaller number of aspects withwith potentially different designs against a larger numbernumber of small aspects with a unique design.

HeuristicHeuristic 24: Introduce a standard structuring for BBsBBs by letting all aspects be present in each BB, even ifif some of the aspects are empty in a particular BB.

HeuristicHeuristic 25: Use the list of aspects for checking completenesscompleteness during review sessions. Structure large reviewreview team by allocating aspects to specific review-ers. ers.

HeuristicHeuristic 26: Make a separate chapter per aspect inin the BB documents.


Performancee observation is the lat-estt aspect. It developed from divers implementationn of similar function-alityy into a separate aspect.

Nott used in tss, next heuristic used instead. .

tsss started with the list of aspects of thee PRXD switching family.

Nott used in tss.

Nott used in tss.

Continuouss discussions among architects,, e.g. the state model (sec-tionn A.3.3.3) is applied also to logi-call entities.

tsss avoids a long list of aspects, e.g. errorr handling used different design conceptss for different parts of the system. .

Inn tss used for documentation and codee of aBB.

Practisedd for reviews.

Suchh chapters are called page groupp which could be independ-entlyy released.



Listt of Heuristics

HeuristicHeuristic 27: Structure the implementation of a BB accordingaccording to aspects.

Heuristicss of Concurrency Design

HeuristicHeuristic 28: Use address spaces as failure con-tainmenttainment units. Recovery from failure is realised within anan address space.

HeuristicHeuristic 29: Use address spaces to design for deployability.deployability. The freedom to relocate functionality to differentdifferent processors depends on the absence of com-monmon data between address spaces.

HeuristicHeuristic 30: Consider the use of a thread on the architecturalarchitectural level.

HeuristicHeuristic 31: An overview of all threads should be givengiven in a global concurrency design.

HeuristicHeuristic 32: Mirror independent behaviour of applicationapplication domain objects by separate logical threads. threads.

HeuristicHeuristic 33: Use a separate thread to handle an externalexternal connection or external messages.

HeuristicHeuristic 34: Cluster all functionality which is acti-vatedvated via object interaction by the external connection oror messages into the thread.

HeuristicHeuristic 35: Use a separate thread for the interac-tiontion of a user with the system.

HeuristicHeuristic 36: Represent the receiving direction of anan external channel or bus by its own thread.

HeuristicHeuristic 37: Message sending over an external channelchannel is done on the budget of the sending thread


Supportedd by using separate files perr aspect.

tsss uses a single address space, MMUU used for protection and of dataa classes (dynamic/persistent/ hard)) (recovery pre data class).

tsss BBs are not relocatable, repeat-abilityy towards external PCs was underr discussion for functionality off the system management interfac-ingg aspect.

Performancee problems and the necessityy for refactoring in tss let to thiss insight.

Noo document, only in the head of architects. .

Firstt design step in tss, e.g. call facilitiess are designed as configura-blee state machines without sepa-ratee threads.

Donee by the BB MTS of the EOS.

Onee call of a subscriber is handled byy one thread instance, no change off thread during one interaction.

Thee system management interfac-ingg aspect has a separate thread.

AA thread instance per external con-nectionn is used for PG handling.

Done,, MTS had a thread interface forr the receiving direction and a procedurall interface for the sending direction. .



Listt of Heuristics

HeuristicHeuristic 38: Refine the design of a separate thread perper bus to have thread instances per connected equip-mentment instance to the bus.

HeuristicHeuristic 39: Let internal consistency have priority overover external reaction.

HeuristicHeuristic 40: Give operational tasks priority over backgroundbackground tasks.

HeuristicHeuristic 41: Use separate thread per different pri-

ority. ority.

HeuristicHeuristic 42: Use a separate thread per cluster of objectsobjects with given priority.

HeuristicHeuristic 43: Split logical threads up into physical threadsthreads per address space.

Heuristicss of Composability Design

HeuristicHeuristic 44: Cluster objects into BBs such that couplingcoupling of objects across BB borders is low and cohe-sionsion of objects within a BB is high.

HeuristicHeuristic 45: Cluster objects into a BB which rep-resentresent a feature.

HeuristicHeuristic 46: Cluster objects into different BBs whichwhich belong to independently evolvable parts.

HeuristicHeuristic 47: Cluster objects into BBs such that a BBBB can be used as a work allocation units for I or 2 persons. persons.

HeuristicHeuristic 48: If the variation point lies inside a BB, refactorrefactor the BB such that the variation point lies at the borderborder of a BB.

HeuristicHeuristic 49: Factor out functionality which is presentpresent in several BBs in a separate BB.


Threadd instances used per PU instance. .

Errorr handling and recovery run underr the highest priority.

Backgroundd tasks have lowest pri-ority. .

Oftenn priorities are assigned per aspect. .

AA good analysis is important for achievingg good system perform-ance. .

Noo separation into logical and physicall thread used since address spacess are not used.

Onee of the first heuristics to use.

Configurabilityy was always an importantt design criterion.

Separatee BBs for 2K and 8K switches. .

Suchh a need leads to the search for aa stable interface and the precise roless of the BBs.

Thiss often lead to the design of a genericc BB, new features often inducee such refactorings.

Refactoringg which is not really nec-essaryy lead to difficult discussions withh project leaders.



Listt of Heuristics

HeuristicHeuristic 50: Take as main criterion stability under evolution,evolution, that is, an interface should be such that it cancan serve for those implementations and those usages whichwhich are likely to happen.

HeuristicHeuristic 51: Factor generic implementation parts whichwhich are used by several specific parts into a generic BB. BB.

HeuristicHeuristic 52: Take the implementation of common aspectaspect functionality as a candidate for a SIG.

HeuristicHeuristic 53: Resolve mutual dependence between BBBB A and BB B in the follow way: if A is expected to be moremore stable than B, then make B depend on A; and vicevice versa if the communication between A and B is expectedexpected to be the most stable part, factor the commu-nicationnication out into a new BB and let both, A and B, dependdepend on it.

HeuristicHeuristic 54: In the case of embedded systems, use importingimporting of interfaces at compile time if needed for performanceperformance reasons. Otherwise use dynamic explora-tiontion of interfaces for more flexibility.

HeuristicHeuristic 55: Structure interfaces according to aspects. aspects.

HeuristicHeuristic 56: Use layering for BBs on two levels. Subsystems,Subsystems, which are collections of BBs, are layered. TheseThese layers are based on the classification of layers ofof domain objects done during object design.

HeuristicHeuristic 57: Individual BBs within subsystems are alsoalso layered in relation to other BBs.

HeuristicHeuristic 58: A common principle for the layering ofof software is to separate hardware-technology-ori-entedented functionality from application-oriented function-ality. ality.


Stabilityy considerations are very important. .

Modularityy of new functionality evolvess via such refactoring.

NewNew SIG were not easily added sincee they were part of the EOS and hadd specific support tools.

Thee stability criteria is very impor-tantt but not always easy to deter-minee in practice.

Onlyy compile time importing is used. .

Usedd in documentation and code of aBB. .

Onee of the most important heuris-ticss to achieve an incremental sys-temm structure.

Complementss previous heuristic. Is oftenn used together with heuristic 53. .

Veryy basic in the electronics indus-try. .



Listt of Heuristics

HeuristicHeuristic 59: Construct layers as virtual machines

forfor higher layers.

HeuristicHeuristic 60: Another way of introducing layers is toto distinguish between generic and specific functional-ity. ity.

HeuristicHeuristic 61: The usage of transparent layers is favourablefavourable to the usage of opaque ones.

HeuristicHeuristic 62: Opacity is used for layers that func-tiontion as facades, such as abstraction layers for hard-ware,ware, operating system or middleware.

HeuristicHeuristic 63: Use layers to structure communica-

tiontion in a system.

HeuristicHeuristic 64: Separate common functionality from

specificspecific functionality.

HeuristicHeuristic 65: Look for the diverse parts in similar functionalityfunctionality for different features.

HeuristicHeuristic 66: Use inversion of control for designing

thethe functionality of a generic BBs.

HeuristicHeuristic 67: A generic BB is stable if new specific functionalitiesfunctionalities may be based on the generic BB with-outout changing it.

HeuristicHeuristic 68: Use an abstraction generic to imple-mentment an abstract concept which is to be extended by specificspecific BBs.

HeuristicHeuristic 69: Use a connectable resource generic toto manage connectable resources which are supplied byby HW boards.

HeuristicHeuristic 70: Design a system infrastructure genericgeneric for functionality which provides an operating infrastructureinfrastructure for almost all application BBs.


Itt is important to think about how one'ss own interface is used by oth-ers. .

Basicc rule for layering in tss.

Mostlyy used throughout tss.

Onlyy used for the EOS.

Donee in tss; leads to incremental andd understandable system struc-ture. .

Thiss is a basic tss structuring prin-ciple. .

Oftenn more important than commo-nalityy analysis.

Basicc principle for component frameworks. .

Thee best results are achieved with PUU handling.

Exampless range from call handling, PUU handling to file handling.

Usedd for almost all external con-nectionss except for MMI-PCs for historicc reasons.

Establishess a 'domain infrastruc-ture'. .



Listt of Heuristics

HeuristicHeuristic 71: System Infrastructure Generics must provideprovide interfaces for application BBs for indicating theirtheir resource requirements.

HeuristicHeuristic 72: Design a layer access generic to restrictrestrict the visibility of the structure of a layer for higherhigher layers.

HeuristicHeuristic 73: Apart from a BB itself, the collection ofof BBs of a white box component can be packaged as unitunit of deployment.

HeuristicHeuristic 74: If two substitutable BBs are to be presentpresent in the same product, the BBM requires that therethere must also be some generic which switches betweenbetween the two.

HeuristicHeuristic 75: Choose generic BBs in such a way thatthat stability of architectural skeleton increases.

HeuristicHeuristic 76: Make a BB is a self-describing com-ponentponent by letting it communicate its characteristics suchsuch as its resource requirements to the infrastructure.

Heuristicss of Deployability Design

HeuristicHeuristic 77: Select a set of objects in such a way thatthat the set may be independently recoverable when an errorerror occurs.

HeuristicHeuristic 78: Align BB-, thread-, fault containment unit-unit- boundaries to HW instances

HeuristicHeuristic 79: Package BBs to deployment sets such thatthat independent selling and evolution remains possi-ble. ble.

Heuristicss of Composability Design

HeuristicHeuristic 80: Use a feature relation graph to describedescribe relations between features.


Supportedd through code generation fromm Data Definition Database.

Donee for access of SM and LRM to EM. .

Forr functional extensions of a tss systemm BBs of a feature are loaded too an installed system.

Oftenn generic BBs implement func-tionalityy to select a specific BB to whichh to communicate.

Iss achievable only over time, the harvestt of good system design.

Supportedd by Data Definition Data-basee in tss.

tsss has a simple recovery model wheree only PU can recover inde-pendently,, recovery of the CC done perr data class, requires complete systemm recovery of that data class.

Nott used since tss BB are designed forr the CC only.

Partiall delivery in tss done per set off BBs implementing features.

AA feature DB contains these rela-tions. .



Listt of Heuristics

HeuristicHeuristic 81: Design a system infrastructure genericgeneric to handle data-driven diversity.

HeuristicHeuristic 82: A desirable non-conservative exten-sionsion is the refactoring of a BB to a generic BB.

HeuristicHeuristic 83: A good family architecture is one whosewhose BB structure resembles the feature structure, i.e. aa good family architecture is feature-oriented.

Additionall Heuristics of the Specialised

HeuristicHeuristic 84: A managed object may consist of an objectobject in the CC and an object in the peripheral hard-ware. ware.

HeuristicHeuristic 85: Hardware objects and hardware abstractionsabstractions of the CC will often be part of the OS.

HeuristicHeuristic 86: Maintenance replacable units (MRU) areare good candidates for hardware managing objects.

HeuristicHeuristic 87: Represent MRUs, which only together realiserealise a specific function in the system, by one hard-wareware managing object.

HeuristicHeuristic 88: For the specialised BBM, we will alwaysalways have the two layers in the central controller, namelynamely application and equipment management.

HeuristicHeuristic 89: When interface abstractions between thethe two layers have themselves state and behaviour createcreate a new layer for these abstractions. They are thenthen to be modelled as managed objects in their own rightright and be represented as an intermediate layer.

HeuristicHeuristic 90: A further division may be appropriate ifif additional abstractions are introduced to abstract fromfrom the distribution of the controller over several sites.sites. The application functionality then runs on top of thethe multi-site abstractions.


Functionalityy of some aspects of somee BBs 'implemented' via 'deploymentt descriptors' only.

'Neverr change a running system' is nott always a good principle.

Goodd results in SM, LRM and EM.

BBM M

Mostt MOs of EM and LRM are splitt in that way.

Standardd rule for separating EOS andd LRM functionality.

Donee for almost all plugable HW.

Shelvee extension cards and the PG cardd to which they are connected aree represented by one managing object. .

Thee specialised BBM is applied in tss. .

Holdss partly for LRM.

Nott used in tss, because tss systems aree mostly single site. Remote PUs forr rural areas are handled as other PUs;; modelling in some cases too simplistic. .



Listt of Heuristics

HeuristicHeuristic 91: A different division of layers may be appropriateappropriate if application functionality extends signifi-cantly.cantly. An application-specific platform encapsulates applicationapplication infrastructure abstractions. Various advancedadvanced applications may run on this platform.

HeuristicHeuristic 92: Infrastructure functionality such as basicbasic services which should be used by all the objects implementedimplemented on the system controller are modelled in thethe lowest layer.

HeuristicHeuristic 93: An important set of managed objects andand their respective BBs concerns the handling of the PUs.PUs. The BBs in the EM layer will reflect the connec-tiontion structure of the PU.

HeuristicHeuristic 94: The system management interfacing aspectaspect consists of the functionality to communicate withwith a system management system and with the opera-tors. tors.

HeuristicHeuristic 95: The recovery aspect consists of func-tionalitytionality for system initialisation and automatic recov-ery. ery.

HeuristicHeuristic 96: The data replication aspect is a con-sequencesequence of the distributed architecture. It consists of functionalityfunctionality to replicate data within a managed object,object, that is, the control and management data of the controlcontrol object is sent to the real resource object, and changeschanges in the real resource object are propagated to thethe control object.

HeuristicHeuristic 97: The configuration management aspectaspect establishes configuration parameters according toto a system database or operator actions.

HeuristicHeuristic 98: The fault management aspect super-visesvises the system configuration and takes decisions on requiredrequired actions in case of failure or other abnormali-ties. ties.


AA basic call handling layer is startedd but not completely worked out. .

Sincee tss developed its own operat-ingg system, these services are made partt of it.

Thiss established the BB structure of thee EM layer without generic BBs.

Thee operator can not only interact withh the application but can config-uree and tune the complete system.

tsss did not separate initialisation andd recovery in separate aspects becausee the large overlap of con-cepts. .

Basicc principle of telecom systems; importantt for structuring internal communicationn in such systems.

Basicc aspect; DB used throughout thee system, state model implemen-tationss per generic of functional area. .

Basicc aspect; uniform implementa-tionn only for error reporting part; errorss of the CC and of the PUs are handledd differently.



Listt of Heuristics

HeuristicHeuristic 99: The performance management aspect hashas the task to monitor and register the quality of the systemsystem configuration. If certain quality thresholds are exceededexceeded fault management is informed.

HeuristicHeuristic 100: A quite typical design is to separate controlcontrol functionality from processing functionality. ProcessingProcessing is allocated to the periphery, while control isis allocated to the CC.

Heuristicss of Organisational and

HeuristicHeuristic 101: Develop a first product that can be usedused as a basis for the product family.

HeuristicHeuristic 102: Define and detail the architecture in suchsuch a way that BBs can be developed according to a simplesimple waterfall model.

HeuristicHeuristic 103: The architecture document describesdescribes the architectural models such as the BB dependencydependency model, aspect designs, concurrency designdesign and deployability design. The architecture doc-umentument should be structured in a way which minimises thethe impact of changes.

HeuristicHeuristic 104: The BB documentation consists of at leastleast three documents: its specification document, its designdesign document and its code document.

HeuristicHeuristic 105: Consider a deviation of the BB developmentdevelopment process from the simple waterfall a qual-ityity problem of the architectural process.

HeuristicHeuristic 106: Proceed with the process oj'integra-

tiontion by extending a stable set of BBs with one or a few

BBs. BBs.


Thee latest aspect of tss. Is not nicelyy implemented throughout the system. .

AA heuristic which determined the overalll system architecture of tss.

Processs Issues

Donee for the tss product family, otherr projects had it to learn the hardhard way.

Importantt quality criteria for archi-tects. .

Thiss was not achieved. There existedd always a set of more or less importantt documents. Concur-rencyy design did not have a sepa-ratee document independent from BBs. .

Donee for all BBs. The specification documentt also covered MO-related peripherall SW.

Forr BBs with completely new func-tionalityy architects sometimes had too work out sample designs.

Veryy important for short integration times. .



A.44 Makin g Products From BBs

tsss products are configured according to the product feature list. The elements of aa product are

thee mechanical shelves together with backplane buses and power supplies,

thee peripheral HW units with the according SW modules,

thee switching matrix modules,

thee operation and maintenance terminals and

thee central processor HW boards with a set of BBs.

Thee selected BBs of a product have to be consistent, that is, they all need to be of aa compatible version.

Inn this section we describe concepts and ways of working for configuring, instantiatingg and evolving tss products. They are not considered part of the core BBM,, however each practical application of the BBM needs to address the issuess of configuration, instantiation and versioning.

A.4.11 Construction Set

Thee use of SW components introduces great flexibilit y into product develop-ment.. Each BB may be independently released and has own version number. Fromm a management point of view concepts and a way of working are needed to effectivelyy use this flexibility .

Thee tss development used the concept of a construction set. A construction sett is the set of BB versions which are compatible and may be used to configure aa product. Several products may be build from the same construction set. In an ideall world where each BB is ideal there would be only one construction set for thee complete product family.

Thee presence of several versions of a BB in a construction set is possible. The situationn where new BBs needed for a new product is handled by extending the constructionn set with these new BBs. If a set of existing BBs needs to be adapted threee options are possible:


createe a new construction set with same versions for the unchanged BBs and thee new versions for the adapted ones. This is done if major changes are nec-essaryy such as restructuring BBs to introduce a generic BB its specifics;

makee the adapted BBs variants with a new identity and add them to the con-structionn set. This is done if new features are to be added;

alloww different versions of the same BB in the same construction set. This donee for minor changes

Thee last option requires to keep additionally the specific version of a BB in a product.. Methods for ensuring compatibility between BBs such as testing have too take the selected option into account.

A.4.22 Product Tailorin g and Evolution

Often,, in order to yield a product from the construction set of compatible BBs adaptationss and modifications are required. In order to determine the required activitiess an initial product configuration step can be performed on the existing basee of developed BBs. The result of these steps will lead to

neww BBs to be developed

adaptationss to existing BBs to be made (figure 93).

FigureFigure 93: Evolving the Construction Set

Thee goal is to minimise the number of BB versions. An extended BB should be (upwards)) compatible with the previous version of that BB, to the extent possi-ble.. The construction set is extended in a compatible way. This again makes it


possiblee to generate the new product by performing another (ideal) product con-figurationfiguration step (see figure 94).

existingg construction set of BBs

initiall product configuration: :

thee lab determines list of BBs accordingg to features

T T relevantt BBs for the product identified

runn project: the lab performs adaptations of existingg BBs and creation of neww BBs

extendedd construction set of BBs

t t

ideall product configuration: :

T T neww product

selectt BBs accordingg to features

FigureFigure 94: Development Steps to Extend the Construction Set

AA BB remains an entity, not only during design and implementation, but also duringg all phases of development. In particular, it is also an entity of documenta-tion.. In fact, as a product is configured out of the parts list of BBs, the documen-tationn is configured as well. Different forms of documentation are supported throughh document generators of the DDD. In figure 95 an overview of the DDD iss given.

Besidess the code generators to support the creation of operator interfacing code,, generators for office data and for manuals also have been developed. All thee documentation is consistent with the system implementation by generation


Itemss related withh EOS Generics:

Commands Commands Tables Tables Reports Reports Formats Formats Strings Strings ModesModesDynamicDynamic Sets Processes Processes Pools Pools ProgramProgram Exceptions PrematurePremature Data

Data a Definition n Dataa Base

D D D D

Commands s

Generator r

MMIPC C

VV J Guidance e Tablee Headers

Officee Data

dataa to be dd by

TOSS and code

('C'' and Assembler suppliedd per Buildingg Block)

Generator--Backends s

Manuals s

FigureFigure 95: Overview of the DDD

fromfrom a single source. The DDD tool thus supports data consistency between dif-ferentt departments.


A.4.33 Product and Site Configuration

Inn the above sections we described the concept of a construction set and how the tailoringg of a product leads to evolution of BBs and construction sets. In this sec-tionn we take a closer look how a specific instance of a product is build.

Productt Configuration

AA product is configured by using the construction set of BBs and the correspond-ingg data definition database (DDD) contents. In order to identify the list of requiredd BBs, that is the parts-list of the product, the following procedure is applied. .

Selectt the number of features required for the product. Use the feature dependencyy model to select also dependent features. Then, use the feature imple-mentationn relation to the select the relevant BBs. Again, the BB dependencies mayy lead to additional BBs.

Applyingg this procedure implicitly results in the subset of binaries required forr the product. One of the goals of configuring a product is to keep the number off BBs on a minimum. The Software Factory, which is responsible for customer products,, determines the BB binary configuration. The project data are docu-mentedd in a 'Project Manual'. Among others, this manual contains the parts list of BBss and project dependent resources like stored announcements and tones.


Thee basis for configuring a specific product instance is the set of BBs and the correspondingg soft data held by the DDD. The steps to be performed in order to yieldd product and site configurations roughly is as follows:

construction n sett of BBs

product product configuration: configuration:

site site configuration: configuration:

\ \ selectt the partss list of BBs

\ \ generatee site data for thee list of BBs generatee start-up file

\ \

installed d product t

/ / onon site: loadd BB binaries,

start-upp file, sitee data files

executee start-up file

/ /

configured d product t instance e

FigureFigure 96: Process Steps for Configuring a Product Instance

Sitee Configuration

BBB binary configuration determines the set of tables contained in a product but nott their contents (table entries). The contents of tables and data files (e.g. stored announcements)) are site dependent and therefore are termed site data (see figure 97).. As well as project administration, site administration is up to the software factoryy (see figure 97). The process of defining site data is termed soft data con-figuration.figuration. Site configurations are documented in so-called site data manual.


Lab b Softwaree Factory

Constructionn Set Project t Site e

Partss Lists: Building g Blocks, , Tables, , Documents s

Sitee Data: Entriess for all Tabless contained inn list of Tables

/ /

- sites

sites s

Data a Base e Tables s

Buildingg Blocks

Hard d Data a

Soft t Data a

Customer r

Documentation n h/ww + s/w Description 00 & M Manual +

Site e Manuals s

+ +

£ £ § § + +

LI I 0 0 Loadd Set

site-independent t software e + +

site-dependent t software e

FigureFigure 97: Process Overview of Product and Site Configuration


A.55 Experience Data

Inn this section we given several sets of data collected from tss projects. The first dataa set (section A.5.1) describes the products of the tss family and the number off installations. The second data set (section A.5.2) gives typical performance characteristicss of tss product. The third data set (section A.5.3) gives the soft-waree sizes of the complete product family. The fourth data set (section A.5.4) comparess the sizes of two component frameworks (generics) with the sizes of theirr plug-ins. The fifth data set (section A.5.5) looks at the level of reuse achievedd within several products. The last two sections have been taken from a studyy performed by Fleischer and Jager [FJ95].

A.5.11 The tss Products

Thee telecommunication switching system tss is supplied to various markets with aa emphasis on the German market.

Thee tss platform is tailored to the specific needs of special applications. This includess applications like operator-based support systems, service provider net-workk access points, mobile containerised exchanges, base station central control (BCC)) for GSM networks and switching systems for authority networks.

Thee most important projects for the tss switching system are in table 9.


Product t

1 1

2 2

3 3

4 4

5 5

6 6

7 7

8 8

9 9

10 0

11 1

12 2

Applications s

nationall operator-assisted directory service,, automated wake-up service

internationall operator-assisted direc-toryy service

operatorr system for the technical tel-ecomecom service

networkk access point for private servicee providers

mobile,, containerised exchange

operatorr system for inquiry and call completionn service

locall / toll exchange


containerr exchange


basee station central control for GSM

basee station central control for GSM

## Systems

90 0

8 8

153 3

9 9

10 0

1 1

10 0

4 4

2 2

23 3

150 0

570 0

Country y

Germany y

Germany y

Germany y

Germany y

Germany y

Germany y

CIS S

Jordan n

Czech h

PRC C

Germany y

(interna--tional) )

TableTable 9: Products of tss


A.5.22 tss System Performance Data

Somee performance numbers of tss products are given below. A tss product can bee configured for:

upp to 20000 subscriber lines (8 lines per PU) or

upp to 6000 trunk lines (30 lines per PU) (system without subscriber lines)

orr a mixture of the two. There are two variants of the switching matrix:

20488 x 64 kbit/s lines or

80966 x 64 kbit/s lines.

Thiss leads to the maximum of 930 (62x30/2) or 3782 (62x122/2) stable calls, respectively,, at the same time in the system.

Thee system performance:

performance:: 40 calls/sec = 144.000 BHCA (depends on signalling and facil-ities) )

7000 messages/sec (between central processor and switching matrix/peripheral groups) )

Recoveryy times: (depends on image and data base size)

reload:: < 8 minutes

restartt with database load: < 4.5 minutes

restartt < 2 minutes

Thee image size for the CC of a typical project:

1500 building blocks

2,66 MByte code

11 MByte hard data (=strings and other constant values)

1,55 MByte soft data (= configuration data base)

1,55 MByte dynamic data

100 MByte process stacks and dynamic pools


A.5.33 Software Sizes

Thee software sizes of the complete tss product family are:

Centrall Controller

Extendedd Operating System

Equipmentt Maintenance

Logicall Resource Management

Servicee Management

Totall Sum

No.. of BBs

175 5

93 3

123 3

89 9

480 0

No.ofELOCS S (^Effectivee Lines of Code) )

462500 0

207146 6

342157 7

373469 9

1385272 2

TableTable 10: Central Controller Software Sizes

Thee 480 BBs of the CC (table 10) of the tss product family amount to ca. 14MBB of binaries, that is a middle of 30 kB binary per BB.

Group p

Centrall Controller Software

Peripherall Software

Personall Computer Software

Switchingg Network Software

SDEE Tools

Totall Sum

No.. of Building Blockss / Modules

480 0

186 6

111 1

2 2

41 1

820 0

No.. of ELOCS (=Effectivee Lines off Code)

1385272 2

416542 2

177881 1

21700 0

506930 0

22 508 325

TableTable 11: tss Software Sizes

Thee complete SW of the tss product family is given in table 11.


A.5.44 Comparing Generics and Specifics

Thee following comparison is made to compare the relative size a component frameworkframework (generic) has with respect to the complete functionality (framework andd plug-in).

Thee degree of reuse due to the use of abstraction generics with two different exampless is made. To this end the delivered source instructions (DSI) of the abstractionn generic and of each type-dependent package are compared to the sum off both figures. To present fair figures, we have to differentiate between DSIs, thatt implement common characteristics within the abstraction generic, and DSIs, thatt do correspond to generic dedicated services, like for instance binding.

Thee first example stems from the equipment maintenance layer. Common functionalityy for the different types of peripheral cards includes image and data download,, supervision mechanism, error handling, configuration management etc.. In the software architecture we therefore defined an abstraction generic, peripherall group card (PGC) generic, and several specific BBs for the handling off different cards. The following figures illustrate what amount of reuse has been achieved. .

PGCC Generic

totall # DSI

7501 1

commonn code DSI

7148 8

genericc dedicated DSI

353 3

TableTable 12: PGC Generic

Typee Dependent Package e

SAGG maintenance

GCCC maintenance

DTGG maintenance

CGCC maintenance

#DSI I

1515 5

784 4

793 3

482 2

summ of DSI

8663 3

7932 2

7911 1

7630 0

percentage e abstraction n generic c

83 3

90 0

90 0

94 4

percentage e specificc BB

17 7

10 0

10 0

6 6

TableTable 13: PGC Specific BBs

Ass a second example the channel associated signalling administration (CASS A) of the logical resource management layer is chosen. This administration


softwaree takes care about the different channel associated signalling systems for telephonee lines, that are configured for a system, and additionally administers the correspondingg line data.

CASAA Generic

totall # DSI

3912 2

commonn code DSI

3521 1

genericc dedicated DSI

391 1

TableTable 14: CASA Generic

Specificc BB

CAII trunk line admin n

CAOO trunk line admin n

CAIRSUU trunk linee admin

CAORSUU trunk linee admin

#ofDSIs s

1754 4

1277 7

1253 3

1592 2

summ of DSIs

5275 5

4798 8

4774 4

5113 3

percentage e abstraction n generic c

67 7

73 3

74 4

69 9

percentage e specificc BB

33 3

27 7

26 6

31 1

TableTable 15: CASA Specific BBs

Ass can be inferred from the figures above, the degree of reuse in the first examplee is higher than in the second one. This is due to the fact, that the hard-waree architecture determined by the manufacturers is designed for commonality, whereass the signalling system exhibits the variety of application functionality. Throughoutt the tss system, the average reuse per abstraction generic, therefore, liess in between both extremes.

Consideringg all abstraction generics throughout the system and evaluating the amountt of reuse contributed by them yields a reuse of about 25%. I.e. the current codee wil l increase by about 25%, if we dispose of the abstraction generics.

Inn general, 70 of the 480 BBs are generics. 35 component frameworks reside inn the application EM, LRM and SM. The EOS contains 25 component frame-workss and 10 system infrastructure generics.


A.5.55 Inter-Product Reuse

Inn this section the reuse of software of several product development projects is evaluated.. Before the actual figures are presented, a description of the method of evaluationn of reuse is given. Thereafter the products are briefly introduced and theirr differences are discussed.

Ass is normally the case, the available BBs within the construction set do not coverr all features required for a new product. Therefore it is necessary to imple-mentt new BBs for the product. These newly implemented BBs in turn extend the constructionn set of BBs. The extended construction set is available for use at a laterr project. This is illustrated in figure 98.

Neww BBs are also implemented for another reason. As time proceeds, short-comingss in the system software architecture inevitably wil l be detected. In order too improve on them, redesigns of specific BBs wil l have to take place. Rede-signs,, however, are always associated with a new project and never occur for theirr own sake. Again this is sketched in figure 98.

Ass a consequence three categories of BBs contributing to a particular project cann be distinguished:

UnchangedUnchanged BBs: thesee BBs are taken over from the existing construction set without any mod-ification.. They therefore directly contribute to reuse of software.

NewNew BBs: thesee BBs implement new system features. Their functionality has not been availablee before and they therefore do not contribute to reuse of software.

ModifiedModified BBs:

modificationn of BBs can occur due to the following reasons:

changee of the user interface of the BB;

redesignn of the BB due to architectural needs (refactoring).

Inn evaluating software reuse one therefore has to deal with three different catego-riess of BBs. New, modified, and unchanged BBs. For each of these categories, twoo different ratios have been determined as a measure of reuse within the tss products.. The first ratio is the number of BBs in each category to the total numberr of BBs within the project. The second ratio is the added number of sourcee lines per category to the total number of source lines per project.

Thee tss Product Family


Forr the categories of new and unchanged BBs these measures are clearly defined.. An unchanged BB has been reused completely, a new BB corresponds too newly developed software and does not contribute to reuse.

Forr the category of modified BBs the interpretation is not as clear. BBs within thesee categories are partly reused and partly implemented anew. The fraction of reuse,, however, could not be resolved with the available data. Therefore a worst casecase strategy has been adopted. For both measures, modified BBs are assumed nott to contribute to reuse of SW.

Beforee the numbers are given, the projects, that have been evaluated, are shortlyy introduced.

Thee first product represents a digital switching system that serves as a com-binedd local and toll exchange. It supports various signalling systems for trunk andd subscriber lines. Additionally it offers various facilities, as for instance: Incomingg call barring, traffic restriction, fixed destination call, three party services,, abbreviated dialling, access code handling, traffic telephony meas-urements,, call forwarding and others more.

Thee second product represents a container local exchange. It includes a chargingg service and signalling systems that are different from the signalling systemss of the first project. Furthermore it only comprises few of the services listedd with the first project, but offers others in return. E.g. the features "con-centrationn of analogue subscriber lines" and "party lines" are additionally present. .

Thee third product represents a service switch, that provides operator assisted value-addedd services. The implementation of those services includes func-tionss like: automatic call distribution, call waiting, generated announcement off directory numbers, data links, call forwarding, traffic measurement, serv-icee statistics. This system is used by service providers of radio communica-tionn networks and within public networks.

Thee fourth product is a combined digital local and toll exchange similar to the firstfirst project. Additionally it comprises features of an operator assisted value-addedd service switch, corresponding to project 3. Therefore it practically cov-erss the same facilities as were presented for the first and the third project. It differs,, however, in the signalling systems, that are being used.

Tablee 16 presents a short summary of the projects analysed. It gives the number off new features introduced with the project and the total amount of BB and DSIs perr project.


projects s

projectt 1

projectt 2

projectt 3

projectt 4

numberr of new features s

14 4

12 2

34 4

22 2

total l

numberr of BBs

87 7

75 5

99 9

103 3

numberr of DSI

196266 6

189921 1

310184 4

288010 0

TableTable 16: Basic Project Data

unchangedd BBs

BBs s

# #

72 2

63 3

47 7

72 2

% %

82.8 8

84.0 0

47.5 5

69.9 9

neww BBs

BBs s

# #

0 0

6 6

13 3

24 4

% %

0 0

8.0 0

13.1 1

23.3 3

modifiedd BBs

BBs s

# #

15 5

6 6

39 9

7 7

% %

17.2 2

8.0 0

39.4 4

6.8 8

TableTable 17: Number of BBs per Category

unchangedd BBs

DSI I

# #

163945 5

154295 5

74396 6

176567 7

% %

83.5 5

81.2 2

24.0 0

61.3 3

neww BBs

DSI I

# #

0 0

16497 7

22579 9

48696 6

% %

0 0

8.7 7

7.3 3

16.9 9

modifiedd BBs

DSI I

# #

32321 1

19129 9

213209 9

62747 7

% %

16.5 5

10.1 1

68.7 7

21.8 8

TableTable 18: Number o/DSIs


projects s

projectt 1

projectt 2

projectt 3

projectt 4

degreee of reuse

>> 82%

>81% %

>> 24%

>61% %

TableTable 19: Degree of Reuse of Application Software

Thee data shown in table 17 through table 19 result from projects developed from 19911 through 1993. They show that the underlying concepts and principles have ledd to a stable system architecture. With this architecture a parts-list of BBs has beenn realised implying configurability and a high degree of inter-product reusa-bility .. As can be inferred from the tables, the fraction of reused DSIs for a prod-uctt ranges between 60 to 80 percent with one exception that is discussed below.

Att the first project, the high fraction of modified BBs (16.5% of DSI) con-trastss the number of newly developed BBs (0% of DSI). This traces back to the fact,, that the new requirements for this project were accomplished by using BBs off former projects, only. Those BBs, that mainly implement signalling systems, hadd to be adapted to the new requirements and therefore appear as modified BBs inn the statistics.

Thee data from the second and fourth product indicate a stable system archi-tecture,, that necessitates only modest modifications in order to bring in new fea-tures.. The degree of reuse of the application software is high.

Notee that these numbers do not include the operating system software. If this weree the case, the degree of reuse would be higher from the very beginning. The numberr of DSIs for the operating system software, which besides the kernel includess infrastructure elements as for instance database management services, iss about 460,000. This compares to the number of DSIs for the application soft-ware. .

Outstandingg with respect to the figures of reused and modified BBs is the thirdd product. The high fraction of modified BBs (68.7% of DSI) is because a basicc data structure of the system had to extended. This data structure was used byy several BBs.


Furtherr data from the four projects show the same distribution of efforts over thee development phases.

Systemm + Architeci

BB B Specification n

turee De finition n

BB B Design n

BB B Coding g

Productt Delivery i i

System m Testing g

30% % 20% % 10% % 40% %

FigureFigure 99: Empirical Data on the Distribution of Efforts