The Executi on Model of APZ/PLEX

-An I nformal Descri pti on

Johan Eri kson and Bo Li ndel l
{johan.eri kson, bo.l i ndel l }@i dt.mdh.se
Department of Computer Sci ence and Engi neeri ng
Ml ardal en Uni versi ty, Vsters, Sweden
Abstract
ProgrammingLanguagefor EXchanges, PLEX, i s a pseudo-
paral l el and event-dri ven real -ti me l anguage devel oped by Erics-
son. The l anguage i s desi gned for, and used i n, central parts of the
AXE tel ephone swi tchi ng system. The l anguage has a si gnal par-
adi gm as i ts top executi on l evel , and i t i s event-based i n the sense
that onl y events, encoded as si gnal s, can tri gger code executi on.
Due to the fact that a PLEX program l e consi st of several i n-
dependent subprograms, i n combi nati on wi th an executi on model
where new jobs are spawned and put i n queues, we al so cl assi fy
the l anguage as pseudo-paral l el .
The l anguage PLEX and the AXE system has been the subject
of study both i n a number of master thesi s projects and i n several
other publ i cati ons. However, onl y bri ef descri pti ons of the execu-
ti on model of PLEX have been presented i n these works.
The l anguage and i ts executi on model are ti ghtl y connected
and i t i s not possi bl e to separate one from the other. Thi s report
presents a thorough descri pti on of fundamental parts of the l an-
guage and i t al so serves as a detai l ed i ntroducti on to the executi on
model of PLEX.
i
Contents
1 Introduction 1
2 TheAXE System 1
2.1 Central - and Regi onal Processors . . . . . . . . . . . . . . . 2
2.2 The Appl i cati on Modul ari ty (AM) Concept . . . . . . . . . . 4
2.3 I nput and Output statements . . . . . . . . . . . . . . . . . 5
2.4 Load, Rel oad and Dump . . . . . . . . . . . . . . . . . . . . 7
3 ProgrammingLanguagefor EXchanges 8
3.1 The structure of a PLEX program . . . . . . . . . . . . . . . 9
3.2 Records, Fi l es and Poi nters . . . . . . . . . . . . . . . . . . 11
3.3 Vari abl es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Data Encapsul ati on . . . . . . . . . . . . . . . . . . . . . . . 15
4 TheExecution Model 15
4.1 PLEX structure and OS requi rements . . . . . . . . . . . . 16
4.2 Software Uni ts . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Functi on Bl ocks . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 Appl i cati on System . . . . . . . . . . . . . . . . . . . . . . . 18
5 ProgramInterwork - Signals 18
5.1 Di rect and buffered si gnal s . . . . . . . . . . . . . . . . . . 20
5.2 Uni que and mul ti pl e si gnal s . . . . . . . . . . . . . . . . . . 21
5.3 Si ngl e and combi ned si gnal s . . . . . . . . . . . . . . . . . . 22
5.4 Local and Non-l ocal si gnal s . . . . . . . . . . . . . . . . . . 24
5.5 Si gnal s and Pri ori ti es . . . . . . . . . . . . . . . . . . . . . . 24
5.6 Si gnal s and Data . . . . . . . . . . . . . . . . . . . . . . . . 24
6 J obs, Signal Buffers and J ob Handling 24
6.1 What i s a Job? . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2 Si gnal Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3 Job Handl i ng . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4 Executi on Ti me Li mi ts . . . . . . . . . . . . . . . . . . . . . 31
7 LinkingEncapsulation 31
7.1 Addressi ng a Program Sequence . . . . . . . . . . . . . . . 32
7.1.1 Addressi ng i n DS . . . . . . . . . . . . . . . . . . . . 35
i i
8 SoftwareRecovery 35
8.1 Forl opp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2 System Restart . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3 Forl opp Rel ease or a System Restart? . . . . . . . . . . . . 39
8.4 Vari abl es and Software Recovery . . . . . . . . . . . . . . . 41
A TheSignal Description 43
1 I NTRODUCTI ON 1
1 Introduction
The programmi ng l anguage PLEX (Programmi ng Language for EXchan-
ges) i s a pseudo-paral l el and event-based real -ti me l anguage devel oped
by Ericsson i n the 1970s. The l anguage i s desi gned for tel ephony sys-
tems and the di al ect studi ed i n thi s report, PLEX-C, i s used i n the Cen-
tral Processor
1
(CP) of the AXE swi tchi ng system from Eri csson. The
l anguage has a si gnal
2
paradi gm as i ts top executi on l evel , and i t i s
event-based i n the sense that onl y events, encoded as si gnal s, can tri g-
ger code executi on. The term pseudo-paral l el has ari sen due to the fact
that a PLEX program l e consi st of i ndependent sub-programs (whi ch
wi l l be di scussed i n Secti on 5, and Fi g. 13), i n combi nati on wi th an exe-
cuti on model (Fi g. 21) where new jobs are spawned and put i n di fferent
queues, cal l ed job buffers, for l ater executi on.
The l anguage has been the subject of study i n a number of mas-
ter thesi s projects at Mlardalen University, [KO00, AGG99, AE00], as
wel l as i n a number of research publ i cati ons, e.g. [MH01, EFGL02].
However, onl y bri ef descri pti ons of the executi on model of PLEX have
been presented i n these works. Thi s i s probabl y due to space l i mi tati ons
and/or the scope of the work i n questi on.
The ai m of thi s report i s to gi ve a more thorough descri pti on of fun-
damental parts of the l anguage than the above menti oned works. I t
al so serves as a detai l ed i ntroducti on to the executi on model of PLEX.
A second ai m i s to serve as a common basi s for future i nvesti gati ons of
the l anguage.
Si nce much of the materi al i n thi s report i s compi l ed together basi -
cal l y from di fferent forms of i nternal Eri csson documents, we gi ve these
references once and for al l at the begi nni ng. I f other materi al i s used,
these references wi l l be gi ven when used. The references used i n thi s
report are [AB99, AB95a, AB98, AB95b, AB02].
2 TheAXE System
The AXE tel ephone exchange system from Eri csson, devel oped i n i ts
earl i est versi on i n the begi nni ng of the 1970s, i s structured i n a modul ar
1
The di fferent ki nd of processors are covered i n Secti on 2.1.
2
Si gnal s are covered i n Secti on 5.
2 THE AXE SYSTEM 2
and hi erarchi cal way. I t consi sts of the two mai n parts:
APT: The tel ephony or swi tchi ng part
APZ: The control part i ncl udi ng central and regi onal processors
whi ch both consi st of hardware and software. The two mai n parts are
di vi ded i nto subsystems.
A subsystem i s di vi ded i n functi on bl ocks. Functi on bl ocks consi st
of functi on uni ts whi ch i s ei ther a central software uni t or a hardware
uni t, a regi onal software uni t and a central software uni t. The ori gi nal
structure of the system i s shown i n Fi g 1.
System Level 1
System Level 2
Subsystem
Function Block
Function Unit
CPS NMS
LIC LIR LIU CJU
AXE
APZ APT
MAS FMS SSS GSS
CJ KR LI
APT - Telephony/Switching part
APZ - Control part including central and regional processors
as well as operating system
CPS - Central Processor Subsystem
MAS - Maintenance Subsystem
AM AM . . .
Fi gure 1: The(original) hierarchical structureof theAXE system. (The
parts that will beof interest in this report is marked with bold text.)
Somewhere around 1994-95, the concept of Application Modularity
(AM) was i ntegrated i nto the system. Thi s wi l l be di scussed i n Secti on
2.2
2.1 Central- and Regional Processors
The hardware aspects that i s of i nterest i n thi s report i s the di sti ncti on
between Central - and Regi onal Processors. Thi s i s because di fferent
2 THE AXE SYSTEM 3
forms of i nterwork i s performed between di fferent ki nds of processors.
The di sti ncti ons are bri ey di scussed i n thi s subsecti on and expl ai ned
i n more detai l i n Secti on 5.
Regional Processor (RP): There are several regi onal processors i n
an AXE system. The mai n task of a regi onal processor i s to rel i eve
the central processor by handl i ng smal l routi ne jobs l i ke scanni ng
and l teri ng.
Central Processor (CP): Thi s i s the central control uni t of the sys-
tem. Al l compl ex and non-tri vi al deci si ons are taken i n the central
processor. Thi s i s the pl ace for al l forms of non-routi ne work. The
work of the processor can be separated i nto two speci cal l y di s-
ti nct parts, namel y i nstructi on executi on and job admi ni strati on.
I nstructi on executi on means handl i ng of uni nterrupted sequences
of operati ons where the work consi sts of address tabl e l ook-up and
cal cul ati ons, pl ausi bi l i ty checks, storage accesses and data mani p-
ul ati ons. The job admi ni strati on mai nl y consi sts of si gnal han-
dl i ng, si gnal conversi on and si gnal buffer handl i ng. The executi on
of i nstructi ons i s a si ngl e-stream work by nature, whereas the job
admi ni strati on to a great extent i s a questi on of pri ori ti zed job
queues (Secti on 6) and transfer of si gnal data.
The CP i s al ways dupl i cated. The two si des work i n paral l el , per-
formi ng exactl y the same operati ons. Duri ng normal operati on,
one CP i s executi ve and the other i s stand-by. A conti nuous check
i s made to ensure that both processors reach the same resul t -
I f they dont, some form of recovery acti on i s performed (Secti on
8). The CP dupl i cati on al so enabl es functi on changes (i nstal l ati on
of new software versi ons) whi l e the exchange i s i n an operati onal
mode by rst i nstal l i ng new software on the stand-by si de and
then change the executi ve and stand-by order between the proces-
sors. As a l ast step, the new software i s i nstal l ed on the former
executi ve (now stand-by) si de.
The CPs store al l central software and data. The CP memory con-
si sts of the regi ster memory and the di fferent stores. Programs
are stored i n the program store (PS) and data i s stored i n the data
store (DS). The reference store contai ns i nformati on about where
2 THE AXE SYSTEM 4
to nd the di fferent programs and data, Fi g. 2.
Program Store
PS
Reference Store
RS
Data Store
DS
Fi gure 2: Stores in thecentral processor (CP). (Theinteraction between
thedifferent stores arecovered in Section 7.)
2.2 TheApplication Modularity (AM) Concept
The AXE Source System i s a number of hardware and software re-
sources devel oped to perform speci c functi ons accordi ng to the cus-
tomers requi rements. I t can be thought of as a basket contai ni ng
al l the functi onal i ty avai l abl e i n the AXE system. Over the years, new
source systems has been devel oped by addi ng, updati ng or del eti ng func-
ti ons i n the ori gi nal source system. But i n the 1980s, the devel opment
of the AXE system for di fferent markets (US, UK, Sweden, Asi a, etc.)
has l ed to paral l el devel opment of the source system si nce functi onal i ty
coul d not easi l y be ported between di fferent markets.
The sol uti on to thi s i ncreasi ng di vergence was the Application Mod-
ularity (AM) concept, whi ch made fast adapti on to customer requi re-
ments possi bl e. The AM concept speci cal l y targeted the fol l owi ng re-
qui rements:
the abi l i ty to freel y combi ne appl i cati ons i n the system,
qui ck i mpl ementati on of requi rements, and
the reuse of exi sti ng equi pment.
The basi c i dea i s to gather rel ated pi eces of software (and hardware)
i nto somethi ng cal l ed Appl i cati on Modul es (AMs). Di fferent tel ecom
appl i cati ons, such as I SDN, PSTN (xed tel ephony), and PLMN (Publ i c
Land Mobi l e Network), are then constructed by combi ni ng the neces-
sary AMs. The i dea i s descri bed i n Fi g. 3, where i t i s al so shown that
di fferent AMs can be used i n more than one appl i cati on.
2 THE AXE SYSTEM 5
AXE
APT APZ
Separate
telecommucination
applications
Aplication Modules (AMs)
shared between different
applications
ISDN PSTN PLMN
AM AM AM AM AM AM
Fi gure 3: TheAM concept incorporated intotheAXE system.
The i ntroducti on of the AM concept ended the probl em wi th paral l el
devel opment of di fferent source systems. I nstead, wi th AMs as bui l di ng
bl ocks, the requi red exchange was constructed by combi ni ng the neces-
sary AMs i nto an exchange wi th the requi red functi onal i ty (i .e., wi th
the necessary appl i cati ons).
2.3 Input and Output statements
An AXE exchange needs to communi cate wi th i ts envi ronment and i ts
operati on and mai ntenance (O&M) staff. Some typi cal si tuati ons coul d
be the fol l owi ng:
- An exchange techni ci an changes subscri ber categori es, repl aces de-
vi ces or connects new subscri bers.
- The exchange i nforms the O&M staff of i mportant events, e.g., i f an
RP i s bl ocked due to a faul t. I n other words, the I /O statements are an
i mportant part of the recovery mechani sm. (See Secti on 8.)
- I nput/output i ncl udes certai n routi ne tasks to, e.g. dumpi ng data on a
hard di sk.
There i s a l arge number of I /O devi ces used; al arm and hard copy pri nt-
ers, di spl ay uni ts, work stati ons and PCs, magneti c tape dri vers, hard
2 THE AXE SYSTEM 6
and exi bl e di sks.
Before communi cati ng wi th an I /O devi ce, the PLEX program has
to sei ze the devi ce. Li kewi se, the devi ce has to be rel eased when the
communi cati on ends. Thi s guarantees excl usi ve access to the devi ce.
Al l I /O devi ces are connected to a support processor (SP), and functi on
bl ocks that recei ve or send i nformati on vi a the I /O system are cal l ed
user blocks. Fi g. 4 shows the i nteracti on between the I /O system and
a user bl ock. When sei zi ng an I /O devi ce, the I /O system assi gns a free
SP
Line Buffer
72 Characters
Analysis Buffer
144 Characters
I/O System
User
Block
2 Insert
3 Write
4 Read
1
1 Fetch
2 3
4
Program Store
I/O device
Fi gure 4: TheI / O systemand its communication with theenvironment.
l i ne buffer and a free anal ysi s buffer (see Fi g. 4) to thi s devi ce. These
buffers temporari l y store the I /O text. The anal ysi s buffer handl es i nput
from the I /O devi ce, and the l i ne buffer handl es output.
The basi c (PLEX) statements for transferri ng i nformati on between
the buffers and the I /O devi ce, and between the buffers and the user
bl ocks are:
- FETCH: transfer i nformati on from the anal ysi s buffer to the user bl ock.
- INSERT: transfer i nformati on from the user bl ock to the l i ne buffer.
- WRITE: orders the I /O system to pri nt out the text i n the l i ne buffer to
an I /O devi ce.
- READ: transfer i nformati on from the I /O devi ce to the anal ysi s buffer.
Agai n, see Fi g. 4.
2 THE AXE SYSTEM 7
Typi cal l y, I /O communi cati on starts wi th the operator enteri ng a
command on an I /O devi ce. The command i s recei ved by the I /O sys-
tem and del i vered to the software uni t where i t has been dened by
the programmer. A command i s recei ved i n a program (i .e., a software
uni t) i n the same way as a si gnal (Secti on 5) but the command recei vi ng
statement must be preceded by the keyword COMMAND to i ndi cate that
thi s i s a statement used by the I /O system.
2.4 Load, Reload and Dump
An AXE exchange may exi st for up to 40 years, whi ch i mpl i es certai n
requi rements regardi ng the operati on and mai ntenance of the software.
The terms Load, Reload and Dump are covered i n thi s secti on si nce
they wi l l be used i n thi s report when we di scuss vari abl es (Secti on 3.3)
and software recovery (Secti on 8).
When al l the software bl ocks have been wri tten and compi l ed, the
programs and data, i ni ti al and exchange, are wri tten, dumped, to a
magneti c tape whi ch i s l oaded i nto the exchange. Thi s process i s cal l ed
i ni ti al l oadi ng. On l oadi ng of new bl ocks, or new revi si ons of exi sti ng
bl ocks, an i ncremental re-l i nki ng occurs, as wel l as an i ni ti al i zati on of
data store vari abl e val ues, i f requi red accordi ng to thei r gi ven variable
properties
3
. A DCI (Data Conversi on I nformati on) i s wri tten for each
bl ock bei ng l oaded to speci fy the data i ni ti al i zati on between the ol d (i f
exi sti ng) and new bl ocks. Duri ng the function changeprocess (Secti on
2.1) the new bl ock can get i ts new val ue from ei ther of the fol l owi ng
three ways:
- Get val ue from data sector
4
.
- Get val ue from DCI .
- Get val ue from exi sti ng software.
I n the case of system fai l ure where a system restart
5
has been per-
formed, software backup copi es are reloaded i nto the exchange. When
rel oaded, some vari abl es wi l l recei ve rel oad val ues from the magneti c
tape, whereas other vari abl es wi l l not have val ues unti l the program
3
Vari abl e properti es i s covered i n Secti on 3.3
4
The data sector i s menti oned i n Secti on 3.1
5
The system restart process i s expl ai ned i n Secti on 8
3 PROGRAMMI NG LANGUAGE FOR EXCHANGES 8
i s executed by a signal
6
. Whether or not a vari abl e recei ves a rel oad
val ue i s determi ned by the vari abl e properti es set by the desi gner. Thi s
i s covered i n Secti on 3.3.
Rel oadi ng means that the contents of DS (i .e., onl y RELOAD decl ared
vari abl es) are rel oaded i nto the exchange agai n. I f a change has oc-
curred i n PS and RS, they wi l l be rel oaded as wel l .
The contents of Program-, Reference- and Data store are regul arl y
saved to a hard di sk (or a magneti c tape). Thi s process i s cal l ed dump
and enabl es the rel oad acti on descri bed above.
3 ProgrammingLanguagefor EXchanges
Programmi ng Language for EXchanges (PLEX) i s desi gned by Eri csson
and used to program tel ephony systems. I t l acks common statements
from other programmi ng l anguages such as WHILE l oops, negati ve nu-
meri c val ues and real numbers. These are not needed i n a tel ephony
exchange system. The l anguage was desi gned and devel oped i n i ts rst
form i n the 1970s and extended i n 1983. The versi on under consi dera-
ti on i n thi s report, PLEX-C, i s used i n the AXE central processors (see
Secti on 2.1). Other l anguages used i n the AXE system are shown i n
Fi g. 5
7
. The reason for devel opi ng a new l anguage for the AXE system
was that no other l anguages under consi derati on ful l l ed Eri cssons re-
qui rements.
Some i mportant characteri sti cs of the l anguage are l i sted bel ow:
PLEX i s an event-based l anguage wi th a si gnal i ng paradi gm as
the top executi on l evel . Onl y events can tri gger code executi on
and events are programmed as si gnal s. A typi cal event i s when a
subscri ber l i fts the phone to di al a number.
The executi on model i s descri bed i n Chapter 4 and si gnal s i n Sec-
ti on 5.
The si gnal s are executed on one of four pri ori ty l evel s (expl ai ned
i n Secti on 6), whi ch resul ts i n very l i ttl e overhead when a hi gher
6
Si gnal s are exami ned i n Secti on 5
7
As coul d be seen i n Fi g. 5, there i s another di al ect of PLEX (PLEX-M). However,
these di al ects are si mi l ar, and when we tal k about PLEX i n thi s report, we mean the
di al ect used i n the central processors, i .e, the PLEX-C di al ect.
3 PROGRAMMI NG LANGUAGE FOR EXCHANGES 9
l evel i nterrupts a l ower si nce each pri ori ty l evel has i ts own regi s-
ter set.
Jobs (Secti on 6.1) at the same l evel are atomi c and can never
i nterrupt each other.
EMRPD
EMRP
EM
RPG
CP
STR STC RPD RP
GARP
C/C++
Plex-M
ASM 6809
ASM 6809 ASM 6809 C/C++
ASA 21R
ASA 210R
Plex-C
ASA 210C
EMRPD - Extension Module Regional Processor Digital
EMRP - Extension Module Regional Processor
STR - Signaling Terminal Remote
STC - Signaling Terminal Central
RPD - Regional Processon Digital
RP - Regional Processon
CP - Central Processon
EM - Extension Module
RPG - RP with group switch interface
GARP - Generic Application RP
C/C++
C/C++
Fi gure 5: The different languages used in different parts of the AXE
system
3.1 Thestructureof a PLEX program
When we tal k about a PLEX program, or a PLEX program l e, we mean
the PLEX l e that speci es a functi on uni t (Secti on 4.3). Thi s document,
the SourceProgramI nformation (SPI ), shown i n Fi g. 6, consi sts of the
fol l owi ng mai n parts:
3 PROGRAMMI NG LANGUAGE FOR EXCHANGES 10
The Declaresector, whi ch contai ns the vari abl e and constant dec-
l arati ons that are used i n the program sector. Vari abl es wi th the
property DS, Data Store, (Secti on 3.3) wi l l exi st beyond the execu-
ti on of subprograms.
The Parameter sector, where speci c AXE parameters are pl aced.
These parameters are not l ocal to a bl ock, and permi t gl obal access
from al l parts of the exchange. They can be changed by customers
si nce they are pl aced i n an SQL database.
The Programsector contai ns the executabl e statements, i .e., the
PLEX source code that wi l l run i n the exchange. Thi s sector i s
normal l y di vi ded i n several subprograms (expl ai ned i n Secti on 5
and Fi g. 13).
The Data sector: Some vari abl es, i .e. Data Store vari abl es, needs
to have i ni ti al val ues when the program (i .e., the SPI ) i s l oaded
i nto the exchange
8
. These i ni ti al val ues can be provi ded i n the
data sector. Al so, the posi ti on, i .e. the base address, of stored vari -
abl es i n memory can be al l ocated i n the data sector. Thi s enabl es
a faster functi on change (bri ey descri bed i n Secti on 2.1).
The ID sector i s used for i nternal documentati on onl y.
The SPI i s compi l ed together wi th the fol l owi ng documents
9
:
- The Signal Survey, SS, whi ch i s a l i st of al l the di fferent si gnal s that
one functi on uni t (i .e., the functi on uni t speci ed i n the SPI ) recei ves
and sends. There i s one SS per functi on uni t. There i s no i nformati on
about senders and recei vers i n the SS, thi s i nformati on i s added l ater
duri ng l oadi ng.
- The Signal Description, SD. The functi on bl ocks and functi on uni ts
communi cate wi th si gnal s (Secti on 5). The SD descri bes the purpose,
type and data of onesi gnal . SDs are stored i n separate si gnal handl i ng
l i brari es.
8
The initial loadingi s descri bed i n Secti on 2.4.
9
The di fferent steps of the compi l ati on process, as wel l as the PLEX compi l er, i s
descri bed i n [AE00]
3 PROGRAMMI NG LANGUAGE FOR EXCHANGES 11
DOCUMENT KRUPROGRAM;
DECLARE;
:
:
END DECLARE;
PARAMETER;
:
:
END PARAMETER;
PROGRAM; PLEX;
:
:
END PROGRAM;
DATA;
:
:
END DATA;
END DOCUMENT;
ID KRUPROGRAM TYPE DOCUMENT;
:
:
END ID;
Fi gure 6: Structureof theSPI , i.e., a PLEX programle.
3.2 Records, Files and Pointers
Records col l ect vari abl es that descri be properti es of a group of i tems,
for i nstance, cal l s or subscri bers
10
. Record vari abl es may be stored el d,
symbol or stri ng vari abl es (Secti on 3.3). Vari abl es i n a record may be i n-
dexed or structured, and they are cal l ed i ndi vi dual vari abl es. DS (Data
Store, descri bed i n Secti on 3.3) vari abl es that are not part of a record,
are known as common vari abl es.
A Filei s a set of records. One l e consi st of one or more records, al l
wi th the same i ndi vi dual vari abl es.
Pointers address the rel evant record i n a l e. I n PLEX, poi nters
are si mpl y record numbers. The records i n a l e are numbered, and
the val ue of the poi nter i s the number of the current record. I n other
words, poi nters i n PLEX are not si mi l ar to poi nters i n C and can not
be mani pul ated i n the same way. Fi g. 7 shows an exampl e l e wi th
i ts records and a poi nter. The number of records i n a l e may be xed
or changeabl e. A xed si ze i s speci ed i n the Data sector of the SPI
(Secti on 3.1), whi l e al terabl e l e si zes are set by commands (Secti on
2.3).
10
A (PLEX) record i s si mi l ar to a struct i n C.
3 PROGRAMMI NG LANGUAGE FOR EXCHANGES 12
n
4
3
2
1
SUBNUMBER
NAME
STATE
0
POINTER
Fi gure 7: An examplelewith n records and a pointer with thecurrent
value2.
3.3 Variables
Dependi ng on how vari abl es i s to be treated at a software error and a
fol l owi ng recovery acti on, the PLEX desi gner can assi gn di fferent prop-
erti es to the vari abl es. Thi s i s to be covered i n thi s secti on.
There are three di fferent data types i n PLEX:
- Field variables for numeri c i nformati on. They contai n non-negati ve
i ntegers onl y. (Negati ve i ntegers are not needed i n the AXE system.)
- Symbol variablesfor symbol i nformati on, e.g., IDLE, BLOCKED, BUSY,
etc.
- Stringvariables store text stri ngs.
These data types (vari abl es) can be stored or temporary.
The val ue of a temporary vari abl e exi sts onl y i n the Regi ster Mem-
ory (RM - i nternal CP regi sters) and onl y whi l e i ts correspondi ng
software i s bei ng executed. Vari abl es are by defaul t temporary.
Stored vari abl es are stored i n the Data Store (Fi g. 2), l oaded i nto a
regi ster i n the RM for processi ng and then wri tten back to the DS.
Thus, i ts val ue i s never l ost, even i f the program i s exi ted and re-
entered l ater. DS vari abl es are al so a natural way to communi cate
between di fferent forlopps
11
.
11
Forl opps are expl ai ned i n Secti on 8.1
3 PROGRAMMI NG LANGUAGE FOR EXCHANGES 13
I t i s the stored vari abl es that may be assi gned the di fferent properti es
al ready descri bed. These properti es are DS, CLEAR, RELOAD, DUMP,
STATIC, BUFFER and COMMUNICATION BUFFER. The properti es wi l l
al l be descri bed i n thi s secti on.
From a storage poi nt of vi ew, the vari abl es can be di vi ded i nto the
fol l owi ng types: Temporary and stored have been descri bed above. The
thi rd category i s the buffers. Buffer vari abl es
12
are al l ocated dynami -
cal l y i n an area reserved for dynami c buffers by usi ng an al l ocate state-
ment. The si ze of the buffers can be speci ed stati c (COMMUNICATION
BUFFER) or dynami c BUFFER. The xed si ze i s speci ed i n the Decl are
sector (Secti on 3.1) whi l e the dynami c si ze can be set i n the Program
sector. The dynami c buffers are sl ower than the stati c si nce they must
be admi ni stered dynami cal l y. These categori es are pi ctured i n Fi g. 8
together wi th i ts properti es.
Under normal ci rcumstances, the exchange starts the (appl i cati on)
software and i t never stops. After seri ous errors, however, the APZ (i .e.,
the operati ng system part) stops the program executi on and restarts
the software. The fol l owi ng properti es descri be the vari abl e behavi or at
start or restart:
CLEAR - Cl eari ng at start/restart
Fi el d vari abl es are set to zero; symbol vari abl es to the rst val ue
i n thei r decl arati on l i st.
RELOAD - Loadi ng at restart wi th rel oad
The vari abl e val ue i s rel oaded from tape/hard di sk to ensure that
the val ues before and after the restart wi th rel oad are the same.
DUMP - Dumpi ng at restart.
Thi s property i s used for testi ng and traci ng purposes.
STATIC - When a software uni t i n an operati ng exchange i s to be
updated, a function changetakes pl ace. Remember from Secti on
2.1 that the CP i s al ways dupl i cated. Thi s means that new soft-
ware can be i nstal l ed whi l e the exchange i s runni ng. A STATIC
decl ared vari abl e means that the vari abl e val ue i s not updated
wi th a new software versi on.
12
Buffer vari abl es are si mi l ar to the array structure i n C.
3 PROGRAMMI NG LANGUAGE FOR EXCHANGES 14
VARIABLES
REGISTER-ALLOCATED
VARIABLES
(Temporary variables)
MEMORY-ALLOCATED
VARIABLES
(DS & BUFFER)
PERMANENTLY
ALLOCATED
VARIABLES (DS)
DYNAMICALLY
ALLOCATED
VARIABLES (BUFFER)
STATIC
CLEAR
RELOAD
DUMP
F
i
e
l
d
V
a
r
V
a
r
S
y
m
b
o
l
V
a
r
S
t
r
i
n
g
DUMP
F
i
e
l
d
V
a
r
Fi gure 8: Variables and properties (froma storagepoint of view).
4 THE EXECUTI ON MODEL 15
Not al l combi nati ons of the vari abl e properti es are possi bl e (i .e., l egal ).
Fi g. 9 contai ns a tabl e l i sti ng al l val i d combi nati ons of vari abl es and
properti es.
Field
Variable
String
Variable
Symbol
Variable
DS
DS DUMP
DS STATIC
DS RELOAD
DS RELOAD DUMP
DS RELOAD STATIC
DS CLEAR
DS CLEAR DUMP
BUFFER
BUFFER DUMP
Temporary
Yes
Yes
Yes No
No Yes
(1)
Yes No
(1) Except for one- and two-dimensional arrays
Fi gure 9: Permitted combinations of variable properties and variable
types.
3.4 Data Encapsulation
Al l vari abl es and constants decl ared i n the Declare sector of the SPI ,
see Secti on 3.1, have thei r scope i nsi de the software uni t speci ed. Al l
subprograms (Secti on 5) of that SPI can access these vari abl es and con-
stants. Subprograms not part of that functi on uni t cannot access these
vari abl es and constants.
4 TheExecution Model
A bri ef di scussi on of the executi on model has al ready been gi ven i n Sec-
ti on 3 and we conti nue and deepen the di scussi on i n thi s secti on. We
rst bri ey di scuss PLEX structure, operati ng system requi rements,
functi on bl ocks and appl i cati on system before we l ook deeper at pro-
gram i nterwork (i .e, signals), Secti on 5, and job buffers, Secti on 6, both
central concepts i n the PLEX/APZ envi ronment.
4 THE EXECUTI ON MODEL 16
Signal
ENTRY 1
Signal
ENTRY 2
Signal
ENTRY 3
Signal
ENTRY 4
... ... ...
Signal
ENTRY n
Variable A
DATA
Common Data Storage
for all Variables in all
entries of the whole
Block
Fi gure 10: The structure of a software unit (block). The possibility of
several sub-programs accessingthesamedata within theblock is shown.
All sub-programs (signal entries) can access all DS variables insidethe
sameblock (except for individuals that areDS variables insidea record).
This conveys a DS variable can be used as a communication channel
between all sub-programs insidethesamesoftwareunit.
4.1 PLEXstructureand OS requirements
PLEX i s an asynchronous concurrent event based real -ti me l anguage
and, as stated i n Secti on 3, i t has a si gnal i ng paradi gm as the top ex-
ecuti on l evel whi ch means that onl y events can tri gger code executi on
and these events are programmed as si gnal s. Si gnal s wi l l be further
expl ored i n Secti on 5. The mai n task of an operati ng system that i s to
run PLEX, i s to buffer i ncomi ng si gnal s and start thei r executi on i n the
ri ght si gnal entry statement.
4.2 SoftwareUnits
I n l arge software systems, such as a tel ecommuni cati on system, there
i s a need to group code i nto modul es, for exampl e, to control a certai n
hardware, or to i mpl ement i n software add-on functi onal i ty. A Software
Uni t i s a quanti ty of PLEX code for the di fferent jobs
13
needed for such
a modul e, cal l ed a functi on. A Uni t can not access data i n another uni t,
i .e, a uni t has data encapsul ati on (see Secti on 3.4).
13
Jobs are covered i n Secti on 6.1.
4 THE EXECUTI ON MODEL 17
Event
Hardware
Hardware
RP(D)
EMRP(D)
unit structure
function block
RP-CP signal
SST
SDT
DATA
unit
}
}
code
enter
exit
send
effect
aptapz signal interface
forlopp
forlopp
manager
restart
code
restart
signal
cp-cp
signal
apz
apt
Central Processor (CP)
APT
application
system
APZ
platform
system
Fi gure 11: APT Application system.
5 PROGRAM I NTERWORK - SI GNALS 18
4.3 Function Blocks
A functi on bl ock i s a software uni t by i tsel f or a software uni t i n the
CP wi th the associ ated software uni t i n the EMRP or RP and possi bl y
associ ated hardware needed to i mpl ement a functi on.
I f we rel ate the functi on bl ocks to the AM concept, descri bed i n Sec-
ti on 2.2, i t shoul d be poi nted out that an AM i s not a PLEX l anguage
construct. From a PLEX l anguage poi nt of vi ew, each AM and the com-
mon resources can be seen as a col l ecti on of bl ocks. Si gnal s between
AMs and to/from the common resources are gathered i nto standard i n-
terfaces.
4.4 Application System
An appl i cati on system i s a group of functi on bl ocks that i nterwork to-
gether to form a compl ete appl i cati on, such as the control of a certai n
tel ephone exchange, see Fi g. 11. Al l the si gnal s and uni ts of the part
of the appl i cati on system hosted on a certai n processor take part i n a
l i nki ng process. (For uni ts wri tten i n PLEX-C, the host i s the CP.)
The l i nki ng process resol ves that si gnal s sent from a certai n uni t are
di rected to the ri ght entry poi nt i n the ri ght uni t.
5 ProgramInterwork - Signals
A si gnal i s an external l y dened l anguage el ement i n PLEX for the i n-
terwork between software uni ts. A si gnal can be descri bed as a message
wi thi n one or between two software uni ts or as an asynchronous (one
way) functi on cal l , i .e., i t i s si gnal s that perform the communi cati on
between di fferent functi on uni ts. Si gnal s can be cl assi ed i n numerous
ways (Secti on 5.1, 5.2, 5.3 and 5.4) but the maindistinctioni s between
direct and buffered si gnal s (Secti on 5.1). A di rect si gnal i s si mi l ar to a
jump from one functi on uni t or program to another, whereas a buffered
si gnal i s more l i ke a fork
14
system cal l except that the executi on con-
ti nues i n the parent process whereas the child process i s put i n the
14
fork i s a nonANSI C functi on that copies thecurrent process and begins executing
it concurrently, [KP96]. The executi on wi l l then conti nue i n thi s newl y created chi l d-
process.
5 PROGRAM I NTERWORK - SI GNALS 19
job queue (Secti on 6) for l ater executi on. I n thi s way, after the sendi ng
of the buffered si gnal , the two executi on paths are i ndependent paral l el
threads, unsynchroni zed wi th each other. The di fference i s expl ai ned i n
more detai l i n Secti on 5.1, but we al ready state that buffered si gnal s i s
the norm and that the cl assi cati on referred to onl y appl i es to CP-CP
si gnal s. CP-RP and RP-CP si gnal s are alwaysbuffered.
As shown i n Fi g. 12, si gnal s are sent between software executi ng on
the di fferent processor types descri bed i n Secti on 2.1.
RP - CP CP - RP RP - CP CP - RP
CP - CP
CP - CP
Function Block A Function Block B
Hardware
Regional
Software
Central
Software
H
A
R
D
W
A
R
E
S
O
F
T
W
A
R
E
Fi gure 12: Thedifferent types of softwaresignals.
Most si gnal s coul d be seen as a jump from a si gnal -sendi ng state-
ment i n one program to a si gnal -recei vi ng statement i n another pro-
gram (even i f buffered si gnal s rst go through a buffer). Thi s i mpl i es
that the code i n a PLEX program uni t
15
never executes from the begi n-
ni ng to the end (i .e., from the begi nni ng of the program l e to the end of
the program l e), but from a si gnal recei vi ng statement (e.g., ENTER), to
ei ther a di rect si gnal -sendi ng statement (e.g., SEND) or an EXIT state-
ment. I n PLEX, a subprogram i s the code sequence from ENTER to
EXIT. I t i s possi bl e to l eave a subprogram wi th an EXIT wi thout a pre-
vi ous si gnal sendi ng statement, but i t i s al so possi bl e to send several
buffered si gnal s before an EXIT statement. Fi g. 13 i l l ustrates a general
program di vi ded i nto subprograms. Note that si nce programs wri tten i n
PLEX do not normal l y execute from start to end, or i n any order, i t can
not be assumed that the program i n Fi g. 13 recei ves SI GNAL1 before or
15
A PLEX program uni t = a PLEX source code l e
5 PROGRAM I NTERWORK - SI GNALS 20
after SI GNAL3, or SI GNAL4 before or after SI GNAL6. Thi s can resul t
i n unpredi ctabl e val ues of stored vari abl es.
PROGRAM; PLEX;
ENTER SIGNAL1;
....
SEND BUFFERED SIGNAL2;
....
EXIT;
ENTER SIGNAL3;
....
SEND DIRECT SIGNAL4;
CUSELESS = 0;
ENTER SIGNAL5;
....
SEND BUFFERED SIGNAL6;
....
SEND DIRECT SIGNAL7;
ENTER SIGNAL8;
....
EXIT;
....
END PROGRAM;
a subprogram
a subprogram
a subprogram
a subprogram
Fi gure 13: A PLEX program le divided in subprograms. Note that
theassignment CUSELESS = 0; will never beexecuted sinceit is placed
between an exit and an enter statement. (SeealsoFig. 6whereacomplete
programleis described.)
Si nce the exchange handl es several cal l s si mul taneousl y whi l e the
CP can onl y execute one program at a ti me, the CP must queue the
si gnal s somewhere. Thi s i s done i n job buffers, a job tabl e or i n ti me
queues and thi s wi l l be expl ored i n Secti on 6.
As was sai d earl i er there are di fferent parameters that descri be the
si gnal properti es of a CP-CP si gnal . Three groups cl assi fy these prop-
erti es and each si gnal has one property from each group. Each group i s
descri bed bel ow and al l possi bl e combi nati ons i s shown i n Fi g. 17.
5.1 Direct and buffered signals
As was stated i n Secti on 5, the mai n di sti ncti on between (CP-CP) si g-
nal s i s whether they are di rect or buffered. Buffered si gnal s start anew
5 PROGRAM I NTERWORK - SI GNALS 21
job, whereas di rect si gnal s continuethe current job. (Jobs are covered
i n Secti on 6.1). That i s, they are handl ed di fferentl y i n the executi on
model .
Di rect si gnal s reach the recei vi ng bl ock i mmedi atel y, they coul d be
seen as di rect jumps to another uni t. By usi ng di rect si gnal s, other
si gnal s have no possi bi l i ty of comi ng-i n-between, i .e., the programmer
retains control over the executi on. However, di rect si gnal s are normal l y
onl y al l owed to be used i n very ti me-cri ti cal program sequences, such as
cal l set-up routi nes.
Wi th buffered si gnal s, i t i s not predi ctabl e when the si gnal reaches
the recei vi ng bl ock. Di rect and buffered si gnal s are i l l ustrated i n Fi g.
14.
Unit A Unit B
A Direct Signal
Unit A Unit B
A Buffered Signal
Job Buffer
Fi gure 14: Direct and buffered signals.
5.2 Uniqueand multiplesignals
Thi s di sti ncti on concerns the number of recei vers of the si gnal . A uni que
si gnal can onl y be recei ved i n one parti cul ar bl ock, whi l e a mul ti pl e
si gnal can go to any bl ock as shown i n Fi g. 15. However, i t i s not possi bl e
to send a mul ti pl e si gnal to more than one bl ock si mul taneousl y whi ch
means that a mul ti pl e si gnal does not perform mul ti cast
16
. But even
i f a mul ti pl e si gnal can go to any of the recei vi ng bl ocks speci ed i n the
Signal Survey
17
, the si gnal sendi ng statement must al ways contai n one
(and only one) recei ver of the mul ti pl e si gnal .
16
Mul ti cast: Send once - recei ved by al l
17
The Si gnal Survey i s descri bed i n Secti on 3.1
5 PROGRAM I NTERWORK - SI GNALS 22
Unit A Unit B
A Unique Signal
Unit D
Unit C
Unit B
Unit A
A Multiple Signal
Fi gure 15: Uniqueand multiplesignals.
5.3 Singleand combined signals
The thi rd di sti ncti on concerns whether the sendi ng bl ock expects an
answer. Combi ned si gnal s demand an i mmedi ate answer, whi l e si ngl e
si gnal s do not requi re such feedback. For thi s reason, combi ned si gnal s
can never be buffered (as shown i n Fi g. 17). I nstead, they behave
l i ke di rect jumps from one uni t to another. When the executi on i n the
other uni t (the recei ver of the si gnal ) ni shes, executi on jumps back to
the ori gi nati ng uni t. Combi ned si gnal s are al ways di rect si gnal s, whi ch
means that executi on conti nues wi thout i nterrupt and al l other si gnal s
have to wai t. Fi g. 16 i l l ustrates these ki nd of si gnal s.
When di scussi ng the sendi ng and recei vi ng of combi ned si gnal s, one
wi l l al so menti on forward and backward si gnal s. A communi cati on be-
tween two parts
18
i s al ways i ni ti ated by one of the parts. The i ni ti ati ng
part i s sendi ng the forward si gnal whereas the part that repl i es to the
cal l i s sendi ng the backward si gnal . Thi s i s pi ctured i n Fi g. 18.
18
Whi ch, i n our target domai n, i s the sendi ng and recei vi ng of si gnal s between func-
tion blocks.
5 PROGRAM I NTERWORK - SI GNALS 23
Unit A Unit B
A Single Signal
Unit A Unit B
Combined Signals
Fi gure 16: Singleand combined signals.
Signal Type Buffered Direct
Single
Combined
unique
multiple
unique
multiple
X
X
X
X
X
X
Fi gure 17: Possible properties for CP-CP signals. X indicates a le-
gal/ possible combination, shaded with Grey indicates an illegal alter-
native. NOTE: A combined backward signal can not bemultiplesince
this signal is an answer (i.e., an acknowledgment) toa caller and must
thereforereturn tothecaller and nobody else.
SEND Signal-A
(Forward)
RETRIEVE Signal-A
(Backward)
RECEIVE Signal-B
(Forward)
RETURN Signal-B
(Backward)
Block A
RECEIVE Signal-A
(Forward)
RETURN Signal-A
(Backward)
SEND Signal-B
(Forward)
RETRIEVE Signal-B
(Backward)
Block B Time
Fi gure 18: Forward and Backward signals.
6 JOBS, SI GNAL BUFFERS AND JOB HANDLI NG 24
5.4 Local and Non-local signals
I n the begi nni ng of Secti on 5, we sai d that si gnal s are used for the
i nterwork between software uni ts. But si gnal s can al so be used for
the i nterwork between different parts of thesamesoftwareunit. These
si gnal s are cal l ed local signals, si nce they are l ocal to the software uni t
they bel ong to. I .e., the reci pi ent resi des i n the same software uni t.
(Consequentl y, al l other si gnal s are cal l ed non-local si gnal s.
The behavi or of a l ocal si gnal i s si mi l ar to that of a GOTO statement
si nce they resul t i n di rect jumps to the reci pi ent. (And i n that sense,
they can be regarded as di rect si gnal s.)
Whether a si gnal i s l ocal or not, i s speci ed i n the Si gnal Descri pti on
(whi ch was bri ey expl ai ned i n Secti on 3.1, and covered i n more detai l
i n Appendi x A). The di sti ncti on between l ocal and non-l ocal si gnal s i s
of i mportance i n, for i nstance a semanti c framework for PLEX.
5.5 Signals and Priorities
Every si gnal that i s sent i n the system i s assi gned a pri ori ty l evel , A -
D. The pri ori ty l evel i s of i mportance when the si gnal i s to be buffered
(Secti on 6), and i t tel l s the i mportance of the source code that i s tri g-
gered to executi on by the si gnal . The pri ori ty of each si gnal i s speci ed
i n the correspondi ng Si gnal Descri pti on.
5.6 Signals and Data
Signal Data are vari abl e val ues sent wi th a si gnal
19
. The data may
consi st of el d vari abl es, symbol vari abl es, poi nters, numeral s, stri ng
objects, buffer vari abl es and el d expressi ons. For si ngl e and combi ned
si gnal s, i t i s possi bl e to send 25 si gnal data. The data i s l oaded to the
regi ster memory i n the central processor (see Secti on 2.1) i f the si gnal
i s di rect, or to the job buffer i f the si gnal i s to be buffered.
6 J obs, Signal Buffersand J ob Handling
I n the fol l owi ng sub-secti ons, we wi l l di scuss the deni ti on of a job(Sec-
ti on 6.1), the di fferent ways of del ayi ng/bufferi ng a si gnal (Secti on 6.2)
19
Thi s i s si mi l ar to a call by valuefuncti on cal l .
6 JOBS, SI GNAL BUFFERS AND JOB HANDLI NG 25
and, nal l y, how jobs are handl ed at runti me (Secti on 6.3).
6.1 What is a J ob?
A job i s a conti nuous sequence of statements executed i n the processor.
A job begi ns wi th an ENTER statement for a buffered si gnal and ends
wi th an EXIT statement.
Between the ENTER and the EXIT statement, several buffered si g-
nal s (or no si gnal s at al l ) may be sent. A job i s not l i mi ted to one CP
software uni t, several uni ts and bl ocks can take part i n a job.
A job does alwayshave a si ngl e entry poi nt but i t mayhave mul ti pl e
exi t poi nts.
I n Secti on 5.5 we di scussed the pri ori ty of a si gnal . I n the fol l owi ng
subsecti ons, we wi l l i nstead tal k about the pri ori ty of a job. Thi s make
sense si nce i t i s more natural to l ook at whol e jobs when di scussi ng
executi on of PLEX code, than i t i s to l ook at a si ngl e
20
si gnal . The
reason i s that a job i ncl udes the actual PLEX code that i s tri ggered to
executi on by the si gnal , as wel l as the si gnal i tsel f.
6.2 Signal Buffers
Some jobs i n the AXE system are not ti me-cri ti cal and can wai t to be
executed, whi l e others need to be executed i mmedi atel y. The rst case
hol ds for admi ni strati ve jobs and the second case for jobs rel ated to traf-
c handl i ng (i .e., tel ephone cal l s
21
) and CP faul ts.
Buffered si gnal s (whi ch coul d be read as the start of a new job)
may be del ayed usi ng one of the fol l owi ng methods:
Job Buffer: del ays a si gnal unti l al l ol der jobs have been processed
Job Tabl e: sends si gnal s at short peri odi c i nterval s
Ti me Queue: del ays si gnal s by rel ati ve or absol ute ti me
We wi l l l ook further to these di fferent ways of del ayi ng a si gnal .
20
By si ngl e si gnal s, we do not mean si ngl e si gnal s as descri bed i n Secti on 5.3.
21
A normal l oad on the system i s 200 tel ephone cal l s that i s to be handl ed every
second. These jobs are al l ti me cri ti cal and have the same pri ori ty, but the performance
woul d not be acceptabl e wi th a rst-come-rst-served approach. A sol uti ons i s to use
buffered si gnal s as a ti me shari ng mechani sm.
6 JOBS, SI GNAL BUFFERS AND JOB HANDLI NG 26
J ob Buffers: Job buffers are queues wi th a FIFO-semantics
22
. There
are four buffers for CP-CP and RP-CP si gnal s and one for CP-RP
si gnal s; J ob Buffer A, J ob Buffer B, J ob Buffer C and J ob Buffer
D, al l for CP-CP and RP-CP si gnal s, where Job Buffer A has the
hi ghest pri ori ty. J obBuffer R i s the buffer for CP-RP si gnal s.
The buffers carry the fol l owi ng type of tasks:
J ob Buffer A - urgent tasks of theoperating system; preferenti al
jobs, e.g., errors i n trafc equi pment.
J ob Buffer B - tel ephone trafc.
J ob Buffer C - I /O communi cati on. The command statement de-
scri bed i n Secti on 2.3 i s handl ed at thi s l evel .
J ob Buffer D - APZ routi ne sel f-tests.
J ob Buffer R - CP-RP si gnal s queue i n JBR, a buffer for si gnal s
sent from the CP to a RP.
TheJ ob Table: The job tabl e contai ns jobs executed at short peri odi c
i nterval s, for i nstance, i ncrementi ng cl ocks for ti me supervi si on.
The job tabl e has hi gher pri ori ty than any of the job buffers. Si nce
the possi bl e executi on ti me after a job tabl e si gnal i s very short,
thi s si gnal onl y i ni ti ates a program sequence i n the recei vi ng bl ock,
whi ch i nserts a buffered si gnal i n one of the job buffers. The
buffered si gnal i ni ti ates the real work i n the program whi ch from
an appl i cati on poi nt of vi ew, has the pri ori ty of the buffer i t i s i n-
serted i n.
TimeQueues: Ti me queues del ay peri odi c and other jobs at l onger i n-
terval s than the job tabl e. There i s one absol ute ti me queue and
three rel ati ve ones. The absol ute ti me queue stores the absol ute
ti me for si gnal executi on (month, day, hour and mi nute). Every
mi nute, the ti me queue compares thi s val ue wi th the system cal -
endar. When there i s a match, the si gnal i s moved to one of the
four job buffers. The three rel ati ve queues have a counter for each
job. Every 100 ms, 1 second and 1 mi nute, respecti vel y, the ti me
queue recei ves a peri odi c si gnal from the job tabl e and decrements
the counter. I f a counter reaches the val ue zero, the correspond-
i ng si gnal i s forwarded to one of the job buffers. I .e., a si gnal that
22
Fi rst I n Fi rst Out
6 JOBS, SI GNAL BUFFERS AND JOB HANDLI NG 27
i s fetched from a ti me queue i s al most never executed at once
23
.
Executi on of the si gnal i s performed when the operati ng system
fetches i t from the job buffer i t was i nserted i n.
Fi g. 19 shows how a software uni t sends a del ayed (and mul ti pl e) si g-
nal . The si gnal i s rst pl aced i n a ti me queue and after that i n a job
buffer. After i t i s taken from the job buffer, the executi on i s started i n
the recei vi ng uni t.
...
Enter SigA
...
Unit B
...
Enter SigA
...
Unit C
Time Queue Job Buffer
...
Send SigA
...
Delay 200ms
EXIT
...
Unit A
Fi gure 19: Sendingof a delayed (and multiple) signal. Thesignal is sent
fromUnit A and received in Unit C but, as could beseen in thegure, it
is possibletoreceivethesignal in Unit B as well i f Unit B is specied as
thereceiver by thePLEX designer.
6.3 J obHandling
The pri ori ti es at runti me correspond to the pri ori ti es among the job
buffers (Secti on 6.2), as wi l l be shown bel ow.
As al ready stated, Secti on 6.2, dependi ng on thei r purpose and ti me
requi rements, jobs are assi gned to certai n pri ori ty l evel s - ve di fferent
l evel s exi st. But the i mportant thi ng, when di cussi ng job pri ori ti es, i s
how di fferent pri ori ty l evel s can i nterrupt each other and, as coul d be
seen i n the fol l owi ng di scussi on, we coul d vi ew the ve di fferent pri ori ty
l evel s as onl y three i f we take the possi bi l i ty for one job to preempt
another i nto consi derati on.
23
The onl y excepti on i s when the recei vi ng job buffer (and every job buffer wi th hi gher
pri ori ty) i s empty.
6 JOBS, SI GNAL BUFFERS AND JOB HANDLI NG 28
Tasks i ni ti ated by a peri odi c Job Tabl e si gnal use the trafc-handl i ng
l evel 1 (THL 1), JBA si gnal s use trafc-handl i ng l evel 2 (THL 2), JBB
use trafc-handl i ng l evel 3 (THL 3), JBC use base l evel 1 (BAL 1) and
JBD use base l evel 2 (BAL 2), see Fi g. 20.
The Job Tabl e has a hi gher pri ori ty than al l the job buffers. JBA has
a hi gher pri ori ty than JBB, and so forth. The jobs i n the job buffers are
executed i n order of pri ori ty - JBA i s empti ed before JBB, and so on.
Data used i n i nterrupted jobs stay i n the processor regi ster memory,
and THL, BAL 1 and BAL 2 jobs have thei r own processor regi sters.
That means all THL jobs share the same regi ster buffers. Hence, no job
at one sub l evel of THL can i nterrupt a job at another sub l evel of THL,
si nce they share the same set of regi sters and the temporary vari abl es
woul d be destroyed otherwi se.
I .e., jobs from the job tabl e, JBA and JBB have to wai t for each other,
but al l three can i nterrupt job from JBC and JBD. As BAL 1 and BAL 2
have di fferent regi ster memori es, JBC can i nterrupt JBD.
Job Table
JBA
JBB
JBC
JBD
JBR
Job Buffers for CP-CP
and RP-CP signals
Job Buffer for CP-RP signals
JBA - urgent tasks of the operating system: preferential traffic
JBB - all other telephone traffic
JBC - input/output to operator and I/O devices
JBD - APZ routine self-test
JBR - signals from Central Processor to Regional Processor
THL - traffic-handling level
BAL - base level
THL 1
THL 2
THL 3
BAL 1
BAL 2
THL
Own processor register
Own processor register
Shared processor
register
Fi gure 20: J ob buffers and runtimepriorities in theAXE system.
I n some cases, however, i t may be necessary to prevent the system
from i nterrupti ng an i mportant task. For exampl e, an operati on and
mai ntenance (O&M, Secti on 2.3) routi ne at C-l evel (BAL 1) i s wri ti ng to
vari abl es that are al so accessed by trafc-handl i ng routi nes at B-l evel
(THL 3). I n thi s si tuati on, i t i s best to i nhi bi t the i nterrupt functi on as
6 JOBS, SI GNAL BUFFERS AND JOB HANDLI NG 29
l ong as the wri ti ng at C-l evel i s i n progress. The i nterrupt functi on i s
i nhi bi ted by the DISABLE INTERRUPT statement and acti vated by the
ENABLE INTERRUPT statement.
We concl ude thi s subsecti on wi th an exampel . Fi g. 21 i l l ustrates the
executi on of several jobs. I n the gure, the executi on starts i n bl ock 1
wi th the rst job, proceeds i n bl ock 2 wi th the second job and nal l y
ends i n bl ock 1 wi th the executi on of the l ast job. Fi g. 22 gi ves a cl oser
l ook of the l i nk (i nto job buffers) and execute process.
I f a new job enters an empty job buffer, the buffer sends an i nter-
rupt si gnal for that pri ori ty l evel . I f the ongoi ng job has a l ower pri ori ty
l evel , that job i s i nterrupted. However, a job can not i nterrupt a job on
the same (or hi gher) pri ori ty l evel .
Time block 1 block 3 block 2
enter
send
exit enter
send
send
exit enter
enter
send
exit
signal 1
signal 2
signal put in
job buffer
signal 5
signal put in
job buffer
signal put in
job buffer
signal 3
signal 4
exit
Fi gure 21: Theexecution model - Four jobs areexecuted. Theprocess of
transferinga buffered signal fromthesendingblock tothereceiving, via
a job buffer, is shown in Fig. 22. NOTE theparallel architecturethat
could becomereal parallel execution.
6 JOBS, SI GNAL BUFFERS AND JOB HANDLI NG 30
(module)
block A
Signal
Number
1
5
4
3
2
Link Signal
Number
ENTER
EXIT
ENTER
SEND siganl
name
EXIT
ENTER
EXIT
Signal
Number
1
4
3
2 Block number of B
APZ
(module)
block B
ENTER
EXIT
ENTER
EXIT
ENTER
EXIT
Hop address
SST SST
SDT
SDT
APZ - Operating System
SDT - Signal Distribution Table
SST - Signal Sending Table
Job Buffer
Signal
Number
Data
Block Nr of
B
Fi gure 22: Linkingand execution for a buffered signal in APZ. Seealso
Fig. 21. NOTE: Theprocedureis thesamefor direct signals except that
they not areinserted in a J ob Buffer.
7 LI NKI NG ENCAPSULATI ON 31
6.4 Execution TimeLimits
As stated i n Secti on 4.1, PLEX i s a real -ti me l anguage. Thi s means that
a system programmed i n PLEX i s a real -ti me system
24
. When tal ki ng
about executi on ti mes l i mi ts, one al ways refer to the executi on ti me of a
job. There are l i mi ts for the executi on ti me, but thi s i s not measured i n
absol ute ti mes. I nstead, there are programmer gui del i nes that speci fy
how many l i nes of code that may be pl aced i n a software uni t (or uni ts)
for one job.
7 LinkingEncapsulation
Al l bl ocks used i n the system are compi l ed separatel y and i t i s al so pos-
si bl e to l oad them separatel y, even at run-ti me. Thi s process i s cal l ed
a Functi on Change and i t was descri bed i n Secti on 2.1. When doi ng
a Functi on Change, the Si gnal -Sendi ng Tabl e (SST) and the Gl obal -
Si gnal Di stri buti on Tabl e (GSDT) has to be updated. The update has
to be done because al l si gnal sendi ngs has to l ook i n the SST and the
GSDT to nd whi ch si gnal to i nvoke.
When updati ng the tabl es, by the Rati onal i zed Software Producti on
(RSP) functi onal i ty, the (new) i ntroduced si gnal i s gi ven a uni que num-
ber, the Gl obal Si gnal Number (GSN). Thi s number i s stored i n the
GSDT as wel l as i n the SST of the Functi on Uni t (bl ock) usi ng thi s
new si gnal . The GSDT al so stores Bl ock Number Recei vi ng (BN-R),
(the uni que number of the bl ock recei vi ng the si gnal ) and the Local
Si gnal Number (LSN) whi ch i s the posi ti on hol di ng the l ocal rel ati ve
address of the entry poi nt of the si gnal entry.
The Si gnal Di stri buti on Tabl e (SDT) i s not updated, as the SDT
hol ds the rel ati ve address to the si gnal entri es i nsi de the Functi on Uni t.
SDT i s set wi th a l ocal number i n the object step (duri ng compi l ati on).
SDT: Contai ns the rel ati ve entry address, set duri ng compi l ati on, of
the speci c program sequences where si gnal s are recei ved.
SST: Contai ns the gl obal si gnal number (GSN) of si gnal s to i nvoke
24
And, as shown by Arnstrm et. al , the AXE system i s cl assi ed as a soft real-time
system [AGG99].
7 LI NKI NG ENCAPSULATI ON 32
Signal
Distribution Table
(SDT)
Signal Sending
Table (SST)
Program Code
PS
One function Unit
(Block)
Fi gure 23: PS, showing SDT, SST and Program Code of one function
unit.
from functi on uni t usi ng thi s SST, created i n the object step and
changed by the RSP.
GSDT: Contai ns the gl obal si gnal number (GSN), the Bl ock Number
Recei vi ng (BN-R) and the Local Si gnal Number (LSN).
I n DS, val ues are stored for al l vari abl es.
I n PS, the programs for al l bl ocks are stored together wi th the Si gnal -
Sendi ng Tabl es (SST), the Si gnal Di stri buti on Tabl e (SDT) and the Gl obal -
Si gnal Di stri buti on Tabl e (GSDT), see Fi g. 23
RS i s used for addressi ng DS and PS, and contai n the Program Start
Address (PSA) and Base Start Address (BSA), see Fi g. 24.
7.1 Addressinga ProgramSequence
Fi g. 25 shows uni t A sendi ng a si gnal to uni t B; the gl obal si gnal
number (GSN) i s found i n the Si gnal -Sendi ng Tabl e (SST) of uni t A.
The GSN i s used to nd the Bl ock Number Recei ve (BN-R) and the Local
Si gnal Number (LSN) i n uni t B (uni t A doesnt know i t i s uni t B
that hol ds the si gnal entry for the si gnal sent from uni t A). The BN-R
i s used to obtai n the Program Start Address (PSA) i n the Regi ster Store
(RS). The PSA i s an absol ute address i n the Program Store (PS), and by
knowi ng the LSN and PSA, and al so usi ng the Si gnal Di stri buti on Tabl e
7 LI NKI NG ENCAPSULATI ON 33
Block 1
RS
Block 2
Block 3
...
...
...
Block n
PSA
PSA = Program Start Address
Reference Table
Fi gure 24: RS, showingtheReferenceTable.
Unit A GSDT
Reference
Table (RS)
UNIT B
GSN
LSN
PSA
BN-R
Fi gure 25: The information ow in determining the signal entry when
sendinga signal.
(SDT) of uni t B the entry poi nt of the program code can be determi ned
i n uni t B. See Fi g. 26.
7 LI NKI NG ENCAPSULATI ON 34
SDT
SST
Program
Code
SDT
SST
Program
Code
Block X
Block Y
PSA
PSA / LSN
GSN
GSN
GSN
GSN
GSDT
LSN BN-R
1
2
PS
RS
PSA
3
SSP
GSN
BN-R /
LSN
4
PSA / LSN
5
IA
6 LSN
BN-R = Block Number Receive
GSDT = Global-Signal Distribution Table
GSN = Global Signal Number
IA = Instruction Address
LSN = Local Signal Number
PS = Program Store
PSA = Program Start Address
RS = Register Store
SDT = Signal Distribution Table
SSP = Signal-Sending Pointer
SST = Signal-Sending Table
PSA + IA
7
Fi gure 26: Theconsecutiveorder of handlinga signal sending.
8 SOFTWARE RECOVERY 35
7.1.1 Addressingin DS
RS actual l y consi sts of two parts: the Reference Tabl e (RT) and the
Base Address Tabl e (BAT). I n the RT there i s one PSA and Base Start
Address (BSA) for each bl ock, and the BSA poi nts to the starti ng poi nt
of BAT, see Fi g. 27
25
.
RT: i s part of Regi ster Store and hol d the Program Start Address and
Base Start Address.
BAT: hol ds the address of the vari abl es i n DS. For each bl ock a vari abl e
i s gi ven a number from 1 and upwards. Thi s number i s cal l ed the
BaseAddress Number (BAN). To get the address of a vari abl e i n
DS, the BSA + BAN wi l l gi ve the posi ti on hol di ng the address i n
DS.
BSA: hol ds the address of current start poi nt of BAT.
8 SoftwareRecovery
After the i ni ti al l oadi ng (Secti on 2.4), the exchange i s supposed to run
smoothl y duri ng i ts l i feti me. Thi s i s al so the normal si tuati on for the
system. However, errors cant be enti rel y el i mi nated and i n thi s secti on
we wi l l study software recovery acti ons. The goal wi th the automated
recovery acti on i s to mi ni mi ze the exchange down-ti me. Thi s i s achi eved
by rst tryi ng to rel ease onl y the dysfuncti onal forl opp
26
(whi ch nor-
mal l y stretches over parts of several bl ocks) and l eave the rest of the
system unaffected. As a l ast step, i f nothi ng el se works, the enti re sys-
tem i s restarted.
Thi s secti on wi l l cover the di fferent steps regardi ng software recov-
ery acti ons. I n Secti on 3.3 we stated that vari abl es are treated di f-
ferentl y at recovery acti ons dependi ng on the properti es set by the de-
si gner. We wi l l end thi s secti on wi th a summary of vari abl e properti es
and thei r behavi or at recovery acti ons.
25
Actual l y, thi s i s how addressi ng i s performed i n some archi tectures. The addressi ng
pri nci pl es may di ffer among the APZ versi ons
26
Forl opp wi l l be descri bed i n Secti on 8.1
8 SOFTWARE RECOVERY 36
PSA BSA
Base Address 1
(the word-address of a
stored variable)
Base Address 2
.....
Base Address n
Base
Address
Table
Reference
Table
PS
BN-R
RS
DS
1
2
3
Block A
Block B
Block n
.....
Block A
Block B
.....
Block n
1 = BSA indicates the starting point of base address table for block A located in reference
store. The BSA will give the absolute address.
2 = BAN indicates where the BAT word address for the specific variable is found. BAN is a
relative address.
3 = The word address indicates where the value of the specific variable is stored in DS.
Fi gure 27: Show how addressing to DS is performed in RS. BSA points
tothestartingpoint of BAT
8 SOFTWARE RECOVERY 37
8.1 Forlopp
The rst l i ne of defense for mai ntai ni ng system avai l abi l i ty i s the For-
lopp rel ease. The purpose of a forl opp rel ease i s to al l ow a si ngl e process
chai n, e.g., a cal l , to be rel eased wi thout adversel y affecti ng any other
processes i n the system.
Forl opp ori gi nates from the Swedi sh word frl opp meani ng se-
quence of rel ated events. I n the contents of AXE, a typi cal forl opp
wi l l resul t i n a path through the system whi ch general l y wi l l be rep-
resented by a chai n of l i nked software resources, such as records. I n
AXE, the word forl opp can be used to denote both the sequence of re-
l ated events and the resul ti ng path through the system. The forl opp
mechani sm i s i mpl emented i n the Mai ntenance Subsystem, MAS, Fi g.
1. Exampl es of forl opps are an ordi nary tel ephone cal l or a command.
Some concepts associ ated wi th forl opps:
A forl opp i denti ty (FI D), stored i n a speci al regi ster, i s assi gned to
each process (a cal l or forl opp). Al l parts parti ci pati ng i n the same
forl opp have the same forl opp i denti ty.
The forl opp manager (FM) stores i nformati on concerni ng the di f-
ferent forl opps.
When a software error i s detected, the FM sends releasesignals to
the bl ocks i nvol ved accordi ng to the i nformati on stored i n FM. A
forl opp rel ease i s hereby performed.
At a forl opp rel ease, a software error dump i s performed, whi ch
means that the contents of the records parti ci pati ng i n the current
forl opp are dumped
27
.
To summari ze, a detected software faul t may resul t i n a forl opp rel ease,
provi ded that the functi on bl ock i n whi ch the faul t occurred i s forlopp-
adapted and the forl opp functi on i s acti ve.
8.2 SystemRestart
The systemrestart has been the tradi ti onal recovery acti on taken by the
APZ (Secti on 2) when i t detects a software faul t. The system restart
27
Secti on 2.4 descri bes what a dump i s.
8 SOFTWARE RECOVERY 38
affects the enti re system and not onl y the forl opp i n whi ch the faul t
occurred. The purpose of a system restart i s to restore the system to a
predened state.
Duri ng restart, restart signals are sent to each bl ock, so that duri ng
successi ve restart phases, bl ocks perform acti ons to compl ete the i ni ti al -
i zati on or restorati on to a consi stent val ue of thei r data store vari abl es.
The system restart procedure coul d be i ni ti ated manual l y, by a COMMAND
(Secti on 2.3), or automati cal l y. A manual system restart cl ears error
si tuati ons, for i nstance the di sconnecti on of a hangi ng devi ce. An auto-
mati c system restart i s detected by programs, mi croprograms and su-
pervi sory ci rcui ts. At a system restart, the job tabl e, the job buffers and
the ti me queues (Secti on 6) are cl eared.
There are three l evel s of system restart acti vi ti es:
Smal l system restart, whi ch does not affect cal l s i n speech posi ti on
and semi -permanent connecti ons. Other cal l s are di sconnected.
Thi s i s a mi ni mal system restart.
Large system restart i n whi ch al l cal l s are di sconnected. Semi -
permanent connecti ons are not affected.
Rel oad and l arge system restart i n whi ch a rel oad i s performed
rst to ensure that RELOAD-marked vari abl es contai n correct val -
ues. Thi s i s then fol l owed by a l arge system restart. Semi -permanent
connecti ons are di sconnected and automati cal l y reestabl i shed.
The reason to have di fferent types of system restarts i s to di sturb trafc
handl i ng as l i ttl e as possi bl e duri ng the restart phase.
Wi th the occurrence of the rst faul t i n a normal bl ock that l eads to
a system restart, the system tri es to repai r i tsel f wi thout di sturbi ng the
trafc too much - A smal l system restart i s i ni ti ated. I f another seri ous
faul t occurs wi thi n a predened ti me i nterval , a l arge system restart
wi l l be i ni ti ated. I n the event of the occurrence of a thi rd seri ous faul t
wi thi n another predened ti me i nterval , a rel oad and a l arge system
restart wi l l take pl ace. Thi s represents the systems most extreme error-
recovery acti on. The descri bed phases i s pi ctured i n Fi g. 28.
Fi nal l y, i t i s someti mes unnecessary to i mmedi atel y i ni ti ate an auto-
mati c system restart. The system restart coul d be del ayed or i nhi bi ted.
Thi s i s done by cal l i ng the selectiverestart functi on.
8 SOFTWARE RECOVERY 39
time
x min x min
Small
Restart
Small
Restart
Large
Restart
Reload
+
Large
Restart
Fi gure 28: Different types of systemrestart.
8.3 Forlopp Releaseor a SystemRestart?
I n Secti on 8.1 we descri bed the concept of forl opps as a way to recover
from a software error wi thout affecti ng more than the faul ty forl opp.
Then, i n the fol l owi ng Secti on, 8.2, we descri bed the system restart
and the di fferent l evel s of restart and when they appl y. Thi s secti on
expl ai ns when the system restart acti on takes over from the forl opp re-
l ease mechani sm.
As we sai d i n Secti on 8.1, a forl opp rel ease i s al ways a rst choi ce i f
an error has been detected. The system restart functi on appl i es when
and i f:
The forl opp rel ease fai l s to recover the system (i .e., the faul ty for-
l opp), or
The faul ty process has not been forl opp-adapted, or
The number of faul ts have been to hi gh accordi ng to a predeter-
mi ned l i mi t.
The l ast case i s checked agai nst an intensitycounter. Thi s counter keeps
tracks of the quanti ty of software faul ts. The counter i s stepped each
ti me a faul t i s detected l eadi ng to a del ayed system restart or a forl opp
rel ease. When the counter reaches the predetermi ned l i mi t, a system
restart i s i ni ti ated. The counter i s then reset and starts agai n from
zero. Fi g. 29 shows the i ntensi ty counter and Fi g. 30 shows the di fferent
l evel s of software recovery.
8 SOFTWARE RECOVERY 40
time
Counter
value
Restart limit (default = 25)
+5
+10
+3
-1 every hour
No restart
Error is ignored
Delayed
restart
Forlopp
release
Fi gure 29: Theintensity counter.
ERROR
Forlopp release
possible and active?
Selective
Restart active?
Intensity
counter high?
Check block
category
Error ignored
Delayed restart
Immediate restart
Delayed restart with reload
System Restart
0 1 2 3
Yes Forlopp
release
System Restart
No
No
No
Yes
Yes
Fi gure 30: Different levels of recovery after a detected softwareerror.
8 SOFTWARE RECOVERY 41
8.4 Variablesand SoftwareRecovery
As sai d i n Secti on 3.3, the vari abl e properti es determi ne how the vari -
abl es are to be treated (i .e., from a data poi nt of vi ew) i n the case of a
system restart. Fi g. 31 shows the pri nci pl es of how di fferent types of
vari abl es shoul d be treated after a system restart.
DS
DS DUMP
DS STATIC
DS RELOAD
DS RELOAD DUMP
DS RELOAD STATIC
DS CLEAR
DS CLEAR DUMP
Start
Small
system restart
Large
system restart
System restart
with
reloading
Cannot
be
trusted
Cannot
be
trusted
Can be trusted
Can be
trusted
Can be trusted
Cannot be trusted
Exception: when the variable value
is checked in system restart routine
Fi gure 31: Data security of different start/ restart types.
Acknowledgements
Thi s report i s publ i shed wi thi n the research co-operati on between Erics-
son AB and Mlardalen Real-TimeResearch Center. The work has been
founded by Eri csson AB, Ml ardal en Real -Ti me Research Center
and the KK-foundati on.
The authors woul d l i ke to J anet Wennersten at Eri csson AB as wel l
as professor Bj rn Li sper at Ml ardal en Uni versi ty for many hel pful
di scussi ons.
We woul d al so l i ke to menti on Per Burman, Anders R. Larsson
and Anders Skel ander at Eri csson AB, as wel l as Peter Funk at
Ml ardal en Uni versi ty, who al l have been eager to keep the research
co-operati on between Eri csson AB and Ml ardal en Uni versi ty up and
runni ng.
REFERENCES 42
References
[AB95a] Eri csson Tel ecom AB. CPS Principles, 1995.
[AB95b] Eri csson Tel ecom AB. PLEX-C 2, 1995.
[AB98] Eri csson Tel ecom AB. PLEX-C 1, 1998.
[AB99] Eri csson Tel ecom AB. Basic Principles of Forlopp Handling,
1999.
[AB02] Eri csson Tel ecom AB. PLEX-C LanguageDescription, 2002.
[AE00] J. Axel sson and J. Eri kson. SAPP, Theori es and Tool s for
Executi on Ti me Esti mati on for Soft Real Ti me (Communi ca-
ti on) Systems. Masters thesi s, Ml ardal en Uni versi ty, 2000.
[AGG99] A. Arnstrom, C. Grosz, and A. Gui l l emot. GRETA: a tool con-
cept for val i dati on and veri cati on of si gnal based systems
(e.g. wri tten i n PLEX). Masters thesi s, Ml ardal en Uni ver-
si ty, 1999.
[EFGL02] J. Eri ksson, P. Funk, J. Gustafsson, and B. Li sper. A tool
concept for executi on ti me anal ysi s of l egacy systems. I n
14th Euromicro Conferenceon Real-TimeSystems, Work-in-
Progress. I EEE, 2002.
[KO00] P. Karl sson and S. Ohl sson. Jmfrel se av regi steral l ok-
eri gsstrategi er fr programmeri nssprket PLEX. Masters
thesi s, Ml ardal en hgskol a, 2000.
[KP96] Al Kel l ey and I ra Pohl . C By Dissection - TheEssentials of C
Programming. Addi son-Wesl ey, 1996.
[MH01] A. Marburger and D. Herzberg. E-cares research project:
Understandi ng compl ex l egacy tel ecommuni cati on systems.
I n Fifth European Conferenceon SoftwareMaintenanceand
Reengineering, pages 139 147. I EEE, 2001.
A THE SI GNAL DESCRI PTI ON 43
A TheSignal Description
There are two mai n documents for si gnal s: The Signal Survey, whi ch
i s a l i sti ng of al l the si gnal s sent and recei ved i n a uni t, and the Signal
Description, whi ch wi l l be studi ed i n thi s secti on. These documents are
compi l ed together wi th the SourceProgramI nformation
28
, SPI .
The Si gnal Descri pti on, SD, i s the document that denes a si gnal .
The type of the si gnal , as wel l as the pri ori ty l evel of the si gnal i s speci -
ed i n thi s document. There i s oneSD for every signal and al l SDs are
stored i n speci al l i brari es. We wi l l study how the SD i nteract wi th the
SPI duri ng the code generati on phase. But as a rst attempt to capture
the contents of the SD, i t coul d be seen as si mi l ar to the h-file i n C
that external l y denes a functi on (among other thi ngs).
The SD i ncl udes the fol l owi ng i tems:
Name of the signal - Every si gnal has a name that, perhaps,
captures i ts functi onal i ty.
Signal number - For i nternal documentati on.
Function - Used to make comments about functi onal i ty.
Signal type- The si gnal type i ndi cates whether the si gnal i s Sin-
gleor Combined. There are three possi bl e type speci cati ons:
Type1: Si ngl e si gnal
Type2: Combi ned forward
Type3: Combi ned backward
I f the si gnal i s Multiple, thi s i s i ndi cated by addi ng the keyword
MULTIPLE to the si gnal type, l i ke i n: TYPE IS 1 MULTIPLE
A Uniquesi gnal has no i ndi cati on at thi s poi nt! (A si gnal i s uni que
by defaul t i f nothi ng el se i s stated.) I f the si gnal i s l ocal , the
keyword LOCAL i s added to the si gnal type.
Possiblereturn signal - For i nternal documentati on.
28
The Source Program I nformati on i s the source code l e, i .e., the document that
we normal l y cal l a program. See Secti on 3.1 for further detai l s.
A THE SI GNAL DESCRI PTI ON 44
Possiblesendingblock - For i nternal documentati on.
Possiblereceivingblock - For i nternal documentati on.
Buffer level - The pri ori ty l evel ! I n Secti on 6, i t i s descri bed how
every si gnal i s assi gned a pri ori ty l evel , and how si gnal s are stored
i n di fferent jobbuffers (in caseof abuffered signal). The buffer
l evel states the pri ori ty l evel of the correspondi ng job and al so i n
whi ch job buffer the si gnal wi l l be buffered (i f i t i s to be buffered,
i .e.).
NOTE: The buffer l evel can have the fol l owi ng combi nati ons:
NO BUFFER: The si gnal i s di rect. (A combi ned si gnal i s
alwaysdi rect, see Secti on 5.3.)
LEVEL A/B/C/D BUFFER: The si gnal i s buffered and uses
the job buffer speci ed. Thi s combi nati on overrides a possi bl e
use of the HURRY opti on i n the si gnal sendi ng statement (see
bel ow).
LEVEL A/B/C/D: The si gnal i s buffered and uses the job
buffer speci ed, unl ess the keyword HURRY i s used i n the
si gnal sendi ng statement, whi ch i ndi cates that the si gnal i s
di rect.
Signal data- Speci cati on of the arguments (i .e., the data) that
the si gnal i s carryi ng.
ID sector - For i nternal documentati on.