Chapter 9: Building Your Own Model

The PBX Example

Modelling is an art rather than a science. All that I can give here are a few commercial and technical tips on how to approach it.

In order to make the exercise more concrete, I decided to use a simple device as an example but selecting a suitable device was not easy ”I looked for something for which the DMTF did not already have a model (thereby ruling out almost everything to do with computers or IP routers), something which all readers would readily understand (thereby ruling out the more esoteric telecommunications devices), something that was reasonably complex and provided services (thereby, unfortunately , ruling out my toaster) and something that was sufficiently uncomplicated that the model could be largely complete.

In the end I settled on a small, primitive, and sparsely featured PBX, the telephone switching device used within a company or hotel to route calls between extension telephones and between extensions and outside lines. Figure 9.1 illustrates the main features of the device:

• It can hold up to eight telephone interface cards, each of which provides connectors for eight telephones.

• It can hold up to four trunk interface cards, each of which provides two connections to the public telephone system.

• It contains a microprocessor to control the various switching devices. This microprocessor runs Linux and the Bayonne open source PBX software (see http://www.gnu.org/software/bayonne/) which it loads from a hard disk built onto the processor card.

• It is powered from the AC electricity supply.

Figure 9.1: PBX Interfaces

A knowledge of the PBX's physical elements will also be of importance to the modelling work. I assume that it is shipped as a small shelf into which various cards may be plugged; see Figure 9.2. The power supply unit, processor card, and at least one telephone interface card need to be present to make a working system. Additional telephone interface cards and trunk interface cards can be added as required.

Figure 9.2: PBX Field-Replaceable Units

Telephony statistics are collected by the processor (number of calls made from each telephone, number of incoming calls blocked by busy telephone, number of outgoing calls blocked by insufficient trunks, etc.) and these need to be made available to an operator.

Maintenance Operators are not allowed access to the telephony statistics but are allowed access to information about the operating system (memory usage, time since last reset, disk usage, etc.) and may run tests on all cards.

Tests are additionally run periodically on all the software and hardware in the PBX and alarms are generated if any problems are discovered .

This "specification" covers only a very small part of the definition of a PBX and leaves more questions unanswered than it answers: what are the precise authority levels of each type of user , how are the users to be authenticated, are the cooling fans and other hardware components to be monitored , what alarms arise spontaneously from the system, etc.? I believe that building a model of the components I have defined will give you sufficient confidence to extend the models as needed without extending this book too much with replication.