CP

Information
Control Coordination Processor 113D (CP113D)

A30828-X1130-K500-1-7618
Coordination Processor 113D (CP113D)
Information Control
Copyright (C) Siemens AG 1998.

Issued by the Public Communication Network Group Hofmannstrae 51 D-81359 Mnchen Technical modifications possible. Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract.
A30828-X1130-K500-1-7618
Information Control
This document consists of a total of 70 pages. All pages are issue 1.
Contents
1 2 2.1 2.2 2.3 2.4 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 4 4.1 4.1.1 4.1.2 4.2 4.3 4.3.1 4.3.2 4.4 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 CP113D Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Base Processor (BAP), Call Processor (CAP), Input/Output Control (IOC) . 8 Bus for Common Memory (BCMY) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Common Memory (CMY) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Input/Output Processors (IOP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 CP113D Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Program Execution Part (PEX), Module CPEX and Access Control (AC), Module CPAC . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Cycle Control (CC), Module CPCC, and Local Memory (LMY), Module MUH. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Coupling Logic (CL), Module CPCL, and Common Interface (CI), Modules CPCIA/CPCIB . . . . . . . . . . . . . . . . . 17 BIOC Interface, Modules IOCIF0 and IOCIF1 . . . . . . . . . . . . . . . . . . . . . . 19 Processor Interface Unit (PI), Modules PIADR and PIDAT . . . . . . . . . . . . 20 Decentral Bus Arbiter for Common Memory (DARB) . . . . . . . . . . . . . . . . . 22 Central Bus Arbiter for Common Memory (CARB) . . . . . . . . . . . . . . . . . . . 23 Common Memory, Control, Microprocessor (CMYMP) . . . . . . . . . . . . . . . 24 Common Memory, Data Network (CMYD) . . . . . . . . . . . . . . . . . . . . . . . . . 25 Common Memory, Control, Part 1 (CMY1C) . . . . . . . . . . . . . . . . . . . . . . . 26 Common Memory, Control, Part 2 (CMY2C) . . . . . . . . . . . . . . . . . . . . . . . 27 Common Memory, Address Network (CMYA) . . . . . . . . . . . . . . . . . . . . . . 28 Input/Output Processor for Message Buffer (IOPMB). . . . . . . . . . . . . . . . . 29 Input/Output Processor for Time and Alarms (IOPTA) . . . . . . . . . . . . . . . . 30 Input/Output Processor for Magnetic Disk Device (IOP:MDD), Modules IK:DTD and IF:MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Input/Output Processor for Magnetic Tape Device (IOP:MTD), Modules IK:DTD and IF:MTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Input/Output Processor for Serial Data Communication Devices, V.24 Interface (IOP:SCDV). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Link Control Unit (LCUB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Link Adaptation Unit (LAUB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Input/Output Processor for Authentication Center (IOPAUC) . . . . . . . . . . . 38 Capacity Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Safeguarding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware fault detection by the hardware . . . . . . . . . . . . . . . . . . . . . . . . . Error detection in the BAP, CAP, BCMY, CMY in the CP113D . . . . . . . . . Error detection in the IOC and IOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware fault detection by software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware Fault Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operation of the hardware fault treatment . . . . . . . . . . . . . . . . . . . . . . . . . Alarm treatment with the bus error routine of the PRO . . . . . . . . . . . . . . . . Detection of software errors by the hardware . . . . . . . . . . . . . . . . . . . . . . . 41 41 41 43 44 45 46 49 51
A30828-X1130-K500-1-7618
Information Control
4.5 4.6 4.6.1 4.6.2 4.6.3 4.6.4 4.7 5
Detection of software errors by the software . . . . . . . . . . . . . . . . . . . . . . . . 51 Software error treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Structure of the software error treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Operation of the software error treatment . . . . . . . . . . . . . . . . . . . . . . . . . . 57 SWET LOCAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 SWET SYSTEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Safeguarding Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A30828-X1130-K500-1-7618
Information Control
1 Introduction
The digital electronic switching system EWSD is divided into a number of functional areas that are largely independent in their operation. Coordination processor D(CP113D) is part of the functional area Control (Fig. 1.1).
Access Analog, ISDN, V5.1
Switching
DLU
LTG
SN
Trunks, V5.2, PABX
LTG
Signaling SS7 links, high speed SS7 links CCNC/ SSNC
Control MB
CT
CP
CCG
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 registration, trafc 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 handles changes in the conguration administers the man-machine interface
A30828-X1130-K500-1-7618
Information Control
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-processing functions. 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 the Input/Output Processors (IOP). Input/output processor (IOP) The IOPs control the exchange of data with the connected call-processing, operation and maintenance and data communication peripherals and with external systems such as 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 input and output lists for the IOP:MB and the communication areas used by the IOPs to exchange 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 and the common memory (CMY). The BCMY is used to transfer data and addresses for read and write cycles in the CMY and for interprocessor communication. Like all other EWSD hardware, the CP113D is composed of modules, installed in frames, which in turn are installed in racks. For more information on the mechanical design of the CP113D hardware, refer the Maintenance Manual Construction.
A30828-X1130-K500-1-7618
Information Control
BIOC 15 IOP 15
BIOC IOP
IOP
IOP
IOC1 CAP0 CAP9 BAPM BAPS IOC0 IOC2
IOC3
BCMY1
BCMY0 CMY1 CMY0
Fig. 1.2
Functional units of the CP113D
A30828-X1130-K500-1-7618
Information Control
2 CP113D Functions
The coordination processor (CP) handles the common functions in the exchange, such as the coordination of the distributed microprocessor controls and the data transfer between 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 common memory (BCMY). The IOCs form the interface between the bus for common memory and the input/output processors (IOP). The IOPs control the exchange of data with the connected call-processing, O&M and data communication devices in the node.
15 BIOC 0 IOC0
IOP
15 BIOC
IOP
IOP
IOP
IOC1
IOC2 IOC3 Interface BIOC PU PU CL LMY CI
CAP0 PU PU CL LMY CI BCMY1
CAP9 PU PU
BAPM PU PU
BAPS PU PU CL LMY CI
Interface BIOC PU PU CL LMY CI
CL LMY CI
CL LMY CI
BCMY0 CMY1 CMY0 MYC MYB0 MYB1 MYB2 MYB3
Fig. 2.1
The functional units of the CP113D
2.1
Base Processor (BAP), Call Processor (CAP), Input/Output Control (IOC)

The base processors (BAP), call processors (CAP) and input/output controls (IOC) are built up of the same hardware components. They are therefore described together here.
A30828-X1130-K500-1-7618
Information Control
Fig. 2.1 shows the BAP, CAP and IOC. Each of these processors consists of a processing 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/output control (BIOC). Processing unit (PU) The PU is duplicated for redundancy in each processor (BAP, CAP, IOC); the two units are 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 data over 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 (maximum capacity), 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 the CPCC, mentioned above. In the text that follows, the memory chips are referred to as the LMY memory medium. From the point of view of the LMY, data that are written to or read from the LMY memory medium consist of a sequence of bits, which the LMY distinguishes as either user bits or check bits. User bits represent data transferred from PU0 to LMC control 0 during a write cycle, for example, 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 memory word, 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 the user bits. In a read cycle, the check bits are used to check the validity of the 32 user bits in 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 for input/output control (BIOC). A maximum of 16 IOPs can be connected to the BIOC - and the peripheral units of the exchange are, in turn, connected to the IOPs.
A30828-X1130-K500-1-7618
Information Control
2.2
Bus for Common Memory (BCMY)

The bus for common memory (BCMY) interlinks all processors (BAP, CAP) including the input/output controls (IOC) and links them with the common memory (CMY). The BCMY is used to transfer data and addresses for read and write cycles in the CMY and to handle interprocessor communication (IPC). The BCMY is duplicated for security. The two BCMYs operate in parallel and process identical information. In special cases, the two 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 via the 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 Arbiter for 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 bus for common memory. Allocation of the BCMY to a processor interface group and from there to one of the four processor interface units (PI) is performed interactively by the decentral and central bus arbiters. The DARB also includes the voltage supervision for the four PIs in the processor interface group. Central bus arbiter (CARB) The central bus arbiter is implemented by the CARB - Central Bus Arbiter for Common Memory (CARB). Up to four decentral bus arbiters, DARB, can be connected to the central bus arbiter of the 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 16 processors via 16 processor interface units (PI), and to allocate the BCMY to one PI and thus to the processor connected to that PI. Memory interface (MI) The MI is the interface between the BCMY and the two common memories CMY0 and CMY1. Central BCMY control, bus drivers Together with the bus drivers, the central BCMY control forms the interface to the processor interface units (PI) and to the memory interface (MI).
10
A30828-X1130-K500-1-7618
Information Control
The task of the central BCMY control and the bus drivers is to concentrate and distribute the address, data and control signals. They generate the control signals for the bus arbiters and memory interfaces (MI), and compare the duplicated control signals to assure the reliability of the BCMY. If a BCMY alarm is raised, the central BCMY control triggers a BUS Reset and assigns interfaces 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 of the 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 availability. The two CMYs (CMY0 and CMY1) can be accessed by all processors and input/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 and write cycles in synchronism. But it is also possible to decouple the two CMYs from one another (split mode).
2.4
Input/Output Processors (IOP)

Various types of input/output processor (IOP) link the CP113D with the other subsystems and functional units of the node, the external mass memories, the O&M terminals, the operation and maintenance center (OMC, over data links) and computer centers (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 unied 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 between the CP113D and the other subsystems and functional units in the node. For security, all subsystems and functional units are served by two IOP:MBs. If one of the two IOP:MBs fails, 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
A30828-X1130-K500-1-7618
11
Information Control
executing commands from the BAP-master, such as resetting the call-processing periphery 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 clock for the CP113D and interfaces to the CP racks via which it receives alarms, such as air conditioning 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 timing signals transferred from a central clock generator (CCG). The hardware clock generates the date and the time in hours, minutes and seconds. The software in the CP113D is thus 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 hardware clock also runs a seconds counter independently of the time of day. Optionally, a radio-controlled clock (radio clock device, RCD, external unit) can be connected 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 and reports them to the safeguarding software in the BAP. An IOP:TA has alarm interfaces to 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 following devices 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 for the connection of MTD, MOD and MDD. The devices are connected to this port via a single shared data link. The transmission rate between the device and the IOP:UNI depends on the type of device. For MDDs, it is between 3 and 5 Mbyte/s. In the case of MTDs, the transmission rate also depends on the recording method: the maximum transmission rate for phase-encoded recording (PE) is 80 kbyte/s, that for groupencoded recording is 310 kbyte/s. There are three ports for PC and data links. Here, either one PC and 2 data links or 3 data links can be connected directly or via MODEM. The ports have V.24/V.28 and X.21/V.11 interfaces. The interfaces can operate either asynchronously with the X-on/Xoff protocol (for connection of a PC) or synchronously with the HDLC protocol. The maximum transmission rate is 19.2 kbit/s in asynchronous mode (PC connection) or 64 kbit/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):
12
A30828-X1130-K500-1-7618
Information Control
The LCUB is the link control unit, which is connected to the bus system for input/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 link adaptation 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 in applications where the CP113D is used in authentication centers (AC) of a mobile communication network (D900, D1800 and D1900). In the D900, D1800 and D1900 networks, the subscribers authorization is checked every time that a call is set up between 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 to simulate authorized access. All of the main protection functions in the AC are handled by the IOP:AUC. The function of the IOP:AUC is to generate the authentication triplets needed for authentication during call setup. The generation of authentication triplets is a very important security function. It involves specific security actions, which is why the IOP:AUC is also referred to as the security box.
A30828-X1130-K500-1-7618
13
Information Control
3 CP113D Hardware
The CP113D hardware has a modular structure throughout. The top level of the structure is the hardware functional units. The functions of the hardware functional units are implemented in modules. In some cases, a module corresponds to a hardware functional unit. But hardware functional units can also consist of several modules.
3.1
Program Execution Part (PEX), Module CPEX and Access Control (AC), Module CPAC
Program execution part (PEX) Depending on whether the PEX is used as BAP, CAP or IOC, specific hardware functions are activated depending on the mounting location. Module CPEX The microprocessor is the central control component, on which the operating programs run. The data and address buses of the microprocessor are decoupled twice, to the local bus and to an internal bus. Program execution in the microprocessor can be interrupted at any time via the interrupt logic. Interrupts (max. 16) can be set by hardware or software via the BCMY, by the own processor or by another processor. The internal and ready signals control all processes related to access to the CPEX module. The request logic receives requests from the microprocessor and generates signals depending 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 error treatment. The memory in the IOCs also contains programs for input/output control and for the call-processing and O&M peripheries. The clock logic receives the 33-MHz clock from module CPCL, generates timing signals of 16 and 8 MHz and distributes timing signals to the relevant processor half. The clock logic 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 instructions of the arbiter. After being started by the local bus control, the input/output control decodes the bits of the logical address and generates control signals for internal sequences in the AC and for other modules belonging to the processor.
14
A30828-X1130-K500-1-7618
Information Control
CPEX
Microprocessor Request logic Internal and ready control
Memory (EPROM) Interrupt logic CPAC AC memory Base address Maximum offset
Breakpoint logic Timer
Access rights
Mapping
Comparator
AC arbiter, internal control of the local bus
Interface for hardware tracer Local bus of processor Fig. 3.1 Port for hardware tracer
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 ready control circuits, provides error protection for data traffic with the BCMY and with the LMY and when receiving IPC information. Any errors occurring during a cycle, and their symptoms, are stored in error registers, from which they can be read and which can be deleted after the error has been dealt with. The input/output control generates control signals for reading from, loading to and clearing the EDC logic, the error registers and the alarm timers for ready timeout and watchdog. The LMY control is an autonomous logic circuit within module CPCC, which has no connections 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
A30828-X1130-K500-1-7618
15
Information Control
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 and write access to the data (user bits) in the LMY; access to the memory medium for user bits (see Fig. 3.2). LMY control 1, which forms part of the CPCC in PU1, starts the error correction code for the memory media containing ECC data in the LMY (check bits); access to the memory medium 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 16 Mbyte (smallest size) to 32 Mbyte (largest size). The LMY is built up of memory unit H (MUH) modules, which are equipped with DRAM memory chips (memory medium). The refresh cycle for the memory chips is executed by LMY controls 0 and 1 on module CPCC. In the following text, the memory chips are referred to as the LMY memory medium. Smallest storable unit in the LMY From the point of view of the LMY, data to be written to or read from the LMY memory medium consist of a sequence of bits, which the LMY recognizes as user bits or check bits. 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 LMY control 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 other words from the data to be written to the LMY memory medium. The generated check bits are written to the LMY memory medium separately from the user bits (see Fig. 3.2). In a read cycle, the check bits are used to check the validity of the 32 user bits in a memory word. 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
16
A30828-X1130-K500-1-7618
Information Control
PU0 CPCC in PU0 Cycle, error and ready control
PU1 CPCC in PU1
EDC logic
Alarm timer Parity generator LMY control 0 Latch and dec. logic Memory control Refresh Input/output control LMY control 1
MUH
Memory medium for data (user bits)
Memory medium for ECC (check bits)
Local bus of processor 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 the reset logic if required. The comparator logic checks that the two PUs are operating in synchronism. It compares the output of the two PUs on the basis of significant signals sent to the CPCL by the two PUs over the local bus. The reset logic is used to reset PU0 and PU1 to a defined initial status. Operating personnel can reset the two PUs and thus the CP113D manually by means of the RESET key. In addition, the reset logic performs safeguarding functions: If, for example, the output from the two PUs is not identical, the reset logic resets the two PUs to a defined initial status and raises a comparator alarm. Diagnostic programs are then run in the modules of 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 by means of visual indications on the faceplate of the CPCL module.
A30828-X1130-K500-1-7618
17
Information Control
The input/output control generates the control signals for reading, loading and deleting the modules internal logic. The two keys, RESET and BOOT, can be used to activate the reset logic manually for testing. A test switch allows the comparator logic to be deactivated. This enables the system to be operated with a single PU only (for testing). The status register contains the reset causes and information on other events that did not 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 information from the processor to the hardware tracer. It also receives control information from 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 control signals for module CPCIA and for the processor interface unit (PI). The IPC control (interprocessor communication) handles IPC requests received from other processors via the processor interface unit (PI). The alarm control circuit processes hardware alarms originating from the PI or for forwarding to the PI. The internal control controls access to the components of modules CPCIA and CPCIB and stores various statuses (such as the selector switch) which can be determined by the software of the CP113D.
18
A30828-X1130-K500-1-7618
Information Control
Local bus of processor
CPCL Comparator logic Transfer Input/output control Recovery and reset logic Clock generator Clock and voltage supervision Keys/Indicators Diagnostic register Statusregister CPCIB Internal control Diagnostic register Splitregister
CPCIA
Latch 0
Latch 1
Hardware tracer port Local bus to the PI (BCMY1), to which the processor is connected
Alarm control
Read/write control and IPC control
Local bus to the PI (BCMY0), to which the processor is connected Fig. 3.3
PI in BCMY0
PI in BCMY1
Input/outputrequests, CMY requests
Block diagram of modules CPCL,CPCIA and CPCIB
3.4
BIOC Interface, Modules IOCIF0 and IOCIF1

The BIOC interface is only present in the IOCs, where it serves as the interface to the bus 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 exchanges peripheral units, for example 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 registers or drivers. The input/output control and IPC control decode the address bits of the local bus and either generate the control signals to read/load/delete the IOCIFs internal logic or activate the control logic for read/write operations. The IOC arbiter administers requests for access to the local bus and generates the signal for bus allocation.
A30828-X1130-K500-1-7618
19
Information Control
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 it is 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 by that IOC and instructions are sent to reset all IOPs. BIOC for connection of up to 16 IOPs Requests from IOP0 through IOP7 Input data from IOP0 through IOP15 IOCIF0 Requests from IOP8 through IOP15 Output data only from IOCIF0 to IOP0 thru IOP15 Input data from IOP0 through IOP15 IOCIF1
Requests from IOP0 through IOP7 Data Addresses Control logic Requests from IOP8 through IOP15
Parity bits
IOC arbiter
Parity generator /checker
IOP error register IOP supervision
Input/output control
Data
Addresses
PU0 Fig. 3.4 Block diagram of modules IOCIF0/1
PU1
3.5
Processor Interface Unit (PI), Modules PIADR and PIDAT

The processors, BAP, CAP or IOP, are connected with redundancy to BCMY0 and BCMY1 via the processor interface units (PI). There is one PI for each BAP, CAP, IOC in both BCMY0 and BCMY1. Each group of 4 PIs in a BCMY, together with the associated decentral bus arbiter, forms a processor interface group. Module PIADR Addresses sent by the processor are transferred to the block address latches and drivers, while control instructions are transferred to the driver logic. In parallel to this, the following information is transferred to the request logic: the number of the selected memory bank in the CMY and the number of the timeslot. The request logic then
20
A30828-X1130-K500-1-7618
Information Control
requests a bus cycle from the bus arbiter. At the same time, the PIAC logic sets the signal PIAC - not ready for processor request for the processor. The input/output transmit control receives and executes input/output instructions. The destination 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 modules internal address bus are enabled by the input/output decoder as soon as the latter detects an active input/output signal. When the decoder for physical/logical port numbers identifies a port number that is valid for this PI, instruction decoding commences in the instruction decoder and registers. No decoding takes place if the parity check network detects an error in the address during an input/output cycle. In such cases, an alarm is raised and reported to the inhibit-bit and reset logic. When an input/output instruction is decoded that requires a response, the input/output response control switches the control signals and data drivers to the BCMY at the correct 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 control and the input/output response control have the same functions as the equivalent components 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 the driver logic if their destination is the control on module PIDAT. In the next bus clock interval, the data sent by the processor over the information lines are written to the register for data from the processor. In a memory write cycle, the request logic causes the drivers for the data, address and control lines to both BCMYs to be enabled. In a memory read cycle, the drivers for the data lines remain disabled.
A30828-X1130-K500-1-7618
21
Information Control
to/from module DARB
to/from connected processor (BAP, CAP, IOC) Info. line
Request logic Inhibit bit and reset logic
Driver logic
Bus error signaling
Processor alarm register
Instruction decoder and instr. register Driver, decoder for phys./log. port number
Input/output response control
Register for data from processor
Input/output transmit control
Address latches Register for data from BCMY Data
Parity check network
Multiplexer
Input/output decoder
PIAC logic
Readregister control Module interface
Addresses
to/from module BBFR PIADR Fig. 3.5 PIDAT
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 4 processor interface units (PI) is performed interactively by the decentral and the central bus arbiters. The decentral and central bus arbiters are described in the section dealing with module CARB. Module DARB (see Fig. 3.6) also accommodates the voltage supervision for the 4 PIs in the processor interface group.
22
A30828-X1130-K500-1-7618
Information Control
PI0 to PI3 in a processor interface group Memory requests Logical AND linkage of the input signals Input/output requests GRANT logic
Multiplexer Processor selection tables
Decoder Selected processor Register for PI0 - PI3 GRANT Load Delete
to/from central bus arbiter (module CARB)
Register for table numbers
Table number storage
Timeslot reservation
BCMY requests from the processor interface group Fig. 3.6 Block diagram of module DARB
to the central bus arbiter (module CARB)
3.7
Central Bus Arbiter for Common Memory (CARB)

Up to 4 decentral bus arbiters, or DARB modules, can be connected to the central bus arbiter implemented by module CARB. The 4 decentral bus arbiters belong to processor interface groups 0 to 3.
A30828-X1130-K500-1-7618
23
Information Control
from the 4 decentral bus arbiters BCMY bus control
BCMY request
GRANT logic Register for table numbers Group selection tables Register for processor interface groups
Selected processor interface group Input/output cycle
Table number memory for memory cycles
Multiplexer
Table number memory for input/output cycles
to the 4 decentral bus arbiters
BCMY bus control
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 is accessed. Read and write access to the external memory are controlled by processor signals. The diagnostic register is used to store results of diagnosis (error numbers), originating from the user-bit control, check-bit control and the memory medium. The diagnostic register is also used for communication between the user-bit control and the check-bit control. The MP read registers are used for communication between the microprocessor and the memory medium. The microprocessor processes the data in accordance with the firmware loaded in the CMY.
24
A30828-X1130-K500-1-7618
Information Control
CMYMP Data from the memory medium Alarms from CMY2C Interrupts from CMY2C MP read register Diagnostic register
Parity monitoring External memory for microprocessor (RAM)
Microprocessor
Data (from the memory medium) to the MK memory interfaces of the two BCMYs and to CMYD
External memory for microprocessor (EPROM)
Address information to CMYA
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 data received 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 the outputs of the receive buffers. They are selected in accordance with the setting of the selector switch. The data write register makes data available from the microprocessor for the CMY memory medium. The data correction network corrects single-bit errors in the write data and forwards these data to the cyclic memory. From here, the data are forwarded to the memory medium (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 and correction). 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).
A30828-X1130-K500-1-7618
25
Information Control
Data from the two BCMYs, destined to be written to the memory medium
CMYD Data input buffer EPD0 ECC generator
Data input buffer EPD1
Data correction network Cyclic memory
Data (originating from the BCMY) to the memory medium
Data selection control Data from the memory medium via CMYMP
Data monitoring
Data write register
Alarms relating to data errors in the memory medium
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 types of memory cycles, such as read, write or refresh. The control signals are sent to the MUH memory modules via the memory access control. The clock selection control sets the selector switch when receiving information from the two BCMYs. If the selector switch is operated, e.g. to switch from BCMY0 to BCMY1, during execution of a cycle, the clock selector switches the received timing signals in such a way that the operations of the cycle in progress are not disturbed. The refresh control refreshes the bits (user bits and check bits) in the dynamic RAM chips at regular intervals. The RAM chips are located in the MUH memory modules.
26
A30828-X1130-K500-1-7618
Information Control
CMY1C Control signals from CMY2C
Refresh control
Scheduler
Memory access control Clock selection control
Control signals to the MUH modules of the memory medium Clock selection signals to: CMYMP, CMY2C, CMYA, CMYD
Timing signals from both BCMYs
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 within the CMY. The bank alarm register stores the bit errors detected by the EDC components on module CMYD. The simulation register is used by the microprocessor on module CMYMP to simulate alarms during diagnosis. The control register is used by the microprocessor to control special memory cycles such 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 by comparison. If the two control signals are not identical, a comparator alarm is raised on module CMYMP. To allow the memory cycle to be completed without error in such cases, bus selection is switched over to the other BCMY. The voltage supervision monitors the voltage to ensure that it remains constant. Power failure causes the microprocessor to be reset, and this in turn activates the following actions: starting the initialization program, aligning clock selection, resetting the user-bit control and check-bit control.
A30828-X1130-K500-1-7618
27
Information Control
CMY2C Instructions from both BCMYs Control signals from both BCMYs Alarms from the MUH modules of the memory medium Fig. 3.11 Block diagram of module CMY2C
Control signals to CMY1
Interrupts to CMYMP Alarms to CMYMP
3.12
Common Memory, Address Network (CMYA)

The two address input buffers, AEP0 and AEP1, fetch addresses from the memory interfaces 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 refresh cycles, the refresh address counter. Before data are written to the memory medium, the address network checks them for even parity. If a parity error is detected, the current write cycle is invalidated and a repeat write cycle is executed 4 timing signals later, using the addresses and data from the other AEP. CMYA Address information from both BCMYs
Address input buffer AEP0
Refresh address counter Address parity network Address information to the MUH modules of the memory medium
Microprocessor address control Address information from CMYMP
Address input buffer AEP1
Microprocessor address counter
Fig. 3.12
Block diagram of module CMYA
28
A30828-X1130-K500-1-7618
Information Control
3.13
Input/Output Processor for Message Buffer (IOPMB)

The transceivers and latches for BIOC decouple the BIOC from the IOPs internal bus. The transceivers for input/output and the registers for transmitted and received signals decouple the IOPs internal bus from the line system for IOP (LSY:IOP) leading to the call-processing periphery. The control logic controls and monitors the LSY:IOP interface and monitors the interface to 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 callprocessing periphery The control logic is implemented in an application-specific integrated circuit (ASIC). The microprocessor is responsible for executing programs and controlling the sequence of program execution. The clock generator generates the 40-MHz clock for the microprocessor and the 20MHz 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 and contains the programs for the IOP:MB. The programs are loaded to the local memory from 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 callprocessing periphery and the IOC and to the program scheduler
A30828-X1130-K500-1-7618
29
Information Control
Clock generator Control logic (ASIC)
Microprocessor
BIOC
Transceivers and latches for BIOC
Transceivers for input/ output Multifunction chip
Register for transmitted and received signals
LSY: IOP
Callprocessing periphery
Interrupt
Memory (local)
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 IOPs 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 multifunction chip. The memory is used to store the firmware and data for the IOP:TA (microprocessor and timers). The hardware clock on the module is duplicated. It is implemented as firmware in two microcontrollers. 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 cable carries 8 alarm lines. The module faceplate contains 4 two-digit displays for time and status. The displays are activated by means of a key. The CCG interface contains logic circuits for selecting the clock from CCG0 or CCG1.
30
A30828-X1130-K500-1-7618
Information Control
Rack alarms (5 x 8 lines)
Memory (local)
Alarm interface
BIOC
BIOC interface
Interrupts Control
Reset
Microprocessor
Clock (operation)
Clock (display)
Multifunction chip
Serial interface
Clock generator
Keys
Display
CCG interface
CCG0 CCG1
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 other clocked components such as timers and interrupt handler (IF:MDD). The microprocessor is responsible for executing programs and controlling the sequence of program execution on module IK:DTD. The scheduler coordinates the execution sequence of individual functions and monitors the transfer of data to/from the interface module. The IPC decoder (interprocessor communication decoder) decodes instructions sent by the 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 form of interrupts.
A30828-X1130-K500-1-7618
31
Information Control
The LED display signals the status of the IOP:MDD, for instance in order to display the results of an off-line diagnosis. The timers produce interrupts, which are forwarded to the interrupt handler. The main function 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) and starts the relevant routines to process the interrupts. The BIOC interface decouples the IOP:MDDs internal bus from the BIOC. Its main functions are to: multiplex and demultiplex the data and address buses check the parity bits associated with data being sent over the BIOC (transmit direction) The memory is built up of: EPROM memory chips, which contain the IOP:MDD rmware 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 specific to the connection of a magnetic disk device (MDD). In simple terms, the IF:MDD is the SCSI interface (ANSI standard) to the driver for the magnetic disk device. The DMA controller is responsible for controlling data transfers between the IF:MDDs buffer and the MDD driver, including error protection. Data are transferred between the buffer 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 le on the MDD. Input data are data that have been read from a le on the MDD. Control information is passed between the IF:MDD and the MDD driver via the ports.
32
A30828-X1130-K500-1-7618
Information Control
Clock generator
DMA controller IPC decoder Interrupt handler
Microprocessor BIOC
Port 1 B U F F E R
FIFO
Data MDD driver
Memory
FIFO
Port 2 Scheduler Timer
Control lines
Module IK:DTD IOP kernel for MDD and MTD Fig. 3.15
Module IF:MDD interface for MDD (SCSI interface (ANSI standard) to the MDD driver)
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:MTD
Most exchanges are equipped with one IOP:MTD, used to back up essential files on tape and to reload saved files from tape, for instance call charge files, or to output the current 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 both IOPs - 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 specific to the connection of a magnetic tape device (MTD). In simple terms, the IF:MTD is the industry-standard interface (PERTEC) to the driver for the MTD. The DMA controller is responsible for controlling data transfers between the IF:MTDs buffer and the MTD driver, including error protection.
A30828-X1130-K500-1-7618
33
Information Control
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. Clock generator DMA controller
IPC decoder
Interrupt handler
Data Microprocessor BIOC
Memory
B U F F E R
Data Port20 Status lines Control lines MTD driver
Port21
Scheduler
Timer
Module IK:DTD, IOP kernel for MDD and MTD Fig. 3.16
Module IF:MTD, interface for MTD (industry-standard interface (PERTEC) to the MTD driver)
Block diagram of IOP:MTD, comprising modules IK:DTD and IF:MTD
3.17
Input/Output Processor for Serial Data Communication Devices, V.24 Interface (IOP:SCDV)
The clock generator generates the timing signals for the microprocessor and the other clocked components such as timers and interrupt handler. The microprocessor is responsible for executing programs and controlling the sequence of program execution on module IOP:SCDV. The scheduler coordinates the execution sequence of individual functions and monitors the 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).
34
A30828-X1130-K500-1-7618
Information Control
The IPC decoder forwards the decoded instructions to the interrupt handler in the form of interrupts. The timers produce interrupts, which are forwarded to the interrupt handler. The main function 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) and starts the relevant procedures to process the interrupts. The BIOC interface decouples the IOP:SCDVs internal bus from the BIOC. Its main functions 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 rmware 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 the results of an off-line diagnosis. Clock generator
Microprocessor
IPC decoder
Interrupt handler DMA controller Memory Serial V.24 interface
BIOC
Connect: 1 local OMT and OMC
Scheduler
Timer
Kernel of module IOP:SCVD
Device interface part of module IOP:SCVD
Fig. 3.17
Block diagram of module IOP:SCDV, comprising kernel and device interface part
A30828-X1130-K500-1-7618
35
Information Control
3.18
Link Control Unit (LCUB)

The BIOC interface decouples the BIOC from the IOPs internal bus and performs the following 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 complexes and 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 16MHz timing signals for the microprocessor by means of frequency division. The microprocessors clock is monitored by the hardware. The memory consists of a flash EPROM memory and a RAM memory. The ash EPROM memory is the programmable read-only memory used to store the IOP:LAUs rmware and software. During power-up of an IOP:LAU, the rst part of the sequence is run from the rmware in the ash EPROM memory. During the second part of the power-up sequence, the entire rmware and software are loaded from the ash EPROM to the RAM memory; (optionally, they can also be loaded from the CP). Firmware and software execution for normal operation is then run from the RAM memory. The firmware and software in both memories (flash EPROM and RAM) are protected by checksums 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 the IOP:LAU pair) via the two LAU interfaces. Data transfer from the LAU interfaces of an LCUB to the two LAUB modules (LAUB-own and LAUB-partner) takes place over two asynchronous, 16-bit wide, multiplexed address and data buses, one for each module. The multiplexed address and data bus is protected by parity checks.
36
A30828-X1130-K500-1-7618
Information Control
Clock generator 32-MHz clock Control logic BIOC BIOC interface Flash EPROM memory RAM memory Multifunction chip V.24 interface for testing Fig. 3.18 Block diagram of module LCUB, link control unit for LAUB LAUBpartner 16-MHz clock Microprocessor LAUBown
LAU interface
3.19
Link Adaptation Unit (LAUB)

An LAUB module has two interfaces that use the BX.25 or X.25 protocol for the connection of data terminals, data-link terminating equipment and data transmission equipment. The connections are made using cables (X25LINK data links), as described earlier. The connectors fitted to the cables used for the X25LINK data links must be suitable 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 multiprotocol chips allows the two interfaces to operate separately from and independently of each other. Consequently, input/output operations at the interface for X25LINK0 can be performed separately from and independently of input/output operations at the interface for X25LINK1. The multiprotocol chips control the input/output operations for X25LINK0 and X25LINK1, 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 rmware 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 the X25LINK to/from the connected equipment. The control logic (implemented as an ASIC) controls access to the memory. The LAUB is also linked to the LCUB modules (LCUB-own and LCUB-partner of the IOP:LAU pair) via the control logic.
A30828-X1130-K500-1-7618
37
Information Control
48 V... 60 V Clock generator Power supply Multiprotocol chip X25LINK0 options: X.21, X.24, V.35, V.36
32-MHz clock LCUBown
+5 V
Control logic (ASIC)
Multiprotocol chip EPROM memory RAM memory
X25LINK1
LCUBpartner
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 IOPs internal bus. Its functions are as follows: 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 complexes and 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 16MHz timing signals for the microprocessor by means of frequency division. The microprocessors clock is monitored by the hardware. The local memory is used to store the firmware for operation of the IOP:AUC. The boot and loader programs are stored in an EPROM memory, and the authentication keys and parameters are stored in an EEPROM memory. The local memory is protected by parity checking. The parity bits are generated and monitored by the control logic. The readonly 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 be connected to this interface in order to load encryption parameters.
38
A30828-X1130-K500-1-7618
Information Control
Clock generator 32-MHz clock Control logic (ASIC) BIOC BIOC interface Memory (local) Multifunction chip 16-MHz clock Microprocessor
Serial interface (V.24) Fig. 3.20 Block diagram of module IOPAUC
3.21
Capacity Stages
Fig. 3.21 illustrates the various capacity stages of the CP113D. The smallest-capacity version of the CP113D contains only two base processors (BAP) and two input/output controls (IOC). Up to sixteen input/output processors (IOP) can be connected to each IOC. The system can be expanded by adding call processors (CAP), further IOCs and further IOPs. The largest-capacity version of the CP113D is equipped with two BAPs, ten CAPs and four IOCs.
A30828-X1130-K500-1-7618
39
Information Control
Maximum capacity of CP113D BIOC 15 Basic-version CP113D 0 IOP 0 IOP IOP 15 BIOC IOP
IOC1 CAP0 CAP9 BAPM BAPS IOC0 IOC2
IOC3
BCMY1 BCMY0 CMY1 CMY0
Fig. 3.21
CP113D capacity
40
A30828-X1130-K500-1-7618
Information Control
4 Safeguarding
4.1 Hardware fault detection by the hardware
Defects 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 be corrected by the use of redundant information, this is done without an error message being issued. Two basic principles apply to the detection of hardware faults by monitoring 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 the addresses, data and control lines. The BAP, CAP, IOC, the CMY control and the control logic of the BCMY are internally 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 the reset logic and start the PRO diagnosis. EDC logic (in CC, to point 2) The EDC logic safeguards the data exchange between LMY and processor and between B:CMY and the processor. Depending on the cycle, it performs the following tasks: 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 the EDC logic in the EDC check either cause the cycle to be repeated or initiate the BUS ERROR ROUTINE. Comparator logic (in CI, to point 3) Important control signals from each B:CMY are transmitted in duplicate to the processor and compared in the CI. Any errors detected are assigned to the B:CMY and cause the B: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 control lines. The duplication is merely used to enable errors to be detected quickly by comparing the control signals in the PI, MI, CMY and the controller itself. Depending on where 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 safeguarding commands), an address parity check is performed. Detected errors are assigned to the B:CMY and cause it to be reset.
A30828-X1130-K500-1-7618
41
Information Control
Data check (to point 6) For error detection in memory, the ECC check is used primarily. If the data from the processor (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 CMY to be switched over permanently. If the data from the storage medium are faulty, the MI switches to the data from the other memory (only for the faulty cycle). Multiple-bit errors cause the preferred direction in the MI to be switched, memory diagnosis to be started in CMY, and alarm treatment to be started in the BAP. PROC LMY ECC 2 COMP PU-0 EDC P 2 5 PU-1 EDC P 2 5 P Parity check (addresses) Error detection - correction logic (Data) Error detection and correction code (Data) Comparator
EDC
CL
COMP
1 3
ECC
CI
COMP
see Continuation Fig. 4.2 Fig. 4.1 CP113D monitoring principle
42
A30828-X1130-K500-1-7618
Information Control
0 COMP Controller 1 0 Controller 1 P
PI 4 5
PI
PI
BCMY1 MI COMP EDC BCMY0 4
C-control COMP P EDC Medium 4 5 6
D-control COMP P EDC 4 5 6
ECC
CMY0 Fig. 4.2 CP113D monitoring principle (Continuation)
CMY1
4.1.2
Error detection in the IOC and IOP

The IOPs and devices are not duplicated internally for error detection, in contrast to the processors and IOCs. Error detection occurs in the IOCs and in the IOPs and the devices 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 error detection features vary, depending on the IOP type. Errors affecting the IOP are reported to the IOP:MB by means of a continuous request sent to the IOC (and thus also to the PIO:IOC). Errors in the other IOP are reported to the 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
A30828-X1130-K500-1-7618
43
Information Control
IOP:TA The hardware clock within the IOP:TA is duplicated. The time is compared cyclically by the processor of the IOP:TA to prevent an incorrect time being transmitted. The processor and the clock pulse generator are monitored by hardware circuits. IOP:DEV In the IOP:DEV, i.e. IOP:UNI, IOP:AUC, IOP:SCDP and IOP:SCDV as well as in the MDD and MTD, supervisory circuits for the voltage, clock and parity of the IOP-RAM together 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 partly by the IOP rmware. The interfaces to the devices are monitored by parity checks or procedures from case to case. IOP:MDD (for magnetic disk memory in the CP113D) The data on the path IOP magnetic disk memory IOP are parity-checked byte by byte. The data on the disk medium are safeguarded using ECC code. The ECC code 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 to the job initiator (software). This can lead at rst to a retry and, if unsuccessful, nally to 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 read checks. Device operations are monitored with regard to maximum duration by the IOP 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 prfsummen-gesicherte Schnittstellenprotokoll. Auerdem werden die RCD-Daten plausibilitts-geprft.
Error treatment in the IOC (for the IOP) As a reaction when an error is detected, the corresponding arbiter restriction is set in the IOC, 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 not prevent the flow of information IOC IOP). When the power supply fails in an IOP module frame, or for certain interface procedure errors 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 data within the windows (= memory ranges) assigned to it. This means that a defective IOP cannot destroy the contents of CMY. This safety feature is necessary to exclude the possibility of errors spreading, as the error 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 software

This refers to routine test programs (for the most part identical with diagnostic programs) that are periodically started.
44
A30828-X1130-K500-1-7618
Information Control
The memories are read cyclically, checked with the ECC and, if necessary, overwritten with corrections (scrubbing). The magnetic tape device test requires that a tape with a write ring and a valid file is mounted 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 devices assigned 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 in the IOP:MB and MBU area. The failure of all devices (or all MBUs) of an IOP is reported by the corresponding PIO to 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 supervisory 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 (administrable) time, and then starts the routine test programs for the I/O area.
4.3
Hardware Fault Treatment

The hardware fault treatment process has the task of creating a functional system configuration after the spontaneous occurrence of hardware faults, or for hardware faults 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 fault by using diagnostic programs. Non-verifiable (sporadic) faults are tolerated if they do not occur repeatedly (the hardware fault treatment process keeps relevant statistics). For sporadic faults, fault messages are merely stored in a file (HF.MCP.HWERROR). For static faults, a message is given to the operating personnel, and an alarm is caused at the system panel (SYP). The error message to the operating personnel contains the modules suspected of being defective, so that in manned switching exchanges, the defective module can be replaced immediately (short repair time).
A30828-X1130-K500-1-7618
45
Information Control
4.3.1
Operation of the hardware fault treatment

As a reaction to detected errors, the inhibit bit is set in the BCMY for the unit suspected as faulty (BAP, CAP, IOC, BCMY, CMY). This activates a ring line (SYSTEM FAILURE Line) which is connected to all processors; see Fig. 4.3. This unit also places additional information 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 fault treatment 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 interrupt 14 must also be set in this CAP/IOC. Die The interrupt routine saves only the PI alarm registers in the CAP and IOC to the CMY. Hardware fault treatment, like in the BAP, does not take place. In the CAPs (and IOCs), no hardware fault treatment occurs apart from the bus error exception routine. Fig. 4.4 shows the alarm registers in the CP113. It is important that the alarm register for a system unit is always located in the corresponding interface on the BCMY, and vice versa. Thus it can still be ready by the diagnostic program even after the system unit has been switched off. The hardware fault treatment process is started in the BAPs via a control line of the BCMY. These alarm registers are only output as part of an error message in the case of sporadic 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 precedence rating of 6 (see Fig. 4.3). If the hardware fault treatment process detects that it is running 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 Dene conguration actions Dene postprocessing actions The other fault treatment steps are performed with a precedence rating of 0. The actual measures adopted are defined and performed by the hardware fault treatment process with a precedence rating of 0 The essential tasks of the fault treatment process with a precedence rating of 0 are: Performing fault verication by means of test tasks. If a fault is detected during verication, the unit is congured to UNA. If no fault is detected during verication, the unit is congured to ACT. Fault verication is monitored statistically to detect sporadic faults.If the statistical threshold value is exceeded, the corresponding unit is congured to UNA without verication. If software errors cause an unmotivated start of the hardware fault treatment process (i.e. a processor interrupt 14 is triggered, although no inhibit bits are set and no alarm register entry exists), the hardware fault treatment process with a precedence rating of 0 assumes a software error and reports it to the software error treatment (SWET).
46
A30828-X1130-K500-1-7618
Information Control
If a unit is congured to UNA, its error messages are entered in the corresponding le HF.ARCHIVE, there is an output message, and the system status analysis is informed of the permanent fault. When a unit has been congured to ACT following fault verication, the symptoms provided for sporadic faults are entered in the le 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 CP safeguarding software. The PIO:IOC receives messages about IOC and IOP faults from the hardware and software. It is the switching point for the analysis of faults and the initiation of fault treatment actions. The IOP is assigned the "SEIZED" status, and for software messages the arbitration disable is also set. If the IOC detects an IOP fault, it sets the arbitration disable. Then the PIO:IOC initiates an IOP test. To perform a test for the IOP:MBs, all connected call processing equipment must be recongured to the redundant IOP:MB. If the test detects a fault, the IOP is congured to UNA. Otherwise the IOP is reset to the status it had before the test, and the call processing units ((MBU, CCNC, SYP, CCG) are recongured. Fault statistics are compiled for each IOP. When a threshold value is reached, the relevant IOP is not tested, but returned to UNA status, and corresponding messages are transmitted to the system panel and the O&M output device. If a unit is congured to UNA, the associated symptoms are entered in the corresponding HF.ARCHIVE le, a message is output and the system status analysis is informed of the permanent fault. UNdetected IOP and device faults are discovered by routine tests triggered periodically by the central safeguarding program. If a fault is detected, the devices are congured to UNA, and messages are transmitted to the system panel (SYP) and the O&M (OMT) output devices (see Fig. 4.6, Operation of the system status analysis). PIO:MB The PIO:MBs receive messages from the PIO:IOC about IOP and IOC failures so that they can switch all call processing equipment connected to the IOPs affected to redundant IOPs. The PIO:MBs receive messages from the IOP:MBs concerning both interface errors between the IOP and the call processing periphery (MBU, CCNC, CCG, SYPC) and internal 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 so it reports them to the peripheral safeguarding program, and IOP faults to the PIO: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 fault has probably occurred. Receiving spontaneous fault messages from the IOP:DEVs, and forwarding them to the PIO:IOCs. Processing fault messages. PIO:TA
A30828-X1130-K500-1-7618
47
Information Control
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). IOP error detection by IOC or PIO
Precedence rating 6
INTERRUPT 14 to BAPM
Precedence rating 0
Evaluate alarm
No CMY, more than 1 error, no IOC? Yes Recovery
No
Statistics threshold reached? No Fault verification: Start diagnosis
Yes
Configure to UNA; enter in HF.ARCHIVE
Inform system status analysis
End
Error detected?
No
Activate unit
Yes Configure to UNA, error message Error message, enter in HF.MCP.HWERROR
End Fig. 4.3
End
Fault treatment with precedence ratings 6 and 0 in the BAPM
48
A30828-X1130-K500-1-7618
Information Control
PRO 0
PRO n
CI PIALR BCMY0 BCMY0 PROALR PRO0 PI MI CMYALR CMY0 CMYALR CMY1 PROALR PROn PIALR BCMY1
CI PIALR BCMY0 PIALR BCMY1 BCMY1 PROALR PRO0 PI MI CMYALR CMY0 CMYALR CMY1 PROALR PROn
CMY0 MIALR BCMY0 MIALR BCMY1
CMY1 MIALR BCMY0 MIALR BCMY1
Fig. 4.4
Location of alarm registers in the CP113
4.3.2
Alarm treatment with the bus error routine of the PRO

The 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 and by additional tests. For hardware faults, the bus error routine sets the inhibit bits for the device affected. This activates 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 the device. Access right violations are passed on to an operating system procedure which checks whether 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 bus error routine repeats the cycle and terminates itself. The ready time-out logic monitors reading access to the B:CMY and the request signal PEX for local bus assignment.
A30828-X1130-K500-1-7618
49
Information Control
NMI
LMY/CMY cycle error
Access violation
WATCHDOG expired
WATCHDOG Yes
No
Yes BERR MC68040 IOC No A
Set both FF inhibit bits STOP
Trigger WATCHDOG, disable all interrupts BERR within the bus error routine Yes
EPROM
RAM Software error
WATCHDOG
Yes
SWSG 139
Analyze initiation causes
BCMY cycle
Yes
SWSG 133
LMY read cycle?
Yes
Access violation Undefined bus error (CC and AC are not set)
Yes Yes Window access by a BAP, CAP Genuine bus error Repeat bus cycle
BCMY test?
Yes
Return to the BCMY test
Yes
Start CI test (BERR-INF) Yes
Error
SWSG 133 Update SLOT SWSG 137 Cancel interrupt disable RTE
IOC A
Yes Set both FF bits for this PROC STOP
Fig. 4.5
Bus error routine
50
A30828-X1130-K500-1-7618
Information Control
4.4
Detection of software errors by the hardware

This 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. A hardware timer (watchdog) supports this monitoring in endless loops.
4.5
Detection of software errors by the software

The 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 a danger 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 either not 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 conguration diagram 4.6 The system status analysis can be initiated: automatically after every conguration which reduces the availability of the system periodically at xed 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 the system by attempting to restart any devices which fail.
A30828-X1130-K500-1-7618
51
Information Control
Every 15 min. for all units in UNA: diagnosis, system status analysis 5 times Error detected?
No
Activate unit
Yes Message from the system status analysis
Unit remains in UNA
End Fig. 4.6 Audits Audits are programs for checking consistency which are called up on demand or periodically. THey run as background processes at a low priority. THey calculate a checksum for (semi-) permanent data and code for comparison with an existing checksum. Transient data are checked for chains, availability or plausibility. If discrepancies are detected, the relevant reaction is initiated (e.g. deletion or correction of incorrect 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 table are compared with those stored in the GP for each LTG (the program checksum for LTGs with memory >1 Mbyte per load segment). The checksum for program data is stored on the disk. Equipment status audit (EQSTA) The conguration states of the CP periphery are stored in the CP memory as duplicated 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 the disk. 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 semipermanent 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. System status analysis
52
A30828-X1130-K500-1-7618
Information Control
Trunk status audit (TRUSTA) TRUSTA checks transient line links in inter-exchange trunk lines, PBX lines and announcement 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 the CP, the transient states of a port are compared with each other. Then the seized/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 necessary. 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 conguration audit (NWCONF) The functional states of the TSG and SSG are carried transiently and semi-permanently in the CP. NWCONF compares these data. Network map audit (NWMAP) Checks for agreement between path data in CHR and TABLE SN/LINK. Checksum Validation Audit (CHKSUMVA) IP Equipment Status Audit (EQSTA) Creates checksum for data in the LTG Compares result with a value in the CP Consistency of transient and semi-permanent states of CP periphery
Maintenance audits
Port status audits
Trunk Status Audit (TRUSTA) Interprocessor Trunk Status Audit IP (IPTRUSTA) see Continuation Fig. 4.8
Status of units idle lists
Consistency of port states in LTG and CP
Fig. 4.7
Audits
A30828-X1130-K500-1-7618
53
Information Control
Billing Register Audit (ABILREG) Call Processing Buffer Audit (CPBUFFER) Channel Register Audit (CHANREG) Interprocessor Channel Status Audit IP (IPCHASTA) Network Configuration Audit (NWCONF)
Consistency of the BIR-POOLS Link: CHR<->BIR
Consistency of the CPB-POOL Link: CHR<->CPB
Call processing audits
Consistency of the CHR
Consistency of channels LTG <-> SN
Switching network audits
Consistency of TSG <-> SSG
Network Map Audit (NWMAP) IP = Interprocessor audit PPU = Peripheral processing unit Fig. 4.8 Audits (Continuation)
Consistency of SN tables <->CHR
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 have run within a certain time period. The real-time monitor has a string of bits in which one 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. If priority 6 has not been processed, neutralization measures are initiated (trace, SWSG SWET, or the processor inhibit bit is set). Deadlock detection Processes which require this monitoring must report to SYMO. SYMO then regularly sends messages and expects responses. If a response is missing, this process is assumed to be deadlocked. This is currently only valid for CALLP and SMOMD.
4.6
Software error treatment

The main task of the SWET (software error treatment) is to define how the system should react to a software error. As it is not possible to correct errors automatically as they occur, steps are taken to neutralize the error. For the correction of error, which can only be preformed by the developer, SWET provides support in the form of error
54
A30828-X1130-K500-1-7618
Information Control
symptom recording. The error symptoms collected by the SWET are used for off-line error analysis and correction; the correction of the software error is achieved by inserting the 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 the error is detected, SWET is activated by the SVC call-up SWSG via the exception handler. Detection of system responses by the system monitoring process. Incorrect system responses 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 incorrect sequences (e.g. invalid operation code) lead to an exception routine being performed in the CP113,which in turn activates SWET. The SWSG numbers 1-127 are module-dependent numbers, i.e. the programmer can use them individually. Each module can thus define its own SWSG from number 1 to a maximum of number 127. The numbers above 127 are not module-dependent, i.e. they exist only once in the whole system. The corresponding error symptom package and the required recovery level are ascertained by means of a table. 5 ms IL4
INTERRUPT 13 (IL6)
SYMO PROCEDURE WATCHDOG TRIGGER OFF
No
Start SYMO? Yes SET IL4
REALTIME MONITORING READ BIT STRING INTERPRET AND DELETE MESSAGE-> SRMEP (IL0 PRIORITY 6)
JUMP TO SYMO WATCHDOG TRIGGER OFF
see Continuation Fig. 4.10 Fig. 4.9 SYMO call
A30828-X1130-K500-1-7618
55
Information Control
DR SET IL6 7 Request to IL2 (GENERATION OF THE 50-ms CLOCK) 6 5 4 TRIGGER WATCHDOG (RESET) 3 2 1 RTE 0 6 5 0 Fig. 4.10 SYMO call (Continuation) PRIORITY 15 Real-time monitoring WATCHDOG
DEST_FIELD:=RECEIVE INBUFF IF DEST_FIELD. SOURCE = TIMER AND DEST_FIELD. FORMAT. JOBCODE = 500 THEN ELSE SWSG (001, SE_SYPAC_2 SE_NSTART3) MRZLPFRNKST ( );
FI; Fig. 4.11
Sequential number
Error symptoms package
Recovery level
Example of a plausibility check
4.6.1
Structure of the software error treatment

Because of the multi-processor structure of the CP113, several software error events can occur independently of each other in different processors. This overlap of software errors, and their evaluation with regard to the recovery actions required, make it necessary to structure the software error treatment (see Fig. 4.12) into the following: SWET LOCAL, on each processor: interface for software error detection
56
A30828-X1130-K500-1-7618
Information Control
interface for the system part of SWET system stop analysis of error situation recording and storage of error symptoms SWET SYSTEM, on the BAPM: denition and triggering of recovery action recording of statistics SWET SYSTEM
SWET LOCAL
SWET LOCAL
SWET LOCAL
BAP-MASTER
BAP-SPARE
CAP0 to CAP9
Fig. 4.12
Structure of the software error treatment (SWET)
4.6.2
Operation of the software error treatment

Figure 4.13 and 4.14. show the flow for the software error treatment.
A30828-X1130-K500-1-7618
57
Information Control
BAP master
Error-detecting processor Software error
IRH
SWET LOCAL
INTERPROCESSOR COMMUNICATION
SWET system No
SASDAT? Yes Yes
Bleibt SASDAT? No IRH
IDLE-LOOP
Continuation on the BAP master
Continuation at the interrupted program address
Recovery
Fig. 4.13
SWET: Basic operation
58
A30828-X1130-K500-1-7618
Information Control
Software error occurred Interrupt Handler - Collect special error messages - Trigger system stop
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 Return to calling program for N/ISTART IDLE loop
SWET SYSTEM in the BAPM - Evaluate recovery action (record statistics) - Define recovery action - Trigger software recovery for recovery levels > SASDATS = SASDATS IRH - Return control >SASDATS Software recovery - Reset identifier to end recursivity - Call up software recovery statistics
Fig. 4.14
SWET: Functions
4.6.3
SWET LOCAL
If a software error occurs in the BAP or CAP, this immediately triggers the IRH, thus activating SWET LOCAL. The following information is assembled by IRH in a separate memory 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
A30828-X1130-K500-1-7618
59
Information Control
System stop If a software error occurs in a processor (CAP, BAP), measures must be taken to ensure that while the CMY data are being recorded to save the error symptoms, other processors do not alter these data. This would corrupt the error record. Therefore it is necessary 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 enables interrupt level 4 of the processor that detected the error, and SWET LOCAL can continue to process the software error. If the local flag is set, the procedure begins a loop to request the global flag. When the global flag is reset, the procedure cancels itself. The processor can continue at the place where it was interrupted. The global flag is removed by the active SWET LOCAL of the processor 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 a permanently defined phase (critical phase) at the same location (via SWSG, runtime check, etc.). To prevent an endless loop of safeguarding sequences as far as possible, it is imperative that recursive SWSGs be recognized. To detect recursive SWSGs, the SWET uses identifiers in the CMY (a flag stating whether SWET is currently active, and the SWSG interrupt address). If SWET is active and the current SWSG interrupt address is identical to 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 second time 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, register contents, 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 identication) Denition 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 error symptoms need to be collected and stored. The recording and storage of error symptoms have the following tasks: Entry of error symptoms in permanently dened areas of CMY, known as the symptom saving areas, which cannot be overwritten by recovery actions (the areas are processor-specic). When recursive SWSGs occur, the entry of interrupt error messages (only the minimum = interrupt information) in a permanently dened area of CMY, known as
60
A30828-X1130-K500-1-7618
Information Control
the EMERGENCY AREA. This area likewise cannot be overwritten by recovery actions. Administration of the processor-specic error message storage area.
Cancelling system stop After the symptom saving process has stored all CMY data, it cancels the global system stop flag. Filtering of SWSG floods For SWSG with the recovery level SASDAT, error symptom recording needs to be suppressed 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 occurrences, no special treatment is given. If the SWSG occurs a fourth time, a message is given that from now on the error symptoms recording and the page printer output will be suppressed for 24 hours (see Fig. 4.15). After this period has elapsed, the entry in the monitoring table is detected. Monitoring is started 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 an additional message to the OMT that this, and possibly other SASDAT treatments, will be suppressed for the next 24 hours.
A30828-X1130-K500-1-7618
61
Information Control
CP22/LX77/WOMXBZ1V11 50-M04/000 0039 ERROR DURING PLAUSIBILITY CHECK DATE TIME UNIT MODULE ERROR : : : : : 97-12-31 12:02:54 BAP MS CSSEZD0C 018
3095/02435
12:02:59 97-12-31 HF.ARCHIVE-00525
! ! ! ! ! ! 1st to 4th SWSG ! ! ! ! ! ! ! ! !
STATISTICS: ========= TIME (SEC): GRENZE:
STAND:
-------------------------------------------------------------000 000 0000 END TEXT JOB 0039 CP22/LX77/WOMXBZ1V1150-M04/000 0039 3095/02435 97-12-31 12:03:26 HF.ARCHIVE00530 ********* SUPPRESSION OF THE SOFTWARE DATA SAVING STARTED MODULE ERROR : : CSSEZD0C 018
END JOB 0039 Fig. 4.15 Examples of output messages of SASDAT
4.6.4
SWET SYSTEM
To check the effectiveness of the recovery actions taken, the SWET must keep the following 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, a higher recovery level must be escalated to. For each escalation (see Tab. 4.1), the escalation level of the highest recovery performed in software recovery, and which is still recorded in the statistics, is requested.
62
A30828-X1130-K500-1-7618
Information Control
Tab. 4.2 shows an example of a printout of recovery statistical information. Recovery level NS 0 NS 1 NS 2 NS 3 IS 1 IS 1B NS 1B IS 2 IS 2G NS 1 NS 3 NS 3 IS 1 IS 1B *) IS 2 *) *) Escalation to
*) these values are subject to the hardware escalation decision Tab. 4.1 Recovery escalation
RECOVERY ACTION SSDATS NSTART0 NSTART1 NSTART2 NSTART3 ISTART1 ISTART2 ISTART2G ISTART2R ISTART2F ISTART1B NSTART1B Tab. 4.2
MONITORING TIME/SECS CURRENT 80 600 600 600 600 600 600 600 600 600 600 60 STANDARD 80 600 600 600 600 600 600 600 600 600 600 60
THRESHOLD CURRENT 40 3 2 2 2 2 STANDARD 40 3 2 2 2 2
10
10
Example of a printout of recovery statistics
4.7
Safeguarding Monitor
The safe guarding monitor is part of the safeguarding software. The control module of the safeguarding monitor runs as a process in interrupt level 0, and forms a uniform interface for safeguarding messages. Measures to safeguard the call processing periphery are not initiated by the safeguarding monitor, but rather by the task-specific processes of the safeguarding software. The safeguarding monitor performs the following tasks: Provision of a uniform interface for safeguarding messages Starting safeguarding processes
A30828-X1130-K500-1-7618
63
Information Control
Distribution of safeguarding messages Coordination of collective messages Logging safeguarding messages Denition of type-specic 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 safeguarding system) is performed exclusively by means of the safeguarding monitor. This ensures that the interface between the safeguarding program and the rest of the system is independent of the process structure of the safeguarding software. Messages between safeguarding processes are also processed via the safeguarding monitor. They therefore receive all jobs via the safeguarding monitor, and return all results via the same route. Starting safeguarding processes Whenever the system is started, and after the executive control program has been completely initialized, the safeguarding monitor starts most of the cyclical safeguarding processes. These include the configuration schedule and several error treatment processes. Then recovery "under operating system control" is started. After the end of recovery has been signalled, the routine test processes for the call processing periphery, the remaining error treatment processes, the error data output process, the control of the safeguarding program and the output of recovery data are started by the safeguarding monitor. Distribution of safeguarding messages The safeguarding monitor distributes the safeguarding messages to the processes responsible for processing. This distribution is normally done by reference to a table. Each message has a receiver permanently assigned to it. This applies especially to tasks issued to safeguarding processes and messages from the call processing periphery. Under certain circumstances, however, the standard distribution is overridden: While recovery is running, recovery receives all messages from the periphery, irrespective of which process the messages are assigned to. If a process exclusively seizes a processor of the call processing periphery (by the conguration task SEZ/BEL), the safeguarding monitor sends all messages for this processor to this process. While a processor is being congured, the device-oriented conguration program receives all messages for the processor. Coordination of collective messages The safeguarding software is a privileged user of IOCP and can issue a collective task at any time. The safeguarding monitor coordinates collective tasks of different safeguarding processes by performing the exchange of messages for collective tasks in such a way that parallel tasks are transmitted too the IOCP in sequence.
64
A30828-X1130-K500-1-7618
Information Control
Logging safeguarding messages The safeguarding monitor logs all safeguarding messages that pass through it by saving them in the hard disk file SG.OPER. Any messages which have a corresponding entry in the monitors 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 be traced. 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 for troubleshooting.
A30828-X1130-K500-1-7618
65
Information Control
66
A30828-X1130-K500-1-7618
Information Control
5
AC ACT ANSI ASIC BAP BCLK BCMY BEL BIOC BIR CAP CARB CC CCG CCNC CHR CI CL CMY
Abbreviations
access control active, ACT (operating state of a unit) American National Standards Institute application specific integrated circuit base processor bus clock system bus for common memory seized (safeguarding), SEZ, (operating state of a unit) bus system for input/output control billing register call processor central bus arbiter for common memory cycle control central clock generator common channel signaling network control channel register common interface coupling logic common memory common memory, control, part 1 common memory, control, part 2 common memory, address network common memory, data network common memory, control, microprocessor coordination processor coordination processor 113D coordination processor, access control call processing buffer coordination processor, cycle control coordination processor, central interface for CP113 (module A) coordination processor, central interface for CP113 (module B) coordination processor, coupling logic coordination processor, executive decentral bus arbiter for common memory direct memory access precedence rating
CMY1C CMY2C CMYA CMYD CMYMP CP CP113D CPAC CPB CPCC CPCIA CPCIB CPCL CPEX DARB DMA DR
CP113C/CR coordination processor 113C/CR
A30828-X1130-K500-1-7618
67
Information Control
DRAM ECC EDC EPROM EWSD FIFO GS HDLC HW IF:MDD IF:MTD IK:DTD IOC IOCIF IOP IOP:AUC IOP:DEV IOP:LAU IOP:MB IOP:MDD IOP:MTD IOP:SCD IOP:SCDP
dynamic random access memory error correction code error detection and correction erasable programmable read-only memory digital electronic switching system first in/first out memory group switch high-level data link control hardware interface for magnetic disk device interface for magnetic tape device IOP kernel for magnetic disk and tape device input/output control input/output controller, interface input/output processor input/output processor for authentication center input/output processor for devices input/output processor for line adaption unit input/output processor for message buffer input/output processor for magnetic disk device input/output processor for magnetic tape device input/output processor for serial data communication devices input/output processor for serial data communication devices, BX.25/X.25 protocoll input/output processor for serial data communication devices V.24/V.28 interface input/output processor for serial data communication devices, X.21/V.11 interface input/output processor for time and alarms input/output processor unified for O&M devices input/output processor for authentication center (module) input/output processor for message buffer (module) input/output processor for serial data communication devices, packet protocol interprocessor communication
IOP:SCDV IOP:SCDX
IOP:TA IOP:UNI IOPAUC IOPMB IOPSCDP IPC
68
A30828-X1130-K500-1-7618
Information Control
IRH LAU LAUB LCUB LED LMY LSY:IOP LTG MB MBG MBU MDD MI MOD MTD MU MUH OMC OMT PC PE PEX PI PIADR PIDAT PIO:DEV PIO:IOC PIO:MB PIO:TA PU RAM RCD SASDAT SCSI SN SSG SVC SW SWET SWSG SYMO
interrupt handler line adaptation unit line adaptation unit, module B line control unit, module B light-emitting diode local memory line system for input/output processor line/trunk group message buffer message buffer group message buffer unit magnetic disk device memory interface magneto-optical disk device magnetic tape device memory unit memory unit H operation and maintenance center operation and maintenance terminal personal computer phase encoded program execution part processor interface unit processor interface, address bus processor interface, data bus physical input/output for devices physical input/output for input/output control physical input/output for message buffer physical input/output for time and alarms processing unit random access memory radio clock device Saving of software data with statistics small computer systems interface switching network space stage group supervisory call software software error treatment software safeguarding (supervisor call) system monitoring
A30828-X1130-K500-1-7618
69
Information Control
SYP TSG UNA
system panel time stage group unavailable, UNA,(operating state of a unit)
70
A30828-X1130-K500-1-7618

CP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CP

Uploaded by

Copyright:

Available Formats

Information

Control Coordination Processor 113D (CP113D)

Coordination Processor 113D (CP113D)

Copyright (C) Siemens AG 1998.

Coordination Processor 113D (CP113D)

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

Coordination Processor 113D (CP113D)

4.5 4.6 4.6.1 4.6.2 4.6.3 4.6.4 4.7 5

Coordination Processor 113D (CP113D)

Access Analog, ISDN, V5.1

Trunks, V5.2, PABX

Signaling SS7 links, high speed SS7 links CCNC/ SSNC

EWSD overview diagram

Coordination Processor 113D (CP113D)

Coordination Processor 113D (CP113D)

IOC1 CAP0 CAP9 BAPM BAPS IOC0 IOC2

BCMY0 CMY1 CMY0

Functional units of the CP113D

Coordination Processor 113D (CP113D)

IOC2 IOC3 Interface BIOC PU PU CL LMY CI

CAP0 PU PU CL LMY CI BCMY1

Interface BIOC PU PU CL LMY CI

BCMY0 CMY1 CMY0 MYC MYB0 MYB1 MYB2 MYB3

The functional units of the CP113D

Base Processor (BAP), Call Processor (CAP), Input/Output Control (IOC)

Coordination Processor 113D (CP113D)

Coordination Processor 113D (CP113D)

Bus for Common Memory (BCMY)

Coordination Processor 113D (CP113D)

Common Memory (CMY)

Input/Output Processors (IOP)

Coordination Processor 113D (CP113D)

Coordination Processor 113D (CP113D)

Coordination Processor 113D (CP113D)

Coordination Processor 113D (CP113D)

Microprocessor Request logic Internal and ready control

Breakpoint logic Timer

AC arbiter, internal control of the local bus

Block diagram of modules CPEX and CPAC

Coordination Processor 113D (CP113D)

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

Coordination Processor 113D (CP113D)

PU0 CPCC in PU0 Cycle, error and ready control

PU1 CPCC in PU1

Memory medium for data (user bits)

Memory medium for ECC (check bits)

Coordination Processor 113D (CP113D)

Coordination Processor 113D (CP113D)

Local bus of processor

Read/write control and IPC control

Input/outputrequests, CMY requests

Block diagram of modules CPCL,CPCIA and CPCIB

BIOC Interface, Modules IOCIF0 and IOCIF1

Coordination Processor 113D (CP113D)

Parity generator /checker

IOP error register IOP supervision

PU0 Fig. 3.4 Block diagram of modules IOCIF0/1

Processor Interface Unit (PI), Modules PIADR and PIDAT

Coordination Processor 113D (CP113D)

Coordination Processor 113D (CP113D)

to/from module DARB

to/from connected processor (BAP, CAP, IOC) Info. line

Request logic Inhibit bit and reset logic