UvA-DARE is a service provided by the library of the University of Amsterdam (https://dare.uva.nl)
UvA-DARE (Digital Academic Repository)
The building block method. Component-based architectural design for large
software-intensive product families
Müller, J.K.
Publication date
2003
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.
General rights
It 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 regulations
If you believe that digital publication of certain material infringes any of your rights or (privacy) interests, please let the Library know, stating your reasons. In case of a legitimate complaint, the Library will make the material inaccessible and/or remove it from the website. Please Ask the Library: https://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.
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 Introduction
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?? S JgP =JgF
mm m
Telecommunication n Switchingg Systemmm m
Telecommunication n Switchingg System 'trunkk linesX 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 Architecture
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 Hardware 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.
200 0 Thee tss Product Family
Alll 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
A.2.33 Software Architecture
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 Architecture 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.
202 2 Thee tss Product Family 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 311 5
III —
99 '' 1 3 -- i ftt 133 1
O O Mll S 3 3 ~'~' I I m m 2 2 -o o C C T J J c c 1 3 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 -t4 4
o o
n n 0 0 er r 0 0"~ ~
m m 0 0 3 " " rt 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 3J 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. .
204 4 Thee tss Product Family
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.
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 will 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).
206 6 Thee tss Product Family
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 Reliability 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.
208 8 Thee tss Product Family
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 willl automatically try to bring the device to the operational state enabled via an automaticc recovery. A crash will 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.
212 2 Thee tss Product Family
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 Xe 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-214 4 Thee tss Product Family
tionss from an old database scheme to the new one are executed. BBs with filesfiles perform possible file 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
216 6 Thee tss Product Family
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 Building 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 will 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 Identity
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.
218 8 Thee tss Product Family
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 0 0 1 1 3 3 1 1 4 4 1 1 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 will 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 will 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. .
2200 The tss Product Family
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 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 will 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.
222 2 Thee tss Product Family
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 sA A
requires s use eT T
Specificc S3 JT T requires s Generic cFigureFigure 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 Infrastructure 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
E Z JJ XZ3
use e use eSIG 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.
224 4 Thee tss Product Family
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
2266 The tss Product Family
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.
228 8 Thee tss Product Family
A.3.77 Self-Describing Components
Alll 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 will 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 file 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 Structuring
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
230 0 Thee tss Product Family 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 Within 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. sys-tem.
HeuristicHeuristic 2: Remove objects, attributes and rela-tionstions which do not describe required system function-ality. function-ality.
HeuristicHeuristic 3: Adapt the functionality of domain-inducedinduced objects to the required perspective of the sys-tem. sys-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.
