Documentcp

Information

Control

Coordination Processor 113D (CP113D)

A30828-X1130-K500-1-7618

2 A30828-X1130-K500-1-7618

Coordination Processor 113D (CP113D) InformationControl

!

Copyright (C) Siemens AG 1998.

Issued by the Public Communication Network GroupHofmannstraße 51D-81359 München

Technical modifications possible.Technical specifications and features are binding only insofar asthey are specifically and expressly agreed upon in a written contract.

A30828-X1130-K500-1-7618 3

InformationControl


This document consists of a total of 70 pages. All pages are issue 1.

Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 CP113D Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1 Base Processor (BAP), Call Processor (CAP), Input/Output Control (IOC) . 82.2 Bus for Common Memory (BCMY) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Common Memory (CMY) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Input/Output Processors (IOP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 CP113D Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1 Program Execution Part (PEX), Module CPEX

and Access Control (AC), Module CPAC . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Cycle Control (CC), Module CPCC,

and Local Memory (LMY), Module MUH. . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Coupling Logic (CL), Module CPCL,

and Common Interface (CI), Modules CPCIA/CPCIB. . . . . . . . . . . . . . . . . 173.4 BIOC Interface, Modules IOCIF0 and IOCIF1 . . . . . . . . . . . . . . . . . . . . . . 193.5 Processor Interface Unit (PI), Modules PIADR and PIDAT . . . . . . . . . . . . 203.6 Decentral Bus Arbiter for Common Memory (DARB) . . . . . . . . . . . . . . . . . 223.7 Central Bus Arbiter for Common Memory (CARB) . . . . . . . . . . . . . . . . . . . 233.8 Common Memory, Control, Microprocessor (CMYMP) . . . . . . . . . . . . . . . 243.9 Common Memory, Data Network (CMYD) . . . . . . . . . . . . . . . . . . . . . . . . . 253.10 Common Memory, Control, Part 1 (CMY1C) . . . . . . . . . . . . . . . . . . . . . . . 263.11 Common Memory, Control, Part 2 (CMY2C) . . . . . . . . . . . . . . . . . . . . . . . 273.12 Common Memory, Address Network (CMYA) . . . . . . . . . . . . . . . . . . . . . . 283.13 Input/Output Processor for Message Buffer (IOPMB). . . . . . . . . . . . . . . . . 293.14 Input/Output Processor for Time and Alarms (IOPTA) . . . . . . . . . . . . . . . . 303.15 Input/Output Processor for Magnetic Disk Device (IOP:MDD), Modules

IK:DTD and IF:MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.16 Input/Output Processor for Magnetic Tape Device (IOP:MTD), Modules

IK:DTD and IF:MTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.17 Input/Output Processor for Serial Data Communication Devices, V.24 Inter-

face (IOP:SCDV). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.18 Link Control Unit (LCUB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.19 Link Adaptation Unit (LAUB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.20 Input/Output Processor for Authentication Center (IOPAUC) . . . . . . . . . . . 383.21 Capacity Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Safeguarding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.1 Hardware fault detection by the hardware . . . . . . . . . . . . . . . . . . . . . . . . . 414.1.1 Error detection in the BAP, CAP, BCMY, CMY in the CP113D . . . . . . . . . 414.1.2 Error detection in the IOC and IOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Hardware fault detection by software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 Hardware Fault Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3.1 Operation of the hardware fault treatment . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.2 Alarm treatment with the bus error routine of the PRO. . . . . . . . . . . . . . . . 494.4 Detection of software errors by the hardware . . . . . . . . . . . . . . . . . . . . . . . 51

4 A30828-X1130-K500-1-7618


4.5 Detection of software errors by the software . . . . . . . . . . . . . . . . . . . . . . . . 514.6 Software error treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.6.1 Structure of the software error treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.6.2 Operation of the software error treatment . . . . . . . . . . . . . . . . . . . . . . . . . . 574.6.3 SWET LOCAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.6.4 SWET SYSTEM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.7 Safeguarding Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A30828-X1130-K500-1-7618 5

InformationControl


1 IntroductionThe digital electronic switching system EWSD is divided into a number of functionalareas that are largely independent in their operation. Coordination processorD(CP113D) is part of the functional area Control (Fig. 1.1).

Fig. 1.1 EWSD overview diagram

The main characteristics of the CP113D– can be adapted to exchanges of any size– stores and administers programs plus exchange and subscriber data– processes input information relating to routing, path selection, zoning, charge regis-

tration, traffic data administration, network management– communicates with the operation and maintenance center– monitors all subsystems, analyzes results of monitoring, detects and reports errors,

signals and processes alarms, locates faults and neutralizes them, and handleschanges in the configuration

– administers the man-machine interface

Trunks, V5.2, PABX

SN

MB

CP

CCG

CT

Access

Signaling

Control

Switching

SS7 links, high speed SS7 links

Analog,ISDN, V5.1 DLU LTG

LTG

CCNC/SSNC

6 A30828-X1130-K500-1-7618


Structure of the CP113D

The CP113D consists of the following functional units:– Base processor (BAP)

The BAP performs all operation and maintenance functions and some call-processingfunctions.– Call processor (CAP)

The CAP performs call-processing functions only.– Input/output control (IOC)

The IOCs form the interface between the Bus for Common Memory (BCMY) and theInput/Output Processors (IOP).– Input/output processor (IOP)

The IOPs control the exchange of data with the connected call-processing, operationand maintenance and data communication peripherals and with external systems suchas host processors or the EWSD Maintenance Network/Operations System (EMN/OS)of the exchange.– Common Memory (CMY)

The elements of the CMY include the database shared by all of the processors, the inputand output lists for the IOP:MB and the communication areas used by the IOPs toexchange data with the O&M and data communication peripheries.– Bus for common memory (BCMY)

The BCMY forms the link between all processors including the input/output controls andthe common memory (CMY). The BCMY is used to transfer data and addresses for readand write cycles in the CMY and for interprocessor communication.

Like all other EWSD hardware, the CP113D is composed of modules, installed inframes, which in turn are installed in racks. For more information on the mechanicaldesign of the CP113D hardware, refer the Maintenance Manual Construction.

A30828-X1130-K500-1-7618 7

InformationControl


Fig. 1.2 Functional units of the CP113D

BIOC BIOC

IOC3IOC1

15IOP

0

BCMY1

0

BAPM

15

CMY1

BCMY0

IOP

IOP

IOP

CMY0

BAPS IOC0CAP9 IOC2CAP0

8 A30828-X1130-K500-1-7618


2 CP113D FunctionsThe coordination processor (CP) handles the common functions in the exchange, suchas the coordination of the distributed microprocessor controls and the data transferbetween them.

The CP113D consists of three processor types, of identical structure:– base processor (BAP)– call processor (CAP)– input/output control (IOC)

BAP, CAP and IOC have access to the common memory (CMY) via the bus for commonmemory (BCMY). The IOCs form the interface between the bus for common memoryand the input/output processors (IOP). The IOPs control the exchange of data with theconnected call-processing, O&M and data communication devices in the node.

Fig. 2.1 The functional units of the CP113D

2.1 Base Processor (BAP), Call Processor (CAP), Input/OutputControl (IOC)The base processors (BAP), call processors (CAP) and input/output controls (IOC) arebuilt up of the same hardware components. They are therefore described together here.

BIOC BIOC

IOC3IOC1

15IOP

0

BCMY1

0

15

CMY1

BCMY0

IOP

IOP

IOP

CMY0

CAP0

PU PU

CL

LMY

CI

MYC MYB0 MYB1 MYB2 MYB3

IOC0

PU PU

CL

LMY

CI

CAP9

PU PU

CL

LMY

CI

BAPM

PU PU

CL

LMY

CI

BAPS

PU PU

CL

LMY

CI

Inter-face

BIOC

IOC2

PU PU

CL

LMY

CI

Inter-faceBIOC

A30828-X1130-K500-1-7618 9

InformationControl


Fig. 2.1 shows the BAP, CAP and IOC. Each of these processors consists of aprocessing unit (PU), local memory (LMY), coupling logic (CL) and a common interface(CI).

The IOC is additionally equipped with an interface to the bus system for input/outputcontrol (BIOC).

Processing unit (PU)

The PU is duplicated for redundancy in each processor (BAP, CAP, IOC); the two unitsare named PU0 and PU1.

The two PUs operate in synchronism with the same clock and process identical data.PU0 is the leading unit and– has read and write access to the data in the LMY,– passes the data read from the LMY to PU1.

For all other functions, such as the processing of data or sending and receiving dataover the BCMY, the two PUs operate in parallel but independently of each other,comparing their results in each case.

A PU consists of:– the Program execution part (PEX), Module CPEX– the access control (AC), Module CPAC– the cycle control (CC), Module CPCC.

Local memory (LMY)

The size of the LMY varies from 16 Mbyte (minimum capacity) to 32 Mbyte (maximumcapacity), provisioned according to requirements.

The LMY is implemented by memory unit H (MUH), which is equipped with DRAM chips(memory medium).

The refresh cycle for the memory chips is performed by LMY controls 0 and 1 in theCPCC, mentioned above. In the text that follows, the memory chips are referred to asthe LMY memory medium.

From the point of view of the LMY, data that are written to or read from the LMY memorymedium consist of a sequence of bits, which the LMY distinguishes as either user bitsor check bits.

User bits represent data transferred from PU0 to LMC control 0 during a write cycle, forexample, so that they can be written to the LMY memory medium.

Check bits are generated by LMY control 1 on the basis of the 32 user bits in a memoryword, in other words on the basis of the data to be written to the LMY memory medium.The generated check bits are written to the LMY memory medium separately from theuser bits. In a read cycle, the check bits are used to check the validity of the 32 user bitsin a memory word.

Bus system for input/output control (BIOC)

The BIOC interface is only found in the IOPs and is used to access the bus system forinput/output control (BIOC). A maximum of 16 IOPs can be connected to the BIOC - andthe peripheral units of the exchange are, in turn, connected to the IOPs.

10 A30828-X1130-K500-1-7618


2.2 Bus for Common Memory (BCMY)The bus for common memory (BCMY) interlinks all processors (BAP, CAP) including theinput/output controls (IOC) and links them with the common memory (CMY). The BCMYis used to transfer data and addresses for read and write cycles in the CMY and tohandle interprocessor communication (IPC). The BCMY is duplicated for security. Thetwo BCMYs operate in parallel and process identical information. In special cases, thetwo BCMYs can be decoupled (e.g. for testing).

The main components of a BCMY are:– processor interface unit (PI)– decentral bus arbiter (DARB)– central bus arbiter (CARB)– memory interface (MI)– bus clock system (BCLK)– central BCMY control, bus driver

Processor interface unit (PI)

The processors, BAP, CAP or IOC, have redundant links to BCMY0 and to BCMY1 viathe PI. There is a separate PI in BCMY0 and BCMY1 for every BAP, CAP, IOC.

Each group of four PIs in a BCMY, together with the associated Decentral Bus Arbiterfor Common Memory (DARB), forms a processor interface group.

Decentral bus arbiter (DARB)

Each processor interface group has a decentral bus arbiter (DARB) leading to the busfor common memory.

Allocation of the BCMY to a processor interface group and from there to one of the fourprocessor interface units (PI) is performed interactively by the decentral and central busarbiters.

The DARB also includes the voltage supervision for the four PIs in the processor inter-face group.

Central bus arbiter (CARB)

The central bus arbiter is implemented by the CARB - Central Bus Arbiter for CommonMemory (CARB).

Up to four decentral bus arbiters, DARB, can be connected to the central bus arbiter ofthe CARB. The four decentral bus arbiters belong to processor interface groups 0 to 3.

The function of the central and decentral bus arbiters is:

to control the selection of bus requests, which can arrive simultaneously from up to 16processors via 16 processor interface units (PI), and to allocate the BCMY to one PI andthus to the processor connected to that PI.

Memory interface (MI)

The MI is the interface between the BCMY and the two common memories CMY0 andCMY1.

Central BCMY control, bus drivers

Together with the bus drivers, the central BCMY control forms the interface to theprocessor interface units (PI) and to the memory interface (MI).

A30828-X1130-K500-1-7618 11

InformationControl


The task of the central BCMY control and the bus drivers is to concentrate and distributethe address, data and control signals. They generate the control signals for the bus arbi-ters and memory interfaces (MI), and compare the duplicated control signals to assurethe reliability of the BCMY.

If a BCMY alarm is raised, the central BCMY control triggers a “BUS Reset” and assignsinterfaces for the connection of a hardware tracer so that tests can be performed.

2.3 Common Memory (CMY)The components of the common memory (CMY) include the database shared by all ofthe processors, and the input and output lists used by the input/output processors (IOP)of the call-processing and O&M peripheries. The CMY is duplicated to ensure high avail-ability. The two CMYs (CMY0 and CMY1) can be accessed by all processors andinput/output controls (IOC) and by the IOPs via both buses for common memory(BCMY0 and BCMY1). In normal operating conditions, both CMYs perform all read andwrite cycles in synchronism. But it is also possible to decouple the two CMYs from oneanother (split mode).

2.4 Input/Output Processors (IOP)Various types of input/output processor (IOP) link the CP113D with the othersubsystems and functional units of the node, the external mass memories, the O&Mterminals, the operation and maintenance center (OMC, over data links) and computercenters (over data links).

The following types of IOP are employed in the CP113D:– Input/Output Processor for Message Buffer (IOPMB)– Input/Output Processor for Time and Alarms (IOPTA)– Input/output processor unified for O&M devices (IOP:UNI)– Input/output processor for serial data communication devices, packet protocol

(IOP:SCDP)– Input/Output Processor for Authentication Center (IOPAUC)– Input/Output Processor for Magnetic Disk Device (IOP:MDD), Modules IK:DTD and

IF:MDD– Input/Output Processor for Magnetic Tape Device (IOP:MTD), Modules IK:DTD and

IF:MTD– Input/Output Processor for Serial Data Communication Devices, V.24 Interface

(IOP:SCDV)– input/output processor for serial data communication devices, X.21/V.11 interface

(IOP:SCDX)

Input/output processor for message buffer (IOP:MB)

The input/output processors for message buffer (IOP:MB) form the interface betweenthe CP113D and the other subsystems and functional units in the node. For security, allsubsystems and functional units are served by two IOP:MBs. If one of the two IOP:MBsfails, the other handles all data transfers alone.

The number of installed IOP:MBs depends on the size of the node.

An IOP:MB performs the following functions independently:– controlling inputs and outputs between the CMY and the call-processing periphery

12 A30828-X1130-K500-1-7618


– executing commands from the BAP-master, such as resetting the call-processingperiphery

– safeguarding functions such as monitoring the interfaces of the IOP:MB

Input/output processor for time and alarms (IOP:TA)

The input/output processor for time and alarms (IOP:TA) contains the hardware clockfor the CP113D and interfaces to the CP racks via which it receives alarms, such as airconditioning alarm.

A CP113D contains two IOP:TAs, connected for security to IOC0 and IOC1 respectively.

The hardware clock in each IOP:TA is itself duplicated, and is synchronized by timingsignals transferred from a central clock generator (CCG). The hardware clock generatesthe date and the time in hours, minutes and seconds. The software in the CP113D isthus able to correct its own software clock when necessary or to reset it after a restart.The time is also displayed on the module faceplate. Apart from date and time, the hard-ware clock also runs a seconds counter independently of the time of day.

Optionally, a radio-controlled clock (radio clock device, RCD, external unit) can beconnected to the two IOP:TAs to set and adjust the hardware clock.

Some alarms in CP racks are not attributable to particular functional units, for example,air conditioning alarm, temperature alarm. The IOP:TA receives these alarms andreports them to the safeguarding software in the BAP. An IOP:TA has alarm interfacesto up to 5 racks.

Input/output processor unified for O&M devices (IOP:UNI)

The input/output processor unified for O&M devices (IOP:UNI) allows the followingdevices and lines to be connected to the CP113D:– one magnetic tape device (MTD)– one magneto-optical disk device (MOD)– one magnetic disk device (MDD) and optionally– one personal computer (PC) and– 2 or 3 data links

The IOP:UNI has an ANSI-standard SCSI (small computer systems interface) port forthe connection of MTD, MOD and MDD. The devices are connected to this port via asingle shared data link. The transmission rate between the device and the IOP:UNIdepends on the type of device. For MDDs, it is between 3 and 5 Mbyte/s. In the case ofMTDs, the transmission rate also depends on the recording method: the maximumtransmission rate for phase-encoded recording (PE) is 80 kbyte/s, that for group-encoded recording is 310 kbyte/s.

There are three ports for PC and data links. Here, either one PC and 2 data links or 3data links can be connected directly or via MODEM. The ports have V.24/V.28 andX.21/V.11 interfaces. The interfaces can operate either asynchronously with the X-on/X-off protocol (for connection of a PC) or synchronously with the HDLC protocol. Themaximum transmission rate is 19.2 kbit/s in asynchronous mode (PC connection) or 64kbit/s in synchronous mode (data links).

Input/output processor for serial data communication devices, packet protocol(IOP:SCDP)

The input/output processor for serial data communication devices, packet protocol(IOP:SCDP) consists of the link control unit (LCUB) and the link adaptation unit (LAUB):

A30828-X1130-K500-1-7618 13

InformationControl


– The LCUB is the link control unit, which is connected to the bus system forinput/output control (BIOC) and handles control functions in the IOP:SCDP.

At the user interface, the LCUB appears under the name input/output processor for linkadaptation unit (IOP:LAU). IOP:LAU is the “logical” name of the LCUB.– The LAUB is the link adaptation unit for the BX.25 or X.25 interfaces of the

IOP:SCDP, and is controlled by the LCUB.

Input/output processor for authentication center (IOP:AUC)

The input/output processor for authentication center (IOP:AUC) is only employed inapplications where the CP113D is used in authentication centers (AC) of a mobilecommunication network (D900, D1800 and D1900). In the D900, D1800 and D1900networks, the subscriber’s authorization is checked every time that a call is set upbetween a mobile station and the network. The purpose of these checks is to protect– the mobile communication network from unauthorized access at user and customer

level and– the authorized mobile subscribers against unauthorized access to the mobile

communication network by unauthorized persons or by subscribers attempting tosimulate authorized access.

All of the main protection functions in the AC are handled by the IOP:AUC. The functionof the IOP:AUC is to generate the authentication triplets needed for authenticationduring call setup.

The generation of authentication triplets is a very important security function. It involvesspecific security actions, which is why the IOP:AUC is also referred to as the securitybox.

14 A30828-X1130-K500-1-7618


3 CP113D HardwareThe CP113D hardware has a modular structure throughout. The top level of the struc-ture is the hardware functional units.

The functions of the hardware functional units are implemented in modules. In somecases, a module corresponds to a hardware functional unit. But hardware functionalunits can also consist of several modules.

3.1 Program Execution Part (PEX), Module CPEXand Access Control (AC), Module CPAC

Program execution part (PEX)

Depending on whether the PEX is used as BAP, CAP or IOC, specific hardware func-tions are activated depending on the mounting location.

Module CPEX

The microprocessor is the central control component, on which the operating programsrun. The data and address buses of the microprocessor are decoupled twice, to the localbus and to an internal bus.

Program execution in the microprocessor can be interrupted at any time via the interruptlogic. Interrupts (max. 16) can be set by hardware or software via the BCMY, by the ownprocessor or by another processor.

The internal and ready signals control all processes related to access to the CPEXmodule.

The request logic receives requests from the microprocessor and generates signalsdepending on the type of cycle to be executed.

The timer contains counters for periodic program interrupts and freely assignable timers.

The breakpoint logic is only used for testing during the design phase.

The memory (EPROM) contains programs for hardware recovery, diagnosis and errortreatment. The memory in the IOCs also contains programs for input/output control andfor the call-processing and O&M peripheries.

The clock logic receives the 33-MHz clock from module CPCL, generates timing signalsof 16 and 8 MHz and distributes timing signals to the relevant processor half. The “clocklogic” component is not shown in Fig. 3.1.

Module CPAC

In the event of access violation, the access control starts the relevant error treatment.

The AC arbiter (access control) administers the requests for access to the local bus.

The local bus control generates the necessary control signals for a cycle on the instruc-tions of the arbiter.

After being started by the local bus control, the input/output control decodes the bits ofthe logical address and generates control signals for internal sequences in the AC andfor other modules belonging to the processor.

A30828-X1130-K500-1-7618 15

InformationControl


Fig. 3.1 Block diagram of modules CPEX and CPAC

3.2 Cycle Control (CC), Module CPCC,and Local Memory (LMY), Module MUH

Module CPCC

The EDC logic (error detection and correction), together with the cycle, fault and readycontrol circuits, provides error protection for data traffic with the BCMY and with the LMYand when receiving IPC information. Any errors occurring during a cycle, and theirsymptoms, are stored in error registers, from which they can be read and which can bedeleted after the error has been dealt with.

The input/output control generates control signals for reading from, loading to andclearing the EDC logic, the error registers and the alarm timers for ready timeout andwatchdog.

The LMY control is an autonomous logic circuit within module CPCC, which has noconnections to the other components of the CPCC.

The functions of the LMY control are split across two controls:– LMY control 0, which belongs to module CPCC in PU0 and

CPAC

CPEX Micro-processor

Requestlogic

Breakpointlogic

TimerInterruptlogic

Memory(EPROM)

Internaland ready

control

Port for hardware tracer

AC arbiter,internal control of

the local bus

Comparator

Local bus ofprocessor

AC memory

Baseaddress

Maximumoffset

Accessrights

Mapping

Interface for hardware tracer

16 A30828-X1130-K500-1-7618


– LMY control 1, which belongs to module CPCC in PU1.

LMY control 0, which forms part of the CPCC in processing unit PU0, handles read andwrite access to the data (user bits) in the LMY; access to the memory medium for userbits (see Fig. 3.2).

LMY control 1, which forms part of the CPCC in PU1, starts the error correction code forthe memory media containing ECC data in the LMY (check bits); access to the memorymedium for check bits (see Fig. 3.2).

Both LMY controls start refresh cycles for their memory media at regular intervals.

Module MUH

The capacity of the local memory (LMY) depends on requirements and ranges from 16Mbyte (smallest size) to 32 Mbyte (largest size).

The LMY is built up of memory unit H (MUH) modules, which are equipped with DRAMmemory chips (memory medium).

The refresh cycle for the memory chips is executed by LMY controls 0 and 1 on moduleCPCC. In the following text, the memory chips are referred to as the LMY memorymedium.

Smallest storable unit in the LMY

From the point of view of the LMY, data to be written to or read from the LMY memorymedium consist of a sequence of bits, which the LMY recognizes as user bits or checkbits.

The smallest storable unit is a 39-bit memory word, consisting of two parts:– 32 user bits and– 7 check bits

User bits represent data, e.g. write data, transferred from processing unit PU0 to LMYcontrol 0 during a write cycle, to be written to the LMY memory medium.

LMY control 1 generates the check bits from the 32 user bits in a memory word, in otherwords from the data to be written to the LMY memory medium. The generated check bitsare written to the LMY memory medium separately from the user bits (see Fig. 3.2). Ina read cycle, the check bits are used to check the validity of the 32 user bits in a memoryword.

Organization of the LMY memory medium

The LMY memory medium is divided into two main areas:– the user-bit area for the user bits of the memory words– the check-bit area for the check bits of the memory words

A30828-X1130-K500-1-7618 17

InformationControl


Fig. 3.2 Block diagram of modules CPCC and MUH

3.3 Coupling Logic (CL), Module CPCL,and Common Interface (CI), Modules CPCIA/CPCIB

Module CPCL

The recovery logic checks for compliance with the recovery conditions and starts thereset logic if required.

The comparator logic checks that the two PUs are operating in synchronism. Itcompares the output of the two PUs on the basis of significant signals sent to the CPCLby the two PUs over the local bus.

The reset logic is used to reset PU0 and PU1 to a defined initial status. Operatingpersonnel can reset the two PUs and thus the CP113D manually by means of theRESET key.

In addition, the reset logic performs safeguarding functions: If, for example, the outputfrom the two PUs is not identical, the reset logic resets the two PUs to a defined initialstatus and raises a comparator alarm. Diagnostic programs are then run in the modulesof the two PUs in order to locate the cause of the error.

The results of diagnosis are written to the diagnostic register, and are also signaled bymeans of visual indications on the faceplate of the CPCL module.

CPCC in PU0

MUHMemory medium for data

(user bits)Memory medium

for ECC(check bits)

Local bus ofprocessor

EDC logic

Parity gene-rator

Input/outputcontrol

Alarm timer

Cycle, error andready control

LMY control 0

Latch anddec. logic

Memorycontrol

Refresh

CPCC in PU1

LMYcontrol

1

PU1PU0

18 A30828-X1130-K500-1-7618


The input/output control generates the control signals for reading, loading and deletingthe module’s internal logic.

The two keys, RESET and BOOT, can be used to activate the reset logic manually fortesting.

A test switch allows the “comparator logic” to be deactivated. This enables the systemto be operated with a single PU only (for testing).

The status register contains the reset causes and information on other events that didnot lead to reset.

The split register contains information on split-mode operation.

Module CPCIA

The main components of module CPCIA are:– latches– hardware tracer logic

The latches transfer information to and from the processor interface unit PI of the BCMY.

The function of the hardware tracer logic is to transfer certain signals and status infor-mation from the processor to the hardware tracer. It also receives control informationfrom the hardware tracer.

Module CPCIB

The main components of module CPCIB are:– read/write control and IPC control– alarm control– internal control

The read/write control handles access via the BCMY. It generates the necessary controlsignals for module CPCIA and for the processor interface unit (PI).

The IPC control (interprocessor communication) handles IPC requests received fromother processors via the processor interface unit (PI).

The alarm control circuit processes hardware alarms originating from the PI or forforwarding to the PI.

The internal control controls access to the components of modules CPCIA and CPCIBand stores various statuses (such as the selector switch) which can be determined bythe software of the CP113D.

A30828-X1130-K500-1-7618 19

InformationControl


Fig. 3.3 Block diagram of modules CPCL,CPCIA and CPCIB

3.4 BIOC Interface, Modules IOCIF0 and IOCIF1The BIOC interface is only present in the IOCs, where it serves as the interface to thebus system for input/output control (BIOC). Up to 16 IOPs can be connected to the BIOC- and the IOPs in turn provide connections to the exchange’s peripheral units, forexample CCNC, MBG, OMT or MDD.

Module IOCIF

The control logic fetches addresses, data and parity bits from the BIOC and places data,parity bits and the output signal on the BIOC.

Module IOCIF has internal buses for the transport of addresses and read/write data;these buses are decoupled from the local IOC bus and from the BIOC by means of regis-ters or drivers.

The input/output control and IPC control decode the address bits of the local bus andeither generate the control signals to read/load/delete the IOCIF’s internal logic or acti-vate the control logic for read/write operations.

The IOC arbiter administers requests for access to the local bus and generates thesignal for bus allocation.

Local bus to thePI (BCMY1), to

which theprocessor isconnected

Local busof processor CPCL

PI inBCMY0

CPCIA

Split-register

Status-register

Dia-gnosticregister

Dia-gnosticregister

Keys/Indicators

Input/output controlRecovery and reset logic

Clock generatorClock and voltage supervision

Transfer

Comparatorlogic

CPCIB

Hardwaretracerport

Latch 1Latch 0

Read/writecontrol and IPC

controlAlarmcontrol

Internalcontrol

Input/output-requests, CMY

requests

PI inBCMY1

Local bus to thePI (BCMY0), to

which theprocessor isconnected

20 A30828-X1130-K500-1-7618


The parity generator/checker generates the parity bits for the IPC data and OUT data.

If the IOP supervisory circuit is activated, an entry is made in the IOP error register. If itis possible to attribute the error to a specific IOP, an arbitration lock is set for this IOP.If it is not possible to attribute the error, the arbitration lock is set for all IOPs served bythat IOC and instructions are sent to reset all IOPs.

Fig. 3.4 Block diagram of modules IOCIF0/1

3.5 Processor Interface Unit (PI), Modules PIADR and PIDATThe processors, BAP, CAP or IOP, are connected with redundancy to BCMY0 andBCMY1 via the processor interface units (PI). There is one PI for each BAP, CAP, IOCin both BCMY0 and BCMY1.

Each group of 4 PIs in a BCMY, together with the associated decentral bus arbiter, formsa processor interface group.

Module PIADR

Addresses sent by the processor are transferred to the block address latches anddrivers, while control instructions are transferred to the driver logic. In parallel to this, thefollowing information is transferred to the request logic: the number of the selectedmemory bank in the CMY and the number of the timeslot. The request logic then

BIOC for connection of up to 16 IOPs

IOCIF0

Input/outputcontrol

Requests from IOP8through IOP15

Input data fromIOP0 through IOP15

Output data only fromIOCIF0 to IOP0 thru’ IOP15

IOCIF1

AddressesData

IOPsupervi-

sion

IOP errorregister

IOC arbiter

Paritygenerator/checker

ControllogicAddress-

esData

Input data fromIOP0 through IOP15



PU0 PU1


Paritybits

A30828-X1130-K500-1-7618 21

InformationControl


requests a bus cycle from the bus arbiter. At the same time, the PIAC logic sets thesignal “PIAC - not ready for processor request” for the processor.

The input/output transmit control receives and executes input/output instructions. Thedestination and operation code of an instruction are transmitted in the address bits.From the BCMY, they are sent to the bus address receiver. Its outputs to the module’sinternal address bus are enabled by the input/output decoder as soon as the latterdetects an active input/output signal.

When the decoder for physical/logical port numbers identifies a port number that is validfor this PI, instruction decoding commences in the instruction decoder and registers. Nodecoding takes place if the parity check network detects an error in the address duringan input/output cycle. In such cases, an alarm is raised and reported to the inhibit-bitand reset logic.

When an input/output instruction is decoded that requires a response, the input/outputresponse control switches the control signals and data drivers to the BCMY at thecorrect time for the response. If an input/output instruction does not require a response,the only actions are to activate switches in the PI or to send messages to the processor,in accordance with the instruction.

Module PIDAT

On module PIDAT, the request logic, input/output decoder, input/output transmit controland the input/output response control have the same functions as the equivalent compo-nents on module PIADR. These functions are carried out in synchronism with the clock,on both modules.

The control signals and addresses sent by the connected processor are received by thedriver logic if their destination is the control on module PIDAT. In the next bus clockinterval, the data sent by the processor over the information lines are written to theregister for data from the processor.

In a memory write cycle, the request logic causes the drivers for the data, address andcontrol lines to both BCMYs to be enabled. In a memory read cycle, the drivers for thedata lines remain disabled.

22 A30828-X1130-K500-1-7618


Fig. 3.5 Block diagram of modules PIADR and PIDAT

3.6 Decentral Bus Arbiter for Common Memory (DARB)Every processor interface group includes a decentral bus arbiter for common memory(DARB).

Allocation of the BCMY to a processor interface group and from there to one of the 4processor interface units (PI) is performed interactively by the decentral and the centralbus arbiters.

The decentral and central bus arbiters are described in the section dealing with moduleCARB.

Module DARB (see Fig. 3.6) also accommodates the voltage supervision for the 4 PIsin the processor interface group.

to/from connected processor (BAP, CAP, IOC)

Info. line

Buserror

signal-ing

Proces-sor

alarmregister

Input/out-put

responsecontrol

Registerfor data

fromprocessor Address

latches

Driver,decoder forphys./log.

port number

Addresses

Input/out-put

transmitcontrol

Input/outputdecoder

Parity checknetwork

Multi-plexer

Registerfor data

fromBCMY

Instructiondecoder andinstr. register

Driverlogic

to/from module BBFR

Read-registercontrol

Data

to/from moduleDARB

Re-questlogic

Inhi-bit bitand

resetlogic

PIAClogic

Module interface

PIADR PIDAT

A30828-X1130-K500-1-7618 23

InformationControl


Fig. 3.6 Block diagram of module DARB

3.7 Central Bus Arbiter for Common Memory (CARB)Up to 4 decentral bus arbiters, or DARB modules, can be connected to the central busarbiter implemented by module CARB. The 4 decentral bus arbiters belong to processorinterface groups 0 to 3.

to the central busarbiter (module CARB)

Load

Decoder

Processor selection tables

to/fromcentral

busarbiter

(moduleCARB)

GRANTlogic

Multiplexer

LogicalAND linkage of the input

signals

Input/outputrequests

Memoryrequests

PI0 to PI3 in a processor interface group

Timeslotreservation

Table numberstorage

GRANT

Selectedprocessor

Register forPI0 - PI3

Register fortable numbers

BCMY requests from the processor interface group

Delete

24 A30828-X1130-K500-1-7618


Fig. 3.7 Block diagram of module CARB

3.8 Common Memory, Control, Microprocessor (CMYMP)The external memory for the microprocessor comprises a program memory (EPROM)and a data memory (RAM). Microprocessor signals are used to select which memory isaccessed. Read and write access to the external memory are controlled by processorsignals.

The diagnostic register is used to store results of diagnosis (error numbers), originatingfrom the user-bit control, check-bit control and the memory medium.

The diagnostic register is also used for communication between the user-bit control andthe check-bit control.

The MP read registers are used for communication between the microprocessor and thememory medium.

The microprocessor processes the data in accordance with the firmware loaded in theCMY.

GRANT logic

Selectedprocessorinterface group

Input/outputcycle

Table numbermemory forinput/output

cycles

Multi-plexer

Table numbermemory for

memorycycles

Registerfor processor

interfacegroups

Groupselection

tables

Register fortable

numbers

BCMYrequest

BCMYbus

control

from the 4 decentral bus arbiters

BCMYbus

control

to the 4decentral

bus arbiters

BCMYbus

control

A30828-X1130-K500-1-7618 25

InformationControl


Fig. 3.8 Block diagram of module CMYMP

3.9 Common Memory, Data Network (CMYD)The data input buffers, EPD0 and EPD1, receive data from both BCMYs. The datareceived from the BCMY are destined to be written to the memory medium.

The function of the data selection control is to generate the enable signals for theoutputs of the receive buffers. They are selected in accordance with the setting of theselector switch.

The data write register makes data available from the microprocessor for the CMYmemory medium.

The data correction network corrects single-bit errors in the write data and forwardsthese data to the cyclic memory. From here, the data are forwarded to the memorymedium (MUH).

The ECC generator (error correcting code) is also connected to the cyclic data memory.It generates the check bits for the user bits.

The data are monitored with the aid of two EDC components (EDC = error detection andcorrection). If an error is detected, single-bit errors are corrected.

Data monitoring checks take place:– before data are written to the CMY memory medium– during operations to read a memory word (user bits and check bits) from the CMY

memory medium

Errors are detected by means of the check bits, and single-bit errors are corrected(ECC).

Interruptsfrom

CMY2C

Data (fromthe memorymedium) to

the MKmemory inter-faces of thetwo BCMYs

and to CMYD

Data fromthe

memorymedium

CMYMP

Paritymonitoring

MP readregister

Microprocessor

Externalmemory for

microprocessor(RAM)

Externalmemory for

microprocessor(EPROM)

Diagnosticregister

Alarmsfrom

CMY2C

Addressinformationto CMYA

26 A30828-X1130-K500-1-7618


Fig. 3.9 Block diagram of module CMYD

3.10 Common Memory, Control, Part 1 (CMY1C)The scheduler supplies the control signals for the memory banks for the different typesof memory cycles, such as read, write or refresh.

The control signals are sent to the MUH memory modules via the memory accesscontrol.

The clock selection control sets the selector switch when receiving information from thetwo BCMYs.

If the selector switch is operated, e.g. to switch from BCMY0 to BCMY1, during execu-tion of a cycle, the clock selector switches the received timing signals in such a way thatthe operations of the cycle in progress are not disturbed.

The refresh control refreshes the bits (user bits and check bits) in the dynamic RAMchips at regular intervals. The RAM chips are located in the MUH memory modules.

Data fromthe

memorymediumvia

CMYMP

Data(originating

from theBCMY) to

the memorymedium

Data fromthe twoBCMYs,

destined tobe written

to thememorymedium

CMYD

Dataselectioncontrol

Data inputbuffer EPD0

Cyclicmemory

Datamonitoring

Datawrite register

ECCgenerator

Data inputbuffer EPD1

Alarmsrelating to

data errors inthe memory

medium

Datacorrectionnetwork

A30828-X1130-K500-1-7618 27

InformationControl


Fig. 3.10 Block diagram of module CMY1C

3.11 Common Memory, Control, Part 2 (CMY2C)The CMY alarm register is used to store alarms and status signals that originate withinthe CMY.

The bank alarm register stores the bit errors detected by the EDC components onmodule CMYD.

The simulation register is used by the microprocessor on module CMYMP to simulatealarms during diagnosis.

The control register is used by the microprocessor to control special memory cyclessuch as scrubbing and diagnosis.

The instruction code register contains the instructions for the microprocessor.

The selection circuit monitors the control signals received from the two BCMYs bycomparison. If the two control signals are not identical, a comparator alarm is raised onmodule CMYMP. To allow the memory cycle to be completed without error in suchcases, bus selection is switched over to the other BCMY.

The voltage supervision monitors the voltage to ensure that it remains constant. Powerfailure causes the microprocessor to be reset, and this in turn activates the followingactions: starting the initialization program, aligning clock selection, resetting the user-bitcontrol and check-bit control.

Timingsignals from

bothBCMYs

Controlsignals

to the MUHmodules ofthe memory

medium

Controlsignals

fromCMY2C

CMY1C

Scheduler Memoryaccesscontrol

Clockselectioncontrol

Refreshcontrol

Clockselection

signals to:CMYMP,CMY2C,CMYA,CMYD

28 A30828-X1130-K500-1-7618


Fig. 3.11 Block diagram of module CMY2C

3.12 Common Memory, Address Network (CMYA)The two address input buffers, AEP0 and AEP1, fetch addresses from the memory inter-faces MI of BCMY0 and BCMY1.

The address selectors in the two BCMYs control the MP address control.

In addition, the MP address control switches the MP address counter and, in refreshcycles, the refresh address counter.

Before data are written to the memory medium, the address network checks them foreven parity. If a parity error is detected, the current write cycle is invalidated and a repeatwrite cycle is executed 4 timing signals later, using the addresses and data from theother AEP.

Fig. 3.12 Block diagram of module CMYA

Alarms from the MUHmodules of the memory

medium

Control signals toCMY1Instructions from both

BCMYs

CMY2C

Control signals fromboth BCMYs

Interrupts toCMYMP

Alarms toAlarms toCMYMP

Addressinformation

fromCMYMP

Addressinformationto the MUH

modulesof the

memorymedium

Addressinformationfrom bothBCMYs

CMYA

Microprocessoraddress control

Address inputbuffer AEP0

Addressparity network

Address inputbuffer AEP1

Microprocessoraddress counter

Refreshaddresscounter

A30828-X1130-K500-1-7618 29

InformationControl


3.13 Input/Output Processor for Message Buffer (IOPMB)The transceivers and latches for BIOC decouple the BIOC from the IOP’s internal bus.The transceivers for input/output and the registers for transmitted and received signalsdecouple the IOP’s internal bus from the line system for IOP (LSY:IOP) leading to thecall-processing periphery.

The control logic controls and monitors the LSY:IOP interface and monitors the interfaceto the BIOC. Its functions include:– receiving and processing IPC instructions (such as initializing the IOP:MB and

reloading programs from the CMY)– receiving and forwarding input/output messages from and to the call-processing

periphery– generating and monitoring the parity bits being sent to the BIOC and to the call-

processing periphery

The control logic is implemented in an application-specific integrated circuit (ASIC).

The microprocessor is responsible for executing programs and controlling the sequenceof program execution.

The clock generator generates the 40-MHz clock for the microprocessor and the 20-MHz clock for the other clocked hardware on the module (e.g. for the multifunction chip).

The local memory is organized into words of 32 bits. It has a capacity of 128 kbyte andcontains the programs for the IOP:MB. The programs are loaded to the local memoryfrom the CMY.

The multifunction chip combines the following functions:– interrupt handling– timing control by means of timers for monitoring the LSY:IOP interfaces to the call-

processing periphery and the IOC and to the program scheduler

30 A30828-X1130-K500-1-7618


Fig. 3.13 Block diagram of module IOPMB

3.14 Input/Output Processor for Time and Alarms (IOPTA)The B:IOC interface decouples the BIOC from the IOP’s internal bus.

The microprocessor controls program execution within the IOP:TA via the internal bus.

The clock generator generates the timing signals for the microprocessor and the multi-function chip.

The memory is used to store the firmware and data for the IOP:TA (microprocessor andtimers).

The hardware clock on the module is duplicated. It is implemented as firmware in twomicrocontrollers.

The multifunction chip combines the following functions:– interrupt handling– timing control by 4 timers– parallel-serial conversion and serial-parallel conversion for data being sent to and

received from the serial interface

Alarms (such as air conditioning alarms) are sent to the IOP:TA over the serial interface.A maximum of 5 racks can be connected to the alarm interface by cable. Each cablecarries 8 alarm lines.

The module faceplate contains 4 two-digit displays for time and status. The displays areactivated by means of a key.

The CCG interface contains logic circuits for selecting the clock from CCG0 or CCG1.

Call-process-

ingperiphery

LSY:IOPBIOC

Clock generator

MicroprocessorControl

logic(ASIC)

Trans-ceivers

andlatches

forBIOC

Trans-ceivers

forinput/output

Registerfor trans-

mittedand

receivedsignals

Memory(local)

Multi-function

chipInterrupt

A30828-X1130-K500-1-7618 31

InformationControl


Fig. 3.14 Block diagram of module IOPTA

3.15 Input/Output Processor for Magnetic Disk Device(IOP:MDD), Modules IK:DTD and IF:MDD

Module IK:DTD

The clock generator generates the timing signals for the microprocessor and the otherclocked components such as timers and interrupt handler (IF:MDD).

The microprocessor is responsible for executing programs and controlling the sequenceof program execution on module IK:DTD.

The scheduler coordinates the execution sequence of individual functions and monitorsthe transfer of data to/from the interface module.

The IPC decoder (interprocessor communication decoder) decodes instructions sent bythe BAP-master via the BIOC, such as:– RESET, to reset the IOP:MDD– INIT, to initialize the IOP:MDD– START, to start the IOP:MDD– reading from the MDD– writing to the MDD

The IPC decoder forwards the decoded instructions to the interrupt handler in the formof interrupts.

Control

Rack alarms (5 x 8 lines)

InterruptsBIOC

CCG0

CCG1

Reset

Memory(local)

Alarminterface

BIOCinterface

Micro-proces-

sor

Clock(opera-

tion)

Clock(display)

Multi-function

chip

Serialinter-face

Clockgenerator

Keys Display CCGinter-face

32 A30828-X1130-K500-1-7618


The LED display signals the status of the IOP:MDD, for instance in order to display theresults of an off-line diagnosis.

The timers produce interrupts, which are forwarded to the interrupt handler. The mainfunction of the timer interrupts is to supervise the timing of input/output operations.

The interrupt handler receives interrupts (from the IPC decoder and from the timers) andstarts the relevant routines to process the interrupts.

The BIOC interface decouples the IOP:MDD’s internal bus from the BIOC. Its main func-tions are to:– multiplex and demultiplex the data and address buses– check the parity bits associated with data being sent over the BIOC (transmit direc-

tion)

The memory is built up of:– EPROM memory chips, which contain the IOP:MDD firmware– RAM memory chips to store status data and processing data produced during

program execution

Module IF:MDD

The module “interface for magnetic disk device” (IF:MDD) contains the adapters specificto the connection of a magnetic disk device (MDD).

In simple terms, the IF:MDD is the SCSI interface (ANSI standard) to the driver for themagnetic disk device.

The DMA controller is responsible for controlling data transfers between the IF:MDD’sbuffer and the MDD driver, including error protection. Data are transferred between thebuffer and the MDD driver on the first-in, first-out principle (FIFO).

The buffer serves as temporary storage for input and output data:– Output data are data intended to be written to a file on the MDD.– Input data are data that have been read from a file on the MDD.

Control information is passed between the IF:MDD and the MDD driver via the ports.

A30828-X1130-K500-1-7618 33

InformationControl


Fig. 3.15 Block diagram of IOP:MDD, comprising modules IK:DTD and IF:MDD

3.16 Input/Output Processor for Magnetic Tape Device(IOP:MTD), Modules IK:DTD and IF:MTDMost exchanges are equipped with one IOP:MTD, used to back up essential files ontape and to reload saved files from tape, for instance call charge files, or to output thecurrent APS generation to a save tape.

Module IK:DTD

Module IK:DTD is the IOP kernel.

The functions implemented on IK:DTD are core functions which are identical in bothIOPs - for connecting a magnetic tape device or a magnetic disk device.

Module IF:MTD

The module “interface for magnetic tape device” (IF:MTD) contains the adapters specificto the connection of a magnetic tape device (MTD).

In simple terms, the IF:MTD is the industry-standard interface (PERTEC) to the driverfor the MTD.

The DMA controller is responsible for controlling data transfers between the IF:MTD’sbuffer and the MTD driver, including error protection.

Clockgenerator

Micro-processor

Memory

Interrupthandler

Scheduler Timer

DMAcontroller

IPCdecoder

MDDdriver

Module IF:MDD interface for MDD(SCSI interface (ANSI standard) to theMDD driver)

Module IK:DTDIOP kernel for MDD and MTD

BUFFER

FIFO

Port 2

Data

Controllines

Port 1

FIFOBIOC

34 A30828-X1130-K500-1-7618


The buffer serves as temporary storage for input and output data:– Output data are data intended to be written to the MTD.– Input data are data that have been read from the MTD.

Control information is passed between the IF:MTD and the MTD driver via the ports.

Fig. 3.16 Block diagram of IOP:MTD, comprising modules IK:DTD and IF:MTD

3.17 Input/Output Processor for Serial Data CommunicationDevices, V.24 Interface (IOP:SCDV)The clock generator generates the timing signals for the microprocessor and the otherclocked components such as timers and interrupt handler.

The microprocessor is responsible for executing programs and controlling the sequenceof program execution on module IOP:SCDV.

The scheduler coordinates the execution sequence of individual functions and monitorsthe transfer of data to/from the connected OMT/OMC.

The IPC decoder decodes instructions sent by the BAP-master via the BIOC, such as:– RESET, to reset IOP:SCDV– INIT, to initialize IOP:SCDV– START, to start IOP:SCDV– transmitting to OMT/OMC (receiving is performed autonomously by IOP:SCDV).

Clockgenerator

Micro-processor

Memory

Interrupthandler

Scheduler Timer

DMAcontroller

IPCdecoder

MTDdriver

Module IF:MTD, interface for MTD(industry-standard interface

(PERTEC) to the MTD driver)

Module IK:DTD, IOP kernel forMDD and MTD

BUFFER

Port20

Port21

Data

Data

Statuslines

Controllines

BIOC

A30828-X1130-K500-1-7618 35

InformationControl


The IPC decoder forwards the decoded instructions to the interrupt handler in the formof interrupts.

The timers produce interrupts, which are forwarded to the interrupt handler. The mainfunction of the timer interrupts is to supervise the timing of input/output operations.

The interrupt handler receives interrupts (from the IPC decoder and from the timers) andstarts the relevant procedures to process the interrupts.

The BIOC interface decouples the IOP:SCDV’s internal bus from the BIOC. Its mainfunctions are to:– multiplex and demultiplex the data and address buses– check the parity bits associated with incoming data arriving from the BIOC (receive

direction)– generate parity bits for outgoing data being sent over the BIOC (transmit direction)

The memory is built up of:– EPROM memory chips, which contain the IOP:SCDV firmware– RAM memory chips to store status data and processing data produced during

program execution

The LED display signals the status of the IOP:SCDV, for instance in order to display theresults of an off-line diagnosis.

Fig. 3.17 Block diagram of module IOP:SCDV, comprising kernel and device inter-face part

Clockgenerator

Microprocessor

Memory

Interrupthandler

Scheduler

BIOC

Timer

DMAcontrol-

ler

IPC decoder

SerialV.24inter-face

Connect:1 localOMT andOMC

Device interface part ofmodule IOP:SCVD

Kernel of module IOP:SCVD

36 A30828-X1130-K500-1-7618


3.18 Link Control Unit (LCUB)The BIOC interface decouples the BIOC from the IOP’s internal bus and performs thefollowing functions:– multiplexing and demultiplexing the data and address buses– generating and checking the parity bits for the BIOC– decoding IPC– transmitting control signals

The control logic handles all tasks related to accessing the local functional complexesand interfaces on the module, e.g.:– clock division– address decoding– controlling access to the memory and the LAU interface– generating parity bits and monitoring parity for the memory

The control logic is implemented as an ASIC.

The microprocessor controls program execution on module LCUB.

The clock generator produces 32-MHz timing signals. The control logic produces the 16-MHz timing signals for the microprocessor by means of frequency division. The micro-processor’s clock is monitored by the hardware.

The memory consists of a flash EPROM memory and a RAM memory.– The flash EPROM memory is the programmable read-only memory used to store the

IOP:LAU’s firmware and software. During power-up of an IOP:LAU, the first part ofthe sequence is run from the firmware in the flash EPROM memory.

– During the second part of the power-up sequence, the entire firmware and softwareare loaded from the flash EPROM to the RAM memory; (optionally, they can also beloaded from the CP). Firmware and software execution for normal operation is thenrun from the RAM memory.

The firmware and software in both memories (flash EPROM and RAM) are protected bychecksums and parity checks.

The main functions of the multifunction chip are:– interrupt handling– timing control by means of 4 timers (e.g. for setting periodic interrupt events)

An LCUB is cross-linked to the two LAUB modules (LAUB-own and LAUB-partner of theIOP:LAU pair) via the two LAU interfaces.

Data transfer from the LAU interfaces of an LCUB to the two LAUB modules (LAUB-ownand LAUB-partner) takes place over two asynchronous, 16-bit wide, multiplexedaddress and data buses, one for each module. The multiplexed address and data busis protected by parity checks.

A30828-X1130-K500-1-7618 37

InformationControl


Fig. 3.18 Block diagram of module LCUB, link control unit for LAUB

3.19 Link Adaptation Unit (LAUB)An LAUB module has two interfaces that use the BX.25 or X.25 protocol for the connec-tion of data terminals, data-link terminating equipment and data transmission equip-ment. The connections are made using cables (X25LINK data links), as describedearlier. The connectors fitted to the cables used for the X25LINK data links must be suit-able for one of the (physical) possible interfaces, X.21, V.24, V.35 or V.36.

Each of the two interfaces is controlled by a multiprotocol chip. The use of two multipro-tocol chips allows the two interfaces to operate separately from and independently ofeach other. Consequently, input/output operations at the interface for X25LINK0 can beperformed separately from and independently of input/output operations at the interfacefor X25LINK1.

The multiprotocol chips control the input/output operations for X25LINK0 andX25LINK1, corresponding to the layer-1 data link control functions.

In addition, the multiprotocol chip controls program execution on module LAUB.

The memory consists of an EPROM memory and a RAM memory.– The EPROM memory is used to store the firmware for module LAUB, for instance

procedures for sequence control of functions, protocol handling and error protection.– The main contents of the RAM memory are the current parametric data on execution

statuses of procedures, plus the input/output data for input or output over theX25LINK to/from the connected equipment.

The control logic (implemented as an ASIC) controls access to the memory. The LAUBis also linked to the LCUB modules (LCUB-own and LCUB-partner of the IOP:LAU pair)via the control logic.

LAUB-own

LAUB-partner

16-MHz clock

Clockgenerator

Controllogic

FlashEPROMmemory

Multi-function

chip

Micro-processor

BIOCinterface

32-MHz clock

BIOC

V.24 interfacefor testing

RAMmemory

LAUinterface

38 A30828-X1130-K500-1-7618


Fig. 3.19 Block diagram of module LAUB, link adaptation unit of IOP:SCDP

3.20 Input/Output Processor for Authentication Center(IOPAUC)The BIOC interface decouples the BIOC from the IOP’s internal bus. Its functions are asfollows:– multiplexing and demultiplexing the data and address buses– generating and checking the parity bits for the BIOC– decoding IPC– transmitting control signals

The control logic handles all tasks related to accessing the local functional complexesand interfaces on the module.

The control logic is implemented as an application-specific integrated circuit (ASIC).

The microprocessor controls program execution on module IOP:AUC.

The clock generator produces 32-MHz timing signals. The control logic produces the 16-MHz timing signals for the microprocessor by means of frequency division. The micro-processor’s clock is monitored by the hardware.

The local memory is used to store the firmware for operation of the IOP:AUC. The bootand loader programs are stored in an EPROM memory, and the authentication keys andparameters are stored in an EEPROM memory. The local memory is protected by paritychecking. The parity bits are generated and monitored by the control logic. The read-only memories are protected by checksums that are monitored by the software.

The multifunction chip combines the following functions:– interrupt handling– timing control by means of 4 timers (e.g. for setting periodic interrupt events)

The multifunction chip also has a serial interface (V.24). A chip-card reader can beconnected to this interface in order to load encryption parameters.

Clockgenerator

Multi-protocol

chip

EPROMmemory

RAMmemory

Power supply

Multi-protocol

chip

Controllogic

(ASIC)

X25LINK0options:

X.21,X.24,V.35,V.36

48 V... 60 V

+5 V32-MHz clock

X25LINK1

LCUB-own

LCUB-partner

A30828-X1130-K500-1-7618 39

InformationControl


Fig. 3.20 Block diagram of module IOPAUC

3.21 Capacity StagesFig. 3.21 illustrates the various capacity stages of the CP113D. The smallest-capacityversion of the CP113D contains only two base processors (BAP) and two input/outputcontrols (IOC). Up to sixteen input/output processors (IOP) can be connected to eachIOC. The system can be expanded by adding call processors (CAP), further IOCs andfurther IOPs. The largest-capacity version of the CP113D is equipped with two BAPs,ten CAPs and four IOCs.

16-MHz clock

Clockgenerator

Control logic(ASIC)

Memory(local)

Multi-function

chip

Micro-processor

BIOCinterface

32-MHz clock

BIOC

Serial interface (V.24)

40 A30828-X1130-K500-1-7618


Fig. 3.21 CP113D capacity

Maximum capacity of CP113D

BIOC BIOC

IOC3IOC1

15IOP

0

BCMY1

0

BAPM

15

CMY1

BCMY0

IOP

IOP

IOP

CMY0

BAPS IOC0CAP9 IOC2CAP0

Basic-versionCP113D

BCMY0

A30828-X1130-K500-1-7618 41

InformationControl


4 Safeguarding

4.1 Hardware fault detection by the hardwareDefects in the hardware detected by hardware monitoring circuits as soon as they occur.This prevents the fault from being transferred to other units. If faulty data can becorrected by the use of redundant information, this is done without an error messagebeing issued. Two basic principles apply to the detection of hardware faults by moni-toring circuits:– The addresses and data are saved by an "error correction code" during transmission

(memory cycles, inter-processor communication) and the data also in the memories(LMY, CMY). The transmission via the BIOC is monitored by parity for theaddresses, data and control lines.

– The BAP, CAP, IOC, the CMY control and the control logic of the BCMY are inter-nally duplicated; they are operated micro-synchronously and the results compared,or (in CMY) checked for equality by an ECC check.

4.1.1 Error detection in the BAP, CAP, BCMY, CMY in the CP113D

Comparator logic (in CL, to point 1)

Certain important signals of PU 0 and PU 1 are compared in the CL. Errors activate thereset logic and start the PRO diagnosis.

EDC logic (in CC, to point 2)

The EDC logic safeguards the data exchange between LMY and processor andbetween B:CMY and the processor. Depending on the cycle, it performs the followingtasks:• Generating 7ECC bits for the 32 data bits of the local bus• Detecting single-bit or multiple-bit errors in read data• Correcting single-bit errors in read data

Depending on the cycle checked, the single-bit or multiple-bit errors detected by theEDC logic in the EDC check either cause the cycle to be repeated or initiate the ”BUSERROR ROUTINE”.

Comparator logic (in CI, to point 3)

Important control signals from each B:CMY are transmitted in duplicate to the processorand compared in the CI. Any errors detected are assigned to the B:CMY and cause theB:CMY to be reset (i.e. cause the setting of inhibit bits in all PIs for this B:CMY).

Comparator logic (in PI, MI, bus controller, CMY, to point 4)

Each B:CMY has its own duplicated controller (bus controller) and duplicated controllines. The duplication is merely used to enable errors to be detected quickly bycomparing the control signals in the PI, MI, CMY and the controller itself. Depending onwhere a different result arises, the error is assigned to the corresponding unit.

Address parity check (to point 5)

In both CMY cycles and IO cycles (inter-processor communication or safeguardingcommands), an address parity check is performed. Detected errors are assigned to theB:CMY and cause it to be reset.

42 A30828-X1130-K500-1-7618


Data check (to point 6)

For error detection in memory, the ECC check is used primarily. If the data from theprocessor (write cycle) are faulty, the data are taken from the other bus for one-bit errors(only for the faulty cycle). Multiple-bit errors cause the B:CMY to be reset and the CMYto be switched over permanently.

If the data from the storage medium are faulty, the MI switches to the data from the othermemory (only for the faulty cycle). Multiple-bit errors cause the preferred direction in theMI to be switched, memory diagnosis to be started in CMY, and alarm treatment to bestarted in the BAP.

Fig. 4.1 CP113D monitoring principle

PROC

PU-0

LMYECC 2

EDC 2

P 5

PU-1

EDC 2

P 5

CLCOMP 1

CI 3COMP

ECC

COMP

P

EDC

Comparator

Parity check(addresses)

Error detection - correc-tion logic (Data)

Error detection andcorrection code (Data)

see Continuation Fig. 4.2

A30828-X1130-K500-1-7618 43

InformationControl


Fig. 4.2 CP113D monitoring principle (Continuation)

4.1.2 Error detection in the IOC and IOPThe IOPs and devices are not duplicated internally for error detection, in contrast to theprocessors and IOCs. Error detection occurs in the IOCs and in the IOPs and thedevices themselves by means of hardware circuits, or the software for the I/O area.

Error detection in the IOPs (for IOP and devices)

All IOPs check the input data from the IOC by means of a parity check. Additional errordetection features vary, depending on the IOP type.

Errors affecting the IOP are reported to the IOP:MB by means of a continuous requestsent to the IOC (and thus also to the PIO:IOC). Errors in the other IOP are reported tothe PIO:DEV/PIO:TA or are detected by same.• IOP:MB

– Parity check to call processing periphery with one parity bit per byte– Watchdog for program sequence monitoring– Loop before and after the transmitters/receivers to call processing periphery, and

before the address and control line transmitters to the IOC– Monitoring of the interface to the CP periphery– Self-supervision within the scanning program by means of a short test– Monitoring of the interface procedure to the IOC

0

Control-ler 1

0

Control-ler 1

PI PI

Medium

6

BCMY1

BCMY0

CMY0

C-control

PI

MI

COMP

P

4

5

COMP

EDC

4

COMP

P

EDC

4

5

6

D-control

COMP

P

EDC

4

5

6

ECC

CMY1

44 A30828-X1130-K500-1-7618


• IOP:TAThe hardware clock within the IOP:TA is duplicated. The time is compared cyclicallyby the processor of the IOP:TA to prevent an incorrect time being transmitted. Theprocessor and the clock pulse generator are monitored by hardware circuits.

• IOP:DEVIn the IOP:DEV, i.e. IOP:UNI, IOP:AUC, IOP:SCDP and IOP:SCDV as well as in theMDD and MTD, supervisory circuits for the voltage, clock and parity of the IOP-RAMtogether with a watchdog are provided, depending on the type.The detection of errors occurs in the IOCs, or by means of the PIO:DEV and partlyby the IOP firmware.The interfaces to the devices are monitored by parity checks or procedures fromcase to case.

• IOP:MDD (for magnetic disk memory in the CP113D)The data on the path IOP → magnetic disk memory → IOP are parity-checked byteby byte. The data on the disk medium are safeguarded using ECC code. The ECCcode is generated by the disk controller and used for error detection and correction.If an error is detected during writing with monitored reading, a message is sent tothe job initiator (software). This can lead at first to a retry and, if unsuccessful, finallyto removal of the disk and/or IOP from operation.

• IOP:MTD (for magnetic tape devices in the CP113D)The data on the path IOP → magnetic tape → IOP are parity-checked byte by byte.Write operations are monitored by the magnetic tape device by means of readchecks. Device operations are monitored with regard to maximum duration by theIOP using timers.

• IOP:SCD (for OMT/CT, data links in the CP113D)The IOP monitors the interface protocol.

• IOP:TA (for RCD)Der IOP überwacht das prüfsummen-gesicherte Schnittstellenprotokoll. Außerdemwerden die RCD-Daten plausibilitäts-geprüft.

Error treatment in the IOC (for the IOP)

As a reaction when an error is detected, the corresponding arbiter restriction is set in theIOC, the IOP is reset, and the PIO:IOC in the BAP master is informed via interrupt 4.(The arbiter restriction disables the transmitter of an IOP to the B:IOC, but doe notprevent the flow of information IOC → IOP).

When the power supply fails in an IOP module frame, or for certain interface procedureerrors between the IOP and IOC, all IOPs are reset.

As an IOP can only address the CMY indirectly, i.e. via the AC, it can only corrupt datawithin the windows (= memory ranges) assigned to it. This means that a defective IOPcannot destroy the contents of CMY.

This safety feature is necessary to exclude the possibility of errors spreading, as theerror detection devices in the I/O area generally do not react as quickly as, for example,the comparators of the BAP, CAP and IOC.

4.2 Hardware fault detection by softwareThis refers to routine test programs (for the most part identical with diagnostic programs)that are periodically started.

A30828-X1130-K500-1-7618 45

InformationControl


The memories are read cyclically, checked with the ECC and, if necessary, overwrittenwith corrections (scrubbing).

The magnetic tape device test requires that a tape with a write ring and a valid file ismounted and that the device is switched to ON-LINE.

The routines can be controlled using MML commands:– Display routine test data– Modify routine test data– Inhibit routine tests– Allow routine tests– Stop each started routine test

Detection of hardware faults in the IOP

The PIO:DEV, PIO:MB and PIO:TA detect specific fault patterns in the IOPs and devicesassigned to them - e.g., by means of plausibility checks and time monitoring.

If a fault is detected in this way, the suspect device is fully tested.

Additional plausibility checks in the call processing input/output cause error detection inthe IOP:MB and MBU area.

The failure of all devices (or all MBUs) of an IOP is reported by the corresponding PIOto the PIO:IOC, which then classifies the IOP as suspect.

Detection of undetected faults

Faults in the IOP and devices that do not impair the system operation (faults in supervi-sory circuits or errors in rarely used functions) are detected by routine test programs.The PIO:IOC is wakened by the organization of the routine tests at a suitable (adminis-trable) time, and then starts the routine test programs for the I/O area.

4.3 Hardware Fault TreatmentThe hardware fault treatment process has the task of creating a functional systemconfiguration after the spontaneous occurrence of hardware faults, or for hardwarefaults that are detected by the routine test programs.

The hardware fault treatment process is initiated by:– an entry in an alarm register– pressing the BOOT/RESET key– the bus error routine.

The hardware fault treatment process activated after a fault is detected verifies the faultby using diagnostic programs. Non-verifiable (sporadic) faults are tolerated if they do notoccur repeatedly (the hardware fault treatment process keeps relevant statistics). Forsporadic faults, fault messages are merely stored in a file (HF.MCP.HWERROR). Forstatic faults, a message is given to the operating personnel, and an alarm is caused atthe system panel (SYP).

The error message to the operating personnel contains the modules suspected of beingdefective, so that in manned switching exchanges, the defective module can bereplaced immediately (short repair time).

46 A30828-X1130-K500-1-7618


4.3.1 Operation of the hardware fault treatmentAs a reaction to detected errors, the inhibit bit is set in the BCMY for the unit suspectedas faulty (BAP, CAP, IOC, BCMY, CMY). This activates a ring line (SYSTEM FAILURELine) which is connected to all processors; see Fig. 4.3. This unit also places additionalinformation about the fault and its location in the corresponding alarm register.

The activation of the SYSTEM FAILURE line causes the BAPs to start the hardware faulttreatment process at a high interrupt level (initiated by interrupt 14).

If the inhibit bit has been set for a CAP/IOC because of a bus error, the hardware inter-rupt 14 must also be set in this CAP/IOC. Die The interrupt routine saves only the PIalarm registers in the CAP and IOC to the CMY. Hardware fault treatment, like in theBAP, does not take place.

In the CAPs (and IOCs), no hardware fault treatment occurs apart from the bus errorexception routine.

Fig. 4.4 shows the alarm registers in the CP113. It is important that the alarm registerfor a system unit is always located in the corresponding interface on the BCMY, and viceversa. Thus it can still be ready by the diagnostic program even after the system unit hasbeen switched off. The hardware fault treatment process is started in the BAPs via acontrol line of the BCMY.

These alarm registers are only output as part of an error message in the case ofsporadic errors and are otherwise stored in the file named HF.MCP.HWERROR.

Fault treatment in the BAPs

Interrupt 14 starts the hardware fault treatment process in both BAPs with a precedencerating of 6 (see Fig. 4.3). If the hardware fault treatment process detects that it isrunning in the BAP spare, it terminates itself (exception: master/spare switchover).

In the BAP master, the following activities are performed with a precedence rating of 6:– Evaluate the alarm– Collect and store error symptoms– Start recovery actions– Define configuration actions– Define postprocessing actions

The other fault treatment steps are performed with a precedence rating of 0. The actualmeasures adopted are defined and performed by the hardware fault treatment processwith a precedence rating of 0

The essential tasks of the fault treatment process with a precedence rating of 0 are:• Performing fault verification by means of test tasks. If a fault is detected during veri-

fication, the unit is configured to UNA. If no fault is detected during verification, theunit is configured to ACT.

• Fault verification is monitored statistically to detect sporadic faults.If the statisticalthreshold value is exceeded, the corresponding unit is configured to UNA withoutverification.

• If software errors cause an unmotivated start of the hardware fault treatmentprocess (i.e. a processor interrupt 14 is triggered, although no inhibit bits are set andno alarm register entry exists), the hardware fault treatment process with a prece-dence rating of 0 assumes a software error and reports it to the software error treat-ment (SWET).

A30828-X1130-K500-1-7618 47

InformationControl


• If a unit is configured to UNA, its error messages are entered in the correspondingfile HF.ARCHIVE, there is an output message, and the system status analysis isinformed of the permanent fault.

• When a unit has been configured to ACT following fault verification, the symptomsprovided for sporadic faults are entered in the file HF.MCP.HWERROR.

Fault treatment in the IOCs and IOPs• PIO:IOC

The PIO:IOC does not treat faults in the IOCs, but only in the subsequent units(exception: CP periphery). The responsibility for the IOCs lies with the central CPsafeguarding software.The PIO:IOC receives messages about IOC and IOP faults from the hardware andsoftware. It is the switching point for the analysis of faults and the initiation of faulttreatment actions.The IOP is assigned the "SEIZED" status, and for software messages the arbitrationdisable is also set. If the IOC detects an IOP fault, it sets the arbitration disable. Thenthe PIO:IOC initiates an IOP test. To perform a test for the IOP:MBs, all connectedcall processing equipment must be reconfigured to the redundant IOP:MB. If the testdetects a fault, the IOP is configured to UNA. Otherwise the IOP is reset to the statusit had before the test, and the call processing units ((MBU, CCNC, SYP, CCG) arereconfigured.Fault statistics are compiled for each IOP. When a threshold value is reached, therelevant IOP is not tested, but returned to UNA status, and corresponding messagesare transmitted to the system panel and the O&M output device. If a unit is config-ured to UNA, the associated symptoms are entered in the correspondingHF.ARCHIVE file, a message is output and the system status analysis is informed ofthe permanent fault.UNdetected IOP and device faults are discovered by routine tests triggered period-ically by the central safeguarding program. If a fault is detected, the devices areconfigured to UNA, and messages are transmitted to the system panel (SYP) andthe O&M (OMT) output devices (see Fig. 4.6, Operation of the system status anal-ysis).

• PIO:MBThe PIO:MBs receive messages from the PIO:IOC about IOP and IOC failures sothat they can switch all call processing equipment connected to the IOPs affected toredundant IOPs.The PIO:MBs receive messages from the IOP:MBs concerning both interface errorsbetween the IOP and the call processing periphery (MBU, CCNC, CCG, SYPC) andinternal faults in the IOP:MBs. By means of messages from the MBU, CCNC, CCG,SYP the PIO:MB analyzes whether there is a fault in the peripheral units, and if soit reports them to the peripheral safeguarding program, and IOP faults to thePIO:IOC.

• PIO:DEV

The PIO:DEV performs the following:– Reporting an IOP fault caused by failure of all devices connected to the IOP.

PIO:DEV informs the PIO:IOC, since a failure of all devices means an IOP faulthas probably occurred.

– Receiving spontaneous fault messages from the IOP:DEVs, and forwarding themto the PIO:IOCs.

– Processing fault messages.• PIO:TA

48 A30828-X1130-K500-1-7618


The PIO:TA performs the following safeguarding tasks for IOP:TA:– Synchronization of clocks after a repeated initial start.– Reporting of fan and temperature alarms to the PIO:IOCs for transmission to the

SYP and output to the O&M output device.– Reporting of faults detected by the IOP:TA to the PIO:IOCs (e.g. CCG clock pulse

and RCD- failure).

Fig. 4.3 Fault treatment with precedence ratings 6 and 0 in the BAPM

Statisticsthresholdreached?

Yes

Yes

No Yes

No

No

Error message,enter in

HF.MCP.HWERROR

Configure toUNA;

enter inHF.ARCHIVE

IOP errordetection byIOC or PIO

No CMY,more than 1 error,

no IOC?

Evaluate alarm

Recovery

End

End

Fault verification:

Start diagnosis

Error detected?

Configure to UNA,error message

End

Precedencerating 0

INTERRUPT 14to BAPM

Precedencerating 6

Activate unit

Inform systemstatus analysis

A30828-X1130-K500-1-7618 49

InformationControl


Fig. 4.4 Location of alarm registers in the CP113

4.3.2 Alarm treatment with the bus error routine of the PROThe bus error routine is initiated by the following hardware units (see Fig. 4.5):– Access control (AC)– Ready time-out logic– EDC logic– WATCHDOG

The bus error routine detects what type of fault is involved from the fault registers andby additional tests.

For hardware faults, the bus error routine sets the inhibit bits for the device affected. Thisactivates the hardware fault treatment in the two BAPs, which then treat the fault.

If there is a software error, the local software error treatment (SWET) is initiated in thedevice.

Access right violations are passed on to an operating system procedure which checkswhether it is really an error, or whether the access control (SLOT) needs to be updated.In the former case the local software error treatment is started, in the latter case the buserror routine repeats the cycle and terminates itself.

The ready time-out logic monitors reading access to the B:CMY and the request signalPEX for local bus assignment.

PRO 0 PRO n

CI CI

BCMY0 BCMY1

CMYALRCMY0

CMYALRCMY1

PROALRPRO0

PROALRPROn

PIALRBCMY0

PIALRBCMY1

PIALRBCMY0

PIALRBCMY1

PROALRPRO0

PROALRPROn

CMYALRCMY0

CMYALRCMY1

MIALRBCMY0

MIALRBCMY1

MIALRBCMY0

MIALRBCMY1

CMY0 CMY1

PI

MI

PI

MI

50 A30828-X1130-K500-1-7618


Fig. 4.5 Bus error routine

Yes

Yes

Windowaccess by aBAP, CAP

Yes

Yes

Yes

Yes

Yes

Yes

No

No

Yes

Yes

Yes

Yes

MC68040

RAM

Accessviolation

WATCHDOGexpired

EPROMTriggerWATCHDOG,disable all interrupts

BERR within thebus error routine

Analyze initiation causes

LMY read cycle?

Return tothe BCMY

test

BCMYtest?

Start CI test(BERR-INF)

Error

IOC

A

Set both FF bits forthis PROC

STOP

Software error

WATCHDOG

BCMY cycle

Accessviolation

SWSG 139

SWSG 133

SWSG 133

SWSG 137

Repeat buscycle

UpdateSLOT

Cancel interruptdisable

Genuinebus error

RTE

A

IOC

Set both FFinhibit bits

STOP

WATCHDOG

NMI

BERR

Undefinedbus error (CCand AC are

not set)

LMY/CMYcycle error

A30828-X1130-K500-1-7618 51

InformationControl


4.4 Detection of software errors by the hardwareThis makes use of the possibilities of the integrated microprocessor chip (illegal code,two privilege levels).

The access control monitors the observation of access rights on the memory level. Ahardware timer (watchdog) supports this monitoring in endless loops.

4.5 Detection of software errors by the softwareThe following principles are used for software error detection:

CHILL

Use of a programming language which– prevents error by structuring or by format checking and data mode checks during

compilation– detects faulty access during the process (runtime checks).

Defensive programming

Plausibility check or coordination when critical data are accessed, or when there is adanger of error distribution (e.g. at interfaces).

Time monitoring (timer) for acknowledgments at interfaces to processors.

System status analysis

By means of an analysis of the system status, error can be detected which were eithernot recognized or wrongly treated by the detection features described so far.

The following errors are detected by the system status analysis:– too many call processors or IOC failed– inconsistency of hardware switches (inhibit bits) and the corresponding configura-

tion diagram 4.6

The system status analysis can be initiated:– automatically after every configuration which reduces the availability of the system– periodically at fixed intervals (for IOP every 10 min.,for central devices the interval

can be set between 15 and 300 minutes)– MML command for consistency check of central devices

Another task of the system status analysis is to preserve the performance level of thesystem by attempting to restart any devices which fail.

52 A30828-X1130-K500-1-7618


Fig. 4.6 System status analysis

Audits

Audits are programs for checking consistency which are called up on demand or peri-odically. THey run as background processes at a low priority. THey calculate achecksum for (semi-) permanent data and code for comparison with an existingchecksum. Transient data are checked for chains, availability or plausibility. If discrep-ancies are detected, the relevant reaction is initiated (e.g. deletion or correction of incor-rect entries; for LTG errors: restart, initial start, etc.).• Checksum validation audit (CHKSUMVA)

Generally, the checksums stored in the CP for the– digit table– timer table– program data– active zone table– passive zone tableare compared with those stored in the GP for each LTG (the program checksum forLTGs with memory >1 Mbyte per load segment). The checksum for program data isstored on the disk.

• Equipment status audit (EQSTA)The configuration states of the CP periphery are stored in the CP memory as dupli-cated data images (transient and semipermanent). These data are also on the disk.A comparison is performed between the data in the CP memory and the data on thedisk. The comparison is used for different checks:– All peripheral devices (CCG, MB, SN and LTG) are checked to see whether their

transient operational status is valid.– The above devices are checked for agreement between the transient and semi-

permanent states.– A check is made for mutual consistency of the states of peripheral devices.– All software and hardware operating states are checked for LIS switches.

No

Yes

Error detected?Activate unit

End

5times

Message from thesystem status analysis

Every 15 min. for allunits in UNA:

diagnosis,system status analysis

Unit remains inUNA

A30828-X1130-K500-1-7618 53

InformationControl


• Trunk status audit (TRUSTA)TRUSTA checks transient line links in inter-exchange trunk lines, PBX lines andannouncement lines:– Line indices in the trunk group header and per line– Lines in idle band that are actually free– Presence of free lines in the idle band

• Interprocessor trunk status audit (IPTRUSTA)The states of 32 ports are transmitted simultaneously to the CP by the LTG. In theCP, the transient states of a port are compared with each other. Then theseized/disabled states in the CP and the LTG are compared.

• Call processing buffer audit (CPBUFFER); Billing register audit (ABILREG)THese audits check the current free pool for discrepancies, and correct it if neces-sary. Active BIRs or CPBs are checked for invalid links to CHR.

• Channel register audit (CHANREG)CHANREG checks all CHR and associated data of the relevant processor (LTG,MBU) for the following errors:– No valid links to other registers (CHR, CPB, BIR)– No valid data in CHR compared with CALL STATE– Invalid CALL STATE /TABLE GS relation– Invalid CALL STATE /PORT STATUS relation– Invalid CALL STATE in relation to existing register link.

• Interprocessor channel status audit (IPCHASTA)– BUSY/IDLE states of channels between SN and LTG are compared (CALL

REGISTER in LTG - TABLE GS in CP).– BLOCKED/UNBLOCKED states of these channels are compared.

• Network configuration audit (NWCONF)The functional states of the TSG and SSG are carried transiently and semi-perma-nently in the CP. NWCONF compares these data.

• Network map audit (NWMAP)Checks for agreement between path data in CHR and TABLE SN/LINK.

Fig. 4.7 Audits

Maintenanceaudits

Port statusaudits

Creates checksum for datain the LTGCompares result with a valuein the CP

Consistency of transient andsemi-permanent states ofCP periphery

Status of units idle lists

Consistency of port states inLTG and CP

Checksum ValidationAudit(CHKSUMVA) IP

Equipment StatusAudit

(EQSTA)

Trunk Status Audit(TRUSTA)

Interprocessor TrunkStatus Audit(IPTRUSTA) IP


54 A30828-X1130-K500-1-7618


Fig. 4.8 Audits (Continuation)

System monitoring (SYMO)

SYMO is responsible for real-time monitoring and deadlock detection (see Fig. 4.9.)• Real-time monitoring

The real-time monitor must ascertain whether processes with priorities 6-15 haverun within a certain time period. The real-time monitor has a string of bits in whichone bit is set per priority pending. SYMO reads this list after the appropriate time,interprets it and deletes it. If priority 6 has been processed, everything is in order. Ifpriority 6 has not been processed, neutralization measures are initiated (trace,SWSG SWET, or the processor inhibit bit is set).

• Deadlock detectionProcesses which require this monitoring must report to SYMO. SYMO then regularlysends messages and expects responses. If a response is missing, this process isassumed to be deadlocked. This is currently only valid for CALLP and SMOMD.

4.6 Software error treatmentThe main task of the SWET (software error treatment) is to define how the systemshould react to a software error. As it is not possible to correct errors automatically asthey occur, steps are taken to neutralize the error. For the correction of error, which canonly be preformed by the developer, SWET provides support in the form of error

IP = Interprocessor auditPPU = Peripheral processing unit

Callprocessingaudits

Consistency of the BIR-POOLSLink: CHR<->BIR

Consistency of the CPB-POOLLink: CHR<->CPB

Consistency of the CHR

Consistency of channelsLTG <-> SN

Consistency of TSG <-> SSG

Consistency of SN tables<->CHR

Billing Register Audit(ABILREG)

Call Processing BufferAudit

(CPBUFFER)

Channel RegisterAudit

(CHANREG)

InterprocessorChannel Status Audit(IPCHASTA) IP

Network ConfigurationAudit

(NWCONF)

Network Map Audit(NWMAP)

Switchingnetworkaudits

A30828-X1130-K500-1-7618 55

InformationControl


symptom recording. The error symptoms collected by the SWET are used for off-lineerror analysis and correction; the correction of the software error is achieved by insertingthe corrected software (PATCH) into the program system.

In the CP113, the SWET is activated when the following events occur:• Detection of implausible data by explicitly coded plausibility checks that are

performed in every user program, above all at interfaces (see Fig. 4.11). After theerror is detected, SWET is activated by the SVC call-up SWSG via the exceptionhandler.

• Detection of system responses by the system monitoring process. Incorrect systemresponses which indicate software errors (e.g. incorrect real-time performance,deadlock, etc.) are reported to SWET by means of the SVC call-up SWSG.

• Messages on software errors by exceptions, e.g. bus error routine. Various incorrectsequences (e.g. invalid operation code) lead to an exception routine beingperformed in the CP113,which in turn activates SWET.

The SWSG numbers 1-127 are module-dependent numbers, i.e. the programmer canuse them individually. Each module can thus define its own SWSG from number 1 to amaximum of number 127. The numbers above 127 are not module-dependent, i.e. theyexist only once in the whole system. The corresponding error symptom package and therequired recovery level are ascertained by means of a table.

Fig. 4.9 SYMO call

REALTIME MONITORING

READ BIT STRINGINTERPRET AND DELETEMESSAGE-> SRMEP(IL0 PRIORITY 6)

WATCHDOG TRIGGER OFF

Yes

No StartSYMO?

WATCHDOG TRIGGER OFF

5 ms

SYMO PROCEDURE

IL4

INTERRUPT 13 (IL6)

JUMP TO SYMO

SET IL4


56 A30828-X1130-K500-1-7618


Fig. 4.10 SYMO call (Continuation)

Fig. 4.11 Example of a plausibility check

4.6.1 Structure of the software error treatmentBecause of the multi-processor structure of the CP113, several software error eventscan occur independently of each other in different processors. This overlap of softwareerrors, and their evaluation with regard to the recovery actions required, make it neces-sary to structure the software error treatment (see Fig. 4.12) into the following:• SWET LOCAL, on each processor:

– interface for software error detection

15

RTE

4

6

5

Real-timemonitoring

WATCHDOG

0

DR

0

1

2

5

6

3

7

PRIORITY

SET IL6

TRIGGERWATCHDOG (RESET)

Request to IL2(GENERATION OFTHE 50-ms CLOCK)

Error symptomspackage

Recoverylevel

Sequentialnumber

SWSG (001, SE_SYPAC_2 SE_NSTART3)

DEST_FIELD:=RECEIVE INBUFF

IF DEST_FIELD. SOURCE = TIMER AND

DEST_FIELD. FORMAT. JOBCODE = 500

THEN MRZLPFRNKST ( );

ELSE

FI;

A30828-X1130-K500-1-7618 57

InformationControl


– interface for the system part of SWET– system stop– analysis of error situation– recording and storage of error symptoms

• SWET SYSTEM, on the BAPM:– definition and triggering of recovery action– recording of statistics

Fig. 4.12 Structure of the software error treatment (SWET)

4.6.2 Operation of the software error treatmentFigure 4.13 and 4.14. show the flow for the software error treatment.

BAP-MASTER BAP-SPARE CAP0 to CAP9

SWET LOCAL SWET LOCAL

SWET SYSTEM

SWET LOCAL

58 A30828-X1130-K500-1-7618


Fig. 4.13 SWET: Basic operation

Continuation at theinterrupted program

address

BleibtSASDAT?

No

No

SASDAT?

Yes

INTERPROCESSOR COMMUNICATION

BAP master Error-detecting processor

Yes

SWET system

Software error

IRH

SWET LOCAL

IDLE-LOOP

IRH Continuation onthe BAP master

Recovery

A30828-X1130-K500-1-7618 59

InformationControl


Fig. 4.14 SWET: Functions

4.6.3 SWET LOCALIf a software error occurs in the BAP or CAP, this immediately triggers the IRH, thus acti-vating SWET LOCAL. The following information is assembled by IRH in a separatememory area, and transmitted to SWET LOCAL:– The current register contents at the time of the interrupt– The SWSG parameters– The semaphore address if the software error is due to a data structure disabled for

too long– Interrupt level from which the interrupt was given

>SASDATS= SASDATS

Software error occurred

SWET LOCAL- Evaluate/set identifier to detect recursive SWSG- Analysis of error situation- Filter SWSG floods- Store error symptoms from the CMY- Cancel the system stop- Record error symptoms from the LMY and the processor hardware- Trigger SWET SYSTEM in BAPM

for SASDAT for N/ISTART

Return to callingprogram

IDLE loop

SWET SYSTEM in the BAPM- Evaluate recovery action (record statistics)- Define recovery action- Trigger software recovery for recovery levels > SASDATS

Software recovery- Reset identifier to end recursivity- Call up software recovery statistics

IRH- Return control

Interrupt Handler- Collect special error messages- Trigger system stop

60 A30828-X1130-K500-1-7618


System stop

If a software error occurs in a processor (CAP, BAP), measures must be taken to ensurethat while the CMY data are being recorded to save the error symptoms, other proces-sors do not alter these data. This would corrupt the error record. Therefore it is neces-sary to stop the system for the phase "Save CMY data".

In system stop, 2 flags are set (CMY, LMY), and all processors are interrupted with ILH.Each processor monitors its own ”flag” in LMY.

If the local flag is set, the procedure resets the flag and terminates itself. This enablesinterrupt level 4 of the processor that detected the error, and SWET LOCAL cancontinue to process the software error.

If the local flag is set, the procedure begins a loop to request the global flag. When theglobal flag is reset, the procedure cancels itself. The processor can continue at the placewhere it was interrupted. The global flag is removed by the active SWET LOCAL of theprocessor that detected the error, after the CMY data are stored.

Detection of recursive SWSG

The term ”recursive SWSG” refers to a SWET call which is issued repeatedly within apermanently defined phase (critical phase) at the same location (via SWSG, runtimecheck, etc.).

To prevent an endless loop of safeguarding sequences as far as possible, it is impera-tive that recursive SWSGs be recognized. To detect recursive SWSGs, the SWET usesidentifiers in the CMY (a flag stating whether SWET is currently active, and the SWSGinterrupt address). If SWET is active and the current SWSG interrupt address is identicalto the last SWSG interrupt address to occur, a recursive SWSG is detected.

The SWET LOCAL uses this identifier to decide whether it has been activated a secondtime within the critical period.

The critical phase covers the entire SWET.

Analysis of the error situation

On the basis of the interrupt information (interrupt address, SWSG number, registercontents, etc.), the following tasks must be performed:– Detection of recursive SWSG– Determination of error type (module-dependent, non module-dependent)– Determination of error location (module identification)– Definition of error symptom package size– Determination of the processor causing the error.

Recording of error symptoms from the CMY

On the basis of error symptom packages detected by the analysis of the error situation(details of any error-specific combination of error symptoms), the corresponding errorsymptoms need to be collected and stored.

The recording and storage of error symptoms have the following tasks:• Entry of error symptoms in permanently defined areas of CMY, known as the

symptom saving areas, which cannot be overwritten by recovery actions (the areasare processor-specific).

• When recursive SWSGs occur, the entry of interrupt error messages (only theminimum = interrupt information) in a permanently defined area of CMY, known as

A30828-X1130-K500-1-7618 61

InformationControl


the EMERGENCY AREA. This area likewise cannot be overwritten by recoveryactions.

• Administration of the processor-specific error message storage area.

Cancelling system stop

After the symptom saving process has stored all CMY data, it cancels the global systemstop flag.

Filtering of SWSG floods

For SWSG with the recovery level SASDAT, error symptom recording needs to besuppressed if the SWSG occurs more than 4 times in 24 hours.

Each SWSG with recovery level SASDAT is monitored for 24 hours. For the first 3 occur-rences, no special treatment is given. If the SWSG occurs a fourth time, a message isgiven that from now on the error symptoms recording and the page printer output will besuppressed for 24 hours (see Fig. 4.15).

After this period has elapsed, the entry in the monitoring table is detected. Monitoring isstarted afresh if this SASDAT occurs again.

Multiple occurrence of SASDAT

If a SASDAT occurs 4 times or more within 24 hours, the operator is informed by anadditional message to the OMT that this, and possibly other SASDAT treatments, will besuppressed for the next 24 hours.

62 A30828-X1130-K500-1-7618


Fig. 4.15 Examples of output messages of SASDAT

4.6.4 SWET SYSTEMTo check the effectiveness of the recovery actions taken, the SWET must keep thefollowing statistics:– Statistics for the frequency of every error which leads to SASDAT– Statistics for the frequency of the recovery levels performed

If the statistics exceed a preset threshold value within a certain monitoring period, ahigher recovery level must be escalated to.

For each escalation (see Tab. 4.1), the escalation level of the highest recoveryperformed in software recovery, and which is still recorded in the statistics, is requested.

CP22/LX77/WOMXBZ1V1150-M04/0000039

3095/0243597-12-31HF.ARCHIVE-00525

12:02:59

ERROR DURING PLAUSI-BILITY CHECK

DATETIMEUNITMODULEERROR

:::::

97-12-3112:02:54BAP MSCSSEZD0C018

! ! ! ! ! ! 1st to 4th SWSG ! ! ! ! ! ! ! ! !

STATISTICS:

=========TIME (SEC):

--------------------------------------------------------------

0000

END TEXT JOB 0039

CP22/LX77/WOMXBZ1V1150-M04/0000039

SUPPRESSION OF THE SOFTWARE DATA SAVINGSTARTED

MODULEERROR

END JOB 0039

GRENZE: STAND:

000 000

3095/0243597-12-31HF.ARCHIVE-00530

12:03:26

::

CSSEZD0C018

*********

A30828-X1130-K500-1-7618 63

InformationControl


Tab. 4.2 shows an example of a printout of recovery statistical information.

4.7 Safeguarding MonitorThe safe guarding monitor is part of the safeguarding software. The control module ofthe safeguarding monitor runs as a process in interrupt level 0, and forms a uniforminterface for safeguarding messages.

Measures to safeguard the call processing periphery are not initiated by the safe-guarding monitor, but rather by the task-specific processes of the safeguarding soft-ware.

The safeguarding monitor performs the following tasks:– Provision of a uniform interface for safeguarding messages– Starting safeguarding processes

Recovery level Escalation to

NS 0 NS 1

NS 1 NS 3

NS 2 NS 3

NS 3 IS 1

IS 1 IS 1B

IS 1B *)

NS 1B IS 2

IS 2 *)

IS 2G *)

*) these values are subject to the hardware escalation decision

Tab. 4.1 Recovery escalation

RECOVERYACTION

MONITORING TIME/SECS THRESHOLD

CURRENT STANDARD CURRENT STANDARD

SSDATSNSTART0NSTART1NSTART2NSTART3ISTART1ISTART2ISTART2GISTART2RISTART2FISTART1BNSTART1B

8060060060060060060060060060060060

8060060060060060060060060060060060

4032222

10

4032222

10

Tab. 4.2 Example of a printout of recovery statistics

64 A30828-X1130-K500-1-7618


– Distribution of safeguarding messages– Coordination of collective messages– Logging safeguarding messages– Definition of type-specific tables and modules

Creating a uniform interface for safeguarding messages

The exchange of messages between safeguarding processes and the rest of the system(especially the call processing periphery and processes external to the safeguardingsystem) is performed exclusively by means of the safeguarding monitor. This ensuresthat the interface between the safeguarding program and the rest of the system is inde-pendent of the process structure of the safeguarding software.

Messages between safeguarding processes are also processed via the safeguardingmonitor. They therefore receive all jobs via the safeguarding monitor, and return allresults via the same route.

Starting safeguarding processes

Whenever the system is started, and after the executive control program has beencompletely initialized, the safeguarding monitor starts most of the cyclical safeguardingprocesses. These include the configuration schedule and several error treatmentprocesses.

Then recovery "under operating system control" is started. After the end of recovery hasbeen signalled, the routine test processes for the call processing periphery, theremaining error treatment processes, the error data output process, the control of thesafeguarding program and the output of recovery data are started by the safeguardingmonitor.

Distribution of safeguarding messages

The safeguarding monitor distributes the safeguarding messages to the processesresponsible for processing. This distribution is normally done by reference to a table.

Each message has a receiver permanently assigned to it. This applies especially totasks issued to safeguarding processes and messages from the call processingperiphery.

Under certain circumstances, however, the standard distribution is overridden:– While recovery is running, recovery receives all messages from the periphery, irre-

spective of which process the messages are assigned to.– If a process exclusively seizes a processor of the call processing periphery (by the

configuration task SEZ/BEL), the safeguarding monitor sends all messages for thisprocessor to this process.

– While a processor is being configured, the device-oriented configuration programreceives all messages for the processor.

Coordination of collective messages

The safeguarding software is a privileged user of IOCP and can issue a collective taskat any time. The safeguarding monitor coordinates collective tasks of different safe-guarding processes by performing the exchange of messages for collective tasks insuch a way that parallel tasks are transmitted too the IOCP in sequence.

A30828-X1130-K500-1-7618 65

InformationControl


Logging safeguarding messages

The safeguarding monitor logs all safeguarding messages that pass through it by savingthem in the hard disk file SG.OPER. Any messages which have a corresponding entryin the monitor’s distribution table, or for which the sender expressly requests no longer,are excluded form these logs.

Examples of logged messages are:– Fault messages from the call processing periphery– Commands from safeguarding processors to the call processing periphery– Result reports from the safeguarding software

The storing of the messages enables the sequence of the safeguarding software to betraced. It can be used for optimization of the safeguarding concept for the hardware (HW) and software (SW) and to compile operational statistics. It can also be used fortroubleshooting.

66 A30828-X1130-K500-1-7618


A30828-X1130-K500-1-7618 67

InformationControl


5 AbbreviationsAC access control

ACT active, ACT (operating state of a unit)

ANSI American National Standards Institute

ASIC application specific integrated circuit

BAP base processor

BCLK bus clock system

BCMY bus for common memory

BEL seized (safeguarding), SEZ, (operatingstate of a unit)

BIOC bus system for input/output control

BIR billing register

CAP call processor

CARB central bus arbiter for common memory

CC cycle control

CCG central clock generator

CCNC common channel signaling network control

CHR channel register

CI common interface

CL coupling logic

CMY common memory

CMY1C common memory, control, part 1

CMY2C common memory, control, part 2

CMYA common memory, address network

CMYD common memory, data network

CMYMP common memory, control, microprocessor

CP coordination processor

CP113C/CR coordination processor 113C/CR

CP113D coordination processor 113D

CPAC coordination processor, access control

CPB call processing buffer

CPCC coordination processor, cycle control

CPCIA coordination processor, central interface forCP113 (module A)

CPCIB coordination processor, central interface forCP113 (module B)

CPCL coordination processor, coupling logic

CPEX coordination processor, executive

DARB decentral bus arbiter for common memory

DMA direct memory access

DR precedence rating

68 A30828-X1130-K500-1-7618


DRAM dynamic random access memory

ECC error correction code

EDC error detection and correction

EPROM erasable programmable read-only memory

EWSD digital electronic switching system

FIFO first in/first out memory

GS group switch

HDLC high-level data link control

HW hardware

IF:MDD interface for magnetic disk device

IF:MTD interface for magnetic tape device

IK:DTD IOP kernel for magnetic disk and tapedevice

IOC input/output control

IOCIF input/output controller, interface

IOP input/output processor

IOP:AUC input/output processor for authenticationcenter

IOP:DEV input/output processor for devices

IOP:LAU input/output processor for line adaption unit

IOP:MB input/output processor for message buffer

IOP:MDD input/output processor for magnetic diskdevice

IOP:MTD input/output processor for magnetic tapedevice

IOP:SCD input/output processor for serial datacommunication devices

IOP:SCDP input/output processor for serial datacommunication devices, BX.25/X.25 proto-coll

IOP:SCDV input/output processor for serial datacommunication devices V.24/V.28 interface

IOP:SCDX input/output processor for serial datacommunication devices, X.21/V.11 inter-face

IOP:TA input/output processor for time and alarms

IOP:UNI input/output processor unified for O&Mdevices

IOPAUC input/output processor for authenticationcenter (module)

IOPMB input/output processor for message buffer(module)

IOPSCDP input/output processor for serial datacommunication devices, packet protocol

IPC interprocessor communication

A30828-X1130-K500-1-7618 69

InformationControl


IRH interrupt handler

LAU line adaptation unit

LAUB line adaptation unit, module B

LCUB line control unit, module B

LED light-emitting diode

LMY local memory

LSY:IOP line system for input/output processor

LTG line/trunk group

MB message buffer

MBG message buffer group

MBU message buffer unit

MDD magnetic disk device

MI memory interface

MOD magneto-optical disk device

MTD magnetic tape device

MU memory unit

MUH memory unit H

OMC operation and maintenance center

OMT operation and maintenance terminal

PC personal computer

PE phase encoded

PEX program execution part

PI processor interface unit

PIADR processor interface, address bus

PIDAT processor interface, data bus

PIO:DEV physical input/output for devices

PIO:IOC physical input/output for input/output control

PIO:MB physical input/output for message buffer

PIO:TA physical input/output for time and alarms

PU processing unit

RAM random access memory

RCD radio clock device

SASDAT Saving of software data with statistics

SCSI small computer systems interface

SN switching network

SSG space stage group

SVC supervisory call

SW software

SWET software error treatment

SWSG software safeguarding (supervisor call)

SYMO system monitoring

70 A30828-X1130-K500-1-7618


SYP system panel

TSG time stage group

UNA unavailable, UNA,(operating state of a unit)

Documents

Documentcp