E&CE 355 PBX Project Fall 2003

© 2001-2003 University of Waterloo Electrical and Computer Engineering E&CE 355 – Software Engineering Private Branch Exchange (PBX) Software Project version 3.1

Detailed contents.................................................................................................2
Tables.........................................................................................................................................4

Revisions.............................................................................................................5 Industrial context................................................................................................6
Southern Bell’s “new” PBX.........................................................................................................6 Your software company..............................................................................................................6 Your team’s capability.................................................................................................................6

Requisite skills package (RSP)..........................................................................8
Deliverables................................................................................................................................8 UNIX ® operating system...........................................................................................................9 Phantom Dialer (PhD) programming exercise..........................................................................10 Supplied materials....................................................................................................................10

Software Requirements Specification (SRS)..................................................12 Software Design Description (SDD)................................................ .................33
Deliverables..............................................................................................................................33 SDD outline...............................................................................................................................33

Implementation.................................................................................................. 36 Acceptance testing............................................................................................37

ECE 355 – PBX Project Description 3.1

Detailed contents
Detailed contents.................................................................................................2
Tables.........................................................................................................................................4

Revisions.............................................................................................................5 Industrial context................................................................................................6
Southern Bell’s “new” PBX.........................................................................................................6 Your software company..............................................................................................................6 Your team’s capability.................................................................................................................6

Requisite skills package (RSP)..........................................................................8
Deliverables................................................................................................................................8 Included files (filenames in italics):.............................................................................................................8 changelog.txt.................................................................................................................................................8 Makefile........................................................................................................................................................8 demoNN.jpg (Demo screen).........................................................................................................................9 Ad hoc quiz...................................................................................................................................................9 UNIX ® operating system...........................................................................................................9 Phantom Dialer (PhD) programming exercise..........................................................................10 Supplied materials....................................................................................................................10 PBX hardware emulator.............................................................................................................................10 Customer Acceptance Tests (CAT)...................................................... ...................................................... 11 Automated Customer Acceptance Tester (ACAT).....................................................................................11 Source code.................................................................................................................................................11

Software Requirements Specification (SRS)..................................................12 Introduction........................................................................................................12 Overview.............................................................................................................14
Software Design Description (SDD) outline..............................................................................15 UNIX ® operating system.........................................................................................................15 C/C++ implementation..............................................................................................................15 Business critical........................................................................................................................15

Specific requirements.......................................................................................16
User interfaces..........................................................................................................................16 Hardware interfaces..................................................................................................................17 Software interfaces...................................................................................................................24 Fault detection..........................................................................................................................28 Manual fault detection control...................................................................................................29 Automatic fault detection...........................................................................................................29 Security.....................................................................................................................................31 Maintainability...........................................................................................................................31 Expandability...........................................................................................................................31

Software Design Description (SDD)................................................ .................33
Deliverables..............................................................................................................................33 Cover letter..................................................................................................................................................33

2

ECE 355 – PBX Project Description 3.1

SDD – Software Design Description..........................................................................................................33 SDD outline...............................................................................................................................33 Identification (1 p.).....................................................................................................................................34 Requirements compliance (1~1½ pp.)........................................................................................................34 Design priorities (½ p.)...............................................................................................................................34 Reuse (¼ p.)................................................................................................................................................34 Multiprocessing (1½~2 pp.)........................................................................................................................34 Process behaviour(1 p. per process)............................................................................................................34 Message sequences (2~3 pp.)......................................................................................................................35 Implementation (1 p.)..................................................................................................................................35

Implementation.................................................................................................. 36
Experience report........................................................................................................................................36 CAT test results...........................................................................................................................................36 Demonstration.............................................................................................................................................36 Ad hoc quiz.................................................................................................................................................36

Acceptance testing............................................................................................37

3

...................22 Table 5 – Line Card Equipment (LCE) test suite.....................................................................10 Figure 2 – SDL/GR PBX System diagram........................28 Table 6 – Common Equipment test suite..............................................................................................................16 Table 3 – Switching network control interface sample scenarios........................27 Tables Table 1 – Delivery priorities................................................................ECE 355 – PBX Project Description 3............................................................................................29 Table 8 – Automatic fault detection interval calculation..............1 FIGURES Figure 1 – Phantom Dialer behavioural specification................................................19 Figure 6 – Line Card functional schematic..............16 Table 2 – Call progress tones.............................................................................20 Table 4 – Service shelf slot equipment....23 Figure 9 – PBX SDL SIGNAL’s..............................26 Figure 12 – Call Processing behavioural specification (3 of 3)...........22 Figure 8 – Voice/Signaling Unit software interface....................26 Figure 11 – Call Processing behavioural specification (2 of 3)..............................................30 Table 9 – Anticipated future capabilities.....29 Table 7 – Manual hardware fault detection commands....................................................................................................................31 4 ..............18 Figure 5 – Switching network functional schematic.........................18 Figure 4 – Time-multiplexed digital signal frame and channels....................24 Figure 10 – Call Processing behavioural specification (1 of 3)..............................................17 Figure 3 – Voice/Signaling Unit functional schematic.....................21 Figure 7 – Tester functional schematic.............

1 October 18. 106-1998 SDD Removed requirement to use UML in design Unapproved Norman Young Updated tables of contents Added tables of figures and tables Modified Anticipated future capabilities September 18.1 5 .1 Revisions 2.0 2.2 3.ECE 355 – PBX Project Description 3. 2001 Created based on past project documentation Added Revisions list Refined Phantom Dialer behavioural specification Clarified Time Switches as translationally symmetric Replaced requirement for IEEE Std. proofread Norman Young Norman Young 2. 2001 October 19. including section on expandability. 2003 Mattias Hembruch Updated details.

while balancing your scarce time and resources with your other on-going projects. fixed-price contracts. Winning this contract with SBR will move your company to the next level. historical products into new markets. SBR is looking only for quality products from demonstrably capable professional suppliers. and industry prominence. you have come understand and apply software engineering principles for their inherent value. SBR poses a carefully constructed selection process to find the best contractor that can repeatedly deliver quality software on time and within budget. this project represents your own professional success and your company’s long-term capital value. the research and development arm of a large telecom manufacturer. Your team’s capability However. Their strategy aims to compress the functionality of a cabinet-based. You will demonstrate your team’s undisputed leadership as SBR’s best potential new supplier by successfully completing the following PBX project. SBR is looking for a small software company to design and implement the control software for its new consumer-oriented PBX. Having survived too many years on poorly planned. 6 . with steady royalty-based income.ECE 355 – PBX Project Description 3. unlike Microsoft’s DOS. Consequently. Like Microsoft’s original contract for DOS with IBM. shoebox-sized appliance. aims to revitalize its parent company’s sales by moving some of its traditional. based on another company’s quick and dirty operating system. the small telephone private branch exchange (PBX) has huge potential in the burgeoning small office / home office (SOHO) market. To advance the product’s release by several months. both domestically and overseas. multi-board design into a simple. One such product. Southern Bell’s “new” PBX Southern Bell Research (SBR). Your software company Your project team is that small software company – you just need to prove it to SBR. larger follow-on contracts.1 Industrial context Your project team completes the PBX project in the following (fictional) industrial context.

such as specific due dates and evaluation weightings. Please check our project web site for administrative details.(x) 7 . N3L 1G4 Re: Request to participate in our PBX software supplier selection process (PBX-SSS-P1) Dear Software Designer: We are pleased to inform you that your company has been selected as a candidate supplier for the control software that will drive our new generation of home/office PBX. and a working evaluation platform. while remaining achievable within our limited available time. your company’s staff completes a small programming exercise related to the larger demonstration project. 2003 Southern Bell Research Home Office Division 100 Diamond Bay Drive Barndyer. Jan Rath Director. since the software design represents the greatest risk to our product’s long-term success arising from your potential role as supplier.ECE 355 – PBX Project Description 3. and to select the best possible supplier from our shortlist of candidates. The exercise ensures that you have all the necessary tools in place. and reliability. Sincerely. Ontario. and by following well known industry standards. The tests will evaluate your implementation for functionality. Your complete participation produces three delivarables: Requisite skills package – In the requisite skills package (RSP).1 Request to participate August 30. Implementation – You finally demonstrate your implemented software by executing it on our evaluation platform under manual and automated test conditions. Software design – Your company demonstrates its software design competence by preparing a Software Design Description (SDD) using the latest appropriate design techniques. perfomance. Consequently. K3J E59 Your Company University Business Park Waterloo. we request your participation in the selection process described below. We will pay particular attention to your design for maintainability. such as documentation. We may also evaluate your staff’s knowledge by asking them ad hoc questions about your software design and implementation. Technical Contracts Management Encl. We look forward to working with you and your staff during this important selection process. we are asking your company to reproduce the software functionality of an earlier generation of PBX. please see the enclosed documents describing the project requirements and supplied materials. We believe that there is no better proof of competence than demonstration. Your SDD carries the most weight in our evaluation of the three deliverables. To confirm your suitability as a supplier. Also. This demonstration represents a realistic design challenge from our application area. development tools. Using the existing PBX as a reference system in this selection process also provides us with important auxiliiary resources. Ontario. and that your staff has the basic knowledge to complete the rest of the selection process work.

and since Solaris is the Unix environment readily available. such as RCS (Revision Control System).g.. As evidence of your build automation process.tar (. The log should show an entry for each change made to each file. such that you can readily produce an executable version of the software from any given version of the source code. one or two sentences) of each member’s background and contributory skills The purpose of the attached package. all source code and other project control files MUST be useable from the Solaris environment. from your chosen automation tool. or CVS (Concurrent Version System). Makefile You must automate your software build process.txt You must use some version control system to manage your project files. including the Makefile. do NOT use a version-control system that is not installed on the Sunee Unix machines.gz/.1 Requisite skills package (RSP) Deliverables You must submit a Requisite Skills Package (RSP) containing the items listed below by the deadline indicated on the course web page. one-line descriptive summary of the reason for the change).tgz) format.tar. we ask you to submit your project Makefile. or its equivalent. Electronic Submission of these items will be requested . we ask you to submit a change log from this system for your project source files. Included files (filenames in italics): readme. e. and Change synopsis (e.g.. We strongly recommend that you use make to realize this automation.ECE 355 – PBX Project Description 3. As evidence of your version control regimen. 8 .e. Please submit as one archive file in .txt This file must indentify: • • • • • • • Date of submission Your company name Names and id numbers of both staff members assigned to the project Brief synopses (i. Since the target environment for the PBX is Unix. as your company’s submission for PBX-SSS-P1-RSP A list of all the items you attach Any special instructions for executing your Phantom Dialer program changelog. as this makes it easier to download your code. including • • • • Date Revision number Programmer id.details to follow.

Show only difference listings for any changes that you may have made to the supplied source files. 9 .1 C/C++ source code Include listings of all source files for the version of the program used to perform the demonstration. you should never compromise functionality.png. Show full listings for the source files that you created from scratch. Platform-independence is a natural consequence of software designed for maintainability. with the caveat that your work remains source-compatible with Solaris™ (possibly as controlled through Makefile directives or environment variables). Describe each screen capture in readme.ECE 355 – PBX Project Description 3. but please choose a COMMON file format (.html). such as GNU/Linux™3. in the United States and other countries. etc). Sun and Solaris are trademarks or registered trademarks of Sun Microsystems. . UNIX ® operating system Your control software must execute under the UNIX ® operating system or one of its variants1. your results could be easily ported across multiple platforms. 1 2 UNIX is a registered trademark of The Open Group (http://www. and possibly also request a live demonstration of your working program.txt. you may develop and execute your software on non-reference platforms.jpg (Demo screen) Include screen captures showing the state of the PBX hardware emulator during program execution. We define the Solaris™ operating system on Sun™ workstations2 as the reference platform. Include one screen image for each of the SDL states shown in the attached specification. in case you later need to demonstrate your results on the reference platform. but simply a means to confirm your staff’s knowledge of the submitted material. However. reliability. Specifically. including at least one screen image with a non-ringing phone off hook. but our technical staff will only help you to use these alternative platforms as their individual knowledge and resources happen to allow at the time.unix-systems. Ideally. or timely delivery for the sake of accommodating non-reference platforms. This ad hoc quiz (which may happen any time after we receive your RSP package) is not a package item in itself. We encourage you to write your software for alternative platforms and tools. 3 Linux is a trademark of Linus Torvalds.gif. performance. Note: JPEG format is NOT required. but at your own risk. Ad hoc quiz Our technical staff may pose you and your staff with questions about your submitted material. and represents a valuable long-term commercial asset. Inc. You may use other operating systems. demoNN.org/trademark.

10 . provides a hardware description of the PBX controlled hardware which might normally appear in a system design document. this SRS provides sufficient details about the Voice/Signaling Unit design to allow for the accurate design of the corresponding control software. in section .ECE 355 – PBX Project Description 3. However. You can use these programs to test your results. and a program to display the current state of the same (diprog).1 Phantom Dialer (PhD) programming exercise In the Phantom Dialer (PhD) programming exercise. as well as a program that allows you to control the emulated hardware (kiprog). Figure 1shows the SDL/GR behavioural specification for the PhD program. in the absence of such a document. The SRS. PROCESS PhantomDialer 1(1) FastBusy Ringing Calculate first line card OnHook Test Relay (Out) Ring Relay (Out) Idle Relay (In) OffHook OffHook OnHook From busy line card? Y Idle Relay (In) Calculate idle line card at random Ring Relay (In) Y Ringing N From ringing line card? Y Ring Relay (Out) N FastBusy Calculate next line card Idle Relay (Out) Done all line cards? N FastBusy Figure 1 – Phantom Dialer behavioural specification Supplied materials PBX hardware emulator We supply a program that emulates the PBX Voice/Signaling hardware in software (heprog). you write a control program that directs an otherwise silent PBX to irritate subscribers with persistent random telephone calls.

Automated Customer Acceptance Tester (ACAT) We supply a program that tests your Call Processing and Maintenance control software under simulated unloaded and loaded conditions (acatprog). you will use the database file of telephone extension numbers supplied with the ACAT.c) and small demonstration call processing program (demo). You are free to use and/or modify this supplied source code for your own purposes. This document will be made available as the project progresses. and the ACAT program itself.1 Customer Acceptance Tests (CAT) The Customer Acceptance Tests (CAT) are defined in a separate supplied document. Source code We supply you with the C source code for a line scan process (line_scan.c).ECE 355 – PBX Project Description 3. 11 . a timer process (timer. You cannot use the ACAT program for the Phantom Dialer program in the RSP. in implementing and testing your final Call Processing and Maintenance control software. However.

implement and test the software specified herein. Fast busy tone – The call progress tone played in a caller’s telephone receiver when the exchange is unable to complete a call. but for reasons not related to subscriber actions.1 Software Requirements Specification (SRS) Introduction Purpose This document is the Software Requirements Specification (SRS) for the control software for the telephone Private Branch Exchange (PBX). thereby closing an associated switch (see switch hook) and allowing the loop current to flow. Caller – The subscriber who initiates a telephone call by closing the switch hook switch on a non-ringing telephone. and is thereby unable to participate in the attempted call. Loop current – The electrical current carried by the tip and ring conductors leading from the line card through a connected telephone. or to acknowledge the first digit dialed of a multi-digit extension number. and Maintenance . Scope This document specifies the software requirements for two main software functions on the PBX: 1. Off hook – The state of a telephone which is either initiating or participating in a telephone call. Idle tone – The call progress tone played in a caller’s telephone receiver (typically silence) when the exchange is either unable to present any other call progress tone. Definitions Busy tone – The call progress tone played in a caller’s telephone receiver when the called telephone is already off hook. usually signified by the telephone’s receiver being off its hook. See also.Plain Old Telephone Service (POTS) for PBX subscribers. Dial tone – The call progress tone played in a caller’s telephone receiver when the exchange is ready to receive the initial dialing action.Automatic and manual fault detection. Call progress tones – The various audible tones played in a caller’s telephone receiver to indicate the relative progress in the stages of completing a call.ECE 355 – PBX Project Description 3. Call processing . See also. Software developers use this document as a reference to design. such as equipment failure. Callee – The subscriber who completes a telephone call by closing the switch hook switch on a ringing telephone. This document does not specify the requirements for ancillary PBX functions. busy tone. Line card – The electrical circuit connecting the tip and ring conductors from a subscriber’s telephone to a telephone exchange. 12 . Call processing – The services provided to subscribers for placing and receiving telephone calls. On hook – The state of a telephone which is not initiating or participating in a telephone call. 2. usually signified by the telephone’s receiver being on its hook. nor does it specify the PBX operator’s capabilities. thereby opening an associated switch (see switch hook) and breaking the loop current. fast busy tone. such as installation or administration.

Booch. behaviour. References Annotated C++ Reference Manual. SDD – Software Design Description SDL – The Specification and Description Language defined by the International Telecommunications Union (IUT) for describing the structure. Electrical and Computer Engineering Department. University of Waterloo. E&CE 355 Course Project Notes on Software Requirements Specifications (version 1.ECE 355 – PBX Project Description 3.00). Electrical and Computer Engineering Department. E&CE 355 Course Project.2).00). University of Waterloo (1998). IEEE Std. end-to-end telephone calls. Stroustrup. Switching network – The component of a telephone exchange that allows for connecting a telephone to another telephone for end-to-end subscriber conversations or other services. derived from the corresponding tip and ring of the plug on an old-style operator’s patch cable. E&CE 455 Software Engineering Course Project Customer Acceptance Tests (version 1. POTS – Plain Old Telephone Service Ring tone – The call progress tone played in a caller’s telephone receiver while a called telephone is ringing. University of Waterloo (1998). Electrical and Computer Engineering Department. Addison-Wesley (1990). Addison-Wesley (1999). The Universal Modeling Language Reference Manual. voice mail. E&CE 355 Course Project 355PBX Hardware Description (version 1. An operator usually has more control over the PBX than an ordinary subscriber. 830-1998. CCITT Blue Book Functional Specification and Description Language (SDL). Rumbaugh. Switch hook – The (historically electromechanical) component of a telephone that detects whether a telephone’s receiver is on hook or off hook. SDL/GR – SDL Graphical Representation SDL/PR – SDL Phrase Representation SRS – Software Requirements Specification Subscriber – An ordinary telephone user who accesses the PBX services through an ordinarytelephone. where a single subscriber initiates a call to another single subscriber by dialing their extension number. Ellis. Jacobson. International Telecommunications Union (1988). IEEE Recommended Practice for Software Requirements Specifications. and design of telecommunications equipment and other systems. PBX – Private Branch Exchange Plain Old Telephone Service (POTS) – A form of call processing that supports only simple. Electrical and Computer Engineering Department. and conference calls. such as the capability to interrupt or terminate other ongoing calls. 13 . POTS excludes advanced services such as call forwarding. University of Waterloo (1998).1 Operator – An advanced telephone user who accesses the PBX services through a sophisticated terminal that includes more functions than a common telephone. Tip & ring – The names for the pair of conductors connecting a telephone to its line card.

ECE 355 – PBX Project Description 3. any PBX control software (PCS) should not rely too greatly on the exact details of the architecture. as described below. which is typically assigned the single-digit extension “0”. The general PBX design favours economy. The PBX control software described in this document supports only the subscriber and maintenance technician classes of users. Maintenance technician: The maintenance technician maintains the PBX’s electrical and mechanical operation. Overview Product perspective The Private Branch Exchange control software controls the PBX voice/signaling hardware. and so the software should be designed to easily accommodate them if necessary. IEEE Std. The PBX considered in this document supports only plain old telephone service among its connected subscribers. Administrator: The administrator configures the PBX with location-specific parameters such as extension number assignments and long-distance access policies. Accordingly. . 830-1998. In a typical field installation. Subscriber: A subscriber places and receives calls through a single ordinary telephone connected to the PBX. however. The supplied ACAT defines a sample extension number assignment file. such as the ability to interrupt an ongoing call. section 2 provides an overview of the PBX control software functions.1 Document overview This document is organized following the IEEE Recommended Practice for Software Requirements Specifications. user characteristics. and section 3 describes the specific requirements for each class of user. User characteristics The PBX has four classifications of users. Operator: The operator is a subscriber with capabilities beyond an ordinary subscriber. 14 . as well as for maintenance personnel to test and maintain the PBX voice/signaling hardware. The maintenance technician performs these tests through the PBX console. It does not support special privileges for an operator or administrator. and design priorities. The administrator performs these functions through the PBX console. on page 36 for a description of the required maintenance tests. in addition to the functions of an ordinary telephone. the roles of operator. The maintenance capabilities of the PBX control software described in this document is limited to initiating manual hardware tests and interpreting the results from manual and automated hardware tests. and ease of operation over feature-richness or sophistication. typically supporting fewer than one hundred subscribers. Product functions The PBX control software provides the control function for allowing telephone subscribers to call each other. and maintenance technician may actually be filled by the same individual. However. administrator. The PBX control software described in this document does not support any operator-specific capabilities. the extension “0” can be assigned to an ordinary subscriber. that these additional functions may be required in future versions. The only administrative function required for the PBX control software described in this document is the extension number assignment. An operator typically accesses these additional capabilities through a specialized terminal that supports these functions directly. The PBX has at most one operator. The PBX itself is a small telephone exchange. reliability. Note. The extension number assignment can be defined statically through a file. nor does it support trunk connections to other exchanges. It is intended for use by small organizations or businesses with members working within close geographic proximity of each other. and a very limited subset of the administrator-related capabilities. See the section. requirements assumptions. but be able to scale up or down (within reason) as necessary.

Consequently. but no official help or support will be offered.ECE 355 – PBX Project Description 3. Inc. with the Solaris™ operating system on Sun™ workstations5 as the reference platform. 4 5 UNIX is a registered trademark of The Open Group (http://www. in the United States and other countries. in the United States and other countries. and its control software by implication. there are no assumptions that are not otherwise represented in specific requirements described elsewhere in this document. Business critical The PBX overall.html). Inc.org/trademark.1 Constraints Software Design Description (SDD) outline The Software Design Description (SDD) prepared for the PBX control software described in this document must follow the outline and guidelines supplied with the project. 15 . Other languages (such as the Java™ programming language6) are permissible. All software must be sourcecompatible with the reference platform. The PBX is not life critical. the design should be reflect appropriate measures in preventing or minimizing the operational financial losses that could ensue from its failure. Sun and Solaris are trademarks or registered trademarks of Sun Microsystems. UNIX ® operating system The PBX control software must execute on the UNIX ® operating system or one of its variants4. is critical to the daily business operations of the company or organization that uses it. Assumptions Since the PBX control software has already been successfully developed and deployed on an identical platform with identical requirements. The project requirements will NOT be changed to allow for easier development using other languages. 6 Java is a trademark or registered trademark of Sun Microsystems. C/C++ implementation The PBX control software should be implemented in the C or C++ programming language.unix-systems.

and the symbols “*” and “#”. The twelve touch-tone keys are labeled with the digits “0” through “9”. The switch hook switch has two positions: on hook and off hook. Call progress tone Idle tone Dial tone Ring tone Busy tone Fast busy tone Presentation Following the first and subsequent digits when dialing multiple digits Following off hook when the PBX is unable to deliver any other call progress tone Following off hook when the PBX ready to connect the call Following the last digit when dialing a telephone extension that is on hook Following the last digit when dialing a telephone extension that is off hook Whenever responding to the caller’s action would exceed the PBX’s available resources Table 2 – Call progress tones 16 . Delivering the Call Processing design and implementation is the top priority. Deliverable Call Processing design Call Processing implementation Call Processing design Call Processing implementation Maintenance design and implementation Maintenance design and implementation Table 1 – Delivery priorities Schedule Early delivery Early delivery Early delivery Priority Imperative Imperative Valuable Valuable Desirable Desirable Specific requirements External interface requirements User interfaces Telephone The telephone is the subscribers’ and operator’s only user interface with the PBX. as it relates to the general requirements and the completion schedule. The ring indicator is typically an audible bell. through which the subscriber listens to the call progress tones and the callee’s voice. Since the PBX control software described is this document does not support an operator. The telephone display transducers comprise a ring indicator and a receiver.ECE 355 – PBX Project Description 3. the following paragraphs are limited to describing an ordinary subscriber’s telephone.1 Apportioning of requirements Table 1shows the relative priority of delivering the PBX control software design and implementation. Table 2 delineates the call progress tones used in the PBX. The call progress tones are sounds produced in the telephone receiver that indicate to the subscriber the relative progress in placing a call. The receiver is a small speaker in the telephone handset. The telephone control transducers comprise the switch hook switch and touch-tone keys. such as a (typically red) coloured lamp. but it might also be accompanied with a visual ring indicator.

(TestVoltage)] [LoopCurrents] Loops VoiceSignalling Unit Status [(LineControl). (TestControl)] Control Control Unit Console 1(2) Figure 2 – SDL/GR PBX System diagram The PBX control software executes on the Control Unit. This document describes only the PBX console since the control software deals only with the console. 17 . 9 Software developers using a general purpose computer as the hardware for the PBX control unit during development can accurately represent the PBX console with a lone terminal. The control software responds to commands from the PBX console and displays results on the same. (SwitchControl). 8 Note that the PBX console is distinct from the keyboard input program (kiprog) and display program (diprog) associated with the hardware emulator that software developers may use when writing the PBX control software. including the Voice/Signaling Unit and the Control Unit in SDL/GR notation. and not these additional maintenance-related user interface elements. such as individual line-card disabling switches or switching network status indicator lamps.7 For the PBX control software described in this document. The Control Unit also controls the Voice/Signaling Unit through the Status and Control SIGNALROUTE’s. the PBX console supports only the maintenance-related hardware tests described in the Maintenace Functional Requirements section on page 28. 7 The maintenance technician may also use controls and displays connected directly to the voice/signaling hardware. The console accepts commands typed on the keyboard. and shows results in text on the display. Figure 3 shows the Voice/Signaling Unit functional schematic. TTRXDigit.1 PBX console The PBX console is the administrator’s only user interface with the PBX and maintenance technician’s primary interface with the PBX. SYSTEM PBX [(SwitchHook). The Voice/Signaling Unit controls connected telephones through their respective loop circuits.9 Hardware interfaces Figure 2 shows the PBX system diagram. represented collectively in Figure 2 as the Loops SIGNALROUTE.8 The PBX console is a computer-like single-user terminal with a QWERTY keyboard and text-based CRT display.ECE 355 – PBX Project Description 3. typically displayed as a single virtual terminal on their computer screen.

Each such digitized signal is called a channel. and the frames constituent 32 channels.000 samples per second (i. The Switching Network supports up to 30 such one-way connections. Frame = 125 sec Channel = 3. . TM1.1 Voice/Signaling Unit Service Shelf [2] TM 2 30 2 1 30 2 1 Loop . Since there are two one-way connections required during the conversation stage of a telephone call.. .. the Switching Network supports up to 15 simultaneous telephone calls. The Switching Network routes timemultiplexed digital signals over the bi-directional TM0. . from the Switching Network’s timemultiplexed digital signal. since it represents the information 18 . Figure 4 shows a single frame.e.000 Hz). Line Interface Shelf [1] TM1 Switching Network .9 sec 0 1 2 3 .. . 29 30 31 Time Figure 4 – Time-multiplexed digital signal frame and channels The time-multiplexed digital signals used in the PBX apply the common technique of representing analog audio signals as digital signals by sampling 8-bits of data at 8. Each shelf contains up to 30 cards. Line Interface Shelf [0] TM0 Ring Bus Test Bus Ring Generator Tester Figure 3 – Voice/Signaling Unit functional schematic The Voice/Signaling Unit centers on the Switching Network. A path from any card to any other card mounted in any of the shelves comprises a one-way connection.ECE 355 – PBX Project Description 3. and TM2 time-multiplexed digital links to the Line Interface and Service shelves. 8 bits of resolution at 8. The Switching Network routes signals among the cards.

30 cards per shelf mapping to the 30 channels used per frame). can appear in zero. The three inbound and three outbound Time Switches are connected to the time-multiplexed digital links from the Line Interface and Service Shelves. Each card on these shelves corresponds to a channel within the frames of the timemultiplexed signals (i. This switching action is controlled through the Voice/Signaling control interface by a value in each of the Time Switch’s interface channel positions. y. The PBX digital circuits are designed to carry a total of 32 channels per frame.e. it is possible to transmit the information from more than one channel in a single frame. Keep this in mind when interpreting the Time Switch control settings. For each channel on this 10 The inbound and outbound Time Switches are translationally symmetric across the Space Switch. Switching network Inbound time switches Space switch Outbound time switches TM0 TS0-In TS0-Out TM0 TM1 TS1-In MUX DEMUX TS1-Out TM1 TM2 TS2-In TS2-Out TM2 (mouth) (ear) Figure 5 – Switching network functional schematic The Switching Network contains six Time Switches and one Space Switch. The Space Switch operates synchronously with each of the three inbound and three outbound Time Switches. these components apply the frame. but with the equivalent capacity of only a single time-multiplexed link. The Space Switch connects the inbound Time Switches to the outbound Time Switches. 1 frame = 1 / (sampling frequency) = 1 / 8000 Hz = 125 µsec. independent of their role as inbound or outbound. A value.ECE 355 – PBX Project Description 3.. y. Since the digital circuits in the PBX can operate at a much higher frequency than 8. All Time Switches are identical. one or many outgoing channels. Figure 5 shows the Switching Network functional schematic. 19 . in the interface channel position x directs the Time Switch to place the data arriving from the incoming channel y into the outgoing channel x. described below..and channel-based characteristics of the time-multiplexed digital signals to route the signals among the connected cards. i.1 from a single audio source. Note that since the value. not reflectively symmetric. The Time Switch derives its name from the fact that its switching action is equivalent to shifting (and possibly duplicating) the channel data with respect to time within a frame.10 Collectively. one or many interface positions. A Time Switch switches the data from the channels on its incoming link to the same or different channels on its outgoing link. The digitized signal’s sampling frequency defines the duration of a frame.e. the signal arriving from the card represented by y can be placed on zero.000 Hz.

The Line Interface shelves accept a single Line Card in each of these slots. Once a line card number must be stored. x.1 equivalent switched link. Each Line Card connects to a single telephone via its Loop circuit. directs the Space Switch to route the data from inbound time switch MUX (channel x) to outbound time switch DEMUX (channel x). Channel index for Space Switch and Line Card index for outboundTime Switch. Inbound Time Switch Space Switch Outbound Time Switch Channel Value Channel MUX DEMUX Channel Value Scenario 1) One-way connection from ring tone (shelf 2. for each one-way connection the following array indices are required: Channel index for inbound Time Switch. the numbers are NOT symmetrical. the PBX can connect to up to 60 telephones. The switching action is controlled through the Voice/Signaling control interface by two values (MUX and DEMUX) in each of the Space Switch’s interface channel positions. The values MUX and DEMUX in the interface channel position. starting/ending Shelf numbers. and incoming channel number. The values that are stored in these four array slots (in order) are: originating line card number.ECE 355 – PBX Project Description 3. 20 . Table 3 delineates the Time and Space Switch control interface settings for two sample scenarios. With two Line Interface Shelves holding up to 30 Line Cards each. the Space Switch selects the inbound and outbound Time Switch whose data will be carried in that channel. This is the greatest source of confusion for this project. The Space Switch derives its name from the fact that this switching action routes the channel data in space. Study this section and the given examples carefully! Each Line Interface or Service Shelf contains 30 slots for cards. card 3) to shelf 0 card 16 via channel 5 TS2-In 5 3 5 2 0 TS0-Out 16 5 Scenario 2) Two-way connection between shelf 0 card 7 and shelf 1 card 3 via channels 8 and 9 TS0-In 8 7 8 0 1 TS1-Out 3 8 TS1-In 9 3 9 1 0 TS0-Out 7 9 Table 3 – Switching network control interface sample scenarios Note: Since the “Channel” positions are indexed via an array. thereby routing each channel’s data among the connected Time Switches. That is. once a channel number.

The Line Card’s Ring Relay controls the bell ringing for the connected telephone. The Ring Bus carries the ring voltage from the Ring Generator to each Line Card. The Switch Hook Detector detects whether the connected telephone is on or off hook. The Ring Generator generates the voltage. and visa versa. While the telephone is off hook. The Line Card’s Test Relay controls whether the Line Card remains connected to the telephone. in the appropriate. for ringing the connected telephone’s bells (see Figure 3). represented in Figure 6 by the pair of Tip and Ring conductors.1 Figure 6 shows the functional schematic for a single Line Card. the Hybrid separates the analog audio signals arriving from the telephone’s microphone. The Test Bus carries test signals between the Line Card and the Voice/Signaling Unit Tester (see Figure 3 on page 18). The Idle Relay controls whether the connected telephone’s receiver receives the Idle Tone from the Line Card’s local Idle Tone Generator. The PBX and telephone communicate over the loop circuit. intermittent time-controlled pattern. or the signal transmitted to the Line Card from the Switching Network. 21 . Line Card A/D Tip Ring Test Relay S/hook detector Ring Relay Hybrid Idle Tone D/A Idle Relay TM (ear) TM (mouth) Test Bus Ring Bus -48V gnd DC supply Figure 6 – Line Card functional schematic Each Line Card connects the PBX to an individual telephone. or momentarily connects to the Test Bus during equipment integrity tests. and going to the telephone’s receiver. The A/D and D/A converters convert the analog audio signals to the time-multiplexed digital signal used in the Switching Network.ECE 355 – PBX Project Description 3.

h used to access the interface elements. Slot 1 2 3 4 5 24 through 30 Generator Idle tone Dial tone Ring tone Slow busy tone Fast busy tone Analyser Touch tone receiver (TTRX) Table 4 – Service shelf slot equipment Figure 8 shows the shared-memory interface to the Voice/Signaling Unit. 22 . The Test Control MUX controls which of the test devices is connected to the test bus at any given time. Tester Test Bus Tester Control MUX No connection 1k Ohm Low V rms High Vrms TT digit "1" TT digit "9" Figure 7 – Tester functional schematic The tester contains the devices for testing the other voice/signaling hardware. The labels shown in courier typeface identify the constants from pbx.ECE 355 – PBX Project Description 3. Table 4identifies the signal processing equipment mounted in the Service Shelf slots. The Low and High voltage meters measure the voltage on the Bus. The Touch-Tone Digit generators generate the analog touch-tone signals representing their respective digit values. The Service Shelf contains the signal processing equipment for generating and analysing the call processing-related digital signals. The No connection presents an open circuit. The 1K Ohm resistor presents a load equivalent to an off-hook telephone.1 Figure 7 shows the functional schematic for the Tester.

. 23 . Card 30 6 5 4 3 2 1 0 Shelf 1 Unused Idle relay LC_LIDLE Ring relay LC_RINGR Test relay LC_TESTR Shelf 2 Service card sense Time-switch control Shelf 2 7 6 5 4 3 2 1 Card 24 Card 25 . 3 . . See also Figure 2 on page 17 for an illustration of the SIGNAL’s in the overall system context. Ch. 3 . 2 1 Card Shelf 0 Shelf 1 Shelf 2 Switch hook sense Line card control 7 Card 1 Card 2 Card 3 . Ch. 30 6 5 4 3 2 1 0 Space switch Tester DEMUX control DEMUX_MASK MUX control MUX_MASK Tester control 7 Control Volt sense MUX control TESTER_CTRL_MASK 6 5 4 3 2 1 0 Volt sense 7 6 5 4 3 2 1 0 Voltage V_MASK Figure 8 – Voice/Signaling Unit software interface Figure 9 shows the SDL SIGNAL’s used to represent events at the Voice/Signaling Unit interface in the SDL PROCESS specifications. .1 32 bits wide Switch hook sense Line card control Status Shelf 0 30 . 2 Ch. . . 1 Ch. . . 2 Ch. Card 30 TTRX sense 0 TM0-In Valid digit TTRX_TPRES Digit TTRX_DIGMASK TM1-In Time-switch control TM2-In 7 Ch.. . 30 6 5 4 3 2 1 0 TM0-Out Outgoing channel CHAN_MASK TM1-Out Space-switch control TM2-Out Space-switch control Tester 7 Ch. 1 Ch.ECE 355 – PBX Project Description 3..

. LineCard). OffHook(LineCard). NEW TYPE Shelf LITERALS 0. */. TTdigit9 ENDNEW TYPE TestBus. Ring.. NEW TYPE mVrms LITERALS 0. LineControl = IdleRelay. HighVoltage. Informally. NEW TYPE TTreceiver LITERALS 0.. . HighVoltage(Vrms).. FastBusy ENDNEW TYPE ProgressTone. TTRX. NEW TYPE LineCard STRUCT shelf Shelf. See the manufacturers reference documentation for a description of this interface. NEW TYPE Slot LITERALS 1... and Figure 12 show the SDL/GR behavioural specification for the Call Processing function. TTreceiver). the current between tip and ring. TTdigit). Tone. Tone(LineCard.. IdleRelay(RelayPos).. Dial. . 2. TestRelay(RelayPos). NEW TYPE Vrms LITERALS 0.. LowVrms. . ConnectTTRX(LineCard. 24 . Talk(LineCard. 2. 1. 1. 1. 3. TestRelay. TTRXDigit(TTreceiver. . 1. 6 ENDNEW TYPE TTreceiver. RingRelay. SwitchControl = Talk. OnHook. TestControl = TestBus. NEW TYPE TTdigit LITERALS 0.. Figure 11. NEW TYPE TestBus LITERALS NoConnect. 30 ENDNEW TYPE Slot. HighVrms. SIGNAL LoopCurrent /* Undefined. Figure 9 – PBX SDL SIGNAL’s Software interfaces The PBX control software uses the software interface provided by the UNIX ® operating system on the Sun™ Solaris™ reference platform. 2. ENDNEW TYPE LineCard. 9 ENDNEW TYPE TTdigit. 2. SlowBusy. Call Processing functional requirements Figure 10. TTdigit1. slot Slot. 255 ENDNEW TYPE mVrms. LowVoltage(mVrms). OnHook(LineCard). TestBus(TestFunction).... TestVoltage = LowVoltage. 1 ENDNEW TYPE Shelf..1 SYSTEM PBX 2(2) SIGNALLIST SIGNALLIST SIGNALLIST SIGNALLIST SIGNALLIST SwitchHook = OffHook. NEW TYPE ProgressTone LITERALS Idle. 1kOhm. 2. ProgressTone). In ENDNEW TYPE RelayPos. 255 ENDNEW TYPE Vrms.ECE 355 – PBX Project Description 3. NEW TYPE RelayPos LITERALS Out. .. RingRelay(RelayPos).

The symbol "Self" refers to the line card for this process.In) Connect TTRX Start Timer (Ringing) Tone (Dial) Ringing Idle Relay (Out) 25 .1 PROCESS CallProcessing 1(3) ON Test Relay (Out) Ring Relay (Out) Idle Relay (In) Start Timer (Dialing) AwaitDigit Digit Timer (Dialing) OnHook Deallocate Self OnHook to Other Stop Timer (Dialing) Stop Timer (Dialing) OnHook Idle OnHook Tone (Idle) Incomplete Analyse digits Complete Invalid Deallocate TTRX OffHook OffHook Allocated Deallocate 2-way path Self Allocated? N Allocate Self Y OffHook to Other SB ON Other Allocated? N Allocate Other FB Deallocate TTRX Y Allocate 2-way path SD Allocate TTRX Tone (Ring) /* Notes: 1. 2. The symbol "Other" refers to the line card for the process assigned with the dialed extension. LineCard-type parameters to SIGNAL's and TASK's are "Self" unless specified otherwise. 3. 4. This specification defines one CallProcessing PROCESS for each line card. */ Ring Relay (Other.ECE 355 – PBX Project Description 3.

1 Figure 10 – Call Processing behavioural specification (1 of 3) PROCESS CallProcessing 2(3) SB Ringing Start Timer (SBusy) Timer (Ringing) OnHook (Self) Tone (Slow Busy) Slow Busy OffHook (Other) Stop Timer (Ringing) Ring Relay (Other.Out) Idle Relay (Other.Out) Ring Relay (Other.ECE 355 – PBX Project Description 3.Out) Stop Timer (Ringing) Ring Relay (Other.Out) Timer (SBusy) FB Start Timer (FBusy) OnHook (Self) Deallocate Other Deallocate Other Stop Timer (SBusy) TK FB Deallocate 2-way path Tone (Fast Busy) Deallocate 2-way path ON Fast Busy ON Timer (FBusy) OnHook (Self) Deallocate 2-way path Stop Timer (SBusy) Idle Relay (In) /* Timer values (seconds) Dialing 25 Ringing 120 SBusy 30 FBusy 30 */ Deallocate 2-way path IdleAfter FastBusy ON OnHook (Self) ON Figure 11 – Call Processing behavioural specification (2 of 3) 26 .

In) Tone (Self.Out) TK Deallocate 2-way path SD Deallocate Other OnHook to Other Deallocate Other ON OffHook to Other ON ON Figure 12 – Call Processing behavioural specification (3 of 3) 27 . Self) Talking OnHook (Self) OnHook (Other) Idle Relay (Self.ECE 355 – PBX Project Description 3.In) Tone (Other. Idle) Idle Relay (Other.1 PROCESS CallProcessing TK 3(3) Connect (Other.Out) TK Deallocate 2-way path Deallocate Other Idle Relay (Other. Idle) Start Timer (EndCall) /* Timer values (seconds) EndCall 3 */ Start Timer (EndCall) Self OnHook Other OnHook OffHook (Self) OnHook (Other) Timer (EndCall) OffHook (Other) OnHook (Self) Timer (EndCall) Stop Timer (EndCall) Stop Timer (EndCall) Deallocate 2-way path Stop Timer (EndCall) Stop Timer (EndCall) Deallocate Other Idle Relay (Self.

If any one or more of the following tests fail. Many of the Common Equipment tests also require a Line Card. or that the Common Equipment failed (see Table 7). we classify the components of the Voice/Signaling Unit as either Line Card-specific Equipment (LCE). Test name All tests Preconditions Except where specified otherwise. we assume the single-fault assumption. then the Common Equipment is definitely faulty. 28 . If all of these tests pass. then there is a 10% probability that the Line Card is still faulty.e. that the hardware under test exhibits at most one fault at time. all controlled and reported through the PBX console. It provides hardware fault detection through manual and automated tests. fewer than 10% of hardware faults can escape detection and thereby lead to service failure for a subscriber. all tests include the following three preconditions: Idle Relay out Test Relay in Ring Relay out Tester MUX at TT digit “1” Network path to a TTRX Tester MUX at Low Vrms Network path from Dial Tone Tester MUX at No connection Tester MUX at 1k Ohm Tester MUX at High Vrms Tester MUX at High Vrms Postcondition A/D converter D/A converter On hook Off hook Ring Relay out Ring Relay in TTRX sense reads “1” Volt sense reads 200 mV ± 10% Switchhook sense reads “0” Switchhook sense reads “1” Volt sense reads 48 V ± 20% (battery DC) Volt sense reads 85 V ± 20% (ringer AC) Table 5 – Line Card Equipment (LCE) test suite Common Equipment (CE) fault detection The combination of tests in Table 6 exercises 90% of the hardware in a Common Equipment. but leaves these details for the reader to infer from the appropriate test description in Table 5. due to faults in hardware that cannot be covered by any test. In all discussions of PBX fault detection. then the Line Card is definitely faulty.. in order to establish the appropriate connection with the Tester through the Line Card’s Test Relay. due to faults in hardware that cannot be covered by any test.1 Maintenance functional requirements The Maintenance function of the PBX control software helps the maintenance technician maximize service availability for subscribers. or Common Equipment (CE). If all of these tests pass.ECE 355 – PBX Project Description 3. The preconditions in Table 6 do not necessarily describe all of the Line Card’s specific relay settings. If any one or more of the following tests fail. Line Card Equipment (LCE) fault detection The combination of tests shown in Table 5 exercises 90% of the hardware in a Line Card. then there is a 10% probability that the Common Equipment is still faulty. It provides no fault isolation information beyond identifying the particular Line Card that failed. We require that the Maintenance function detect at least 90% of the hardware faults. i. That is. Fault detection To specify the Maintenance functional requirements.

g. respectively (TTRX) connect the Tester MUX at TT digit “1” (and subsequently at TT digit “9”) and connect a network path to the TTRX Tone Generators For each Tone Generator on Volt sense reads 200 mV ± 10% the Service Shelf.. the Maintenance function also automatically initiates the same hardware test suitess at regular intervals. Automatic fault detection In addition to allowing the maintenance technician to manually initiate hardware fault detection tests. this table exercise each of the respectively Tester functions except No connection and 1k Ohm. Command test ce test lc shelf line Notes Output result ce timestamp result lc shelf line timestamp result pass | fail shelf 0|1 line 1 | 2 | 3 | … | 30 timestamp Fri Sep 13 00:00:00 1986 or equivalent Table 7 – Manual hardware fault detection commands The Maintenance function displays a single “>” prompt character when it is ready to accept commands.g. connect to each of the input Time Switches at least once. Table 7 summarizes the commands available for manual control of the hardware fault detection hardware. a Tone Generator) and a signal detector (e. connect a signal source (e.1 Test name Time switch Preconditions Postcondition For just one arbitrary channel The signal passes through the Time Switch on the time switch. Tester Low Vrms) Space Switch For just one arbitrary channel The signal passes through the Space Switch on the Space Switch. The results of the manual fault detection also appear on the PBX console. and each of the output Time Switches at least once TTRX For each Touch Tone Receiver TTRX sense reads “1” and “9”. This automatic fault detection serves two purposes: 29 . connect to the Tester Low Vrms Ring Generator Tester MUX at HighVrms Volt sense reads 85 V ± 20% (ringer AC) Tester (The tests described above in Switchhook sense reads “0” and “1”.ECE 355 – PBX Project Description 3.) Set the Tester MUX at No connection and 1k Ohm.. respectively Table 6 – Common Equipment test suite Manual fault detection control The maintenance technician can initiate hardware fault detection manually through commands entered at the PBX console.

9 = 51.6 h MTTDauto Note: For demonstration purposes.007008) – 1. The following calculations ensure that the PBX meets minimum acceptable downtime due to hardware faults and repair. the technician will be informed of failures. respectively. test one Line Card every minute. with 60 Line Cards. The frequency of the automatic tests determine how quickly.9 MTTDauto + 0. thereby improving overall service to subscribers. due to hardware failures By automatically reporting faults. use a Line Card MTTDauto of 1 h. Quantity Value FR Failure Rate FRLC 800 FITS (given) FRCE 28. More frequent test execution provides earlier detection and correction.007008 = ((1/3 ÷ 0. the Maintenance function allows the supporting maintenance technician to take corrective action.1 * 1 h) + 1 h) x 0. The frequency of automatic test execution must balance the improved hardware reliability provided by early detection with overall service availability for subscribers.1 • • Assisting the maintenance technician by automatically reporting detected faults Preventing the subscribers from getting unexpected results from the PBX. i.1 * 1 h) + 1 h) x 0.2877 h = 17. on average. but only for failed tests.000 FITS (given) DRuser 0.9 MTTDauto + 0.9 MTTDauto + 0.1) ÷ 0.1 (given) DRauto 0.9 MTTDauto + 0.1 MTTDuser) + MTTR) x (28.24528 MTTDauto = ((1/3 ÷ 0.1 MTTDuser) + MTTR) x (800 failures / 109 h) x (365 x 24 h/year) = ((0. Common Equipment MTTDauto DThw 1/3 = (MTTD + MTTR) x (failures / year) = ((0.1) ÷ 0.9 (given) MTTR 1 h (given) MTTDuser 1 h (given) DThw < 1/3 MTTDauto unknown Line Card Equipment MTTDauto DThw 1/3 Unit FITS FITS FITS faults/fault faults/fault hours hours hours/year hours Description Failures in 109 hours Failure Rate for a Line Card Failure Rate for a Line Card Fraction of faults detected by user Fraction of faults detected automatically Mean Time To Repair Mean Time To Detect by user Down Time due to hardware Mean Time To Detect automatically = (MTTD + MTTR) x (failures / year) = ((0.e. Table 8 shows the calculation of the automatic fault detection test execution interval for an individual Line Card. and for the Common Equipment. such as replacing the failed equipment. as well detecting faults.. Performance requirements All performance requirements are defined by the supplied Customer Acceptance Tests (CAT).ECE 355 – PBX Project Description 3.9 = 0. 30 .000 failures / 109 h) x (365 x 24 h/year) = ((0. the automatic fault detection tests use resources that the PBX might otherwise make available to subscribers for placing calls. However.24528) – 1.2 minutes Table 8 – Automatic fault detection interval calculation The Maintenance function automatic fault detection displays the results on the PBX console. using the identical output format as for the manual test command output shown in Table 7.

1 Software system attributes Security The PBX control software has no general or specific security requirements. to prevent interlopers from disrupting their timecritical business in trading. some general capabilities can be anticipated for future versions. a stock brokerage company may locate the PBX console in a locked room. and locate the PBX in a commonly accessible equipment room. Table 9 summarizes and prioritizes (in order of declining importance) the major anticipated future capabilities that a good design would readily accommodate. a charitable organization may take no special security precautions. Maintainability This document describes the specific requirements for the current version of the PBX control software. Quantitative expansion Additional touch-tone receivers Four-digit extension numbers Additional line card shelves Additional line cards Additional switching network paths Table 9 – Anticipated future capabilities Table 9 notwithstanding. Qualitative expansion Interactive extension assignment Trunk-based calls Call transfer Call forwarding Call answer Call display with display blocking 31 . under no circumstances should the development of the current version of software compromise the priorities delineated in Table 1 – Delivery priorities for the current Call Processing and Maintenance requirements. that is.ECE 355 – PBX Project Description 3. by locating the PBX console and telephones in physically secure locations as required by the particular application. In contrast. For example. All PBX system and software security is realized through physical means. Although not required for the current version.

Since it is good programming practice to use predefined constants. as well as similar changes. instead of hardcoded values. . In particular. This is not meant to be taken to extremes: we will NOT put values of “0” in for MAX_SLOTS or such. the PBX control software should NOT rely on hardcoded numbers to determine numeric values such as the number of linecards/phones to manage. 60 channels instead of 30. and its capacities increased or modified.h . To this end. the following constants (taken from pbx. /* * Hardware constraints */ #define MAX_CHANNELS #define MAX_SLOTS #define FIRST_USED_SLOT #define LAST_USED_SLOT #define MAX_SHELVES #define FIRST_USED_SHELF #define LAST_USED_SHELF #define SERVICE_SHELF #define FIRST_TTRX #define LAST_TTRX 32 32 1 30 3 0 1 2 24 30 32 .1 Expandability As outlined in 3. The only differences that may arise are that there may be 12 or 18 Time Switches instead of 6. That is. However. changing FIRST_TTRX and LAST_TTRX to the same number should work (with only one TTRX for the whole system).ECE 355 – PBX Project Description 3.5.implementations will need to #include this file) should be used. adding more TTRXes should also work.2. etc. Similarly. the hardware emulator may be updated. calls will continue to be completed as described earlier in this document. this requirement should not add any overhead to any PBX control software implementation. The overall functionality of the PBX will NOT change. 80 linecards per shelf instead of 30. Some of these changes may happen between the RSP and Implementation stages.

following the outline and guidelines described below. This outline assumes that you use SDL in describing your design.. independent of your choice of description language. then identify this difference in your cover letter. Bind it well. if any. assigned by our technical staff) Names and id numbers of all staff members assigned to the project The purpose of the attached package. 33 .ECE 355 – PBX Project Description 3. SDD outline We recommend the following outline for your SDD document. we will evaluate your design and design description for implementation and maintenance purposes. we prefer precise. and the nature of the design itself. if possible. In any case. your document must contain the same essential design information as what is outlined here. In general. Deliverables You must submit a Software Design Description (SDD) package containing the items listed below. The page counts shown with each section title are rough estimates about how many pages it should take to represent the relevant information. Your page count may vary. Print your document in duplex. as your company’s submission for PBX-SSS-P1-SDD A list of differences between the outline of your SDD and the recommended outline. By the listed estimates. as well as the evaluation weighting values posted on our web site. If you opt to use a different design description language. the SDD provides individual developers with sufficient information to allow them to complete their assigned programming tasks with minimal additional communication with each other. In your submission for SBR’s software supplier selection process. Cover letter The one-page cover letter must identify: • • • • • • • Date of submission Your company name Your company’s selection process id (e. the SDD provides sufficient information for future developers to plan the changes they will need to make to the design and implementation. During maintenance. succinct documentation. in order to accomplish their software maintenance tasks. the total page count ranges from 13 to 18 pages. depending on what major functional capabilities you include in your design .1 Software Design Description (SDD) The Software Design Description (SDD) communicates the software design to developers filling two roles: • • Implementation Maintenance During implementation. ece355a. with a brief explanation for each difference A list of all the items you attach SDD – Software Design Description See the document outline and evaluation criteria described below.g. You will not be rewarded or penalized for varying from these estimates.

Using SDL. C/C++ struct’s) Process behaviour(1 p. and expandability A brief list of any specific accommodations or novel techniques applied in your design (if any) to realize a distinctive benefit in addressing your general design priorities Reuse (¼ p.) This section identifies the supplied source code. with INPUT. with the PBX Control Unit (CU) as the containing top level BLOCK PROCESS’s. that you used in your design. etc. shown in either SDL’s data notation. Call Processing.. if any. reliability. 34 . It should identify: • • • • The originating Software Requirements Specification (SRS) document and version The major functional capabilities included in the design. OUTPUT.) This section should identify: • • A brief summary of your general design priorities with respect to effort and risk in completing the work versus the software’s overall functionality. or the implementation language’s notation (e. and summarizes the any differences between the presented design and the specified requirements.e.) This section describes your software design structure from the view of multiple concurrent processes. If you did not use any of the supplied source code. STATE transitions. or directly in the top level CHANNEL’s and/or SIGNALROUTE’s. It should include: • A process behaviour description for each PROCESS. per process) This section describes your software design behaviour. including those connecting BLOCK’s and PROCESS’s with each other..) The title page and/or front matter pages must identify the following details: • • • • • Your company name Project and design name Version number Date of design Document revision history Requirements compliance (1~1½ pp. e.ECE 355 – PBX Project Description 3. TASK.g. Maintenance A list of the specific differences (if any) between the originating requirements and the presented design A brief explanation of the reasons for each difference. each shown within their respective BLOCK. it should include the control software’s: • • • • • BLOCK diagram. and with the Voice/Signalling Unit (VSU) at the top-level CU interface SIGNALLIST’s for each CHANNEL and/or SIGNALROUTE Parameters and/or data types for each SIGNAL. Multiprocessing (1½~2 pp. using SDL’s communicating finite state machine notation. SBR has sufficient information about the supplied material to understand your design without reiterating it in your document. then you should state this explicitly.g. identifying the trade-off chosen in the design Design priorities (½ p.. i. The software design for any supplied source code that you did use does not need to be documented in your SDD.1 Identification (1 p. DECISION boxes.) This section identifies the source of the originating requirements.

1 Message sequences (2~3 pp. we also ask for you to illustrate the control software’s overall behaviour from alternate view. UNIX msg) A brief description of the sequence you apply in starting up and shutting down the multiple processes in your design.g. we ask you to illustrate interactions from a few key scenarios. your SDD should include the following implementation-dependent details: • • • Pseudocode illustrating your general approach to implementing the SDL Finite State Machine (FSM) A table listing each CHANNEL and/or SIGNALROUTE and the target operating system inter-process communication (IPC) mechanism used to implement it (e. Your ability to illustrate the interactions reinforces our confidence in your understanding of the presented design. called party disconnects Touch tone receiver overload Space switch failure Implementation (1 p.. including the establishment of IPC connections 35 .) To confirm that your design can be realized on the target platform. as described in the Customer Acceptance Tests (CAT).ECE 355 – PBX Project Description 3. The Message sequences section of your SDD should include: • • • • • A Message Sequence Chart for each of the following CAT test cases Off hook timeout Call established. that of interaction among the processes.) Although the process behaviour description is complete in describing each process’ behavioural design. Since it is impossible to show all possible interactions.

For example. with a brief explanation of the reasons for each change A summarized list of the changes you did make during implementation compared to your submitted design. as well as clear identification of your project team.. a copy of your own CAT test results.ECE 355 – PBX Project Description 3. prepared to answer questions. and experience report. we may be more lenient in evaluating a failed test case if the experience report anticipates the possibility of failure. Your responses to our questions may also influence our evaluation of your other results. Ad hoc quiz Our technical staff may pose you and your staff with questions about your design. and how you might improve your role assignments on future projects A summarized list of the changes you would make to your submitted design.to two-page experience report provides: • • • • • • • • • Date of submission Your company name Your company’s selection process id (e. and your staff’s explanation for the failure and suggestions for improvement are reasonable and consistent with observed facts. The primary purpose of this quiz is to confirm your staff’s knowledge of their submitted work. These test results should be marked with a date and time stamp indicating the time of execution. one or two sentences) of each member’s actual role on the project A brief summary (i. including both manual and automatic tests. test results.. The one.e.1 Implementation Your implementation submission comprises a short experience report. We will evaluate the report for how it shows your awareness of opportunities for improvement. including both manual and automatic tests. during a scheduled demonstration session. assigned by our technical staff) Names and id numbers of all staff members assigned to the project Brief synopses (i.e. (if any). implementation. 36 . ece355a. three or four sentences. and a demonstration of your working software under test conditions. We may also use the experience report as a basis for questions during the ad hoc quiz. We request that all team members attend your demonstration session. with a brief explanation of the reasons for each change A summarized list of the failures you observed or anticipate (if any) in Customer Acceptance Testing of the software.) of how well the team member role assignments worked. Experience report The experience report captures the lessons your team gained during the selection process.g. Demonstration Our technical staff will observe a live demonstration of your software under some or all Customer Acceptance Tests (CAT). (if any) in future work on the same project.. with a brief explanation of the reasons for each failure CAT test results You must submit a hardcopy of the test results from your own prior execution of the Customer Acceptance Tests (CAT).

37 . More information about the CAT stage will be made available as the project progresses.ECE 355 – PBX Project Description 3.1 Acceptance testing See the supplied Customer Acceptance Test (CAT) and Automated Customer Acceptance Tester (ACAT) for details about acceptance testing.