Telecommunications & Computer Engineering - Технически ...

JOURNAL 

OF THE TECHNICAL UNIVERSITY 

AT 

PLOVDIV, BULGARIA 

�FUNDAMENTAL SCIENCES AND 

APPLICATIONS� 

VOL. 13 (1) 2006 

ANNIVERSARY SCIENTIFIC 

CONFERENCE 2006 

THE SCIENTIFIC REPORTS 

Telecommunications 

Computer Engineering

ORGANIZING COMMITTEE 

Conference Co-chairs: 

Prof. Kamen Veselinov, PhD Rector of TU - Sofia 

Prof. Dimitar Katsov, PhD Director of the Plovdiv 

Branch of TU - Sofia 

Members: 

Prof. DSc Vassili Loumos Greece 

Prof. DSc Mark Himbert France 

Prof. DSc Panayiotis Frangos Greece 

Prof. DSc Reinhart Verschoore Belgium 

Prof. DSc Yasser Alayly France 

Prof. Dr. Dr.h.c.mult. Uwe Heisel Germany 

Acad. Prof. DSc Yuri Kuznetsov Ukraine 

Prof. DSc Alexander Tsiganenko Russia 

Prof. DSc Victor Baranov Russia 

Prof. DSc Edward Evreinov Russia 

Prof. DSc Okyay Kaynak Turkey 

Acad. Prof. DSc Kiril Boianov Bulgaria 

Corr. Memb. Prof. DSc Mincho Hadjiski Bulgaria 

Corr. Memb. Prof. DSc Petko Petkov Bulgaria 

Prof. DSc George Popov Bulgaria 

Prof. DSc Marin Nenchev Bulgaria 

Prof. DSc Mincho Minchev Bulgaria 

Prof. Angel Vachev, PhD Bulgaria 

Prof. George Stoianov, PhD Bulgaria 

Prof. Drumi Bainov, PhD Bulgaria 

Assoc. Prof. Pepo Yordanov, PhD Bulgaria 

Assoc. Prof. Valentin Kirchev, PhD Bulgaria 

Assoc. Prof. Kostadin Iliev, PhD Bulgaria 

Assoc. Prof. Valyo Nikolov, PhD Bulgaria 

Assoc. Prof. Peyo Stoilov, PhD Bulgaria

- 3 - 

CONTENTS Page 

BOIAN MURATEV, JULIANA GROZDANOVA, BOYKO PETROV 

STAND-ALONE MODULE FOR USB DATA STREAM TO DMX512 AND ART-NET 

COMPATABLE PACKETS CONVERTION USING ARM STR711…………………………………… 11 

HRISTO HRISTEV, STOYAN MISHINEV 

NETWORK TRAFFIC GUARANTEE FOR DISTRIBUTED DESKTOP PLATFORMS…………..… 17 

IVANKA VALOVA, PETAR POPOV 

ENHANCEMENT OF STANDARD DATA ANALYSIS METHODS…………………………………… 27 

KRASSIMIR KOLEV 

APPLES GRADING USING INDEPENDENT COMPONENT ANALYSIS…………………………… 37 

NIKOLAY KAKANAKOV, NIKOLAY RAITCHEV, GRISHA SPASOV 

VIRTUAL LABORATORY FOR DISTRIBUTED SYSTEM ……………………………………...…… 43 

NIKOLAY KAKANAKOV, BORIS RIBOV 

DISTRIBUTED SYSTEM FOR MONITORING AND CONTROL IN INTERNET 

ENVIRONMENT ……………………………………...…………………………………………………. 49 

MITKO SHOPOV, HRISTO MATEV, GRISHA SPASOV 

ON THE USE OF WEB SERVICES FOR BUILDING DISTRIBUTED AUTOMATION SYSTEMS 55 

ATANASKA BOSAKOVA-ARDENSKA, NAJDEN VASILEV, ANELIA PAGUROVA ( MATAKOVA ) 

PARALLEL IMAGE PROCESSING OF 24-BIT BITMAP FILE WITH FILTER ‘MEAN’…………. 61 

ATANAS DESEV 

8 - BIT IP CORES USING LIKE BASIS FOR SYSTEM-ON-CHIP PLATFORM FOR REALTIME 

EFFICIENCY…………...…………………………………………………………………………………. 71 

ATANAS DESEV 

METHODS AND RESOUSCES FOR HARDWARE RTOS ACCELERATION...…………………… 81 

VLADIMIR VALOV, IVANKA VALOVA 

IMPORTANT MILESTONES IN DEVELOPMENT OF ANALYTICAL DATA PROCESSING 

THEORY………………………………………...………………………………………………………….. 89 

SVETLANA VASILEVA 

ALGORITHMS OF WORK OF NODES ON THE PROTOCOL FOR 2PL WITH PRIMARY 

COPIES IN DISTRIBUTED DATABASE MANAGEMENT SYSTEMS…………………...…………. 99 

VASIL STOYANOV 

WIRELESS SENSOR NETWORKS WITH DYNAMIC NETWORK TOPOLOGY………………… 107 

VELIN KRALEV, NINA SINYAGINA 

WEB SERVICE BASED SYSTEM FOR CUSTOMER RELATIONSHIP MANAGEMENT……...… 113 

RADOSLAVA KRALEVA, VELIN KRALEV 

ON MODIFICATION OF THE ITERATIVE SELF-ORGANIZING DATA ANALISYS 

TEACHINIQUE ALGORITHM…………………………………………...………………………………. 121 

Copyright © 2006 by Technical University at Plovdiv, Plovdiv, BULGARIA. ISSN 1310 - 8271

- 4 - 

VELIN KRALEV 

THE WEB SERVICES LIKE AN INSTRUMENT OF BUILDING THE DISTRIBUTED 

SOFTWARE SYSTEMS .................………………………………………………………………………... 129 

VELKO ILTCHEV 

ALGORITHM FOR PROPAGATION TO BASE CONJUNCTIONS FOR THE 2P-METHOD FOR 

QUERY PROCESSING IN DEDUCTIVE DATABASE SYSTEMS.....………………………………… 137 

VELKO ILTCHEV 

STORAGE, MANIPULATION AND RETRIEVAL OF ORDERED XML INTO/FROM 

RELATIONAL DATABASE……………………………………………………………………………… 147 

SIMEON MOEV, PETKO BAKALOV 

VALUATION OF AV-PROGRAMS EFFECTIVENESS ……………..................................................… 157 

CH. G. MOSCHOVITIS, E. G. PAPKELIS, H. T. ANASTASSIU, K. T. KARAKATSELOS, I. CH. 

OURANOS , P. V. FRANGOS 

AN ENHANCED STATIONARY PHASE METHOD (SPM) APPROXIMATION FOR THE 

ASYMPTOTIC CALCULATION OF THE SCATTERED ELECTRIC FIELD FROM A FINITE 

RECTANGULAR PLATE………............................................................................................ 163 

MARIA MARINOVA, ELENA DUNCHEVA 

SIMPLESCALAR SIMULATION TOOL ………………………………………………………………... 173 

YURI HOPTERIEV 

A MODULE FOR A DYNAMIC PRESENTATION OF EXAMPLES IN ELECTRONIC 

TEXTBOOKS ON WEB PROGRAMMING – A METHOD FOR ITS REALIZATION ………….. 185 

IVANKA VALOVA, BOZHAN ZHECHEV 

STUDY OF TECHNICAL POSSIBILITIES OF NEW VERSION OF MS COM+…………….…….. 191 

DILYANA BUDAKOVA, LUYDMIL DAKOVSKI 

INTELLIGENT VIRTUAL AGENTS-A NEW COMPUTER’S INTERFACE ....................... 201 

MALINKA IVANOVA 

WEB 2.0 TECHNOLOGIES IMPACT ON ACTIVE LEARNING IN ENGINEERING 

EDUCATION ……............................................................................................ 207 

SPIRIDON ARNAUDOV 

СПЕЦИАЛНО ДООПРЕДЕЛЯНЕ НА ЛОГИЧЕСКИ ФУНКЦИИ: ОПТИМИЗАЦИОННА 

ПРОЦЕДУРА "БАЛАР" В ПОСЛЕДОВАТЕЛНОСТНИЯ СИНТЕЗ ................................................ 213 

DOBRINKA PETKOVA, PETAR NENCHEV, KRASIMIR KRASTEV, VESELINA VASILEVA*, 

PENKA NEDELCHEVA 

STUDYING THE APPLICATION OF CAD SYSTEMS…………………………………………………. 219 

ATANAS KOSTADINOV 

VHDL MODELS OF SENSORS WITH ANALOG INPUT AND DIGITAL OUTPUT………………… 225

©Journal of the Technical University at Plovdiv 

“Fundamental Sciences and Applications”, Vol. 13(1), 2006 

Anniversary Scientific Conference’ 2006 

BULGARIA 

11 

STAND-ALONE MODULE FOR USB DATA STREAM TO 

DMX512 AND ART-NET COMPATABLE PACKETS 

CONVERTION USING ARM STR711 

BOIAN MURATEV, JULIANA GROZDANOVA, BOYKO PETROV 

Abstract. This paper describes an ARM application for converting of USB data stream to 

two different standards – DMX512 and Art-Net. The module realizes bidirectional 

connection between personal computer and light objects network by Art-Net and 

unidirectional connection by DMX512. The personal computer connection is realizes by 

using USB 2.0 full speed interface. 

Key words: USB, DMX512, Ethernet, Art-Net, light object. 

УСТРОЙСТВО ЗА ПРЕОБРАЗУВАНЕ НА ВХОДЯЩ ПОТОК 

ДАННИ ПО USB ИНТЕРФЕЙС В DMX512 И ART-NET 

СЪВМЕСТИМИ ПАКЕТИ, ЧРЕЗ ARM МИКРОКОНТРОЛЕР STR711 

1. Въведение 

Разглежданото устройство позволява посредством персонален компютър да 

бъдат управлявани различни видове светлинни обекти, използвайки един от двата 

основни стандарта – DMX512 и Art-Net. Като светлиннен обект може да се разглежда 

всеки управляем източник на светлина, поддържащ някакъв стандарт за управление. 

DMX512 представлява стандартен протокол за връзка между управляващо 

устройство (предавател) и управляван светлинен обект (приемник). Той е създаден през 

1986 година от U.S.Institute of Theatre Technology (познат като USITT) [1]. 

Един DMX512 порт (изход) може да управлява максимум 512 канала. Този порт 

е известен като DMX512 universe (или само universe). Когато е необходимо управление 

на повече от 512 канала, се използват втори DMX512 universe [1]. Връзката между 

използваните universes и броя на каналите, които могат да управляват те, е дадена в 

Таблица 1. 

Няма ограничение в броя на universes. Единствено скоростта на протичащите 

процеси може да бъде ограничаващ фактор за използването на повече universes. Важно 

е да се отбележи, че приемникът (управлявания светлинне обект) може да разпознае 

само канали от 1 до 512 [1]. Това означава, че в система, притежаваща повече от една 

universe, ще има физически идентични комбинации universe/канал. Като пример може 

да се разгледа управляващо устройство (DMX512 предавател), състоящ се от 5 

universes. Ако устройството приемник (светлинният обект) се свърже към канал 2331 на 


12 

предавателя, то ще бъде свързано към universe №5 и ще има адрес 283. Това е така, 

защото изходният канал 2331 на предавателя се явява канал 283 от universe №5 

(Таблица 1). 

Таблица 1. Връзка между universe и брой канали 

UNIVERSES Управлявани канали 

1 

2 

3 

4 

5 

. 

. 

1 ÷ 512 

513 ÷ 1024 

1025 ÷ 1536 

1537 ÷ 2048 

2049 ÷ 2560 

. 

. 

DMX512 сигналът се предава посредством индустриален стандартен интерфейс 

наречен EIA485 (познат като RS-485) [1]. 

Потокът от информация, който се изпраща от предавателя, е под формата на 

пакет (DMX пакет). Началото на пакета започва със стартов бит, информиращ всички 

приемници, свързани към предавателя, че започва изпращането на нов пакет. След 

стартовия бит се изпращат последователно данни към всеки един от каналите, като се 

започне от канал 1 до канал 512 (или канал с по-нисък номер, което зависи от дизайна и 

размера на управляващото устройство - конзола). Информацията за даден канал е 

разделена от тази за останалите посредством специален старт и стоп бит [1]. 

Структурата на DMX512 потока от информация е представен графично на Фиг. 1. 

Оригиналният стандарт DMX512 непозволява обратно предаване на 

информация, т.е. светлинния обект неможе да изпраща данни за своето състояние към 

управляващото устройство. За отстраняване на този недостатък е необходимо 

използването на допълнителен хардуер. 

MTBP 

IDLE 

BREAK 

MAB START 

BIT 

DATA=0 

STOP 

BITS 

MTBF 

START 

BIT 

8 DATA BITS 

STOP 

BITS 

START CODE CHANNEL 1 NEXT CHANNELS 

Фиг. 1. DMX512 протокол 

Art-Net е Ethernet протокол, базиран на комплекта протоколи TCP/IP. Неговата 

цел е да позволи пренасянето на големи по размер DMX512 пакети върху широко 

използваните стандартни мрежови технологии. Първоначално е проектиран да работи 

над 10BaseT (мрежа със скорост до 10Mbit/s). Art-Net е създаден от Artistic License и за 

момента е свободно достъпен [4]. 

Използването на Ethernet (10BaseT) позволява да бъде предавана до 40 пъти 

повече информация спрямо един DMX512 кабел и съответно да бъдът управлявани до 

40 пъти повече устройства. Също така, съсгласно Art-Net стандарта, светлинния обект

13 

може да връща обратно информация за своето състояние (ако това е заложено при 

неговото поректиране) към управляващото устройство [3]. 

При Art-Net протокола по подразбиране се използват IP адреси Клас А. По този 

начин Art-Net устройствата могат да комуникират директно без да се налага 

свързването на DHCP сървър към мрежата. Използването на адреси от Клас А е 

допустимо в затворени мрежи. Това е важно тъй като трябва да е сигурно, че Art-Net 

информацията не се изпраща към Интернет или друг вид мрежа [4,2]. 

Всички комуникации се осъществяват по UDP стандарт. Всеки Art-Net пакет 

формира полето за данни на UDP пакета (Фиг. 2) [4]. 

IP ниво 

MAC ниво 

Физическо ниво 

Art-Net 

TCP UDP 

Фиг. 2. Място на Art-Net в мрежовия модел 

Микроконтролер 

Етернет контролер 

2. Описание на блоковата схема на устройството 

Разглежданото устройство е изградено от четири основни блока – управляващ 

микроконтролер, програмируема логика (CPLD), Ethernet контролер и RS-485 приемопредавател 

(Фиг. 3). 

USB 

connector 

uC CPLD 

POWER 

+ 

LED 

CLK 

RESET 

OSC 

Ethernet 

controller 

Isolation Transformer 

RJ45 connector 

Copyright © 2006 by Technical University at Plovdiv, Plovdiv, BULGARIA. ISSN 1310 - 8271 

CLK 

LAN LED 

2 

DMX512 

connector 

RS-485 

transceiver 

2 

2

14 

Фиг. 3. Блокова схема на устройството 

Микроконтролерът е основния управляващ елемент в схемата. Той 

инициализира периферията, LAN контролера, приема, обработва и изпраща данни. 

Използван е микроконтролер STR711FR1 на фирмата STMicroelectronics. Това е 32битов 

ARM микроконтролер, базиран на ядро ARM7DTMI. Характеризира се с: 128KB 

FLASH програмна памет; 16KB FLAH памет за данни; 64KB RAM памет; периферия, 

включваща USB интерфейс и два порта с общо 30 входно/изходни пина, 

мултиплексирани с UART интерфейс, SPI интерфейс, таймери, АЦП и др. 

Най-важното качество на използвания микроконтролер е вграденият USB v2.0 

интерфейс, работещ на пълна скорост (Full Speed – 12Mbit/s). По този начин се 

редуцира използвания хардуер, тъй като не се налага добавянето на външна интегрална 

схема за поддръжка на USB. 

Връзката между микроконтролера и Етернет мрежата се осъществява от 

интегрална схема CS8900A-CQ3 на фирмата Cirrus Logic. Това е Етернет решение, 

поддържащо пълен дуплекс (full-duplex) и обединява всички аналогови и цифрови 

части, необходими за изграждането на завършена Етернет схема. CS8900A 

позволяваща обмен със скорост до 10Mbits/s. 

Използването на праграмируема логика (CPLD) улеснява проектирането на 

печатната платка на устройството. Също така, по този начин се позволява да бъде 

използван само един тактов генратор с подхощята честота, а всички необходими 

тактови импулси се формират от CPLD. Използван е програмируем логически елемент 

на фирмата Xilinx. 

За предаване на данни към светлинни обекти поддържащи DMX512 се използва 

интегралната схема DS75176 от National Semiconductor. Тя представлява RS-485/RS-422 

приемо-предавател. Посоката на обмен на данните се определя посредством два пина. 

Въпреки, че в тази версия на устройството се реализира само изпращане на DMX512 

пакети, изплозването на приемо-предавател позволява при бъдещо усъвършенстване на 

устройството лесно да се реализира двупосочна връзка. 

3. Принцип на дейстиве на устройството 

Принципът на действие на устройството (програмното осигуряване) е 

илюстриран графично на Фиг. 4. При първоначално подване на захранване се 

преминава през няколко етапа на инициализация, включващи инициализиране на 

управляващия микроконтролер, инициализиране на USB периферията, инициализиране 

на Ethernet контролера. 

След приключване на процеса по инициализация, микроконтролера започва 

изпълнение на основния цикъл на програмата. Тук периодично се следи дали има 

приети данни от персонални компютър посредством USB интерфейса или от 

светлинните обекти поддържащи Art-Net по Ethernet мрежата. 

При получаване на данни от персоналния компютър, управляващия софтуер 

определя в кой от двата стандарта да бъдат пакетирани те преди да се изпратя към 

сватлинните обекти. Информацията за стандарта който ще се използва се добавя към 

данните при тяхното формиране от програмното осигуряване на пресоналния 

компютър. 

DMX512 данните се пакетира в DMX512 пакети и се изпращат към светлинните 

обекти поддържащи този стандарт през RS-485 предавателя DS75176. 

Данните за Art-Net мрежата се пакетират в Art-Net съвместими пакети (UDP 

пакети) и се предават от микроконтролера към Ethernet контролера, който от своя 

страна предава пакетите към Art-Net мрежата от светлинни обекти.

15 

В съответствие с Art-Net стандарта, устройството поддържа възможнжст за 

приемане на обратна информация от светлинните обекти, които позволяват това. За 

тази цел, в основния цикъл на програмата се следи дали Ethernet контролера е приел 

пакет с данни от Art-Net мрежата. Ако има приет UDP пакет, приложния софтуер го 

депакетира, извлича данните, които в последствие се пакетират в USB пакет и 

посредством USB интерфейса се изпращат към персаналният компютър. 

Подаване на 

захранване 

Инициализация 

Имали приети данни по 

USB? 

НЕ 

Имали приети данни по 

Етернет? 

НЕ 

ДА 

ДА 

Депакетиране на 

UDP пакета – 

извличане на 

данните 

Пакетиране на 

данните в USB 

пакет 

Изпращане на 

USB пакета към 

персонален 

компютър 


данните в UDP 

пакет 

Изпращане на 

UDP пакета към 

Art-Net мрежата 

Фиг. 4. Принцип на действие на устройството 

Депакетиране на 

USB пакета – 

извличане на 

данните 


данните в 

DMX512 пакет 

Изпращане към 

RS-485 

предавателя 


DMX512 

Избор на стандарт за 

предаване на данните 

4. Заключение и постигнати резултати 

Едно от качествата на реализираното устройство е, че дава възможност 

персонален компютър да обменя данни с Етернет мрежа, без необходимостта от 

мрежов хардуер и софтуер. От друга страна, ако компютърът вече е свързан към друг 

вид мрежа, например Интернет, то използването на това устройство ще доведе до 

работа на тази мрежа и мрежата от светлинните обекти, без те взаимно да си влияят. 

Съгласно Art-Net стандарта, не се допуска изпращане на Art-Net информация към друг 

тип мрежа. Предотвратяването на взаимното влияние е ключов момент. Ако 

компютърът трябваше да е свързан едновременно директно към Art-Net мрежата на 

светлинните обекти и към друг вид мрежа, то щеше да се наложи да бъдат взети 

софтуерни мерки, за да се гарантира, че двете мрежи са независими една от друга и 

няма взаимно влияние. 

Art-Net

16 

Разгледаното устройство е реализирано практически. Наситената печатна платка 

може да се види на Фиг. 4. 

Фиг. 5. Практическа реализация на устройството 

ЛИТЕРАТУРА 

1. http://www.dmx512-online.com/ 

2. Ст. Джиев. Индустриални мрежи за комуникация и упраление, Техника, София, 

2001. 

3. W. Howell, A. Artistic Licence Application Note 13: What is Art-Net?, Artistic Licence, 

2002. 

4. Specification for the Art-Net mx Ethernet Communication Standard, Artistic Licence, 

2002. 

5. J. Hyde, USB Design by Example, Intel University Press, 1999. 

Department of Electrical Engineering 

Technical University–Sofia, Plovdiv Branch 

63, Saint Petersburg Str. 

4000 Plovdiv 

BULGARIA 

E-mail: abpetrov@persecteam.com




BULGARIA 

17 

NETWORK TRAFFIC GUARANTEE FOR DISTRIBUTED 

DESKTOP PLATFORMS 

HRISTO HRISTEV 1 , STOYAN MISHINEV 2 

Abstract: This paper describes the thin-client architecture and distributed desktop platforms 

over shared network topology. In this model only the input from keyboard or mouse activities and 

display output information is exchanged between thin-client server and terminal. These results in 

network traffic with characteristics substantially different from well-know conventional network 

traffic. For this study, we would like to analyze network performance and network possibility of the 

university network to support distributed desktop platform. We examine different policy based 

queuing for thin-client traffic management. 

Key words: thin clients, QoS, network performance, distributed desktop platforms 

ГАРАНТИРАНЕ НА МРЕЖОВИЯ ТРАФИК ЗА РАЗПРЕДЕЛЕНИ 

ДЕСКТОП ПЛАТФОРМИ 


Разпределените десктоп платформи, използвани към настоящият момент могат 

да бъдат катекоризирани според това как се разпределя изчислителният ресурс между 

клиента и сървъра. Едни от най-популярните и разпространени разпределени десктоп 

среди днес са X Windows [4,5,6], Citrix's MetaFrame продуктите [14], Microsoft RDP – 

базиран отдалечен десктоп, Virtual Network Computer (VNC) [17], изследователският 

прототип THINC, както и Sun Ray продукт линията [15]. Голяма част от тези 

платформи са проектирани като потребителски устройства с минимални функции. 

Целта е да се редуцира цената за брой десктоп система. Те обаче предоставят 

достатъчна гъвкавост и мобилност, както и пълната функционалност сравнима с тази на 

работните станции. Класифицират се като тънки клиенти (thin-client computing) но са 

известни и с други имена, като сървър-базирани изчислителни системи (server-based 

computing), терминални устройства (dumb terminals) и др. 

Съществуват два базови функционални модела за тънки клиенти. При единият, 

устройството на тънкият клиент е просто и се използва само като входно/изходно от 

потребителя. Сървъра приема команди генерирани от калвиатура и мишка, предоставя 

опресняване на дисплея, изпълнява приложения, комуникационни функции и съхранява 

данни. 

При вторият модел, сървъра изпраща части от данни и приложения към клиента. 

Клиента оперира с тези данни независимо и при необходимост изисква още данни за 

своята функционалност. 

Архитектурата на повечето тънки клиенти е централизирана и в голяма степен 

улеснява контрола върху софтуера, неговото конфигуриране и обслужване. 


18 

Централизацията обаче налага завишени изисквания към ресурси като сървър, система 

за съхраняване на данни и мрежова среда от , които зависи пълната функционалност на 

тънките клиенти. За разпределените десктоп платформи мрежовата цялост и 

пропусквателната и способност са от съществено значение. При пропадане на мрежата 

потребителите губят възможността да работят с файлове, приложения или каквото и 

да е до момента когато тънкият клиент отново се синхронизира със сървъра. Ето защо 

ресурсите на системата, както и комуникационната среда са подложени на завишени 

изисквания, като например способността на мрежата да се възтановява автоматично 

при пропадане на сегмент. Друго много важно условие за работоспособност на система 

от разпределени десктоп платформи е поддържане в номинални граници на 

предварително наложени изисквания относно закъснения и загуба на пакети. 

Наличието на чат от тези условия в реално работещи и вече съществуващи 

информационни инфраструктури не винаги съществува. При практическото 

реализиране на архитектура с тънки клиенти базиранa върху Sun Ray сървър софтуер, в 

локална компютърна мрежа с поделени ресурси и достатъчно голяма производителност 

се установиха моменти на кратковременни прекъсвания в работата на системата. 

Ефекта е подчертано изразен при наличие на трафик от типа на FTP, HTTP и предаване 

на големи последователности от данни по общата среда за пренос. Това е основната 

причина, която провокира проучване на проблема и намиране на решение, 

осигуряващо стабилна работа на разпределените десктоп платформи. 

Целта на тази статия е да представи изследване върху поведението на опашките и 

мрежовите характеристики във възли от граф, обслужващ архитектура на тънки 

клиенти заедно с други информационни ресурси. 

2. Модел на система с тънък клиент 

Представеният модел на среда за обслужване на тънък клиент е съобразен с 

параметри и звена, които имат основно влияние върху производителността на една 

разпределена десктоп система. В случая това са пропусквателна способност на 

комуникационният канал, производителност на сървъра и производителност на 

клиента. Можем да представим тези звена използвайки опростен модел от три 

последователни M/M/1 опашки показани на Фиг. 1. С цел минимизиране на задачата 

приемаме, че сървърът и процесите обслужващи тънкият клиент работещи върху него 

изцяло гарантират работоспособността на системата. Производителността във възела 

на тънъкият клиент основно зависи от компресията на получените данни и 

способността му да ги декодира. Приемаме, че тези характеристики са задоволителни. 

За целите на настоящото изследване изключваме влиянието на сървъра и тънкият 

клиент в модела. 

Фиг. 1. Модел на система за обслужване на тънък-клиент 

Възелът на комуникационният канал също може да бъде представен като 

каскада от последователни М/М/1 схеми - Фиг. 2. Приемаме, че честотата на 

постъпващите заявки от входният поток е с поасоново разпределение. Допускаме за 

всеки един от възлите, независимо обслужване на заявките с експоненциално 

разпределение на времето за обслужване. Постъпването на заявките в следващият възел

19 

или изходът им от системата да става в порядък на някяква фиксирана вероятност. 

Опашките да са с неограничена дължина. При тези условия можем да разгледаме всяка 

една M/M/1 схема като независима и да я анализираме самостоятелно. 

В модела средната сумарна латентност за системата от каскадни опашки ще е 

равна на сумата от средните латентности за всяка една опашка. 

Tr = Tri 

+ Tr j + Trk 

(1) 

За един възел средният брой на очакващи заявки за обслужване ще бъде 

ri = λiTri 

където: 

Tr - средно време за пребиваване на заявката в системата 

λ i - средното количество на постъпващи заявки за секунда в опашка ( n i ) 

Tri - средно време за пребиваване на заявката в M/M/1 опашка ( n i ) 

Фиг. 2. Модел на комуникационнен канал за пренос на данни 

За всяка опашка като независима M/M/1 схема можем да определим средното 

закъснение на заявките по формулата: 

Tsi 

Tsi 

Tri 

= = 

(2) 

1− 

ρ 1− 

λiTsi 

където 

ρ = λTs 

Tsi - средно време за ослужване във възела 

Времето за обслужване на заявките Ts във възела представлява и е в пряка 

зависимост от отношението на дължината на пакетите в битове ( L ) и скоростта за 

предаване на данни в битове за секунда ( R ). 

L 

Ts = 

R 

От тук 

L 

Tri 

= (3) 

R − Lλ 

i 

i 

От формулa (3) се вижда, че средното закъснение на заявките в комуникационният 

канал е в пряка зависимост от големината на обслужваните заявки, както и от скоростта 

за предаване на данни по линията. 


20 

За да изпълним условието и осигурим допустимата латентност в 

комуникационният канал, който обслужва разпределените десктоп платформи можем 

да приемем някои от следните решения. 

• да се задели самостоятелен канал за обслужване на системата от тънки 

клиенти 

• да се увеличи скоростта за предаване на данни в поделената преносна 

среда 

• приоритезиране на трафика в опашките на активните възли 

За случая с приоритезиране на трафика в опашките приемаме заявките с 

назначен приоритет единица (1) да се обслужват преди заявки с назначен приоритет две 

(2). Заявки с еднакъв приоритет да се обслужват от дисциплина за диспечеризация 

FIFO. Да не се отхвърлят заявки, които очакат обслужване от опашката. За целта са 

валидни формулите: 

λ = λ + λ 

i 

i1 

i2 

ρ i = ρi1 

+ ρi 

2 

При експоненциално разпределение на времето за обслужване на заявките 

средното закъснение в система с приоритетни опашки се определя по формула (4): 

λi1 

λi2 

Tri 

= Tri1 

+ Tri 

2 

λi 

λi 

където 

ρi1Tsi1 

+ ρi 

2Tsi2 

Tri1 

= Tsi1 

+ 

1− ρi1 

(4) 

Tr 

i2 

= Ts 

i2 

Tri1 

− Ts 

+ 

1− 

ρ 

i 

i1 

След отчитане на резултати за линия с пропусквателна способност от 10Mbps, 

средна дължина на малки пакети с големина 240 байта и съответно за големи пакети с 

големина 1500 байта, които постъпват с честота 20 пакета в секунда и средно време за 

обработка на пакетите съответно 1ms и 10ms, както и наложено условие за по- висок 

приоритет на малките пкети се отчете, че приоритетните пакети ще бъдат обслужени 

3,7 пъти по-бързо. Основеният недостатък на описаният модел е следствие от 

наложеното условие за неограничен размер на опашките. Модела не отчита загуби на 

пакети. За случая е направен симулационен модел и анализ на трафика от симулацията. 

Фиг. 3. Схема на симулационен модел

21 

3. Резултати от симулационен модел на система с тънък клиент в поделена 

мрежова среда 

За целите на симулацията е използван мрежовият симулатор NS-2 [16, 9], който 

представлява модулно конструиран дискретно-събитиен симулатор използван найчесто 

за изследвания в областта на мрежите. Симулационният модел показан на Фиг. 3 

се състои от четери възела свързани с дуплексни линии и пропусквателна способност 

от 10 Mbps. Закъснението по линиите е 10 ms. Възел n 0 генерира трафик към възел 

n 3, 

който трафик е идентичен с този изпращан от сървър към тънък клиент - Фиг.4. 

Възел n 1 генерира фонов UDP и TCP поток от големи пакети. Симулирани са два 

основни случая с различно управление на опашката за входящите пакети на възел n 2 . 

Фиг. 4. Трафик от система “сървър - тънък клиент” 

При първата симулация е моделирана услуга с “максимални усилия”. Мрежата 

се старае да обработи постъпващият трафик максимално бързо без да дава никаква 

гаранция относно тестовият поток и относителният резултат от своите усилия. 

Дисциплината за управлвние на опашката е FIFO а трафика не се приоритезира. 

Направената повторна симулация се основава на механизма за приоритетна 

обработка на трафика. Общият мрежов поток е разделен на класове в зависимост от 

числов признак – приоритет. Симулационният модел е със същите параметри на 

системата но тестовият поток се обслужва с по-висок приоритет. Използвани са клас 

базирани опашки. 

На Фиг. 5 са показани резултатите от симулационният анализ. От графиките се 

вижда, че за случая когато всички пакети се разглеждат като равноправни и заявките се 

обработват в порядъка на тяхното постъпване, пропусквателната способност на канала 

за тестовият поток варира в границите от 7,2 Mbps до 9,8 Mbps. Отчетеното усреднено 

закъснение за пакетите на тестовият поток е от порядъка на 26 ms а размера на 

опашката е достигнала до 24 броя чакащи обслужване пакета. 

За вторият случай с приоритетна обработка на трафика и управление на 

опашката се вижда, че отчетените параметри за тестовият поток са с по-добри 

характеристики. Долната граница за пропусквателната способност на канала е 9,2 

Mbps. Закъснението на пакетите варира в интервала между 10 ms и 11,6 ms, което е с 

два порядъка по-малко от случая при мрежа с “максимално усилие”. Максималниат 

брой пакети в опашката чакащи обслужване е занижен до 2 броя. 


Пропусквателна способност при управляема и неуправляема опашки 

22 

Латентност в ms при управляема и неуправляема опашки 

Размер на опашките в брой пакети 

Фиг. 5. Резултати от симулационният анализ на система показана на Фиг.3 

Резултатите от симулацията показаха достигане на високи, макар и в границата 

на допустимото стойности за закъснение по линията, при обслужване само на един 

тънък клиент и наличие на агресивен фонов трафик от големи пакети. Наличието на 

голям брой пакети в опашката предполага отхвърляне на новопостъпващите при 

запълване на буфера и. С цел изследване на проблема в среда с реални устройства от

23 

типа на тези, които работят в университетската локална мрежа експеримента бе 

повторен върху следната тестова постановка: 

4. Тестова постановка 

Тестовата постановка показана на Фиг. 6 включва три компютъра с операционна 

система UNIX и комутатор на Cisco Systems. Генерираният тестов поток от HOST1 се 

изпраща към HOST3. Фоновият поток генериран от HOST2 се изпраща към виртуален 

обект, чийто адрес е въведен ръчно в CAM таблицата на комутатора. Към същият порт 

е присъединен и HOST3. Целта е да се подели капацитета на изходящият порт от 

тестовият и фоновият потоци. За генерирането на синтетичен трафик е използван 

пакета Rude&Crude [7]. 

Фиг. 6. Опитна постановка - конфигурация 

Както при симулацията, така и при тестовата постановка са изследвани два 

основни случая, с различно управление на опашката за входящите пакети на 

поделеният порт. При първия не е приложено специално управление на трафика. За 

целите на изледването при втория случай е приложено стриктно приоритезиране на 

трафика и назначаване на по-висок приоритет за тестовият поток. И в двата случая 

успоредно с тестовият поток се пуска агресивен фонов поток от големи пакети. 

Отчетени са основните характеристики на мрежовите изисквания, за обслужване на 

разпределена система от тънки клиенти а именно загуба на пакети и латентност. 

На Фиг. 7 са показани резултатите от изследването. Ясно се откроява голямата 

загуба на пакети, до 45% за случая на система с “максимално усилие” . Закъснението 

на пакетите от тестовият поток е в номинални стойности, според изискванията за 

обслужване на архитектура с тънки клиенти, базиранa върху Sun Ray сървър софтуер. 

При прилагане на политика със стриктни приоритети се вижда, че се повлияват както 


24 

загубата на пакети така и закъснението. В случая не се отчита загуба на пакети при 

тестовият поток а неговата латентност в мрежата е 28 ms. 

Тестов поток - закъснение и загуби на пакети в опашка при мрежа с 

“максимално усилие” и наличие на фонов поток 

Тестов поток - закъснение и загуби на пакети в опашка с приоритети и наличие 

на фонов поток 

Фиг. 7. Резултати от изследването на тестовия поток чрез опитна 

постановка 

4. Заключение 

Основна причина за поява на кратковременни прекъсвания в работата на 

инсталираните тънки клиенти в съществуващата обща поделена информационна 

инфраструктура е загуба на пакети при наличие на агресивен трафик с големи пакети. 

При проектиране на компютърни мрежи които предполагат обслужване на 

разпределени десктоп платформи е необходимо да се планират устройства 

позволяващи вграждане на алгоритми и политики за управление на опашки. Проблем 

при вграждането на политика със стриктни приоритети може да възникне при излишък 

на високоприоритетният трафик. Тогава опашките с нисък приоритет ще останат не 

обслужвани. За такива мрежови среди е много удачно да се комбинират справесливи 

алгоритми за управление на опашки, както и клас базирани опашки. 


1. William Stallings, High-speed network and internets – performance and Quality of 

Service; 2d edition

25 

2. Jean Walrand, An Intraduction to Queuing Networks, University of California 

Berkeley 

3. W. Richard Stevens, TCP/IP Illustrated, Volume1, Addison-Wesley professional 

computing series 

4. Jeff Horwitz, Unix System Management Primer Plus 

5. http://www.linuxdevcenter.com/pub/a/linux/2005/08/25/whatisXwindow.html 

6. http://www.its.strath.ac.uk/courses/x/ 

7. http://www.xfree86.org/ 

8. RUDE&CRUDE – UDP data emitter/collector http://rude.sourceforge.net/ 

9. K. Fall, K. Varadhan, The ns Manual, The VINT Project, UC Berkeley, LBL, 

UCS/ISI and Xerox PARC 

10. К. Боянов, Хр. Турлаков, Компютърни мрежи ИНТЕРНЕТ, София 1998 

11. Corporate Headquarters, Catalyst 3550 Multilayer Switch Software Configuration 

Guide, Cisco Systems, Inc 

12. The FreeBSD Documentation Project, FreeBSD Handbook 

13. Rolf Kersten, Solaris(TM) OE Guide for New System Administrators, Sun 

Microsystems GmbH, Germany 

14. C. Broomes, E. Khnaser, R. Crump, M. Craft, Configuring Citrix MetaFrame XP 

for Windows, 2002 

15. M.Kuhn, P.Evans, Sun Ray protocol observations, 

http://www.cl.cam.ac.uk/~mgk25/sunray/protocol.html 

16. The Network Simulator ns-2 http://www.isi.edu/nsnam/ns/ 

17. Virtual Network Computing http://www.cl.cam.ac.uk/research/dtg/attarchive/vnc/ 

Department of Communication and Information Technology 


25, Tsanko Dystabanov Str. 

4000 Plovdiv 

BULGARIA 

E-mail:crs@tu-plovdiv.bg 





BULGARIA 

27 

ENHANCEMENT OF STANDARD DATA ANALYSIS 

METHODS 

IVANKA VALOVA, PETAR POPOV 

Abstract. The development of information technologies, which allow storage of everincreasing 

volumes of huge datasets, urged the necessity of creation and development of 

new methods for information analysis. Such needs has led to the rise of new and 

perfection of existing methodologies for data analysis, which objectives are to enhance 

the standard data analysis methods and to provide some clarifying results, expressed by 

notions of real world, and presented mathematically through “symbol objects”. 

This paper aims to study and present a methodology for data analysis, called symbolic 

data analysis-SDA. The idea for making use of this theory was proposed by Prof. 

Noirhomme- Fraiture in 2005 in course of preparation of a joint implementation project. 

The paper studies and summarizes results from scientific works of researchers, working 

in field of SDA. 

Key words: data analysis, symbolic objects, symbolic data table. 

РАЗШИРЯВАНЕ НА МЕТОДИТЕ НА СТАНДАРТНИЯ АНАЛИЗ НА 

ДАННИ 


С цел да се извлекат нови знания се поражда необходимостта от разширяване на 

методите на стандартния анализ на данни. Методологията наречена “символен анализ 

на данни” предоставя разяснителни резултати, изразени чрез концепциите на реалния 

свят, математически представени чрез разбираеми “символни обекти”. Символния 

анализ на данни е продиктуван благодарение на развитието на информационните 

технологии, които имат капацитет да съхраняват все по-увеличаващ се обем от 

огромни набори данни. 

Описанията на данни се наричат “символни”, когато те са по-сложни от 

стандартните данни, поради факта, че те съдържат вътрешни променливи и са 

структурирани. Символните данни произтичат от много източници, с цел да се 

обобщят огромни множества от данни. Те изискват по-сложни таблици наричани 

“символни таблици за данни”, защото една клетка от таблицата не съдържа както 

обикновено единични количествени или категоризиращи стойности. Една клетка може 

да съдържа няколко стойности свързани от таксономия или интервали с логически 

правила и т.н. Нуждата от разширяване на стандартните методи за анализ на данни 

(изследователски, групиращ …..) към символни таблици за данни, се увеличава с цел 


28 

да се добие по-точна информация и да се обобщят огромни набори от данни съдържани 

в базата данни. 

Основни дефиниции: 

“Символен анализ на данни” - разширение на стандартния анализ на данни към 

символни таблици. “Символни таблици за данни” - една клетка с данни не съдържа 

както обикновено единични количествени или категоризиращи стойности. Клетката 

може да съдържа няколко стойности свързани от таксономия или интервали с 

логически правила 

“Символните обекти” - представляват разяснителен резултат от изчисления на 

стандартен анализ на данни и могат да бъдат използвани с цел да се дефинират 

запитвания към базата данни. 

“Извличане на знание” означава да се извлекат разяснителни резултати, представени 

чрез “символни обекти”. 

“Символните обекти”-моделират “идея” или “физически съществуваща 

единица” в реалния свят. Какво наричаме идея? Има два вида “идеи”. брилянтно 

дефинирани от Арнолд и Никол [1] и Ж.П. Шаньо [4]: 

1. “Идеята за реалния свят” като град, регион, сценарии за пътно транспортно 

произшествие, вид безработица, …… Идеята е дефинирана от понятията “намерениесхващане” 

и “обхват” [1]. “Схващането- намерението на една идея са атрибутите, 

които тя съдържа и които не могат да бъда отнети от нея без тя да бъде разрушена. 

Например- схващането на идеята за триъгълник включва бегла степен, фигура, три 

линии, три ъгъла, равенството на тези три ъгъла на два прави ъгъла и т.н. Обхват на 

дадена идея, предметите към която тя се отнася, които са също така наричани по-нисши 

на даден универсален термин, който е по-висш за тях. По този начин идеята за 

триъгълник, като цяло обхваща всички различни видове триъгълници.” 

2. “Идеята за нашия разум” (наречени “умствени обекти”, както е 

дефинирано от Ж.П. Шаньо, който представя в нашия разум идеи за реалния свят, чрез 

тяхното намерение и “начина за изчисляване на техния обхват”, а не обхватът сам по 

себе си тъй като няма място за всички възможни обхвати. 

Идея за нашето съзнание може математически да бъде моделирана от символен обект, 

който е дефиниран от функцията за описание "d" (т.е. нейното намерение) и функцията 

за нанасяне “а” способна да изчисли нейния обхват, например описанието на това което 

наричаме “кола” и начина на разпознаване, че дадена съществуваща единица на 

реалния свят е кола. Идеята за реалния свят може да бъде моделирана от символен 

обект и неговия обхват. Докато “идеите” или “съществуващите единици” на реалния 

свят са математически моделирани от “символни обекти”, тяхното компютърно 

моделиране е предоставено от така наречените “обекти” използвани в “обектно 

ориентирания език”-например в компютърни езици като C ++ или JAVA. 

Според традицията на Аристотел, идеите са характеризирани от логическо 

свързване на свойства. Според традицията на Адансон [14], (Адансон (1727-1806 е бил 

френски натуралист, изпреварил с много времето си) идеята е характеризирана от 

набор от подобни един на друг обекти. 

Според традицията на Аристотел, ако всички елементи намиращи се в обхвата 

на понятието са еквивалентни, третата тенденция произлизаща от психологията и 

познавателната наука Рош (1978), цели да се вземе предвид, че идеите трябва да бъдат 

представени от класове, които “имат склонност да бъдат дефинирани от гледна точка 

на прототипни примери, които съдържат атрибутите, които са най-представителни за 

предметите вътре във класа”. Следвайки Вагнер, Виле [26] казва: “в традиционната 

философия, нещата за които тяхното намерение описва всичките свойства валидни за 

обекта на техния обхват, се наричат “идеи”.

29 

Символните обекти комбинират предимствата на тези четири тенденции: 

1. Традицията на Аристотел, при която те могат да имат разяснителната 

сила на логическо описание на идеите, които те представят. 

2. Адансонската традиция, при която елементите на обхвата на символния 

обект са подобни едни на други в смисъл, че те трябва да удовлетворяват по най-добър 

начин същите свойства (не задължително от булевата алгебра). В този смисъл идеите 

които те представят са политеистични [14]. 

3. Гледната точка на Рош, където тяхната функция на елементи дава 

възможност, да се предоставят прототипни примери, характеризирани според найпредставителните 

атрибути [7]. 

4. Свойството на Виле е удовлетворено от така наречените “завършени 

символни обекти”, което може да докаже, че те основават решетката на Галоа (виж 

например, Диде [3, 4, 5]. 

2. Кратък обзор 

След като първите документи анонсират основните принципи на символиния анализ на 

данни [3], много трудове са били написани в същата посока. По-важни от тях са: 

o Трудовете на Дж. Леб [22], Е. Диде[4], Р. Вин (1995)[21], Конрът (1993)[17] - В 

случая когато обектите са описани от символни данни, и в случаите на структурирани 

данни са разработeни разширения на стандартни дървета на решения. 

o Факториалния анализ на обектите, дефиниращ главен компонентен анализ 

описан от един вектор на цифрови интервали и в същата посока грижейки се за дадени 

подвластни правила ( Лауро и Палумбо (1998) [2 ], Р. Верд и деКарвальо (1998) [20]. 

o “правила за символно разграничение”- Е. Периьол, “сегментиращите дървета за 

напластяващи данни”- М.К. Браво, Дж. М. Гарсия-Сантесмасес (1998) 

разграничителния анализ на Кернел, започващ от различието между символните 

описания. С. Лисоа (1998) и Дж.Пи. Расън [18]. 

o връзка с територията на “основаното на примери аргументиране”- Е. Ориол 

(1995). С цел да се изберат символни променливи, които разграничават по най-добрия 

начин обектите или класовете, няколко трудове са изработени от Р. Вин (1991) [21] и 

Зиани (1996) [25]. 

o извличане на символни обекти от факториален анализ на данни Гетлър-Сума 

(1992), Смади (1995). 

o предоставяне на символни обекти от времеви серии, Ферари, Гетлър-Сума, К. 

Пардо, Х. Тонг (1995)[8]. 

o Дисертации представени в Париж 9 – Университета Дафин: 

o Мфомоне (1998), изграждане на пирамида, където съединение е 

асоциирано със символен обект [6]. 

o Шавен (1998), разделение на набор от символни обекти, чрез “top-down” 

алгоритъм, който също предоставя символен обект, асоцииран с всеки 

придобит клас. 

o Хилали (1998) изобразяването на класове от обекти, описани чрез вектор 

на вероятни разпределения. 

o Полаило (1998) разширяването на решетките на Галоа, до символни 

данни при нанасяне и “завършени” символни обекти получаване на 

резултат. 


30 

3. Произход на символния анализ на данни 

Символният анализ на данни произлиза от едновременното влияние на няколко 

сфери на анализ: 

- стандартният изследователски анализ на данни, където се отдава по-голямо 

значение на обектите, отколкото в стандартната статистика и където символиният 

подход разширява методите до по-сложни описания на единиците и дава поразяснителни 

резултати. 

- Изкуственият интелект (AI), където повече усилия са посветени в откриването 

на програмни езици, с цел да се представи сложно знание, вместо IR p вектори на 

стандартните статистически единици. Трябва да бъде отбелязано, че простият език 

използван с цел да се представят символните обекти е повече вдъхновен от езиците 

основани на логика от първа група [23] , отколкото от графическата презентация. 

Трябва също да бъде отбелязано, че в символния анализ на данни, ние не сме особено 

заинтересувани от компютърния език (SQL, C++, JAVA, ...), който е използван с цел да 

се представят символните обекти, а от тяхното математическо моделиране, начина по 

който те са индуцирани от данните, тяхното графично представяне и т.н. 

- Цифровата таксономия в биологията, интелигентните машини в изкуствения 

интелект, класифицирането в анализа на данни [9, 19]. 

4. Приложение на символния анализ на данни 

В логическите съчинения („Органон”) на Аристотел (IV в. пр. н.е.) ясно се 

разграничава “първа група обекти” (като кон или човек), разглеждани като единица 

асоциирана към индивид от света на “втора група обекти” като единица асоциирана 

към клас от индивиди. 

Първата цел е да се разшири стандартния анализ на данни към втората група субекти. 

Пример: 

При преброяване на населението на дадена държава, всеки обект от всеки регион 

е описан от набор от цифрови или категоризиращи променливи, предоставени в 

няколко релации в базата данни и е разглеждан като “първа група обект”. 

С цел да се изучат регионите считани като “втора група обекти”, ние можем да опишем 

всеки регион обобщавайки стойностите взети от техните жители, чрез интервали или 

под набори на категоризиращите стойности, или хистограми или вероятностни 

разпределения и т.н. в зависимост от променливата. Създава се “символна таблица за 

данни”, където всеки ред дефинира “описанието” на региона и всяка колона е свързана 

към символнтаа променлива. Разширяване на стандартния анализ на данни към 

символна таблица за данни е първата цел на методологията наречена “символен анализ 

на данни”. 

Друга важна цел е да се придобие (или да се “извлече”) разяснителен резултат (т.е. 

знание) чрез извличане, на така наречените “символни обекти”, които моделират 

“идея” или “физическа съществуваща единица” в реалния свят. “Символичен обект” се 

дефинира от неговото “намерение” и чрез начина на намиране на неговия “обхват”. 

Например описанието на регион се нарича “намерение”, набора от обекти, които 

удовлетворяват това намерение, се нарича “обхват”. Синтаксисът от символични 

обекти трябва да има разяснителна сила. 

Например, символният обект дефиниран от следния израз: 

a(w) = [age(w) ∈ [20, 50] ] Λ [Брой на децата (w) ≤ 3] ни предоставя: 

o намерението на клас от обекти чрез описанието d = ( [20,50], 3), 

където [20, 50] е интервал на произволна променлива, свързана с региона, 

отнасящ се за възрастта на променливата,

31 

o калкулиране на обхвата чрез функция “а” дефиниран с помощта на 

релации Λ and ≤ . 

o обектът "w" принадлежи към “обхвата” ако неговата възраст е 

между 20 и 50 години и има по-малко или 3 деца. 

Този вид символен обект, може да бъде разширен по следния начин: обектите са от 

втората група (като градове и региони) и представят класове от обекти от първа група, 

следователно описанията на обектите са предоставени чрез разпределения (например 

хистограма на възрастта в даден град). В този случай трябва да се дефинира различен 

вид взаимовръзка “R” и праг с цел да се калкулира обхвата. 

Фиг. 1 представя отделните етапи на анализ на символни данни. 

Фиг.1 Символен анализ на данни 

5. Използване на класове в символния анализ на данни 

Един естествен въпрос изниква при всичките тези сфери на анализа: как се 

получават класовете и тяхното описание? 

В исторически план ние можем накратко да кажем, че съществуват три тенденции: 

Първата предложена от Жусо през 1748 година [12] е традицията на Аристотел и 

се състои в това да се дефинират класовете отгоре надолу, чрез добър подбор на 

свойствата, които ги характеризират от най-общия до най-специфичния. Получава се 

дърво на решения, където всяко разклонение е характеризирано чрез релации от 

свойства. Много други са продължили тази тенденция, стартирайки със обекти от първа 

група: Бреиман и колектив (1984) [13], а също и стартирайки със обекти от втора 

група: Х. Раламбонрейни (1991) [10], Лебе, Р. Виджин (1991) [21,22]. 

Втората тенденция, представена за първи път от Адансон (1757) [14], който 

представя първия алгоритъм за “Последователно натрупващо се йерархично 

клъстериране”. Този добре познат “bottom up” алгоритъм, стартиращ чрез класове 

редуцирани до обекти, слива на всяко ниво най-сходните класове. Тази тенденция е 

добре представена от Уард (1963)[25], Жардин и Сибсън (1971), Снийт и Сокъл (1973), 

Жамбу (1978), Роа (1985), Бок (1974 ), Сельо, Говаер, Льошовалие и Раламбондраини 


32 

(1989), и др. Класовете получени по този начин, съдържат сходни обекти. Тогава е 

възможно те да бъдат обобщени чрез разделяне на връзките от свойства, ето защо тези 

класове са наречени “политеистични” противно на класовете обобщени от връзки от 

свойства наречени “монотеистични”. Докато от друга страна първата тенденция ражда 

монотеистични класова чрез “top-down” процес, втората произвежда политеистични 

класове чрез "bottom up” процес. В тази рамка, фамилния метод наречен 

“Концептуално клъстериране”, е бил разработен за преглед през осемдесетте години от 

Ленгли и Сейдж (1984), Лебовиц (1983), Д.Х. Фишер. (1987) и Фишер и Ленгли (1986). 

Вместо да произвежда дървета, както е при Диде (1984), Бертран (1986) например, е 

описан възходящ процес на изграждане на пирамида от политеистични класове (т.е. 

обобщаване на йерархични дървета, позволяващи припокриване на гроздове). При 

Брито и Диде (1991) и Брито (1994) една възходяща пирамида произвежда 

монотеистични класове. 

Третата тенденция се състои в директното търсене на класове и тяхното 

представяне. Например “Методът на динамичното клъстериране” [3, 4, 5], дефинира 

обща рамка и алгоритми, които целят да откриват едновременно класове и техните 

представяния по такъв начин, че те “да съвпадат” заедно по възможно най-добрия 

начин. Този подход е бил използван с няколко видове между-класови структури 

(разделения, йерархии, …..) и представителни методи за всеки клас (начални числа, оси 

на множители, регресии, …..). При Диде (1976), е предложено логическо представяне 

на гроздове. С оглед на “Концептуалното клъстериране”, алгоритъм базиран на метода 

за динамично клъстериране или вдъхновен от него, сред другите пионерски документи 

на “Концептуалното клъстериране” трябва да се споменат трудовете на Льошавалие 

[24], Сиди (1980), Михалски и Степ [23]. 

6. Визуализация на символни обекти: Решението Zoom Star 

В този раздел са представени няколко метода и софтуер, посветени на 

визуализацията на символни обекти [15, 16]. Те използват радиални графи. Същите 

могат да бъдат представени двуизмерно (Zoom Star, Simple Star) или триизмерно 

(3DZoom Star, Temporal Star). Всяко изображение се отнася само за един набор 

индивиди в агрегирана форма, но няколко обекта могат да бъдат сравнени, когато те са 

представени един до друг или когато са наложени един върху друг. Възможно е също 

така да бъде визуализирана еволюцията на един обект, който се променя с времето. За 

представянето на различните характеристики се използва звук. 

Фигура 2 представя стойността на 8 стоки за три различни седмици. Това позволява 

анализ на еволюцията на стоки в един портфейл, в зависимост от времето. 

Фиг. 2: Анализ на еволюцията на 8 стоки за три различни седмици [15 ]

33 

6.1 Триизмерен Zoom Star 

В тази версия, плоскостта на звездата се вижда триизмерно и хистограмите 

асоциирани с категорийните променливи са представени директно върху оста. 

Възможно е обръщането на фигурата с цел откриването на най-добрия ъгъл за изглед. 

Триизмерният Zoom Star може също така да бъде изобразен един до друг. 

6.2 Временна звезда 

Това представяне е използвано, за да визуализира един символен обект изменящ 

се с времето. Триизмерните Zoom Stars визуализиращи един обект в различни моменти 

във времето са нишка в централната ос представяща времето. Диаграмата може да бъде 

увеличена, преместена, завъртяна около времевата ос (фигура 3). За подчертаване на 

еволюцията от един временен момент към друг, външните (или вътрешните) краища на 

интервалите могат да бъдат свързани, правейки външен (или вътрешен) прозрачен воал. 

Фигури 2 и 3 представят стойността на 8 стоки от един и същи портфейл, изменящи се 

за период от 8 седмици. 

Фигура 3: Презентация на временна звезда за стойността на стоки през 8 

последователни седмици. [16] 

6.3 Анимиране в двумерен Zoom Star 

Анимирането може също така да бъде използвано, за да покаже промените на 

набори в зависимост от времето. При свръх налагането на двумерни звезди вариращи 

във времето (както е в фигура 2), ние получаваме анимиран ефект показващ 

еволюцията на един обект. Използвани са различни цветове за да бъде ясно изразен 

процеса. 

Модулите са разработени в среда Java, OpenInventor, 3D MasterSuite и Java Media 

Framework. OpenInventor е тримерен графичен API, използващ стандарт OpenGL. 3D 

Master-Suite разширява и включва OpenInventor и триизмерни графични класове от 

високо ниво. Потребителят е снабден с няколко интерактивни средства. Те касаят 

стандартните визуализационни характеристики, като увеличаване, ротация на фигурите 

и настройки на цвета и фона. 


Развитието на информационните технологии, които имат капацитет да 

съхраняват все по-увеличаващ се обем от огромни набори от данни породи 

необходимостта от възникване и развитие на нови методи за анализ на информация. 

Тази потребност доведе до възникване на нови и усъвършенстване на съществуващите 

методологии за анализ на данни, чиито цели са да разширят методите на стандартния 

анализ на данни и да предоставят по разяснителни резултати, изразени чрез 

концепциите на реалния свят, математически представени чрез “символни обекти”. 

Тази статия изследва методология за анализ на данни наречена символен анализ на 

данни. Идеята за използването на тази теория ни беше предлажена от проф. 


34 

Noirhomme- Fraiture през 2005 година по време на подготовката на съвместен проект. 

Статията изследва и обобщава трудове на учени работещи в тази област. 

Цел на нашата бъдеща работа ще бъде разработване на нови алгоритми в анализа на 

символни данни, разширяване на методологията на символния анализ на данни чрез 

използавне, невронни мрежи, размита логика и т.н. 


1. А. Arnault and Р. Nicole, LaLogique ou l’art depensur” Reprinted by Froman, Stuttgart, 1965. 

2. C. Lauro, F. Palumbo, "New approaches to Principal Component Analysis of Interval Data". 

Proc. NTTS'98 Sorrento, Italy. Nanopoulos, Garonna, Lauro edit. Eurostat (Luxembourg), 1998. 

3. E. Diday. Orders and overlapping clusters by pyramids. In: Multidimensional Data Analysis (eds. J. 

De Leeuw, W. J. Heisen, J. J. Meulman and F. Critchley), DSWO Press, Leiden, 201-234, 1986. 

4. E. Diday, Introduction a e’Approche Symbolique en Analyse des Donnees. Premiere Jouneles 

Symbolique-Numerique, CEREMADE, Universite Paris - Dauphine, 21-56, 1987. 

5. E. Diday, Emilion, R. and Hillali, Y. (1996). Symbolic Data Analysis of Probabilistic Objects by 

Capacities and Credibilities. Atti Della XXXVIII Riunione Scientifia, 5-22. 

6. E. Mfoumoune, "Les aspects algorithmiques de la classification ascendante pyramidale et 

incrémentale" . Thèse de doctorat, Université Paris 9 Dauphine, 1998. 

7. E. Rosch, "Principle of categorization". E. Rosch, B. Lloyd edits. Cognition and Categorization , 

pp 27-48 . Hillsdale, N.J.: Erlbaum, 1978. 

8. Ferraris, Gettler-Summa, C. Pardoux, H. Tong (1995) "Knowlege extraction using stochastic 

matrices: Application to elaborate a fishing strategy" Proc. Ordinal and Symbolic Data Analysis. 

Paris ; Diday, Lechevallier, Opitz edit. Springer Studies in Classification. 

9. Georgi Kirov, K. Trichkov , "Soft Computing agents in distributed network applications", 

International Scientific Conference Informatics in the Scientific Knowledge 2006, ISK’2006, June 

28 – 30, 2006,Varna, Bulgaria, pp. 143-153. 

10. H. Ralambondrainy, "Apprentissage dans le contexte d'un schéma de base de Données" 

Kodratoff, Diday edit. CEPADUES, Toulouse, 1991. 

11. I. Valova, Knowledge extraction from data bases, KMPro, Bulgaria - Chapter meeting, Sofia, 

19.06.2006. 

12. Jussieu, "Taxonomy. Coup d'oeil sur l'histoire et les principes des classifications botaniques". 

Dictionnaire d'Histoire Universelle, 1748. 

13. L. Breiman, L., Friedman, J. H., Olshen, R. A. and Stone, C. J. Classification and 

Regression Trees, Wadsworth, 1984. 

14. M. Adanson "Histoire Naturelle du Sénégal- Coquillages". Bauche Paris, 1757. 

15. M.Noirhomme- Fraiture, M.Rouard: Visualising and Editing Symbolic Objects,, in Hans- 

Hermann Bock, Edwin Diday (eds.):Analysis of Symbolic Data. Exploratory methods for extracting 

statistical information from complex data., Springer Verlag, Heidelberg, 2000, ISBN 3-540-66619- 

2. 

16. M. Noirhomme-Fraiture: Visualization of Large Data Sets: the Zoom Star Solution, Journal of 

Symbolic Data Analysis, vol 1, July 2002. http://www.jsda.unina2.it 

17. N. Conruyt, (1994) "Amélioration de la robustesse des systèmes d'aide à la description, à la 

classification et à la détermination des objets biologiques. Thèse de doctorat, Université Paris 9 

Dauphine. 

18. P. J. Rasson, S. Lissoir, "Symbolic Kernel discriminante analysis" Proc. NTTS'98 Sorrento, 

Italy. Nanopoulos, Garonna, Lauro edit. Eurostat (Luxembourg), 1998. 

19. P. Andreeva, S. Vassileva, A. Afuzova-Christova "Improved Models for Machine Learning 

through Density Estimation", International Scientific Conference Informatics in the Scientific 

Knowledge 2006, ISK’2006, June 28 – 30, 2006,Varna, Bulgaria, pp. 89-105 

20. R. Verde, and DeCarvalho, F. A. T. Dependence Rules Influence on Factorial Representation of 

Boolean Symbolic Objects. In: Knowledge Extraction form Statistical Data, 1998. 

21. R. Vignes, "Caractérisation automatique de groupes biologiques". Thèse de doctorat, Université 

Paris 9 Dauphine, 1991.

35 

22. R. Vignes and Lebbe J. "Génération de graphes d'identification à partir de descriptions de 

concepts", in Induction Symbolique-Numérique. Kodratoff, Diday edit. Cepadues (Toulouse), 1991. 

23. S. Michalski, and Stepp, R. E., Learning from Observation: Conceptual Cluster- ing. In: 

Machine Learning (eds. R. S. Michalski, J. G. Carbonell, and T. M. Mitchell), Springer-Verlag, 331- 

363, 1984. 

24. V. Stephan, V. Hebrail, G. and Lechevallier, Y. (2000). Generation of Symbolic Objects from 

Relational Databases. In: Analysis of Symbolic Data (eds. H. -H. Bock and E. Diday), Springer- 

Verlag, 78-105, 2000. 

25.Ward, 3 hierarchical groupings to optimize an objective function". J. Amer. Stat. Assoc. 58, pp. 

236-244, 1963. 

26. Wille R. (1989) "Knowledge Acquisition by methods of formal concepts analysis, in Data 

Analysis, Learning symbolic and Numeric Knowledge. Diday edit. Nova Science Publishers, 1989. 

27. Ziani . (1996) "Sélection de variables sur un ensemble d'objets symboliques" Thèse de doctorat, 

Université Paris 9 Dauphine 

Institute of Control and System Research 

Bulgarian Academy of Sciences 

Akad. Bonchev str., Bl.2, P.O. 79 

1113 Sofia 

BULGARIA 

E-mail: vania@icsr.bas.bg 





BULGARIA 

37 

APPLES GRADING USING INDEPENDENT COMPONENT 

ANALYSIS 

KRASSIMIR KOLEV 

Abstract. The mathematic model of Independent Component Analysis (ICA) is presented. The 

ICA is one of the most widely used methods for blind source separation. Spectral characteristics of 

apples were analyzed. Two main independent components were found which play a role in the 

ripening of apples. The method can be implemented in a real time sorting machine. The classification 

system performs well with a small number of apples data is shown, which increases the speed of the 

fast ICA algorithm. 

Key words: apple grading, independent components 

КЛАСИФИКАЦИЯ НА ЯБЪЛКИ ИЗПОЛЗВАЙКИ 

МЕТОДА НА НЕЗАВИСИМИТЕ КОМПОНЕНТИ (ICA) 


Ябълките са плодове с богато съдържание на ценни съставки. Ябълковия плод е 

един от най-консумираните и притежава противораково и противогрипно действие. 

Зрелостта на ябълките е процес свързан с разлагане и намаляване на хлорофила и 

изграждане на каротиноиди. Хлорофила и каротиноидите имат специфичен добре 

изучен абсорбционен спектър. Спектъра на излъчване на ябълките е комбинация на 

тези индивидуални спектри. Използвайки спектралните характеристики за ябълки е 

възможно да се определи концентрацията на основните вещества съдържащи се в 

ябълките. Възможно е намиране на регресионен модел на база на обучение чрез 

спектрални изображения със известни концентрации на веществата определени чрез 

хроматографски анализ. 

Калибрирането на спектралните изображения използвайки химически еталонни 

измервания е бавен и скъп процес който затруднява практическото приложение. Това 

налага да се търсят нови подходи за изграждане на регресионни модели и 

класифициране без обучител. Техниките които могат да извършват класификация без 

обучител са известни като скрито разделяне на сигнали [3]. Един от най-широко 

използвани съвременни методи за разделяне на скрити сигнали е метода на 

независимите компоненти (ICA). Главната цел на изследването е възможността за 

прилагане на метода на независимите компоненти (ICA) за калибриране на 

класифицираща система за ябълки. Използвайки метода на независимите компоненти 

(ICA) е направен опит за разгадаване на специфични компоненти в спектъра на 

ябълките. Резултатите от анали са за сравнени с тези определени чрез хроматографски 

анализ. 


2. Материали и методи 

38 

Спектралното изображение се състои от голямо количество m пиксела. Всеки 

пиксел съдържа стойности на поглъщане за k дължини на вълните. Когато 

пространствената връзка на пикселите се пренебрегне, спектралното изображение може 

да бъде описано като двуразмерна матрица Х, където Х съдържа наблюдаваните 

променливи (x1,x2,…,xk) за m пиксела, xi е стойността на поглъщане за дължини i 

(i=1…k). Спектъра на пиксел l (l=1…m) може да бъде разглеждан като линейна 

комбинация на спектрите на поглъщане на веществата в плода. В контекста на метода 

на независимите компоненти (ICA) тези вещества се наричат независими компоненти. 

Матрицата S съставена за независимите компоненти (s1,s2…,sk), si е вектора на 

стойностите на поглъщане на независимите компоненти за дължина i. Спектъра на 

поглъщане на независимия компонент j в плода се отразява чрез (sj,1,sj,2,…sj,k) и се 

означава като IC-j. За да получим от Х матрицата S, е нужно да се знае 

комбинационната матрица А с размерност m.n т.е. 

X=A.S (1) 

Независимите компоненти sij са скрити променливи и те не могат да бъдат 

наблюдавани директно. Комбинационната матрица А също се смята, че е неизвестна. 

Задачата на метода на независимите компоненти (ICA) е да намери и двете матрици A и 

S чрез Х на наблюдаваните спектрални изображения. Известно е че това може да бъде 

направено когато компонентите са взаимно статистически независими и имат не 

гаусово разпределение. 

Размера на А матрицата е пропорционален на броя на пикселите в Х матрицата. 

Ако се използват всички пиксели на спектралното изображение, матрицата Х ще стане 

твърде голяма. Затова се използва случайно избрана серия от пиксели. След определяне 

на A и S може да се пресметне концентрацията на всички пиксели на спектралното 

изображение. За да получим матрицата на концентрация за всички независими 

компоненти се използва: 

' 

' 

A im = S.X im 

(2) 

Разгънатите пространствени връзки между пикселите се възстановяват в 

комбинационната матрицата А. 

Преди прилагане на метода на независимите компоненти (ICA) е необходимо да 

се центрират и изчистят наблюдаваните променливи. Центрирането се извършва чрез 

изваждане на матрицата на средните стойности на Х, т.е. M = E{X} 

Тази предварителна обработка се прави само за опростяване на алгоритмите на 

метода на независимите компоненти (ICA). След определяне на комбинационната 

матрица А със центрирани данни може да се изчисли и матрицата S със центрирани 

данни т.е S=A -1 .M 

Изчистването е техника, която трансформира матрицата Х така че да съдържа 

некорелирани компоненти със променени елементи. Изчистването може да се направи 

използвайки метода на независимите компоненти (ICA). Препоръчително е да се 

извърши и редуциране на размерността на данните едновременно с изчистването. За 

обработка на данните е използван бърз алгоритъм на метода на независимите 

компоненти (ICA). Алгоритъма използва фиксирана итерационна процедура за 

намиране на максимума на негаусовото поведение на центрираната и изчистена Х 

матрица. Този алгоритъм е сто пъти по-бърз от стандартния градиентен метод на 

независимите компоненти (ICA), и позволява вграждане в реална DSP платформа за 

обработка на изображения. Важните характеристики на бързия метод на независимите 

Λ

39 

компоненти (ICA) е, че приближението е квадратично, независимите компоненти 

могат да се изчислят един по един, алгоритъма е прост, ефективен и изисква по-малко 

място в паметта. 

Анализиране на спектрални изображения на ябълки чрез метода на 

независимите компоненти (ICA) 

Анализирани са петдесет и седем ябълки от сорта „златна превъзходна” в 

различна степен на зрялост. За всяка от 57 ябълки е снето спектрално изображение с 

размери 640х480 пиксела. Направена е предварителна обработка за премахване на 

фона. От всяко спектрално изображение случайно са взети 104 пиксела. Всичките 5928 

пиксела образуват данните на матрицата Х. Промените от геометрията са коригирани 

чрез нормализация. Направена е и една обратна логаритмична трансформация за да 

може да сравняват спектъра със еталонни спектри на поглъщане дадени в справочници 

за дадени вещества. Спектъра се състои от 80 честотни ленти покриващи обхвата от 400 

до 720 nm. Под 450 nm цялата светлина се поглъща от плода. Поради това първите 

честотните ленти се изключват от анализа. Извършва се изчистване на началния вектор. 

Използвайки бърз алгоритъм за метода на независимите компоненти (ICA) се 

изчисляват комбинационната матрица А и независимите компоненти. Бързия 

алгоритъм за метода на независимите компоненти е оптимизационна задача 

стартирана с случаен тегловен вектор. За това алгоритъма се повтаря докато се получи 

същата матрица Х сто пъти. За бързо калибриране, матриците Х и А трябва да бъдат 

колкото е възможно по малки, тъй като скоростта на алгоритъма е пропорционален на 

размерността на данните. За да се тества колко данни са нужни алгоритъма се повтаря 

104 пъти с различно количество пиксели от един до сто и четири за ябълка. 

Тъй като метода на независимите компоненти (ICA) има възможност да извлече 

независимите компоненти очаква се, че получените стойности са във връзка със 

съставните вещества на плода. Но намерените стойности на независимите компоненти 

не за реалните концентрации на веществата измерени, чрез хроматографски анализ. 

Поради това е необходимо начално калибриране на независимите компоненти със 

еталонни стойности. За да се тества възможността на метода на независимите 

компоненти (ICA) за калибриране в реално време е направена кръстосана проверка. 36 

плода са използвани за калибриране на класифицираща система за ябълки чрез метода 

на независимите компоненти (ICA). 

3. Резултати и дискусия 

Използвайки бърз алгоритъм се намира комбинационната матрица А 5928х2 и 

два независими компоненти IC1 и IC2. На фиг.1 са показани двата главни компонента 

от метода на главните компоненти (PCA) и двата независими компоненти от метода на 

независимите компоненти (ICA). 


40 

Фиг. 1. Спектрални компоненти 

Хроматографския анализ показва, че chlorophyll и carotenoids са веществата с 

голяма промяна в концентрация в процеса на узряване на ябълките. Спектрите на 

chlorophyll и carotenoids са показани на фиг.2. Вижда се ,че получените независими 

компоненти приличат на действителните абсорбционни спектри, като IC-2 има 

максимум при 670nm, но високата абсорбция около 430nm в еталонния спектър е 

преместенa към 510nm. 

Това изместване се дължи на други вещества и на ефекта на разтваряне на 

еталонния спектър. 

Фиг. 2. Относителни спектри на поглъщане 

Фиг. 3.Средноквадратична грешка 

Сравняването на главните компоненти PC1÷2, независимите компоненти IC1÷2 

и еталонните спектри показа, че ICA е по-подходящ за намиране на концентрацията на 

веществата отколкото метода на главните компоненти. Повторяемостта на резултатите 

беше тествана сто пъти със същата матрица Х. Тъй като бързия метод на независимите 

компоненти (ICA) започва със случаен тегловен вектор, оптимизацията може да се 

натъкне на локален максимум. Оказа се , че в 82% от изчисленията резултатите са 

същите като на показаните на фиг.1. Чувствителността на метода на независимите 

компоненти (ICA) от размера на матрицата Х е тествана с вариране на броя на 

пикселите от 1÷104 за ябълка.

41 

Фиг. 4. Стойности на независимия компонент. 

Фиг. 5. Стойности на главния компонент. 

На фиг.3 е показана големината на средноквадратичната грешка на намерените 

независими компоненти в зависимост от големината на матрицата Х. 18% грешни 

решения са премахнати от графиката. Използването на по-голяма матрица Х слабо 

увеличава устойчивите решения, вижда се, че в целия обхват разликата е твърде малка, 

поради което използване на 8 пиксела например е напълно достатъчно. Това ще 

редуцира времето за калибриране в реално-време на системата за класифициране на 

ябълки. На фиг.4 и 5 са показани резултатите на концентрацията на независимите 

компоненти в комбинационната матрицата А и на главните компоненти. Тук не се 

забелязват разлики в получените резултати. 

Направи се кръстосана проверка за потвърждаване на възможността използване на 

метода на независимите компоненти за калибриране в поток. На фиг. 6 са показани 

наблюдаваните и предсказани концентрации. 

∑ 

Процентното отклонение изчислено чрез 

∑ 

m 

⎛ 

⎞ 

⎜ yˆ 

− ⎟ 

n ij ( i) 

⎜ j= 

1 ⎟ 

⎜ 

− yi 

⎟ 

i= 

1 m 

⎜ 

⎟ 

2 

Q = 1 − 

⎝ 

⎠ , където 

n 

2 

( y − y) 


∑ 

i= 

1 

i

ˆij( i) 

42 

Фиг. 6. Предсказана концентрация чрез ICA. 

y − предсказаната концентрация на пиксел j от ябълка I на база на калибриращ 

комплект от всички ябълки без i-та ябълка. 

y измерена концентрация 

i 

y средната концентрация за всички ябълки 

n броя на ябълките 

m броя на избраните пиксели за ябълка 

e съответно 0.82 за IC-1 и 0.86 за IC-2. 


Направените изследвания показаха, че метода на независимите компоненти (ICA) е 

подходящ за калибриране на класифицираща система за ябълки работеща в реално 

време на база на спектрални изображения.. Необходимо е само да се направи начално 

калибриране към действителните стойности на веществата. Промените по-време на 

класифицирането партиди ябълки, светлинни източници, сензори могат да се 

прекалибрират в поток използвайки метода на независимите компоненти (ICA). 

Предимство на тази система сравнение с системите с обучител е използването на помалко 

еталонни данни за калибриране. Скоростта на обработка може още да се повиши, 

ако се използват изображения получени чрез камера с адресация на пикселите. 


1. Hollas, M.. Modern Spectroscopy, John Wiley&Sons,2004. 

2. Hollet, L. .Food Analysis by HPLC , Marcel Dekker, 2002 

3. Hyvarinen, A., J. Karhunen . Independent Component Analysis, John Wiley&Sons,2001. 

Department of Computer Systems and Technologies 

University of Food Technologies – Plovdiv 

26, Mariza Bld. 

4002 Plovdiv 

BULGARIA 

E-mail: kr_kolev@abv.bg




BULGARIA 

43 

VIRTUAL LABORATORY FOR DISTRIBUTED SYSTEM 

NIKOLAY KAKANAKOV, NIKOLAY RAITCHEV, GRISHA SPASOV 

Abstract. The paper presents a web based system for e-learning for the course 

“Distributed systems and computer communications” from the MSc program of 

department “Computer systems and technologies”. The system provides separate 

interfaces for students and lecturers. Each student can read online course materials, make 

tests and submit course projects. The lecturer can upload materials, tests, course project 

assignments, as long as monitoring test results, project work and students progress. The 

system has unique extra functionality – it provides interface for students to carry out the 

laboratory work for part of the course, entitled “Remote procedure call”. 

Key words: e-learning, distributed systems, RPC. 

ВИРТУАЛНА ЛАБОРАТОРИЯ ПО РАЗПРЕДЕЛЕНИ ИСТЕМИ 


Развитието на електрониката и комуникационните технологии, заедно с 

навлизането на Интернет във всички свери на съвременния живот, доведе до появата на 

електронно правителство (e-Government), електронно здравеопазване (e-Health), 

електронна търговия (e-Market), електронно обучение (e-Learning) и други. Тези 

явления отговарят на изискванията на съвременното общество за достъп до 

информация от всяка точка и по всяко време. Появата на нови технологии води и до 

поява на нови изисквания – сигурност, надеждност, достъпност. 

Създаването на система за провеждане на електронно обучение не следва 

развитието на технологиите, а следва еволюцията в изискванията на хората. Жизненият 

цикъл на една такава система включва създаване на материали, публикуване и достъп. 

Създаването на материалите се извършва от програмисти, дизайнери и специалисти в 

областта на курса. Публикуването на материалите е на Web сървър, който е в основата 

на достъпността на системата. Понякога материалите могат да бъдат разделени на 

множество сървъри, обединени от един портал. Достъпът до материалите е 

посредством Интернет браузер и може да се осъществи от всяка точка и по всяко време. 

2. Системи за Електронно Обучение 

Електронното обучение може да бъде проведено по няколко различни сценария. 

Най-простият сценарий включва само публикуване на теоретични и методически 

материали (telementoring). В един по-сериозен сценарий се включва и система за оценка 

на усвояването на материала от страна на обучавания – система за тестове. Самото 

създаване и провеждане на тестове е нерешен проблем в електронното обучение, тъй 


44 

като в повечето случаи не е автоматизирано. Има разработки, които се стремят чрез 

създаването на софтуерни агенти да автоматизират генерирането на тестови въпроси от 

материала и да направят интерактивно оценяването [1, 3, 5]. 

Фиг. 1. Структура на електронното обучение. 

Друг сценарий на провеждането на електронно обучение е провеждането на 

дискусионни форуми. Те могат да се реализират чрез електронна поща или чрез видео 

конференции. Проблемът при създаването на такива системи е, че изискват повече 

комуникационни ресурси и обучаваните и обучаващите е необходимо да са 

едновременно в системата [1, 3, 5]. 

Един от най-трудните за решаване проблеми при електронното обучение е 

създаването и провеждането на упражнения. Това е така, защото необходимите 

материали и ресурси за различните дисциплини са много различни. Например 

необходимост от макети, опитни постановки, компилатори, програмни среди, 

измервателна апаратура. Едно решение на този проблем е използването на макети, 

които се дават под наем или се продават на студентите. Те могат да си ги инсталират 

вкъщи и да провеждат упражнението. Това, обаче, е скъп вариант и е приложим само за 

високоплатени курсове. Друг вариант, който може да бъде приложен, е разработването 

на емулационни и симулационни програми, които да заместят опитната постановка. 

Така проведените упражнения ще бъдат достъпни и лесни за изпълнение [1, 3]. 

Съществуват множество системи за електронно обучение, позволяващи 

публикуването на материали и провеждането на онлайн тестове. Затова настоящата 

разработка се ограничава само до създаването на виртуална лаборатория за 

провеждането на лабораторни упражнения по дисциплината „Разпределени Системи и 

Компютърни Комуникации” от ОКС ”Магистър”, специалност „Компютърни Системи 

и Технологии”.

45 

3. Виртуална Лаборатория по Разпределени Системи 

Създадената виртуална лаборатория има за цел да улесни провеждането на 

лабораторни упражнения по дисциплината „Разпределени Системи и Компютърни 

Комуникации”. Поддържат се три различни нива на достъп до системата: 

администратор, преподавател и студент. Администраторът създава курса и приема 

регистрацията на потребителите, като единствено той може да променя нивото на 

достъп на регистрираните потребители (фиг. 2). За да се осигури надеждност и 

сигурност при едновременна работа на много потребители се поддържат сесии. Всеки 

студент е с отделна сесия, което позволява организирането на отделно Web 

пространство за него. Така може да се продължи работата оттам докъдето е стигнал 

предишния път. 

Фиг. 2. Регистрирани потребители и нива на достъп. 

Преподавателят може да качва материали за упражненията, лекции, програма, 

конспект, литература Той също може да проверява посещаемостта на студентите, 

грешките, които допуска всеки от тях при изпълнение на задачите. Студентите освен 

достъп до лекционни материали, методическо ръководство за упражненията, имат и 

възможност да си изберат курсова задача, да се регистрират, че ще работят по нея и да 

публикуват получените резултати за обсъждане и оценка. 

Най-важната част от разработката е възможността за дистанционно провеждане 

на някои теми от упражненията без необходимостта студентите да закупуват някакви 

софтуерни продукти, образци или материали. Цялото упражнение се провежда през 

Интернет. Като пример за лабораторно упражнение е дадена темата „Отдалечено 

извикване на процедури” [6]. В това лабораторно упражнение студентите се учат да 

разработват процедури за отдалечено извикване по модела ONC-RPC, въведен от Sun 

Microsystems. Това е най-базовия и най-стар модел за разработка на отдалечени 

процедури и всички останали се явяват негово развитие. При него се описва 

интерфейса и поведението на процедурата с специфичен език – IDL. Това описание 

включва сигнатурата на отдалечената процедура (име, брой и тип на параметрите, 

връщан резултат) и описание на комплексните структури и типове данни. Студентът 

въвежда IDL описанието през форма на страницата (фиг. 3) и когато натисне бутона 

„Send” данните се изпращат към специален инструмент, който генерира необходимите 

заглавни и сорс файлове. Този инструмент е инсталиран на сървър за упражнения и на 

студентите не им е необходим никакъв специфичен софтуер. Генерираните файлове се 


46 

запазват в отделна директория за всеки потребител и той може в последствие да 

редактира тези от тях, които е необходимо. След редактирането на файловете и 

добавяне на потребителски такива, програмата може да бъде компилирана и да се 

генерират изпълними файлове. Тук отново не е необходимо потребителя да има 

компилатор, защото компилирането се извършва на сървъра. Всеки потребител има 

достъп само до директорията, съдържаща генерираните от него файлове и така може 

упражнението да се извършва на части [6]. 

Фиг. 3. Въвеждане на IDL декларации през Web формата. 

Изпълнението на инструмента за отдалечени процедури и компилирането на 

сървъра вместо при клиента позволява гъвкавост на системата и използването на 

олекотени клиенти като джобни компютри, мобилни телефони. Това позволява полесното 

преминаване от електронно към мобилно обучение. Отдалеченото изпълнение 

се извършва посредством CGI процедури [2]. 


Разработената система позволява отдалеченото провеждане на лабораторни 

упражнения по дисциплината „Разпределени Системи и Компютърни Комуникации”. 

Използването на тази система съвместно с популярни системи за електронно обучение 

ще позволи провеждането на дистанционни курсове по тази дисциплина. Системата не 

реализира напълно електронното обучение по дисциплината а само провеждането на 

лабораторните упражнения. 

В бъдеще трябва да се направи анализ на журналната информация на Web 

сървъра на системата,което ще позволи по-доброто й администриране и подобряването 

на интерфейса й. Анализирането на журналите позволява получаването на информация 

за профила на потребителя, най-търсени ресурси, тънки места, последователност на 

извикване на ресурси [4]. Друга важна стъпка в бъдещото развитие е пълното 

интегриране на системата към някоя съществуваща система за електронно обучение и 

автоматизиране на създаването на упражнения като обекти за обучение (learning 

objects) [3].

47 


1. Aymerich, F., N. Dessi, B. Pes, A. Saba, An automatic assessment system supporting 

computer science entrance examinations, Proc. IEEE International Conference on 

Advanced Learning technologies, 2004, pp. 657-659. 

2. Ашок Апу, Администриране и защита на Apache Server, Дуо Дизайн, 2004, ISBN: 

954-8396-19-X. 

3. Horton, W., Horton, K., E-Learning tools and technologies, Wiley Publishing 2003, 

ISBN: 0-471-44458-8. 

4. Krishnamurthy, B., J. Rexford, Web Protocols and Practice, HTTP/1.1, Networking 

Protocols, Caching and Traffic Measurement, Addison-Wesley, 2001, ISBN:0-201-710889. 

5. Nichols, M., A theory for eLearning. Educational Technology & Society, 6(2), 1-10, 

(2003), Available at http://ifets.ieee.org/periodical/6-2/1.html. 

6. Tanenbaum, A., M. Van Steem, Distributed Systems Principles and Paradigms, Prentice 

Hall 2002, ISBN 0-13-088893-1. 


Technical University of Sofia, Branch Plovdiv 


4000 Plovdiv 

BULGARIA 

E-mail: kakanak@tu-plovdiv.bg; nraitchev@mail.bg; gvs@tu-plovdiv.bg. 





BULGARIA 

49 

DISTRIBUTED SYSTEM FOR MONITORING AND 

CONTROL IN INTERNET ENVIRONMENT 

NIKOLAY KAKANAKOV, BORIS RIBOV 

Abstract. The paper proposes a distributed system for monitoring and control in internet 

environment. The system is based on IPC@CHIP SC12 microcontroller as a “host” and 

PIC16F877А as a “controller”. IPC@CHIP SC12 has integrated Ethernet interface and 

TCP/IP stack with Web server. PIC16F877А can monitor sensor or control hardware 

signals. It supports 1-Wire communication protocol based on I 2 C through DS2482-100 

chip (Dallas). It also has 6 ADC inputs (10bit) for monitoring analog signals, 4 

temperature signals (resolution 0.0625°C), 12 discrete inputs and RFID card reader. The 

system implements three-tier client/server model. The interaction between the “host” and 

the “controller” is based on serial ASCII protocol. 

Key words: Distributed Monitoring and Control, Sensors, Embedded Systems. 

РАЗПРЕДЕЛЕНА СИСТЕМА ЗА МОНИТОРИНГ И КОНТРОЛ ПРЕЗ 

ИНТЕРНЕТ 


Общата архитектура на системата е показана на фигура 1. Тя се базира на 

многослоен модел клиент-сървър, приложим в системи за разпределена автоматизация 

[2]. На най-горнят слой са потребителите, които се връзват към системата през 

Интернет, посредством стандартен Web браузер и HTTP. 

Фиг. 1. Архитектура на системата. 


50 

На вторият слой е разположен Web портал, който служи за администратиране на 

цялата система и за централизирано управление и конфигуриране на долните слоеве. 

Порталът служи и като единна входна точка за потребителите към системата. Връзката 

между този слой и долния е посредством специално проектиран протокол за извличане 

на данни от разпределени вградени ситеми – CNDEP [3]. 

На последният слой работи подсистемата, която извършва реалния мониторинг и 

контрол. Тя включва контролер, който събира информация от външните сензори и хост, 

който се грижи за доставянето на информацията до система на по-високо ниво за 

анализ и обработка. В настоящата разработка за създаването на „хост” частта е 

използвана вградената платформа IPC@Chip на фирмата Beck [1]. Той реално работи 

като „мост” между CNDEP и серийния протокол за достъп до „контролера”. На него 

работят двата комуникационни процеса, които си взаимодействат в реално време и се 

извършва идентификацията на потребителите (по RFID картата). 

2. Контролер 

В настоящата статия под “контролер” се разглежда блока за комуникация със 

сензорите, който събира информацията от тях и анализира моментното им състояние. 

Блокова схема на контролера е показана на фигура 2. Той е изпълнен на базата на 

едночипов микроконтролер от серията PIC16F87X на фирмата Microchip [4]. 

Фиг. 2. Структура на контролера. 

Избора на конкретния минроконтролер бе съобразен с това той да разполага с 

необходимите ресурси по отношение на комуникационни интерфейси и наличие на 

вградени хардуерни модули за обработка на информацията и съхранението и. Избора 

падна на микроконтролера PIC16F877A. Последният представлява RISC процесор 

работещ на 20MHz, който осигурява производителност от 5MIPS. Контролера 

разполага с вграден хардуерен модул за сериен интерфейс, I 2 C интерфейс, 8 канален 

аналогово-цифров преобразувател, двуканален цифрово-аналогов преобразувател, 

вградена EEPROM памет с размер 256 байта и налична RAM памет от 368 байта. 

Програмната памет е от тип FLASH, като размера е 8192 думи (14,3KB). Входно 

изходните шини са общо 33. 

Контролера поема следенето на статуса на множество сензори: безжичен четец 

на карти за идентификация (RFID); 6 аналогови входни сигнала с корекция на нулевото 

отместване в групи по 3 с голяма точност и статистическа корекция на грешката; 12

51 

цифрови дискретни входа и 4 цифрови температурни сензора с голяма точност. 

Контролера следи дали параметрите на всички тези сензори са в нормите зададени 

предварително в конфигурационна таблица и сигнализира алармено събитие към хост 

системата при излизане от границите на параметрите. При възвръщане към допустимия 

интервал от стойности на дадения параметър отново се генерира събитие към хост 

системата за да се уведоми, че следения процес е в нормите. 

Комуникацията между контролера и хост системата се осъществява посредством 

сериен RS232 интерфейс чрез ASCII команди. За тази цел в контролера работи 

команден интерпретатор, който обработва потока от символи и взима съответно 

решение за изпълнение на дадената команда. 

Всички параметри на сензорите се записват в регистров файл, който може да 

бъде достъпен за четене от хост системата. От своя страна хост системата може да 

задава и запазва началните конфигурационни параметри за следене на всеки един 

сензор в EEPROM паметта на контролера, както и да включва или изключва даден 

сензор. Това става с команди за запис от хост системата към контролера. 

Изходните данни от сензорите, както и текущото състояние на алармения буфер 

се намират в регистров файл в RAM паметта на контролера, която може да бъде 

прочетена от хост системата във всеки един момент от време. Последната може 

периодично да чете състоянието на сензорите с цел статистическо натрупване на данни 

от тях. Контролера е длъжен да уведоми хост системата чрез заявка за прочитане на 

алармения буфер ако даден параметър излезне извън рамките на допустимите 

стойности (генериране на алармено събитие от сензор). След прочитане на алармения 

буфер следва процедура на потвърждение, инициатор на която е хост системата. В 

алармения буфер се съдържа информация за поредния номер на алармата и номера на 

сензора, който я поражда. Ако такава бъде породена от множество сензори то се 

отбелязва мулти-алармено събитие. В алармения буфер може да бъде прочетена и 

стойността на брояч показащ общия брой рестарти на системата. При всяко пускане 

този брояч се увеличава с единица и неговата стойност се запомня в енерго-независима 

памет. В системата е предвидена отказоустойчива проверка на контролера в реално 

време. Проверява се кректността на изпълнение на хода на програмата и ако възникне 

критична ситуация се взимат мерки централния микроконтролер да бъде рестартиран. 

При наличие на проблем породен от некоректно поведение на контролера последният 

се рестартира, като брояча на начални стартирания се увеличава с единица. Предвидена 

е и възможност хост системата да рестартира принудително контролера при загуба на 

комуникация с него. В този случай брояча на начални стартирания също се увеличава с 

единица. 

В контролера е реализирана специфична операционна система, чрез която се 

следят всички процеси свързани с обработката на информацията от сензорите. 

Стартирани са множество процеси, някои от които са: комуникационен процес 

обслужващ серийния RS-232 интрфейс; опорен таймер; процес на АЦП; процес на 

следене на дискретните входове; процес на следене на температурните сензори; процес 

на следене на безжичния четец на карти и др. Специфичната операционна система е 

реализирана на езика асемблер (MPASM) с цел да се оптимизират процесите по 

оптимално използуване на ограничения ресурс на микроконтролера. 

3. Сензори 

Типа на сензорите, които се поддържат от контролера е разнообразен с цел 

универсалност при приложението на системата. Това налага да бъдат използвани и 

различни интерфейси за връзка. 


52 

3.1 Дискретни сензори – нормален режим на работа 

Дискретните сензори са галванично разделени и се следят по логически нива. 

Такъв тип сензори са например: сензор за врата, пожарен сензор, контактен сензор и др. 

Предвидена е възможност да бъде задавано активното следящо ниво – дали 

генериращото аларма събитие да бъде изпълнявано по логическа нула или логическа 

единица. За всеки един от тези сензори е предвидено хистерезисно време (таймаут) за 

задействане, което да се изчака преди да се вземе решение за алармено състояние. Това 

време се задава в секунди (от 1 до 63) и се запазва в конфигурационната таблица на 

сензорите, като за всеки един вход то се задава независимо. Използуването на 

хистерезисно време на задействане е продиктувано от спецификата на работа на 

множество от дискретните сензори с цел отсраняване на фалшиви въздействия 

породени от случайни шумове. 

3.2 Дискретни сензори – специален режим на работа 

За всеки един дискретен вход може да бъде зададено да работи по специфичен 

алгоритъм, нужен за определен тип специални сензори. При тях няма твърдо изменение 

на сигнала с, което да се предизвика алармено събитие а се наблюдава определен закон 

от преходи от единица в нула. Такива са например обемните сензори. При тях когато 

има движещ се обект в активната зона се предизвиква моментално задействане на 

сензора, и след някакъв интервал от време отново се възобновява нормалното 

състояние. Към тази група сензори принадлежат и шоковите сензори. За да може такива 

сензори да бъдат включвани към контролера е необходимо дадения дискретен вход към 

който е свързан такъв сензор да бъде конфигуриран да работи като “специален”. В този 

режим на работа не се проверява за хистерезисен интервал от време, като веднага се 

генерира аларма при поява на активно алармено ниво (то може да бъде задавано дали 

да е с високо или ниско логическо състояние). Ако сензор в този режим се задържи в 

активно състояние повече от 30 секунди се генерира ново алармено събитие за 

“липсващ сензор”. Това е индикация, че има окъсяване на сигналната линия или пък 

отпадане на сензора поради технически или умишлени причини. 

3.3 Аналогови входове/сензори и АЦП 

Обхвата на преобразуване е от 0 до +5V, като разделителната способност е 10 

бита. Поради необходимостта крачетата на микроконтролера да бъдат използувани за 

множество други входнo/изходни шини се използва само един входен аналогов сигнал 

и външен аналогов мултуплексор. За аналогов мултиплексор е използуван 4051, като се 

реализира динамично във времето сканиране на всички 8 аналогови сигнали. За 

измерванията е използван алгоритъм отстраняващ грешката. За целта се измерват 10 

поредни отчета на стойността на всеки един от входовете, отстранява се най-малката и 

най-голямата стойност и се осреднява стойността от останалите 8 измервания. Това 

гарантира получаването на значителна точност и отстраняване на грешката от случайни 

шумове. Измерената стойност се сравнява с реперните за минимална и максимална 

допустими граници и при излизане от тези граници за определен времеви период се 

генерира алармено събитие. В статуса на аларменото събитие е достъпна информация 

дали то е породено от спадане на напрежението на дадения аналогов сензор под 

минималния репер или е породено от превишаване над максималния репер. 

Хистерезисния времеви интервал е предвиден за да може бързо изменящи се 

процеси (шумове) да не генерират случайни сработвания на алармено събитие. 

Хистерезисния период се задава в конфигурационната таблица в секунди, като той е 

общ за всички аналогови входове и е в границите от 1 до 255 секунди. 

В схемата са предвидени два коригиращи аналогови входа чрез които се отчита 

реперната нулева стойност от която да започне измерването. Това се налага поради 

наличието на потенциали породени от токови контури при връзката на външни

53 

аналогови сензори. От отчетената стойност за всеки вход се изважда измерената 

реперна стойност и по този начин се получава действителната, която подлежи на 

последващо сравнение дали принадлежи на интервала от допустими стойнсти зададен в 

конфигурационния фаил. При необходимост може двата входа, измерващи реперните 

напрежения да бъдат свързани към нулевата шина, с което да се разреши измерването 

на пълния диапазон от стойности и да се изключи корекцията. 

3.4 Температурни сензори и интерфейс за връзка с тях 

Нулиране на 1-wire чрез команда 0x54 към 

драйвеа DS2482 

НЕ 

Начало 

Четене на статуса от DS2482 

Отговор от 1-wire 

устройство? 

Подаване на команда 0хА5 към DS2482 

(команда за изпращане на данни) 

Изпращане на команда 0xCC към DS18B20 

(глобалена адресация) 

Изпращане на команда 0х 44 към DS18B20 

(стартиране на температурното измерване) 

Подаване на команда 0х 96 към DS2482 

(команда за четене на байт от 1-wire) 

Проченен байт = 0х FF? 

Подаване на команда 0хА5 към DS2482 

(команда за изпращане на данни) 

Изпращане на команда 0xCC към DS18B20 

(глобалена адресация) 

Изпращане на команда 0х BE към DS18B20 

(команда за четене на таблицата с данни) 

Подаване на команда 0х 96 към DS2482 

(команда за четене на байт от 1-wire) 

ГРЕШКА! 

Липсващ сензор 

КРАЙ 

ДА 

ДА 

Това втори прочетен 

байт ли е ? 

ДА 

НЕ 

НЕ 

Контролера позволява измерването 

на четири независими температури чрез 

интелигентни цифрови сензори DS18B20 

производство на фирмата Dallas/Maxim [5]. 

Самите сензори са компактни в 3-краков 

корпус TO92 и измерват температура в 

диапазона от –55 градуса до +125 градуса и 

разделителна способност от 0,0625 градуса 

(12 бита). Интерфейса за връзка на 

температурните сензори към контролера е 

1-Wire [5] и се характеризира с двупосочен 

трансфер на команди и данни по 2 линии 

(маса и данни). 

За да може да бъде изпълнен 

комуникационния протокол изискващ се от 

1-wire стандарта и да се разтовари 

централния микроконтролер от 

допълнителни задачи е използуван външен 

драйвер, който формира времедиаграмите 

на сигналите по шината. Този дарйвер 

поема комуникацията по 1-wire шината, 

като към него му се подават команди от 

контролера посредством I 2 C интерфейс. 

Използвания чип за драйвер на 1-Wire е 

DS2482-100 [5] и позволява реализирането 

на мрежа от 1-wire сензори свързани в 

паралел към шината. Всеки един сензор в 

шината има уникален адрес, чрез който се 

адресира при обмен на информация (данни или команди). 

3.5 Четец за безжични карти по RFID стандарта 

Контролера позволява четенето на идентификационните номера от безжични 

RFID карти. Това прави системата много атрактивна за реализиране на постоянен 

контрол и наблюдение в реално време на процеси в необслужваеми обекти и зони, 

изискващи контрол на достъпа. За безконтактни идентификационни карти са 

изпозувани TEMIC-5557, работещи на 125kHz. За четец на транспондерите на RFID 

картите се използва чипа U2270B, като декодирането и формирането на 

комуникационния протокол се изпълнява от допълнителен микроконтролер от серията 

PIC16F84. Изхода на последния е по стандарта RS232 с канална скорост 9600bps-8N1, 

като се предават прочетените 5 идентификационни байта от безконтактната карта. 

В контролера е предвидена функция за мултиплексиране на серийния интерфейс 

поради необходимостта той да бъде използван за комуникация и с хост системата. 

Данните от четеца за карти се протичат еднократно при доближаване на нова карта 

след което комуникацията се предава към хост системата. Контролера позволява да 


54 

бъде въведено побитово маскиране на прочетените 5 байта (използуване на маска). 

Това дава възможност идентификацията да бъде реализирана само по определена част 

от информационните данни съдържащи се в картата. 

4. Заключение и бъдещо развитие 

Към проекта ще бъде включена възможност за дистанционен контрол на крайни 

устройства. В контролера се предвижда да има 8 галванично разделени дискретни 

изхода, които да управляват консуматори от различен тип и с различна мощност; 2 

аналогови галванично разделени изхода и интерфейс за комуникация с външен димер, 

който може да управлява консуматори на ~220V безжично посредством радио-канал на 

433MHz. За целта ще бъдат използувани съвременни сигурни техники за достъп до 

средата [6]. Допълнителна функционалност ще даде модула за контрол на консуматори, 

управлявани по захранващата ел. мрежа. 

Друго важно допълнение към системата ще бъде възможността за автоматично 

конфигуриране на всеки „хост” чрез зареждане на конфигурационен файл от сървъра на 

втория слой [2]. Така във всеки един момент на сървъра ще има картина на: всички 

„хостове”, връзката между тях, конфигурацията им и включената към съответния им 

„контролер” периферия (сензори, четци, управялеми устройства и др.). Това ще 

позволи самодиагностика на системата и ще гарантира увеличена надеждност. 

Като заключение може да се каже, че системата представлява завършена 

единица способна да поеме управлението, следенето и контрола на различни процеси, 

както и контрола на достъпа до помещения и зони. 


[1] Beck’s IPC@Chip homepage, Beck IPC GmbH, http://www.beck-ipc.com/ 

[2] Kakanakov, N., M. Shopov, G. Spasov, A New Web-based Multi-tier Model for 

Distributed Automation, Journal of “Information technology and Control”, b.2/2006. 

[3] Kakanakov, N., I. Stankov, M. Shopov, G. Spasov, Controller Network Data Extracting 

Protocol – Design and Implementation, Proc. of CompSysTech’06, V. Tarnovo, Bulgaria, 

2006, pp. IIIA.14-1 IIIA.14-6. 

[4] Microchip PIC16F87XA Data Sheet, Microchip Technology Inc., 1998; 

http://www.microchip.com/ 

[5] Maxim Integrated Products Inc., http://www.maxim-ic.com/ 

[6] Ribov, B., Introducing the newest Philips' microcontrollers into secured telemetry 

wireless applications, Proc. of CompSysTech'06, V. Tarnovo, Bulgaria, 2006, pp.I.4-1 I.4-6. 

Dept. Computer Systems and Technologies 

Technical University of Sofia, Branch Plovdiv 


4000 Plovdiv 

BULGARIA 

E-mail: kakanak@tu-plovdiv.bg 

Space Research Institute 

Bulgarian Academy of Science 

6, Moskovska Str. 

1000 Sofia 

BULGARIA 

E-mail: ribov@developer.bg

- 55 - 




BULGARIA 

ON THE USE OF WEB SERVICES FOR BUILDING 

DISTRIBUTED AUTOMATION SYSTEMS 

MITKO SHOPOV, HRISTO MATEV, GRISHA SPASOV 

Abstract. The paper discusses the applicability of Web services for building distributed 

automation systems and the benefits they bring. An adaptation of some of the wellproven 

enterprise architecture models and their applicability in distributed measurement 

is presented. The presented sample implementation is based on open and standardized 

approaches – high-level programming languages, object-oriented platforms, Internet 

technologies, and standardized communication interfaces. 

Key words: distributed automation, embedded systems, multi-tier models, web services. 

ПРИЛОЖЕНИЕ НА WEB УСЛУГИТЕ В ИЗГРАЖДАНЕТО НА 

РАЗПРЕДЕЛЕНИ СИСТЕМИ ЗА АВТОМАТИЗАЦИЯ 


Тенденция от последните години е да се избяга от използването на частни, 

затворени хардуерни и софтуерни платформи за изграждане на системи за разпределена 

автоматизация и да се премине към отворени и стандартизирани подходи и решения. В 

това отношение проектирането на подобни системи е силно повлияно от използването 

на езици за програмиране от високо ниво, обектно-ориентирани платформи, Интернет 

технологии и стандартни комуникационни интерфейси [1, 2, 7]. 

Допълнителна подкрепа осигурява бързият темп на развитие на хардуера, 

осигурявайки пазара с множество нови вградени системи с интегриран TCP/IP стек, 

вграден Web сървър и продължително увеличаващи се изчислителни възможности. 

Моделите, прилагани в разпределената автоматизация, въпреки своите специфични 

изисквания, следват доказаните в бизнес среда модели за обмен на данни. 

Специфичността на разпределените системи се проявява в две основни насоки – 

специфичните изисквания към актуалността на данните и ограничените ресурси на 

вградените системи [5, 8]. 

Внедряването на web услугите в системите за разпределена автоматизация е 

сравнително нова и интересна област за изследвания. Авторът на [7] предлага модел за 

адаптиране на web технологиите в индустриалната автоматизация, в който функциите 

на вградените системи са представени като услуги от сървър работещ в междинния 

слой (Remote Service Server). В [6] авторите разглеждат два метода за реализиране на 

отдалечено управление на газов хроматограф – с CGI приложение и посредством web 

услуга. Текущия проект SIRENA [1] има за цел създаването на рамка за да се улесни 


- 56 - 

изграждането и внедряването на SOA архитектурата и в частност web услугите в 

индустриалната автоматизация, в следващото поколение вградени системи, както и 

приложенията и услугите, които те предлагат [1]. 

В настоящата статия се разглеждат популярни модели за изграждане на 

разпределена автоматизация базиращи се на използването на TCP/IP протоколния стек, 

многослойни архитектури и Web технологии. Предложена примерна реализация 

използва четирислойна архитектура [3] и стандартизирания интерфейс на Web услугите 

[4] за комуникация между средните слоеве на системата. 

2. Модели за разпределена автоматизация 

Сред моделите за изграждане на разпределена автоматизация, най-голям е делът 

на трислойните архитектури. Те се характеризират с различни реализации на 

междинния слой [5]: 

• Модел със сървър за транзакции – сървърът за транзакции има за цел да 

разпределя заявките към мрежата от контролери. Той може да 

осъществява групиране на еднотипните заявки и приоритизиране на 

отделните заявки. 

• Модел със сървър за отдалечени услуги – функциите на отделните 

контролери се представят като услуги привързани към софтуерни 

компоненти на междинния сървър. По този начин клиентът комуникира с 

компонентите на сървъра, а не директно с контролерите [7]. 

• Модел с Web сървър – една от най-разпространените реализации поради 

популярността на сървърните технологии. Базира се на динамични HTML 

документи и скриптове изпълнявани на сървъра. 

• Трислоен модел с Web услуги – Този модел залага на универсалността на 

описанието на данните чрез XML и универсалността на предаване им 

чрез HTTP. Функциите на вградените системи се представят чрез Web 

услуги описани на стандартен език – WSDL. 

Всеки от гореизброените модели притежава различни предимства и недостатъци 

за различни конкретни приложения. Представения в [3] многослоен модел има за цел да 

обедини предимствата на отделните модели. Този модел се състои основно от четири 

слоя отделени по функционалност и администриране (фигура 1). 

Фиг.1. Четирислоен модел за разпределена автоматизация. 

Функциите на отделните слоеве са [3]: 

• Клиентски слой – На този слой са разположени различните клиенти на 

системата. Те отправят заявки за услуги към системата посредством 

стандартен Web браузър или чрез Web услуги. Отговорът на системата 

зависи от платформата на клиента. (PC, PDA, cellphone).

- 57 - 

• Презентационен слой – Този слой е отговорен за обработването на 

заявките и формирането на отговорите. Заявките се анализират и 

препращат към подходящ сървър от слоя за услуги. Сървърът работещ на 

този слой се нарича Web портал и е базиран на портал технологията. 

• Слой за услуги – Този слой дава основната функционалност на системата. 

Различните услуги на този слой работят на отделни машини следователно 

срив на един сървър се отразява само на конкретната услуга, която той 

предлага. Този модулен подход позволява гъвкавост и надеждност на 

системата. 

• Даннов слой – Ролята на този слой е да продуцира и съхранява данни. 

Конкретната му реализация зависи от слоя за услуги. При услуга за 

събиране на журнална информация се представя от база данни. В случай 

на автоматизационна услуга – от мрежа от контролери. 

3. Експериментална реализация на система за разпределена автоматизация 

В тази точка е представена експериментална система за изграждане на 

разпределена автоматизация, реализирана върху представения в предишната точка 

четирислоен модел. Архитектурата на системата (фигура 2) е изградена от следните 

компоненти: 

• мрежи от контролери със сензори за мониторинг на температура и влажност. 

Използваните вградени системи са съответно DS TINI на Dallas Semiconductors 

[13] и IPC@Chip SC12 на Beck IPC [12]. 

• сървър за транзакции – реализиран чрез Apache Tomcat 5.5.14 servlet контейнер и 

Apache Axis работещи на машина със следните параметри - 333MHz Pentium II, 

256 MB памет и OС Debian Linux 2.4.27-2-386. 

• сървър за събиране на журнална информация – реализиран чрез Apache Tomcat 

5.5.14 servlet контейнер и сървър за управление на база данни MySQL 5.0.22. 

• услуга за изчертаване на графики [10] 

• UDDI регистър – реализиран чрез Microsoft UDDI Services. 

Фиг. 2: Обща архитектура на системата. 


- 58 - 

3.1. Сървър за транзакции 

Сървъра за транзакции (transaction server) представлява една от възможните 

реализации на слоя за услуги (Service tier). Неговата роля е да осъществява свързващо 

звено между предлаганите от система за разпределена автоматизация услуги и данните, 

които постъпват от мрежата от сензори. Сред възможните му приложения са 

осъществяване на контрол и измервания във фабрики (plant control and monitoring) и 

автоматизиране на дома и офиса. В предложената реализация, сървъра за транзакции 

получава заявки за изпълнение на определени услуги от представителния слой 

(presentation tier), които заявки трансформира в серия от транзакции към слоя за данни. 

Комуникацията с представителния слой и останалите сървъри на същия слой се 

осъществява посредством web услуги. В конкретния случай, слоя за данни е представен 

от мрежа от контролери, комуникацията с които се осъществява чрез специално 

разработен протокол – CNDEP [9]. 

Фиг. 2: Вътрешна архитектура на сървъра за транзакции. 

Структурата на сървъра за транзакции включва два компонента (нишки), които 

комуникират помежду си посредством синхронизирани опашки (фигура 3). 

Компонентата ‘TS thread’ се използва за предоставянето на функционалността на 

мрежата от сензори чрез Web услуги. За различните web услуги се генерират различни 

последователности от команди към слоя данни. Компонентата ‘CNDEP thread’ има за 

цел да осъществи изпълнението на командите над мрежата от контролери. В 

конкретния случай e използваn протоколът CNDEP. Подмяната на протоколът за 

комуникация с контролерите ще изисква единствено подмяната на тази компонента. 

3.2. Сървър за събиране на журнална информация 

Предназначението на този модул е да събира и съхранява и предоставя 

журнална информация от вградените системи. Възможностите на сървъра за събиране 

на журнална информация са: заявка за събиране на конкретна информация от мрежа от 

контролери или конкретна вградена система; регистриране на заявката и стартиране на 

работна нишка; тази нишка има две задачи – събиране на информацията през зададен

- 59 - 

период и съхранението и в база данни; предоставяне при заявка на информация от 

базата с данни. Всички тези задачи са реализирани като Web услуги. Извличаната от 

базата данни информация е XML кодирана, което улеснява по-нататъшното и 

обработване. 

3.3. Услуга за изчертаване на графики 

За изчертаване на графики се използва web услугата представена в [10]. Тази 

услуга получава серия от данни и ги организира в таблици или графики. Таблиците се 

съхраняват в comma separated values (.csv) формат, а графиките като картинки (bmp 

формат). Построяването на графиката се извършва от Graphic Server .NET 3.0 

компонента от Graphic Server Technologies. Графиките могат да се синтезират за 

различни данни получени от Web-услугата за регистрация. 

3.4. Откриване на услугите 

Един от популярните методи за откриване и локализиране на услуги е 

използването на централизиран справочник. При него се използва отделен сървър за 

съхранение на информацията за наличните отдалечени услуги. Популярни технологии 

за реализиране на централизирани справочници са Jini, Universal Plug and Play (UPnP) и 

Universal Description, Discovery, and Implementation (UDDI). От тях последния е част от 

стандартите за Web услуги. 

Стандартът UDDI дефинира правилата за взаимодействие с централизирания 

регистър и формата на записите в него. Операциите над регистъра са за регистриране и 

за търсене на информация. Съществуват два типа UDDI регистри: публични и частни. 

Публичните са свободно достъпни в Интернет и служат за свободно търсене на Web 

услуги. Частните UDDI регистри се използват от организации за регистриране и 

търсене само на частни, използвани изключително от тях или партньорски организации 

Web услуги [11]. 


В статията са разгледани популярни модели за изграждане на системи за 

разпределена автоматизация. Разгледани са предимствата произтичащи от прилагането 

на SOA архитектурата и технологията на web услугите в тези системи. Предложена е 

реализация на четирислоен модел позволяваща географското разпръскване на 

отделните звена без това да се отразява съществено върху функционалността на цялата 

система. Реализацията се основава на отворени и стандартизирани подходи, което 

позволява улеснена интеграция със съществуващите информационни системи както и 

със следващото поколение програмни системи за управление а автоматизационни 

контролери. 

5. Благодарности 

Изследванията в настоящата работа са финансирани от Фонда за научни 

изследвания към МОН – проект “ВУ-966/2005”, “Интегриране на web услуги и данни в 

разпределени информационни системи за автоматизация в интернет среда”, договор 

“ВУ-МИ-108/2005”. 


1. F. Jammes and H. Smith. Service-Oriented Paradigms in Industrial Automation, IEEE 

Transaction on Industrial Informatics, Vol. 1, Issue 1, Feb. 2005, 62 – 70. 


- 60 - 

2. M. Fowler. Patterns of Enterprise Application Architecture, Addison-Wesley Professional, 

2002, ISBN: 0-321-12742-0. 

3. N. Kakanakov, M. Shopov and G. Spasov. A new Web-based multi-tier model for 

distributed automation systems. Information Technologies and Control, Vol. 2, 2006. 

4. N. Kakanakov, M. Shopov and G. Spasov. Distributed Automation System based on Java 

and Web Services, Proceedings of the CompSysTech’06, Veliko Tarnovo, Bulgaria, June 

15-16, 2006, III-A.24-1-6. 

5. Н. Каканаков. Web базирани модели за разпределена автоматизация. Автоматика и 

Информатика, бр. 3, 2006, 40-44, ISSN: 0861-7562. 

6. U. Topp, and P. Müller. Web based service for embedded devices. 2001. 

7. N. Jazdi. Component-based and Distributed Web Application for Embedded Systems. 

International Conference on Intelligent Agents, Web Technology and Internet Commerce, 

Las Vegas, USA, 9-11 July 2001. 

8. G. Borriello, R. Want. Embedded Computation Meets the World Wide Web. 

Communications of ACM, Vol. 43, Issue 5, May 2000, pp. 59-66. 

9. Kakanakov, N., I. Stankov, M. Shopov, and G. Spasov. Controller Network Data 

Extracting Protocol – design and implementation. Proceedings of the CompSysTech’06, 

Veliko Tarnovo, Bulgaria, June 15-16, 2006, pp. IIIA-14.1 – IIIA-14.6. 

10. Kakanakov, N. An Application of Web Services for Distributed Measurment. 

Proceedings of the Young Researchers Session, International Symposium on Modern 

Computing., 4-6 October 2006, Sofia, Bulgaria, pp. 55-60, ISBN: 954-91743-5-2. 

11. Alonso, G. Myths around Web Services. IEEE Data Engineering Bulletin, Vol.25, 

number 4, 2002. 

12. http://www.beck-ipc.com/ipc/ - IPC@Chip Homepage [October 2006]. 

13. http://www.maxim-ic.com/products/tini/ - DS TINI Homepage [October 2006]. 


Technical University–Sofia, Branch Plovdiv 


4000 Plovdiv 

BULGARIA 

E-mail: mshopov@tu-plovdiv.bg; hristo.matev@gmail.com; gvs@tu-plovdiv.bg

- 61 - 




BULGARIA 

PARALLEL IMAGE PROCESSING OF 24-BIT BITMAP FILE 

WITH FILTER ‘MEAN’ 

ATANASKA BOSAKOVA-ARDENSKA, NAJDEN VASILEV, 

ANELIA PAGUROVA (MATAKOVA) 

Abstract. In this paper are shown implementations of two parallel algorithms for image 

processing by filter ‘mean’ and a mask sized 5x5. It is shown a sequential 

implementation of algorithms which we used for a comparative analysis with parallel 

algorithms. Programs work with 24-bit BMP images. There are shown results from 

experiments proving that programs using partial sums are speeder in both 

implementations parallel and sequential. It is made a comparison between sequential and 

parallel algorithms. 

Key words: Parallel algorithms, Image processing, filter ‘mean’, MPI 

ПАРАЛЕЛНА ОБРАБОТКА НА 24 БИТОВ БИТМАП ФАЙЛ 

С ФИЛТЪР „MEAN” 


Алгоритмите за обработка на изображения най-често се разделят в три 

йерархични групи [1]: 

- алгоритми за първична обработка на изображения: целят намаляване на шума (noise 

reduction) и общо подобряване качеството на изображението (image enhancement); 

- алгоритми за междинна обработка на изображения: използват се за сегментация на 

изображения (segmentation), скелетизация (skeleton), откриване на контури (edge 

detection) и др.; 

- алгоритми за обработка на изображения от високо ниво: към тази група спадат 

различни алгоритми за откриване и разпознаване на обекти (тази група алгоритми е 

тясно свързана с изкуствения интелект (artificial intelligence)). 

За много практически приложения е необходимо обработването на изображения 

да става възможно най-бързо или дори в реално време. Един от възможните подходи за 

постигане на по-високо бързодействие е използването на паралелни алгоритми. 

Филтърът „mean” (или средно число) спада към групата алгоритми за първична 

обработка на изображения [5]. В литературата е известен още като „neighborhood 

averaging” или осредняване по съседите. Филтриране от този тип в пространствената 

област представлява обхождане на цялото изображение с квадратна маска (с нечетна 

размерност) и сумиране стойностите на пикселите попадащи под маската. Получената 

сума се дели на броя сумирани пиксели и по този начин се получава новата стойност за 


- 62 - 

пиксела, попадащ под централния елемент на маската. Филтърът може да бъде 

анизотропен или рекурсивен. При анизотропната му реализация на всяка стъпка от 

придвижването на маската се използват стойностите на пикселите от оригиналното 

изображение, а при рекурсивната - стойности, които са получени от предишните стъпки 

от движението на маската. 

2. Файлов формат BMP 

BITMAP е графичен файлов формат, който e устройствено-независим, известен 

още като Device Independent Bitmap (DIB). Този формат позволява на операционната 

система (ОС) Windows да изобразява битмапи, независимо от хардуера на дисплея. 

Битмапите в Windows са масиви от битове, пренасочени към пиксели от дисплея. DIB 

фиксира цвета на пикселите на изображението по начин, независещ от този, който 

използва съответния дисплей за визуализиране на пикселите. Това се дължи на факта, 

че всеки DIB носи своя собствена информация за цветовете, а оттам и управлението на 

цветовите палитри е по-лесно. Всеки компютър, работещ с ОС Windows, може да 

обработва DIB, които обикновено се съхраняват като файлове с разширение ‘.bmp’. 

Основните компоненти на един битмап файл са: файлов хедър, информационен 

хедър, цветова таблица, растерни данни. Устройствената независимост на DIB от 

хардуера на дисплея до голяма степен се дължи на факта, че всеки DIB носи своя 

собствена информация за цветовете. При 1, 4 и 8-битовите DIB тази информация се 

съдържа в цветова таблица, която е разположена веднага след информационния хедър. 

Тя представлява масив от елементи, чиито брой е равен на броя на използваните 

цветове в изображението. Имайки предвид факта, че цветовата таблица е налична само 

за монохромни, 4 и 8-битови битмапи, то максималния брой на елементите в нея е 2^8 = 

256. Всеки байт от растерното изображение (при 8-битовите битмапи) съответства на 

индекс от цветовата таблица, посредством който от нея се извличат данни за реално 

използвания цвят. За 24-битовите DIB-изображения всеки пиксел представлява RGB 

(red-green-blue) цвят, което определя напълно цвета на всеки един пиксел и поради тази 

причина не е необходима цветова таблица. 

3. Видове комуникация между процеси чрез MPI стандарта 

Message Passing Interface (MPI) е гъвкав интерфейс за писане на програми, 

предаващи съобщения/данни [4]. Комуникацията в MPI бива два вида – блокираща и 

неблокираща. Независимо от вида й, при изпращане/получаване на данни се извършват 

следните няколко стъпки [2]: 

При изпращащия процес тези стъпки са: 

1. Данните се копират в потребителския буфер от потребителя; 

2. Потребителя вика една от изпращащите MPI подпрограми; 

3. Системата копира данните от потребителския буфер в системния буфер; 

4. Системата изпраща данните от системния буфер до процеса получател. 

При процеса получател се случва следното: 

1. Потребителят вика една от MPI подпрограмите за получаване; 

2. Системата получава данните от процеса източник и ги копира в системния 

буфер; 

3. Системата копира данните от системния в потребителския буфер; 

4. Потребителят работи с данните от потребителския буфер. 

От фигура 1 се вижда, че при изпращане на данни, не трябва да се използва 

буфера, докато системата копира данните от потребителския буфер в системния буфер. 

При получаване на данни, данните няма да са напълно получени, до цялостното им 

копиране от системния буфер в потребителския буфер. При използването на

- 63 - 

подпрограми за блокираща комуникация като MPI_Send и MPI_Recv, програмата няма 

да се връща в точката на извикване, докато копирането от/в системния буфер не 

приключи. От друга страна, при подпрограмите за неблокираща комуникация като 

MPI_Isend и MPI_Irecv, програмата незабавно се връща в точката на извикване, след 

като данните са копирани от/в системния буфер. Чрез допълнителна функция MPI_Wait 

се прави проверка дали копирането е приключило. В случай, че се използва 

потребителския буфер преди копирането да е завършило, то в системния буфер могат 

да бъдат копирани невалидни данни (при неблокиращо изпращане), или 

потребителския буфер ще съдържа такива (при неблокиращо получаване). Като цяло, в 

практиката се използва предимно неблокираща комуникация, въпреки сложността й, 

поради факта, че тя е по-бърза от блокиращата. С други думи, потребителят може да 

извършва странични изчисления, докато системата копира данни между 

потребителския и системния буфер в двете посоки. 

Фигура 1. Движение на данните при Point-to-Point комуникация 

4. Реализация на паралелна обработка на 24-битово BMP изображение 

4.1. Класически филтър ‘mean’ 

Реализацията на анизотропен филтър ‘mean’ за цветно изображение (r, g, b) 

изглежда по следния начин: 

void Filter_mean(int height, 

int width, 

unsigned char * src_pixels, 

unsigned char * dst_pixels, 

int mask_size) 

{ 

int i, j, x, y, next_row; 

unsigned int sum_r, sum_g, sum_b; 

int half_mask = mask_size / 2; 


} 

- 64 - 

COLOURINDEX** src_rows, dst_rows; 

int row_offset = BmpWidthInBytes(width); 

src_rows = (COLOURINDEX**)malloc(sizeof(COLOURINDEX*)*height); 

dst_rows = (COLOURINDEX**)malloc(sizeof(COLOURINDEX*)*height); 

--mask_size; 

for( i = 0; i < mask_size; ++i ){ 

src_rows[i] = (COLOURINDEX*)src_pixels; 

src_pixels += row_offset; 

dst_rows[i] = (COLOURINDEX*)dst_pixels; 

dst_pixels += row_offset; 

} 

next_row = i; 

++mask_size; 

height -= half_mask; 

width -= half_mask; 

mask_size *= mask_size; 

for (i = half_mask; i < height; i++){ 

src_rows[next_row] = (COLOURINDEX*)src_pixels; 

dst_rows[next_row] = (COLOURINDEX*)dst_pixels; 



++next_row; 

for (j = half_mask; j < width; j++) { 

sum_r = sum_g = sum_b = 0; 

for (y = - half_mask; y

- 65 - 

dst_rows[i][j] присвояваме частното от деленето на гореспоменатите суми на броя 

елементи, които обхваща маската (mask_size* mask_size). 

4.2. Филтър ‘mean’ с използване на частични суми 

Обработката на изображението се ускорява при използване на частични суми. 

При нея изчисляването на новата стойност за всеки първи пиксел от ред на 

изображението става по класическия начин, а новите стойности за всички останали 

пиксели от реда се изчисляват по-бързо с помощта на частични суми [3]. 

Анизотропната реализация на филтър ‘mean’ с използване на частични суми е следната: 

void Filter_mean_ps(int height, 

int width, 

unsigned char * src_pixels, 

unsigned char * dst_pixels, 

int mask_size) 

{ 

int i,j,a,b,ib, next_row, next_col, junk_sum; 

int sum_r[MAX_MASK_SIZE], 

sum_g[MAX_MASK_SIZE], 

sum_b[MAX_MASK_SIZE], 

mask_sum_r, mask_sum_b, mask_sum_g, 

temp_sum_r, temp_sum_g, temp_sum_b; 

int half_mask = mask_size / 2, 

quad_mask = mask_size * mask_size; 

COLOURINDEX** src_rows, dst_rows; 

int row_offset = BmpWidthInBytes(width); 

src_rows = (COLOURINDEX**)malloc(sizeof(COLOURINDEX*)*height); 

dst_rows = (COLOURINDEX**)malloc(sizeof(COLOURINDEX*)*height); 

--mask_size; 

for( i = 0; i < mask_size; ++i ) 

{ 

src_rows[i] = (COLOURINDEX*)src_pixels; 


dst_rows[i] = (COLOURINDEX*)dst_pixels; 


} 

next_row = i; 

++mask_size; 

height -= half_mask; 

width -= half_mask; 

for (i = half_mask; i < height; i++) 

{ 

src_rows[next_row] = (COLOURINDEX*)src_pixels; 

dst_rows[next_row] = (COLOURINDEX*)dst_pixels; 




++next_row; 

- 66 - 

mask_sum_r = 0; mask_sum_b = 0; mask_sum_g = 0; 

for( a = 0; a < mask_size; ++a ){ 

sum_r[a] = 0; sum_g[a] = 0; sum_b[a] = 0; 

for ( b = -half_mask; b

- 67 - 

free(dst_rows); 

} 

Функцията void Filter_mean_ps (int, int, unsigned char *, unsigned char*, 

mask_size) реализира филтъра mean, но с използване на частични суми. Подават й се 

като параметри височината и ширината в байтове на изображението, указател към 

оригиналния масив от растерни данни, указател към масива с филтрирани растерни 

данни и размера на маската, с която се филтрира изображението. Функцията заделя 

памет за два масива за изходното и филтрираното изображение, с размери, колкото е 

броя на редовете на изображението. Растерните данни се обхождат дo ред (респ. 

колона) с номер half_mask. В масивите sum_r[], sum_g[], sum_b[] натрупваме сумите на 

обходените от маската пиксели по компоненти (синя, зелена, червена). В променливите 

mask_sum_r, mask_sum_b, mask_sum_g натрупваме по компоненти, сумите изчислени в 

sum_r[], sum_g[], sum_b[]. В масива dst_rows[i][j] записваме частното от деленето на 

гореспоменатите суми на броя елементи, които обхваща маската (quad_mask). 

Пълзейки с маската на дясно, за изчислението на градацията на всеки съседен пиксел 

вече са натрупани първите mask_size-1 частични суми, остава да се пресметне 

частичната сума от следващата колона, за да може да се изчисли градацията на 

съседния пиксел. Нея я натрупваме в променливите temp_sum_r, temp_sum_b, 

temp_sum_g. След това от натрупаната вече сума на маската изваждаме частичната 

сума на първата колона и прибавяме на нейно място новата частична сума за колоната 

(след тази последно обработената от маската). Частичните суми на колоните, които се 

редуцират се индексират чрез променливата junk_sum. Това се повтаря за цялото 

изображение. Променените растерни данни се записват в масива dst_rows[i][j]. 

4.3. Експериментални резултати 

Експериментите са проведени при следните условия: 

- изпълнение на всяка от програмите по десет пъти; 

- измерване на времето за обработка в секунди; 

- BMP (Bitmap) изображение с 1024 реда и 768 колони; 

- паралелните програми са изпълнени с общо 8 процеса (1 главен, 7 подчинени); 

- използване на функции от библиотеката MPI; 

- изпълнение на паралелните програми от клъстерна машина с четири 

двупроцесорни компютърни системи. 

Таблица 1. Време за обработката на 24 битов BMP файл (1024х768 ) по анизотропния 

метод на сканиращата маска (5x5) с филтър mean” 

Брой 

измервания 

Последователна 

програма 


програма с 

частични суми 

Паралелна 





1 2,849675 0,799393 0,457306 0,121437 

2 2,849628 0,799013 0,417366 0,113027 

3 2,849601 0,799094 0,412652 0,118204 

4 2,849605 0,79932 0,425654 0,122937 

5 2,850328 0,799034 0,457128 0,119172 

6 2,84966 0,799072 0,415534 0,112586 

7 2,850137 0,799087 0,419536 0,112881 

8 2,849641 0,79903 0,416082 0,113038 

9 2,851022 0,799007 0,45576 0,114396 

10 2,849708 0,79959 0,417002 0,115706 

средни 2,8499005 0,799164 0,429402 0,1163384 


стойности 

- 68 - 

Както при последователната, така и при паралелната реализация на 

предложените алгоритми пускането на програмите е извършено чрез Internet. 

време [s] 

3.0 

2.5 

2.0 

1.5 

1.0 

0.5 

0.0 

1 2 3 4 5 6 7 8 9 10 

брой измервания 











Графика 1. Сравнение между последователните и паралелните реализации на филтър 

‘mean’ с и без използване на частични суми 


Експерименталните резултати показват, че филтрирането на изображения с 

филтър mean с частични суми при последователната програма е около 3,6 пъти побързо 

за конкретното изображение, отколкото при филтрирането на изображението без 

използване на частични суми. Ускорението се дължи на факта, че при ‘пълзенето’ на 

маската по реда надясно, част от търсената сума, определяща новата стойност на 

следващия елемент, вече е изчислена [4]. 

Времето за филтриране на съответните изображения с паралелната програма е 

значително по-малко (приблизително 7 пъти) при по-големи изображения. Най-добри 

резултати във времето при обработката на изображения дава паралелният алгоритъм с 

използване на частични суми. 

Теоретично може да се очаква, че при паралелна обработка бързодействието 

трябва да бъде толкова пъти по-голямо, колкото повече са използваните процесори. 

Тъй като за осъществяване на измерванията са използвани четири двупроцесорни 

компютърни системи, може да се очаква осем пъти по-голямо бързодействие. 

Направените експерименти показват по-малко увеличение на бързодействието поради 

две основни причини: 

- при последователната обработка се отчита времето само за обработване масива на 

изображението, а при паралелната е включено и времето за изпращане на редове от 

изображението на всеки от slave процесите, както и времето за получаване на 

обработените редове; 

- използваната при експериментите машина работи в многозадачен и многопотребителски 

режим.

- 69 - 


1. Gonzalez. “Digital image processing” second edition, 1987. 

2. www.redbooks.ibm.com 

3. N. Vasilev, A. Bosakova-Ardenska. Parallel algorithms of the scanning mask method for 

primary images processing, CompSysTech’04, Rousse, Bulgaria 

4. www.mpi-forum.org 

5. http://www.cee.hw.ac.uk/hipr/html/mean.html 




4000 Plovdiv 

BULGARIA 

E-mail: abosakova@yahoo.com, mnvasilev@yahoo.com, a_pagurova@yahoo.com 


- 70 -

- 71 - 




BULGARIA 

8 - BIT IP CORES USING LIKE BASIS FOR SYSTEM-ON- 

CHIP PLATFORM FOR REALTIME EFFICIENCY 

ATANAS DESEV 

Abstract. We are examined few 8051-based IP, there is description of benefits and 

blemish of the appropriate core. Synthesis was done on Spartan-3 FPGA. We are shown the 

difficulties met on realization and achievement of requirements for working in real-time. 

8 - БИТОВИ ЯДРА КАТО ОСНОВА ЗА СИСТЕМА-ВЪРХУ-ЧИП 

ПЛАТФОРМА ЗА РАБОТА В РЕАЛНО ВРЕМЕ 


Редица изследвания на пазара на микропроцесорни устройства показват 

стабилният пазарен дял на 8-битовите контролери, който и в следващите няколко 

години ще остане с приходи от около 5.5 милиарда долара и производство на около 3 

милиарда чипа годишнo. Популярността на тези устройства се дължи на техните 

основни предимства, известни като 3P (preformance, periphers, price) – увеличена 

производителност, брой и фунцкионалност на периферните устройства, както и 

намалена цена и консумация [1]. Все по-голям брой производители на 

полупроводникови прибори предлагат „вградени” микропроцесорни устройства на 

базата на 8-битови ядра. Някои автори наричат тези устройства „smart” или 

интелигентни. Наличието на вграден процесор в даден продукт го прави 

„интелигинтен”, защото е способен сам да събира, съхранява, обработва и предава 

нужната информация. 

8-битовите микроконтролери се срещат на практика почти навсякъде в нашето 

ежедневие, трябва да отбележим ще съществува огромно количество и разнообразие от 

функционалност при тези устройства [1]. В настоящата статия се прави опит да се 

разгледа пазарът на 8-битовите контролери предлагани като IP core ядра и да се 

изследва възможността им да се вграждат в конфигуруеми системи-върху-чип (на 

базата на Spartan-3 FPGA) работещи в условия на реално-време със занижени 

изисквания (soft real-time). 

2. Изложение 

С намаляване на цената на FPGA устройствата става удобно използването на IP 

core или повторно използване на инженерния труд. IP (intellectual property) ядрата дават 

възможност на дизайнерите бързо, лесно и ефективно да създават сложни системивърху-чип 

проекти, като интегрират предварително създадени фунцкционални блокове. 


- 72 - 

По този начин се избягва нуждата от допълнителна верификация, тези ядра гарантират 

спазването на определените работни параметри, тъй като са предварително тествани и 

оптимизирани. Правилният избор на едно IP ядро е комплексна задача и зависи силно 

от спецификаците на изисквания краен продукт. Повечето от тези ядра се доставят под 

две форми: soft и hard (някои автори споменават и за firmcore). Soft-ядрата се 

„синтезират” от клиента, той може да си имплементира ядрото в негова система. 

Докато hard-ядрата са вече „внедрени” и не позволяват допълнителни интервенции. 

Всеки вид си има своите предимства и недостатъци. Като основно предимство на softядрата 

може да посочим тяхната гъвкавост, те се предлагат най-често под формата на 

VHDL или Veriolg RTL изходен код, заедно с необходимите тестбенчове и макроси за 

синтезирането и верификацията им. По този начин разработчика на системата може да 

внесе допълнителни промени в кода и ядрото да придобие необходимата допълнителна 

функционалност. Също така, soft-ядрото е много по-независимо технологично и е 

„преносимо”, защото задачите за оптимизация, в контекста на производителност и 

заемани ресурси, се поемат от VHDL/Verilog компилатора и CAD средата предоставяна 

от дадения производител на FPGA/CPLD/ASIC чипове. Основно предимство за hardядрото 

е неговата висока производителност и намалена консумация. Това се постига 

чрез много „финна настройка” на ядрото за съответния технологичен процес на 

изработка. От друга страна това го прави много по зависимо и трудно преносимо, 

например ако е разработено за 0,25µ процес, същото може да не работи коректно с 

0.35µ. Подробно предимствата и недостатъците на IP ядрата, както и кратка методика 

за техния правилен избор е дадена в [3]. 

Съществува огромно разнообразие от предлагани IP-ядра, дори почти всички 

производители на FPGA/CPLD/ASIC чипове предлагат в техните CAD системи 

библиотеки съставени от набор IP-ядра, при това технологично съобразени с конкретно 

използваната логика. Добър пример в това отношение е Xilinx CoreGenerator. В 

настоящата статия ние акцентираме само върху IP-ядра представляващи процесорни 

елементи [4,5] и по-специално 8-битови контролери. В последните няколко години 

цената на програмируемите прибори спадна драстично, като наред с това се увеличи 

капацитета им и се вградиха памети, хардуерни умножители, DCM и други 

функционални блокове. На фиг. 1 е показана таблица описваща характеристиките на 

една съвременна серия FPGA устройства. В настоящата работа е използван чип 

XC3S200. Предвид ресурсите, с които разполага Spartan-3 200K, e удобно целия 

микроконтролер да се имплементира в FPGA. 

фигура 1. Фамилия FPGA устройства Xilinx Spartan-3 

Тук влизат и RAM/ROM паметта на контролера, както и възможността за реализация на 

XRAM. Важно е да отбележим, че инструкциите за умножение (деление) могат да 

бъдат имплементирани на хардуерно ниво, тъй като има 12 вградени 18bit x 18bit 

хардуени умножители в използвания FPGA.

- 73 - 

3. Особености при IP soft-ядро. 

Възможностите, които ни предоставят съвременните FPGA устройства 

позволяват да имплементираме цели микроконтролери заедно с паметите и 

периферията в чипа [2,5,6,7]. Това прави дизайнът напълно синхронен, а с подходяща 

оптимизация бихме могли да постигнем много по-добра производителност и по-малко 

заемани ресурси [8]. В [11] е показан дизайн на 8-битов акумулатор-базиран 

микроконтролер притежаващ 4 инструкции, които се имплементира в CPLD с 32 

макроклетки. Обект на разработката в [7] е световно известният 8-битов контролер 

PicoBlaze, наричан още KCPSM или програмируем краен автомат. Особеното при него 

е, че всички инсртукции за изпълнение (програмната памет) са заредени в BlockRAM 

блок в FPGA. Контролерът изисква само 35 CLB (конфигуруеми логически блока), 

което позволява дори в най-малкият FPGA Spartan-3 да се имплементират няколко 

контролера. Естествено изчислителните ресурси на този процесор за слаби, а основен 

недостатък е, че програмната памет е ограничена до 1024 думи. Въпреки това може 

успешно да се ползва като управляващ програмен краен автомат. Друг пример за добре 

оптимизирани за реализация в FPGA микроконтролери са [8,9,12]. Прави впечатление, 

че някои разработчици се ориентират към RISC базирани архитектури с ясни и 

изчистини системи от инструкции, като предпочитани езици за разработка са Verilog и 

VHDL. Разбира се съществуват и немалко CISC базирани разработки с богат набор от 

инструкции, но това се отразява на размера на заеманите в FPGA ресурси, тъй като за 

по-големия брой е нужна повече декодираща логика. Наред с традиционните езици за 

описание на електоронен хардуер все по-голяма популярност добива т.нар. метод на 

хардуерния/софтуерен кодизайн. Реализацията на специализирано процесорно ядро за 

вграждане в системи-върху-чип може с пълна сила да се възползва от този подход. При 

проектирането се взимат специфичните изисквания за подобен род продукт, от една 

страна ядрото да бъде достатъчно универсално, за да се възползва от съществуващия 

софтуер, асемблери и компилатори, но от друга да бъде максимално ефективно за 

дадено множество от управляващи програми, тъй като функционалността поставяна 

пред тези устройства е строго специфична. Процесорът за вгрдаждане трябва да бъде 

проектиран по начин позволяващ разширяване на възможностите с нови (периферия, 

специални регистри, памет и методи за адресация) [2]. Системата от инструкции трябва 

да бъде съобразена с размера на програмната памет, също трябва да се избират 

правилно и методите за адресация. Общо стремежът трявба да е насочен към 

минимална заемана площ, защото това води до по-добра реализация в система-върхучип 

и по-малка консумация (важно е за системите работещи с батерии). 

Хардуерният/софтуерен кодизайн е процес на съвместно проектиране. Единият процес 

се състои от определяне на оптималната система от инструкции и ахритектурата на 

ядрото, а другият се отнася към оптимизацията на ядрото, неговата операционна и 

управляваща части се изследват и минимизират по площ. Съществува взаимно влияние 

между двата процеса, затова винаги се търси подходящ компромис. В редица 

разработки се използват езици и среди за кодизайн, например в [10] е разработен 8битов 

RISC микроконтролер с 33 инструкции и програмируем таймер. Използван е език 

от високо ниво Handel-C за целия дизайн и отстраняване на бъгове. Контролерът е 

имплементиран в Xilinx XC4010XL FPGA устройство. Интересно е да се отбележи, че 

целия проект е реализиран за 48 часа. Подобен подход с използване на език от високо 

ниво SystemC е [13] за разработване, тестване, сумилация и оптимизация на 8051съвместимо 

ядро. Дериватът на SystemC – ArchC пък е изполван за описание на „цикълсъвместими” 

с 8051 инструкции и е наблюдавно тяхното поведение. Съществуват и 

други езици от високо ниво за описание на хардуер и позволяващи кодизайн [2]. 


- 74 - 

4. Избор на 8051-съвместимо IP soft-ядро. 

Съществува голямо разнообразие от 8-битови микроконтролери под формата на 

IP ядра, които са адаптирани за нуждите на работа в реално време. [14] е отличен 

пример за това, като целевия процесор е MC6805. В литературата са известни 

разработки базирани на AVR, PIC и други по-малко познати процесорни ядра. 

Съществува тенденция към създаване на мултипроцесорни системи-върху-чипа, на 

базата на няколко 8-битови процесорни ядра [15]. Това води до добра скалируемост, 

истински многозадачен режим, паралелно изпълнение, но за да възползваме от тези 

подобрения трябва софтуерът да е написан по специфичен начин за дадения 

мултипроцесор, което не е много популярно. В [1] е обосновано защо нашият избор за 

процесорно ядро се спира на 8051 архитектура. Основното му предимство е лесното 

нагрдаждане с нова периферия (през SFR) и огромното количесто от вече написан 

софтуер, асемблери, компилатори, RTOS и библиотеки. Въпреки, че с 25-годишната си 

архитектура това ядро се приема за доста архаично, съществуават доказателства за 

добрите възмножности, които то предоставя както като изчислителна мощ [16]. В [17] 

се предлага изцяло проектиран за работа в реално време 8051 контролер под формата 

на IP soft-ядро. Поддържат се до 65000 процеса благодарение на промени във 

вътршната архитектура на процесора – той е имплеметиран като фон Нойман процесор. 

Въпреки това, съвместимостта с оригиналния набор от инструкции е запазенa, като са 

добавени нови обслужващи RTM мениджера за реално време, инкорпориран в 

процесора. Премахнати са само някои редко използвани бит-ориентирани инструкции, 

в оригиналия модел на контролера съществува само 1 свободна инструкция с КОП 

А5H. В uRT51 са добавени съшо и мениджер на паметта, мениджер на прекъсванията и 

модул за дебъг . Целият проект е насочен за имплементация в Altera FPGA се обслужва 

от специално създадена интегрирана среда за разработка uRT51 programming suite, 

позволяваща пълно наблюдение на системата, програмиране, дебъг и осблужване на 

дисциплини EDF и RM. Системата-верху-чип е напълно синхронна и е постигната 

работна честота от 10MHz при използване на Altera APEX EP20KE200 FPGA, което 

дава възможност за прецизни времеви фунцкии от 100ns. 

Можем да направим условно разделение на два класа IP-ядра при избора ни: 

комерсиални и некомерсиални. В [18] са описани някои от най-добрите 8051- 

комерсиални ядра, а в таблица 1 са приведени характеристиките им. 

ЯДРО ПАМЕТ ПЕРИФЕР 

ИЯ 

ОСОБЕНОСТИ 

Actel 

Core8051 

100% ASM51 (8051/80C31/80C51) съвместим набор от инструкции, 

намалено време за изпълнение на инструкциите до 12 цикъла, Netlist и 

RTL версии, Verilog and VHDL Core Source Code, 4 8-Bit I/O Ports, 

алтернативни порт функции, като външни прекъсвания, предоставят се 

повече входно изходни пинове в сравнение с оригиналния 8051, сериен 

порт, два 16-Bit Timer/Counters4 приоритетни нива с 13 източника на 

прекъсвания, Core8051 Speed Advantage Average: 8.0 

Opcode и Cycle еквивалент на Intel 8051, поддържа Intel Hex file format 

Aldec до 4K Bytes Internal Program Memory (ROM), до 128 Bytes Internal Data 

8051 Memory (RAM), , до 128 Special Function Registers SFR, Full Duplex 

UART, 6-Source/5-Vector Interrupt Structure

Atotek 

ATT8051 

C128 

DCD 

DP8051 

Pipelined 

Mentor 

Graphics 

Inventra 

8051 

Trentz 

Electroni 

c TE-51 

Synopsys 

DW8051 

- 75 - 

ATT8051C128 е microcode-freedesign създаден за имплементиране в 

FPGA. Дизайнът е напълно синхронен с тактуване по нарастващ фронт, 

без вътрешни tri-states състояния. 

DP8051 е процесор с много висока призводителност, оптимизирано за 

скоростspeed soft ядро. То е специално разработено с идея за 

консумацията на енергия. DP8051 използва конвейрна RISC 

архитектура 10 пъти по-бърза от оригиналното ядро и може да 

изпълнява 85-200 million instructions per second 

M8051W високопроизводително 8051 съвместимо ядро, изисвкващо 

само два такта за машинен цикъл за разлика от отигиналното, изскващо 

12, като се напълно се запзва съвместимостта. Това позволява на 

M8051W да бъде до 6 пъти по-бързо при еднаква консумация или 1/6 от 

консумацията на енергия, когато работи със стандартна скорост. 

За разлика от оригиланият 8051 микроконтролер, в този няма никаква 

интегрирана периферия. Такава може да бъде добавена допълнително, 

когато се исиква от дизайна. Ядрото също не поддържа и прекъсвания, 

затова инструкцията RETI не е имплементирана.Инсртукциите за 

умножение и делене MUL and DIV се изпълняват за два такта, в 

стандартния 8051 за 4. Поддържат се само част от оригиналния набор от 

регистри със специално предназначение SFR. 

DW8051 е съвместимо със стандартния набор от инструкции на 8051и 

може да бъде конфигуриран до много модификации на индусртуални 

стандартни 803x/805x архитектури. Налице са контролните сигнали за 

805x В/И портове. Чрез задаване на допълнителни параметри са 


QuickCor 

e 

QC8051 

Quickchi 

p 

QUIC_80 

51 

RDC 

RISC 

DSP 

Controlle 

r 

R8032TT 

E 

Roman- 

Jones 

PicoBlaze 

- 76 - 

достъпни още един сериен порт и трети таймер. DW8051 дизайнът е 

напълно синхронен. Благодарение на редуциране на машинния цикъл се 

постига повишена производителност, а чрез dual указател за данни се 

осигурява манипулирането на големи по обен данни. В зависимост от 

вида и начина на реализация и имплементираните функционални 

блокове DW8051 ядрото заема около 10k-13k gates. Работната честота 

достига до 120MHz, за по-големи честоти се изисква производствен 

процес 0.25 микрона или по-малко. Приложениеята, които не изискват 

пикова изчислителна мощ могат да се използват възможността, 

процесора да работи на по-ниска честота, като постига сходна с 

оригиналния 8051 производителност. Това води до понижена 

консумация. Стандатният 8051 предоставя интерфейс с периферията 

само през портовете си. В допълнение към портовете, DW8051 предлага 

и възможност за директен достъп през шината за памет и SFR. Това 

осигурява възможност и на потребителксата специализирана периферия 

да се свързва към ефективаната SFR шина, същата която се използва от 

вътрешната стандартна 8051 периферия. За целта могат да се използват 

свободните SFR адреси, които не са заети от вътрешната периферия. 

Този подход осигурява прединмства като бързо четене и запис – 1 цикъл 

срещу 2, ако се използва mem_bus; директно адресиране; може да се 

използва битово ориентирани инструкции, ако се налага побитова 

адресация; компактен и ефективен код. 

Използва се конвейрна архитектура, повечето от инструкциите се 

изпълняват за един цикъл. Разполага с потребителски конфигуруем блок 

от регистри със специално предназначение SFR. Използва се 

архитектура за мониторинг в реално време на вътрешните операции, без 

използване на „монитори”, през JTAG порт. 

QUIC_8051 е съвместим с оригиналния 8051, но не е идентичен. 

QUIC_8051 изпълнява инструкциите си до 6 пъти по-бързо на еднаква 

тактова честота. Това не се отразява на вградените периферни 

устройства. Използва се модерна тристепенна конвейрна архитектура, 

постига се максимална честота от 20MHz при имплементация в FPGA. 

Възможно е използването на различни средства за дебъг. 

8032TTE е високопроизводителен съвместим с 8051 RISC 

микроконтролер, базиран на конвейрна архитектура. Използват се 

различни тайминг спецификации при запис/четене на външна програмна 

и даннова памет, но наборът от инсдтрикции е обратно съвместим. 

8032TTE предлага 4 адресни пространства: 64КB програмна памет, 

64КB външна програмна памет, 256 байта вътрешна памет за данни и 16битов 

PC. От своя страна 256-те байта вътрешна памет за данни е 

разделена на две адресни пространства - 256 байта вътрешна памет за 

данни и 128 байта за регистри със специално предназначение. Горните 

128 байта се адресират индиректно. Изполват се 4 регистрови банки, 128 

адресируеми бита, а стекът е разположен във вътршната памет за данни. 

R8032TTE използва хардуерни умножители, за да се ускорят 

изчисленията. Може да извърши 1 инструкция за умножение за 1 

машинен цикъл. 

PicoBlaze Emulated 8051 е софтуерно съвместим контролер (включва 

сериен порт и 

таймери).

Emulated 

8051 

- 77 - 

Таблица 1. Описание на по-известни soft 8051 съвместими IP ядра 

Въпреки, че комерсиалните IP-ядра предлагат много добра производителност тяхната 

цена в висока. Повечето се преглагат в затворена EDIF форма, а в случаите когато се 

предоставя VHDL или Verilog RTL код цената може да достигне до няколко десетки 

хиляди долара. Затова е наложително да се търси некомерсиално ядро. Същесвтуват 

добри разработки като Dalton Project [19] и e8051 [20]. Трябва да отбележим, че е8051 е 

комерсиален продукт, на базата на който са създадени много високопроизводителни 

деривати на 8051 (например Dallas DS80C320), но съществува и ограничена версия за 

свободно позване. Dalton проектът, предлага много добър набор от тестови програми. И 

двете ядра обаче не са особено подходящи за реализация на система-въху-чип за работа 

в реално време. 

В [21] e описан 8051 съвместим модел MC8051 (фиг.2)., разработка на фирма 

Oregano Systems и Техническият Университет - Виена, предлаган безплатно под GNU 

LGPL лиценз. Редица автори са избрали именно това ядро за основа на техните 

проекти. Подходяшо е за изграждане както на FPGA системи, така и за ASIC. В [22] на 

базата на MC8051 е проведено изследване за имплементация на ядрото чрез 

STMicroelectronics CORELIB8DLL_HCMOS8D VLSI CMOS 0.18 micron стандартни 

клетки в ASIC, а и по отношение на комсумацията на чипа [23]. От направената 

литературна справка MC8051 се оказва най-подходящо за използване като основа за 

създаване на система-върху-чип за реално време на базата на програмируема логика. 

Предимствата се състоят основно във възможността за оптимизация на наборът от инструкции 

с цел по-ефективно изпълнение на определени команди съобразени с особеностите 

на реално-времевите процеси по подобие на [24] и добавяне на специализирани 

функционални блокове. В [24] са сравнени резултатите от изпълнението на специално 

създаденият тест за определяне на производителнотта на реално-времеви системи - 

Rhealstone. В тестът са използвани няколко имплементации - базов MC8051 и MC8051 

с добавени нови инструкции (ART8051), и двете под управлението на софтуерна RTOS. 

Получените резултати са ползва на модифицираната версия. В [25] MC8051 се въвежда 

нов режим на работа в реално време на timer/counter - Mode 0: 13-bit timer/counter and 

real-time counter. 

Дизайнът на MC8051 е напълно синхронен, позволявайки значително по-добра 

производителност в сравнение с оригиналното 8051 ядро - Average Performance Gain: 

8,405405405. В MC8051 има възможност за избор на различни модули, като например 

брой на таймерите [21] само със смяната на една константа в RTL кода, което е много 

важно предвид крайния капацитет на използваният FPGA чип (4320 клетки). На фигура 

3 са показа резултатите от имплементацията на MC8051 ядрото в Xilinx Sparta-3 

XC3S200 FPGA. Използван е Xilinx ISE WebPACK 8.1.02i. 


Фиг. 2 Блокова схема на MC8051 

- 78 - 

Selected Device : 3s200ft256-4 

========================================== 

Number of Slices: 1749 out of 1920 91% 

Number of Slice Flip Flops: 536 out of 3840 13% 

Number of 4 input LUTs: 3104 out of 3840 

80% 

Number of bonded IOBs: 74 out of 173 42% 

IOB Flip Flops: 69 

Number of MULT18X18s: 1 out of 12 8% 

Number of GCLKs: 1 out of 8 12% 

========================================== 

Timing Summary: Speed Grade: -4 

Minimum period: 74.925ns (Maximum Frequency: 

13.347MHz) 

Minimum input arrival time before clock: 70.146ns 

Maximum output required time after clock: 65.211ns 

Maximum combinational path delay: 60.433ns 

========================================== 

Фиг. 3 Резултати от 

имплементацията в FPGA 

При реализацията на проекта всичкинеобходими за микроконтролера памети (IRAM, 

ROM, SFR) са имплементирани във вътрешната за FPGA BlockRAM. За целта се 

използват примитивите на Spartan-3 RAMB16_S9. Добавен е един блок SIU – serial 

interface unit, също и специалните инструкции за умножение и делене MUL и DIV. 

Изплозва се един от вградените в FPGA 12 хардуерни умножители, както се вижда от 

репорта, което ускорява значително операциите свързани с умножение/делене. В 

проекта са реализирани всичките 4 8-битови В/И порта. Прави впечатление, че се 

заемат почти всички ресурси на FPGA, може да ги редуцираме като не се задават 

всички 32 В/И пина, а само част от тях. Проектът е на базата на MC8051 вресия 1.4 от 

2002г. 

Установена e оптимизация по площ, но въпреки това се постига много добра 

тактова честота от около 13MHz. При реалните тестове на ядрото се забелязват 

проблеми при обработката на прекъсвания, изразяващи се в непредвидимо изпълнение 

при връщане от прекъсване – инструкцията RETI. Този проблем е успешно решен във 

версия 1.5 на ядрото. Тъй като MC8051 е с йерархичен дизайн, лесно може да се добави 

обслужване на потребителски функционални блокове, като се дефинират нови SFR 

регистри в модула i_control_mem. Това ще позволи директна адресация към 

специализианата периферия. Описанието на нови инструкции се прави в модулите 

i_control_fsm и i_control_mem, съответно за определяне на функциите на инструкцията 

и нейното декодиране. При една по-финна оптимизация и максимално използване на 

примитивите на Spartan-3 FPGA може да се постигне много добра производителност, 

до 20MHz тактова честота, инструкции изпълнявани за един цикъл, хардуерно 

подпомагане на операции по умножение/делене и други. Това ни дава възможност 

успешно да използваме ядрото, като основа за система-върху-чип платформа за работа 

в реално време, особено ако се добави хардуерен ускорител за RTOS под формата на 

специализирана периферия. 


Можем да обобщим, че „вграждането” на soft-ядро в FPGA и изграденият на 

негова база микроконтролер има редица предимства пред традиционния такъв със 

сходни функции – най-важното за работа в реално време е напълно синхронният дизайн 

на микроконтролера и периферията. Друго предимство е възможността за реализиране

- 79 - 

на собствени инструкции от разработчика (потербителя). Той може да извърши 

предварително програмиране и да определи в потока от команди, изпълнявани от 

процесора, кой са най-често срешаните. По такъв начин тези инсртукции могат да се 

групират в една изпълнявана апаратно, като производителността на процесора за 

определен вид задачи ще нарастне, а програмирането му ще се облекчи. 

Допълнителните (специални) потебителски инструкции могат да се изпълняват от АЛУ 

или в допълнителен изчислителен блок свързан към АЛУ, например бързо 

преобразувание на Фурие FFT. Последно е възможността за надграждане на контролера 

със нови функционални блокове, като техния брой и предназначение е ограничен 

единствено от наличните ресурси на FPGA. 


1. А. Десев, Н. Шопов, О. Мариносян. Настояще и пазарни тенденции при 8-битовите 

микроконтролери, Научна конференция с междунардоно участие „Храни, наука и 

технологии”, УХТ – Пловдив, 2006. 

2. Иосиф Каршенбойм. Микропроцессор своими руками, Компоненты и технологии, 

№ 6’2002 

3. Choosing an Intellectual Property Core., MIPS Technologies, Inc., 2002. 

4. Daniel Mattisson, Marcus Christensson. Evaluation of synthesizable CPU cores, Master 

Thesis, CHALMERS UNIVERSITY OF TECHNOLOGY, Gothenburg, 2004. 

5. Gary Cheng-Yu Wang. Automated Reuse of Embedded Controllers, University of 

Auckland, 2004. 

6. C. Piguet. Reconfigurable Microcontrollers, CSEM Centre Suisse d’Electronique et de 

Microtechnique Neuchâtel, Switzerland, 2004. 

7. Ken Chapman. Creating Embedded Microcontrollers, Xilinx Co. UK, 2003. 

8. Jan Gray. Designing a Simple FPGA-Optimized RISC CPU and System-on-a-Chip, Gray 

Research LLC, 2000. 

9. Yap Zi He. Building A RISC Microcontroller in an FPGA, Universiti Teknologi Malaysia, 

2002. 

10. D. SulÍk. Design of a RISC Microcontroller Core in 48 Hours, Slovak University of 

Technology, 2003. 

11. Tim B¨oscke. A minimal 8Bit CPU in a 32 Macrocell CLPD, 2002. 

12. Matten Tariq, Meeshal Kausar. 8 Bit RISC Mmicroprocessor - Written in Verilog and 

implemented on FPGA, AIR University, 2005. 

13. Diogo José Costa Alves, Tiago Sampaio Lins. A 8051 μC FUNCTIONAL RTL 

DESCRIPTION USING SYSTEMC FOR PLATFORM BASED DESIGN, Centro de 

Informática, Universidad e Federal de Pernambuco, 2003. 

14. Guillermo Jaquenod, Oscar Bria. Adapting an IP MC6805 core for multiprocessing and 

multitasking, Fac. Ingeneria, UNCBA, Argentina, 2003. 

15. B.D. Theelen, A.C. Verschueren, V.V. Reyes. Scalable single-chip multi-processor 

architecture with on-chip RTOS kernel, Journal of Systems Architecture 49 (2003) 619–639. 

16. В.Л.Лепеха, А.М.Сергиенко. VHDL -модель ультрабыстрого процессора 8051. 

17. R. Cayssials, E. Ferro and O. Alimenti. uRT51: An Embedded Real-Time processor 

implemented on FPGA devices, Universidad Nacional del Sur, Bahía Blanca – Argentina. 

18. Author: Amit Dhir, Saeid Mousavi. High-performance Spartan-II 8-bit Microcontroller 

Solution, Xilinx, WP114 v1.0, 2000. 

19. Dalton Project - Synthesizable VHDL Model of 8051. 

20. www.e8051.net 

21. Oregano Systems, MC8051 IP core - Synthesizeable VHDL Microcontroller. 


- 80 - 

22. M. Schutti, M. Pfaff, R. Hagelauer. VHDL Design of Embedded Processor Cores: the 

Industry-Standard Microcontroller 8051 and 68HC11, ASIC Conference 1998. Proceedings. 

Eleventh Annual IEEE International, 13 – 16 Sept. 1998, Pages: 265 – 269. 

23. Roland Holler. Entwurf eines 8051-Microcontroller IP-Blocks, Diplomarbeit, Technische 

Universitat Wien, 1999. 

24. Lee L.C., Link H. Embedded Processor Core Design to Support Real-Time Operating 

Systems. Department of Electrical and Computer Engineering, University of Auckland, New 

Zealand, 2003. 

25. Cakiroglu M., Ozcerit A.T., Cetin O. , Eskikurt H.I. Integration of Real-time counter 

unit into a microcontrller through reconfiguration, Sakarya University, Tech. Edu. Fac. 

Adapazari, Turkey. 

Atanas Desev, PhD student 

Department of Computer system and technologies 

University of Food Technologie, Plovdiv 

26, Maritza blvd., 

4000 Plovdiv 

BULGARIA 

E-mail: desev@hifii-plovdiv.acad.bg 

Atanas Desev, PhD student 




4000 Plovdiv 

BULGARIA 

E-mail: desev@hifii-plovdiv.acad.bg

- 81 - 




BULGARIA 

METHODS AND RESOUSCES FOR HARDWARE RTOS 

ACCELERATION 

ATANAS DESEV 

Abstract. We are examined basic methods and resources for hardware RTOS 

acceleration. There are brief descriptions of methods including coprocessor 

approach, instruction set optimization and partial and full accelerators. There is 

proposal of HW-RTOS-8/4 conceptual model, facilitate basic functions like 

process scheduling, interprocess synchronization, semaphores and timers. 

Behavior test and results from synthesis on Spartan-3 FPGA was done. 

МЕТОДИ И СРЕДСТВА ЗА ХАРДУЕРНО УСКОРЕНИЕ НА 

ОПЕРАЦИОННИ СИСТЕМИ ЗА РЕАЛНО ВРЕМЕ 


С нарастващият в световен мащаб брой на „вградените” микропроцесорни 

устройства се забелязва и усложняване на обслужващият системен софтуер и фърмуер. 

Тук централно място заема RTOS – операционната система за реално-време, тъй като 

пред „вградените” системи много често се поставя условие за функциониране в режим 

на реално време, например широко използваният кабелен модем Motorola SB5100 е под 

управлението на VxWorks RTOS с вграден web сървър. Операционната система 

предоставя ниво на абстракция от хардуера и набор от системни примитиви, както и 

API програмен интерфейс, използван от приложните програмисти. Нарастването по 

обем и сложност налага по-интензивно използване на централния процесор, което от 

своя страна води до редуцуране на процесорните ресурси, предоставяни на приложните 

програми. „Натоварването” при използването на RTOS варира в широки граници, като 

при системите от долния пазарен сегмент на 8/16 – битови контролери и процесори е 

по-ниско до 4-5%, защото се обслужва само многозадачния режим на работа и 

планирането на процесите, докато при 32/64 – битовите и DSP процесори може да 

достигне и до 30% поради обслужване на допълнителна периферия, мрежови стекове, 

файлови системи и други. 

В настоящата статия се разглеждат някои от най-използваните подходи за 

намаляване на „натоварването” на процесора при използването на RTOS. За целта може 

да направим условно разделение - на средства и на методи. В т.2 и т.3 се разглеждат 

съответно средствата и методите, в т.4 се предлага концептуален модел на ускорител за 

4 процеса при 8-битов контролер, а в т.5 са направени основните изводи и са 

представени предизвикателствата пред реализацията. 


- 82 - 

2. Описание на средствата 

Под средства разбираме елементната база – хардуерът, който се използва в 

системата за реално време. Подобно на [1] можем условно да отличим три групи 

хардуер. На първо място са т. нар. процесори с разширени възможности – advanced 

embedded processors – това са устройства от горния пазарен сегмент, които притежават 

характеристики и възможности нетипични за масовите микроконтролери и процесори: 

мултискаларни архитектури – DEC ALPHA 21164, PowerPC 604, MIPS R1000, 

UltraSPARC; Intel HyperThreading – един физически процесор се разглежда като два 

логически, за ОС и програмиста те са два реални процесора; Intel и AMD DualCore 

процесори – два физически процесора в един корпус; The Imagination Technologies 

META процесор – RISCP/DSP функции, предоставя се под формата на IP core за 

вграждане в SoC платформи; TI TMS320C80 MVP – едночипови многоядрени DSP 

процесори; Infenion TriCore – hardcore IP, CarCore IP ядро – базирано на TriCore, 

позволява изпълнение на една „hard realtime” и няколко „soft realtime” нишки. 

Поради високата цена и консумирана мощност на “advanced” процесорите, често 

в практиката се използва програмируема логика FPGA/CPLD за имплементиране на 

интензивни изчисления или специфични функции. Наблюдава се тенденция за все пошироко 

навлизане на FPGA в областта на вградените системи, като главен фактор е 

понижената им цена, намалена консумация, както и възможностите за повторно 

реконфигуриране. Използването на „готови ядра” - IP cores пък може значително да 

намали времето за разработка на даден проект, както и цената му. Наред с навлизането 

на термини като „хардуерен/софтуерен кодизайн” и „системи-върху-чип”, както е 

отбелязано в [2,3] се появява и нова група от устройства, обединяваща предимствата на 

традиционния подход и иновациите при реализиране на даден продукт ориентиран към 

пазара на вградените устройства. Тази група може да отнесем отново към FPGA 

поради наличието на такава логика в чипа – това са конфигуруемите систми-върхучип 

(CPU/DSP + FPGA) CSoC. Най-често при тях се използва soft-core програмируем 

процесор, изпълняващ RTOS. Обикновено, наборът от инструкциите на процесора 

може да се разширява с нови дефинирани от разработчика, като по този начин за 

постигането на дадена функция се редуцира комплексната последователност от 

инструкции до една инструкция реализирана на „хардуерно” ниво. Заедно с 

използването на soft-core процесори се вграждат и hard-core процесорни елементи (ПЕ), 

например Xilinx Virtex Pro съдържа до четири PowerPC 405 вградени ПЕ, а Altera 

Exalibur е с ARM7 ПЕ. Към класа на по-малките можем да отбележим известните Atmel 

AT94K с ядро AVR, Triscend E5 с 8032, както и Cypress CsoC. FPGA заедно с CSoC 

формират втората група от елементна база за хардуерно ускорение. 

В трета група отделяме т.нар. процесори за реално време. Това са ПЕ специално 

създадени и съобразени с особеностите на функционирането в режим на реално време. 

Най-известният представител на тази група е Inmos Transputer T800 и Т9000 – RISC 

процесор широко използван при изграждане на паралелни изчислителни системи, 

разполагащ с инкорпориран хардуерен диспечер, използващ специализиран паралелен 

eзик OCCAM, но вече спрян от производство. Неговият наследник е SGS-Thomson 

ST20 с ядро С4, което управлява две процесни опашки – нископриоритетна опашка, 

която използва преемтивно (с изтласкване) планиране чрез „time slicing” и високо 

приоритетна опашка, която използва кооперативно планиране. В [4] се разглеждат 

влиянието от използването на кеш, предсказване, MMU и DRAM като не се препоръчва 

използването им в процесори за “предвидимо” изпълнение. ARM966E-S представлява 

разновидност на ARM9 ядро и се предлага под формата на „hard realtime” макроклетка, 

като се постига минимално закъснение при прекъсване „interrupt latency”. Липсва MMU 

както и кеш памет, вместо нея се използва SRAM за инструкции/данни. Във Виенският

- 83 - 

университет по технологии е създаден SPEAR (scalable processor for embedded 

applications in realtime enviroment), на базата на SPEAR Готфрид Фуш създава LANCE – 

суперскаларен 16-битов микроконтролер за реално време. В университета Brigham 

Young – САЩ, Доран Уайлд и екип разработват RTP – 16-битов процесор за реално 

време. Проектът цели създаване на лесна за употреба система с бързо контекстно 

превключване, възможност за междупроцесна и междупроцесорна комуникация и 

RTOS имплементирани в FPGA. Основните характеристики са мултипроцесорна 

система (1-16), до 16 процеса в 1 процесор, всеки процесор има собствено В/И 

пространство с до 256 порта. 16-битовата В/И шина е свързана към използваните от 

процесора периферни устройства. Достъпът до периферията, която се използва от два 

или повече процесора, трябва да бъде синхронизиран. Това се постига чрез използване 

на системни „ресурси” – мутекси, семафори, таймери и други. Предложено е 

иновативно архитектурно решение наречено TRM – task resources matrix. 

3. Описание на методите 

В тази точка се прави кратък обзор на трите основни подхода, при които се 

осъществява хардуерно ускорение на RTOS. Тези методи включват използване на 

копроцесор, оптимизиран набор от инструкции, както и частични и пълни хардуерни 

ускорители. 

3.1 Метод с копроцесор. 

Исторически погледнато това е първият метод, използван за хардуерно ускорение. 

Идеята е копроцесора да обслужва RTOS, освобождавайки главния процесор само за 

изпълнение на потребителските програми. Съществуват множество разработки с 

подобен подход [1,2]. Андрю Мортън и екип от университета Waterloo предлагат 

“Realtime kernel support for coprocessors” – използват се cs1 Kernel и EDF Scheduler. 

Подобен проект наречен „ARPA – An Open Source systems-on-chip for Realtime 

Applications” е разработен от екип в университета Aweiro. В [5] се представя идеята за 

„task-scheduler” копроцесор. В предложения проект се ползва външен 8032 процесор, в 

ролята на копроцесор управляващ планирането на процесите, които могат да бъдат до 

32. Всички прекъсвания са достъпни за копроцесора, като по този начин се гарантира 

правилната работа при планирането. Копроцесорът е реализиран на отделна платка и се 

свързва към главния чрез системната шина. Подобна на тази разработка е [7], но се 

отнася за вграден „on-chip” програмируем В/И процесор. Използва се TriCore TC10GP 

ядро и MicroC/OS-II RTOS, която се изпълнява на PCP (peripheral control processor), 

докато диспечеризацията се извършва от главния процесор. Комуникацията между 

процесорите се извършва чрез прекъсвания и се постига значително намаляване на 

прекъсванията при планиране и закъсненията при обработката на подпрограмите за 

обслужване на прекъсванията ISR. 

3.2 Оптимизиране на наборът от инструкции. 

Съществуват два начина на изпълнение – към стандартното ПЕ на базата на 

допълнителна програмируема логика се реализират новите инструкции (Altera Exalibur, 

Triscend E5/7) или целият процесор се имплементира в FPGA (XSOC, gr4000, 

MircoBlaze). Появяват се т.нар. FIP – flexible instruction processor – Shay Ping Seng 

предлага рамка за разработка включваща „processor templates” или шаблони от стекбазирани 

и регистър-базирани процесори. Тази техника позволява подобряване на 

производителността и функционалността чрез FIP-оптимизирани компилатори и 

технико-специфични оптимизации като техники за ефективна FPGA реализция (NIOS, 

PicoBlaze). Предлагат се и методики за избор на ISA, като се вземат предвид както 

производителността, така и размера на полученото ядро, това налага компромис при 

избора на броя и на вида на инструкциите. Редица автори разглеждат ASIP – application 


- 84 - 

specific instruction processor, за целта те използват „soft core” процесори като Altera 

NIOS, Xilinx MicroBlaze, OpenRISC, Tensilica Xtensa и други, разширявайки 

съществуващия набор със собствени инструкции. В [1,3] се предлага реализация на 

нови инструкции реализиращи части от RTOS ядро на MicroC/OS-II. Използвани са 

процесорите Altera NIOS и OpenRISC, като допълнителни инструкции са поддържащи 

планирането на процесите, управлението на събитията и част от времевите фунцкии. 

Измерените резултати на базата на Rhealstone и Dhrystone тестове, показват подобрения 

съответно с 10-35% и около 13%. 

3.3 Частитни и пълни ускорители 

В тази точка са изложени разработки, които пренасят функциите на една RTOS от 

софтуерна към хардуерна реализация. В зависимост от това, кои от тези функции са 

имплементират правим и разделение на частични и пълни ускорители. Разбира се 

съществуват и такива, който не е удачно да бъдат реализирани хардуерно или просто не 

е възможно, например обслужване на файлова система. Предимствата, които тези 

ускорители предоставят са значително намаляване на „натоварването” на процесора по 

обслужване на RTOS и възможността да се използват по-сложни и eфективни 

алгоритми за приложните процеси. 

Частичните ускорители са ориентирани към строго определена функционална 

част от RTOS. В литература са описани множвество разработки за решаване на 

безизходни ситуации, защитни механизми, обслужвания на прекъсвания, ускорение на 

контекстно превключване и други. В [8] се описва копроцесор за ускорение на 

планирането на процесите. Възмножно е използването на множество дисциплнини на 

планиране и комбинации между тях. Разработката е ориентирана към мултипроцесорни 

системи и дава много добри резултати. Намаляване на „натоварването” между вградени 

микроконтролери с до 30 пъти благодарение на хардуерно подпомагане на 

междупроцесорната комуникцая IPC е описано в [9]. В [10] се използва външен FPGA, 

които имплементира списък за 32 процеса, организирани по времеви приоритети. 

Предлага се прецизна резолюция от 100µs и няколко режима на прекъсванията. В други 

няколко разработки се предлага концепцията „нанопроцесор – ускорител”. Идеята е да 

се използва „нанопроцесор” в ролята на малък ускорител за различни фунции като 

реконфигуруема логика, В/И контролер и диспечер. Начело на тази концепция стои 

екитът на Брус Джейкъб от университета на Мериленд, САЩ. Всички разработки се 

базират на симулатор SimBed за процесор Motorola Mcore и MicroC/OS-II RTOS v2.3. 

Същият екип разбработва и „Hardware support for RTOS – Realtime Тask Мanager” 

изпълняващ ролята на диспечер, управление на събитията и времевите функции. 

Последният им проект наречен „Architectural support for embedded operating systems – 

CCAM configurable content-adressable memory” е насочен към по-комплексните системи. 

Винсент Муни от Технологическият университет Джорджия – САЩ е един пионерите в 

областта и заедно с екипа си имат множство разработки и нововъведения, по значимите 

от които са описани в [11,12,13]. В [11] се предлага малък, прост и ефективен 

хардуерен модул подпомагащ синхронизацията в мултипроцесорни системи-върхучипа. 

Подобен е модула описан в [12], но е ориентиран към управлението на паметта 

SoCDMMU, в [13] се предлага откриване на безизходни ситуации SoCDDU (Deadlock 

Detection Unit). Съществува и модул за разрешаване на критични секции. Всички тези 

модули по-късно за обеденини в една интегрирна среда за разработка δ-framework, 

която автоматично генерира различен набор от HW/SW RTOS. 

Пълните ускорители обединяват няколко RTOS фунцкии [17]. Най-известните 

разработки пренадлежат на шведа Ленард Линд, чиито академични проекти [14, 15] покъсно 

придибиват комерсиален вид под формата на IP core - Sierra HW-RTOS [16].

Системна архитектура - концепция 

System-on-Chip 

Тест програми (HW) Тест програми (SW) 

BLOCK 

RAM/ROM 

Xilinx Spartan-3 

FPGA 

HW-RTOS-8 

Oregano 8bit 

MC8051 IP core 

Monitor 

Модул 

- 85 - 

4. Концептуален модел на ускорител за 4 процеса при 8-битов контролер 

HW-RTOS-8/4 

task_create 

Ready 

Готов 

Running 

Изпълняван 

Dormаnt 

task_delete 

task_start() 

sem_release() 

undelay() 

Block 

Блокиран 

sem_take() 

task_block() 

delay() 

Вътрешна архитектура 

на HW -RTOS-8 

Scheduler 

Task 

Sem 

Timer 

Control 

Фиг.1 Концептуален модел на ускорител за 4 процеса при 8-битов контролер HW-RTOS-8/4 

HW-RTOS-8/4 се състои от шест функционални модула, всички използват общ тактов 

сигнал – фигура 1. Той изпълнява ролята на RTOS, т.е. това е хардуерен ускорител имплементиращ 

основните функции като управление и планиране на процесите, комуникация 

и синхронизация, семафори, таймери и т.н. BLOCK RAM/ROM се използва за 

съхранение на няколко тестови програми. В същото време се съхранява малко ядро, което 

обслужва HW-RTOS-8/4, т.е. предоставя системни извиквания. Модулът Monitor реализира 

мониторинг на поведението на цялата система, но не е задължителен. Използват 

се две шини: Address Bus – по нея CPU адресира всички вътрешни регистри и Data 

Bus, по която се извеждат резултатите от/за HW-RTOS-8/4. Когато възникне системно 

извикване от приложна задача, кода на функцията и параметрите на системното извикване 

се предават на микроядрото, то ги праща до HW-RTOS-8/4, те се декодират, изпълнява 

вътрешна операция и се връща съответния резултат на микроядрото, което от 

своя страна го предава на приложението. 

• Scheduler – планиране на процесите, то е приоритетно с изместване. Максималният 

брой процеси е 4, всеки има присвоен приоритет от 0 до 3. По-високо приоритетен 

процес може да измести по–ниско приоритетен. При процеси с еднакъв 

приоритет се използва цикличен механизъм Round-Robin. 

• Task – управление на процесите, за всеки процес се създава PCB – блок за управление 

на процеса, при унищожаването на процеса автоматично се разрушава 

тази структура. Task модулът е реализиран като state machine. Съществуват 4 

състояния определящи текущия статус на процеса и един процес, който се използва 

за декодиране на инструкцията. 

• Timer – управление на времеви функции, delay, wait и т.н. Това всъщност е един 

брояч. След като изтече интервала (модула на броене) се сменя сигнала Delayed, 

който е свързан към Task модула. Тогава възниква смяна на състоянието. 

• Sem – синхронизация, поддържат се 8 двоични семафори, използвани за синхронизация, 

когато е нужно даден ресурс на системата да се споделя между няколко 

процеса. На практика семафорите представляват FIFO опашки. Всички блокирани 

процеси, по точно техните идентификатори ID, се вписват в опашката и когато 

семафорът се освободи всички ID на блокираните роцеси се изчитат като дадения 

процес се “събужда” и участва отново в планирането. 


- 86 - 

• Scheduler (диспечер) контролира целия планиращ механизъм в HW-RTOS-8/4. 

Той може да функционира с 4 процеса на 4 приоритети нива. Обикновено броят 

процеси се създава при системна инициализация. Освен тези процеси трябва да 

се създаде и т.н. idle task. Това е процес на престой, т.е. той се изпълнява когато 

няма никакъв друг процес за изпълнение в състояние готов. Това се налага поради 

факта, че ако не съществува такъв idle task, поведението на системата става 

непредвидимо при положение, че няма готов процес за изпълнение. Idle task не 

трябва да прави никакви системни обръщения към HW-RTOS-8/4. Възможно е 

динамично създаване и унищожаване на процеси по време на изпълнение 

(runtime). Когато се създаде процес, той се инициализира в определено състояние 

(blocked или ready). Процесът трябва да има и приоритет, който също се 

присвоява когато се създава процеса. Също така трябва да се присвои и уникален 

идентификационен номер ID, за да може HW-RTOS-8/4 да различава отделните 

процеси. Процесът може да бъде в едно от следните 4 състояния: 

• Изпълняван (running), Готов (ready), Блокиран (blocked), Спящ (dormant). 

Диспечерът гарантира, че най-високо приоритетният процес измежду готовите ще се 

изпълнява винаги. Когато изпълнява даден процес съществуват няколко събития, които 

могат да променят състоянието на процеса, а именно: 1. Процесът издава доброволно 

заявка за превключване – task_yield; 2. Процесът се опитва да заяви семафор, който вече 

е бил зает и така преминава в състояние блокиран; 3. По-високо приоритетен процес 

преминава в състояние готов и по този начин измества текущо изпълнявания процес, 

който отива отново в опашката на готовите процеси. 

• Control - контролен модул, този модул контролира всички обръщения от страна 

на CPU към вътрешните регистри на HW-RTOS-8/4. Функционалността му се 

свежда до декодиране на адресите и генериране на контролни сигнали към останалите 

модули. 

Предлаганият модел е тестван на поведенческо ниво и имплементиран в FPGA 

устройство Xilinx Spartan-3 200. На фигура 2 е показана експерименталната платка 

Фиф. 2 Експерименталната платка 

Number of Slices 363 out of 1920 18% 

Number of slices Flip Flops 346 out of 3840 9% 

Number of 4 input LUTs 654 out of 3840 17% 

Number of bounded IOBs 30 out of 173 17% 

Number of BRAMs 4 out of 12 33% 

Number of GCLKs 1 out of 8 12% 

Minumim peridod - 8.653ns Maximum Frequency - 115.573 MHz 

Minimum input arrival time before clock: 10.220ns Maximum output required time after clock: 6.306ns

- 87 - 


Нарастващата сложност при днешните вградени системи с микропроцесорно управление 

налагат увеличеното използване на реално-времеви операционни системи. За 

съжаление те притежават значителни ограничения по отношение на производителността, 

особено при 8-битови платформи. Чрез предлаганите методи за хардуерно 

ускорение се цели значително минимизиране на основните недостатъци, асоциирани с 

реално-времевите операционни системи. Въпреки, че както се отбелязва при системите 

от горния пазарен сегмент процентът на натоварване на процесора вследстие от 

използване на RTOS е по-висок, то тези системи разполагат с достатъчен изчислителен 

ресурс, за да оперират правилно и стабилно и по традиционния чисто софтуерен 

подход. При 8/16-битовите устройства, използването на хардуерен RTOS ускорител 

може значително на облекчи работата на процесора, чиито ресурси да бъдат изцяло 

ориентирани към изпълнението на потребителските програми. 


1. M. Sindhwani, T.F. Oliver. RTOS acceleration techniques – review and challenges, 

Nanyang Technological University, Singapoure, 2002. 

2. Neil Bergmann, Peter Waldeck. A catalog of hardware acceleration techniques for realtime 

reconfigurable system on chip, University of Queensland, Australia, 2003. 

3. Timothy F. Oliver, Siraj Mohammed. Accelerating an embedded RTOS in a SOPC 

platform, Nanyang Technological University, Singapoure, 2003. 

4. Christoph Berg. Requiments for and design of a processor with predictable timing, 2002. 

5. Cooling J. and Tweedale P. Task scheduler co-processor for hard real-time systems 

Micro-processors and Microsystems, 20 (1997), pp. 553 -566. 

6. Ramakrishnan N. Towards an independwnt on-chip RTOS manager. Honors Year Project 

Report, Nanyang University, 2002 

7. Schauser K E, Scheiman C. Exploiting the capabilities of communications co-processors, 

Proceedings of the 10th International Parallel Processing Symposium, pp. 109-115, 1996. 

8. Burleson W, Ko J, Niehaus D. The spring scheduling coprocessor: a scheduling 

accelerator, IEEE Transactions on VLSI Systems, Volume: 7 Issue: 1 pp. 38-47, 1999. 

9. Srinivasan S, Stewart D B. High speed hardware-assisted real-time interprocess 

communication for embedded microcontrollers, 21st IEEE Real-Time Systems Symposium, 

pp.269 - 279., 2000 

10. Parisoto A, Souza A Jr. F-Timer: dedicated FPGA to real-time systems design support, 

Proceedings of the Ninth Euromicro Workshop on Real-Time System, 1997, pp. 35-40. 

11. Saglam B E, Mooney V J III. System-on-a-chip processor synchronization support in 

hardware, Design Automation and Test Conference and Exhibition in Europe, 2001., pp. 633 

12. Shalan M, Mooney V J III. Hard-ware support for real-time embedded multiprocessor 

system-on-a-chip memory manage-ment, Tenth International Symposium on 

Hardware/Software Codesign, pp. 79-84, 2002. 

13. Shiu P H, Yudong Tan, Mooney V J III. A novel parallel deadlock detection algorithm 

and architecture Ninth International Symposium on Hardware/Software Codesign, 2001. 

14. Lindh L. Fastchart - a fast time deterministic CPU and hardware based real-time-kernel 

Workshop on Real Time Systems, 1991. Euromicro '91, pp. 36-40. 

15. Lindh L. FASTHARD - A Fast Time Deterministic HARDware Based Real-time Kernel, 

Fourth Euromicro workshop on RealTime Systems, pp. 21-25, 1992 


- 88 - 

16. Realfast. Realfast Sierra Operating System Data Sheet, 2003. 

17. Nakano T, Komatsudaira Y, Shiomi A, Imai M. VLSI implementation of a real-time 

operating system, Asia and South Pacific Design Automation Conference, 1997, pp. 679-680 




4000 Plovdiv 

BULGARIA 

E-mail: desev@hifii-plovdiv.acad.bg

- 89 - 




BULGARIA 

IMPORTANT MILESTONES IN DEVELOPMENT OF 

ANALYTICAL DATA PROCESSING THEORY 

VLADIMIR VALOV, IVANKA VALOVA 

Abstract. This paper presents most important milestones in development of analytical 

data processing theory. There are discussed achieved applied results, as well as existing 

drawbacks. In the paper are highlighted some interested issues for purposes of additional 

scientific studies, oriented towards software applications. 

Key words: OLAP, APL, software applications 

ПО-ВАЖНИ ЕТАПИ В РАЗВИТИЕТО НА ТЕОРИЯТА ЗА 

АНАЛИТИЧНА ОБРАБОТКА НА ДАННИ 


Стимулиран от увеличаващото се търсене на интегрирана бизнес 

информация, пазарът на OLAP (On-Line Analytical Processing-Аналитична обработка на 

данни в реално време) продуктите се разви бързо през последните години. Нови 

продукти и нови версии на вече съществуващи продукти следващи последните 

тенденции разширяват непрекъснато разнообразието от предлагани инструменти.От 

гледна точка на науката и на концепцията за база данни, съхраняването и обработката 

на данни в многомерни модели е новаторска дисциплина със специални нужди, дори 

ако вече установените концепции могат да се използват в един нов контекст. 

Необходимо е да бъдат конкретизирани съществуващите концепции, за да се 

осъществи трансфера на знания и да бъдат разбрани бъдещите изследвания и нужди на 

разработките. Следователно е необходимо знание относно постигнатите резултати и 

относно техниките и концепциите реализирани в софтуерните продукти. Тази статия 

проследява по-важните етапи в развитието на теорията за аналитична обработка на 

данни. Представени са постигнатите приложни резултати, както и съществуващи 

недостатъци. Изведени са интересни теми за целите на допълнително научно 

изследване ориентирано към софтуерните приложения 

2. Първите идеи за разработване на многомерни модели - APL 

Идеята за обработка и анализ на многомерни модели съществува от 1962 год. 

След публикацията на книгата на Кен Айверсън “Език за програмиране”. Първото 

компютърно приложение на APL езика се използва от IBM и датира от края на 60-те 

години. Операторите са гръцки символи и програмите са толкова кратки, че e трудно да 

се предви какво може да направи една APL програма. Станал известен като “Език само 

за писане –Write Only Language (WOL)”, тъй като e по-лесно да се пренапише 

програмата, отколкото да се поправи. Гръцките символи на APL имали нужда от 


- 90 - 

специални екрани, клавиатури и принтери. Това било в дните на голямите по размер 

компютри с ниска мощ и приложенията, които използвали APL се обработвали бавно и 

били много скъпи. APL имал незаслужената репутация на гладен за памет, тъй като 

масивите били обработвани в RAM. Въпреки своите недостатъци APL е използван в 

много бизнес приложения от 70-те и 80-те години, които имат подобни функции на 

днешните OLAP системи. IBM развива цяла операционна система за APL наричана 

VSPC. Въпреки, че хардуерните проблеми били разрешими APL е прекалено елитарен 

за да привлече повече разработчици. Езикът се появява при персоналните компютри 

през 80-те години (и все още се използва, понякога в преработена форма, наричана “J”) 

но престава да има пазарно значение след 80-те години. Възможно е да се програмират 

многомерни приложения, използвайки масиви на други програмни езици [1, 2, 5, 6]. 

APL 

IRI's 

Express 

EPS'-FCS 

Comshare's 

System W 

EPS' 

FCS-Multi 

1962's 1985 1990 1993 1996 2000 

Фиг.1. Развитие на идеята за многомерни модели представена в дати 

4. Развитие на идеите през 70-те години, Express – 1970 

MOLAP 

или 

ROLAP ? 

Oracle купува 

Express 

Gentia 

Arbor's MS-Panorma 

ESSBASE 

Panorama SAP BW 

Planning Codd 

MS 

Sciences' OLAP OLAP 

EPiC 

Софтуерният продукт Express, известен със своя академичен произход се 

създава в началото на 70-те години. С пренаписания си формат и модерна кодова 

система, той се превърна в широко използвано съвременно предложение на OLAP, в 

което първоначалните концепции от 70-те години все още са заложени под 

повърхността му. Дори след 30 години Express остава една от главните OLAP 

технологии. Express използва двуслойна структура на данни (фиг.2). В края на 2000 

година Oracle обяви, че ще вгради възможности на OLAP сървър в Oracle9i, започвайки 

в средата на 2001 година. Oracle9i OLAP Servises включва версия на Express engine, 

наричана аналитичната работна среда, както и нов ROLAP engine.

- 91 - 

Фиг.2 Двуслойна структура от данни съдържаща многомерни модели 

4. По-важни събития и софтуерни продукти през 80-те години 

През 80-те години се появяват нови софтуерни продукти за разработване на 

многомерни модели. В началото на десетилетието се появява Stratagem и в една от 

неговите форми - Acumate е предлаган на пазара до средата на 90-те години. 

Независимо че е прилича на Express се използва малко. По различно време е 

притежаван от Stratagem CA, която по-късно получава два ROLAP продукта, Prodea 

Beacon и Information Advantage DecisionSuite. 

System W на Comshare (1981 год.) е първият продукт с хиперкуб-подход и е 

ориентиран към разработка на финансови приложения от крайния потребител. Въвежда 

много нови концепции, които все още не се използват широко, като например пълни 

не-процедурни правила, многомерно показване на цял екран и редактиране на данни, 

автоматична рекалкулация и (партидна) интеграция на релационни данни. 

Недостатъците на този продукт са необходимост от добър хардуер и по-малко 

възможности за програмиране в сравнение с другите продукти. Продуктът се използва 

на Unix, не се продава и подобрения не са вероятни. 

Друг творчески продукт от началото на 80-те години е Metaphor (1984). 

Насочен към маркетинговите специалисти в компании за потребителски стоки той 

въвежда множество нови концепции, които стават популярни през 90-те години, като 

например: 

• клиент/сървър изчисленията 

• обработка на многомерни модели на релационни данни 

• обработване в група и обектно-ориентиран подход. 

Сандартния PC хардуер не е способен да изпълни всички изисквания на Metaphor и се 

създава специфични за него персонални компютри и мрежова технология. 

През 1985 се създава продукта Command Center на Pilot. Поради ограничената 

мощ на персоналните компютри от 80-те години, той е ориентиран централно към 

сървъра. Command Center вече не се продава, но е въвел много концепции, които могат 

да бъдат разпознати в съвременните OLAP продукти, включително автоматично 

обработване на времеви серии, многомерна клиент/сървър обработка и опростени 

човешки фактори (подходящи за използване на тъч-скрийн и мишка). 

Около средата на 80-те години Sinper е навлязъл в света на електронни таблици 

за многомерни приложения, първоначално със специфични DOS електронни таблици, а 

след това чрез връзка с DOS 1-2-3. Той навлиза в ерата на Windows като превръща 


- 92 - 

(тогава наричащият се) TM/1 продукт в многомерен бек-енд сървър за Excel и 1-2-3. 

Традиционните продавачи на специфични фронт-енд продукти са принудени да 

последват примера и продукти като Express, Holos, Gentia, MineShare, PowerPlay, 

MetaCube и WhiteLight предлагат интегриран достъп за електронни таблици до 

съответните сървъри. 

Около края на 80-те години електронната таблица започва да доминира при 

анализа на данни от крайния потребител. Първата електронна таблица за многомерни 

модели се появява под формата на Compete. В началото се определя като много скъп 

инструмент за обикновените специалисти. Computer Associates (CA) го придобива 

заедно с няколко други продукти за електронни таблици, включително SuperCalc и 

20/20. Главното следствие от придобиването на Compete от CA е рязко намаляване на 

цената, премахване на защитата против копиране и широко рекламиране на продукта. 

Въпреки това той не се превърнал в тенденция, която да бъде повторена и при другите 

OLAP продукти, придобити от CA. През следващите няколко години старият Compete 

все още можел да бъде открит включен в пакети от продукти с голямо намаление на 

цената. По-късно Compete формира основите на версия 5 на SuperCalc на СА, но 

концепциите разработени относно многомерността му не се рекламират. 

В края на 80-те продуктите DOS One-Up на Comshare и по-късно базирания на 

Windows Commander Prism (наричан по-късно Comshare Planning) използват 

концепции, подобни на хост-базираната System W. Продуктът Essbase на Hyperion 

Solution, въпреки че не е директен наследник на System W, е повлиян от неговия 

финансово ориентиран, напълно пре-изчислен подход с хиперкуб. Колкото и иронично 

да е, Comshare впоследствие лицензира Essbase engine (вместо да използва собствени 

разработки) в някои от своите модерни OLAP продукти. 

5. 90-те години- висока динамика и иновации в OLAP технологиите. 

През 1990 година Cognos PowerPlay излиза на пазара (http://www.cognos.com/ ). 

Това е първият OLAP продукт за настолни (desktop) компютри и за Windows. Първите 

десктоп OLAP продукти представят малки кубове, генерирани от големи бази данни, но 

свалени на персоналните компютри за обработка (при мрежовото му внедряване 

кубовете обикновено съществуват на сървъра). Дистрибуторът който предлага и 

инструмент за релационна заявка, и инструмент за анализ на многомерни модели 

(Cognos с Impromptu и PowerPlay) докладва, че вторият е много по-добре приеман от 

крайните потребители, отколкото първия. 

През 1992 Essbase излиза на пазара. Първият добре рекламиран OLAP продукт, 

който се превръща в лидер на пазара за OLAP сървъри през 1997 година. Софтуерният 

продукт притежава патент за своя “метод и апарат за съхраняване и обработване на 

многомерни данни в паметта на компютъра”. Патентът обобщава гореспоменатата 

двуслойна структура до многослойна структура (с цел да се апроксимират липсващите 

данни на различните нива на D-структурата). В допълнение, масиви и В дървета могат 

да бъдат използвани по избор на всяко ниво по начин определен от потребителя. 

Администраторът има способи да повлияе върху структурата на данните, определяйки 

плътните и неплътни D-структури, които изграждат двата слоя. Arbor Essbase предлага 

достъп за писане в софтуера на множеството потребители. Има проблем при 

повикването на транзакциите. 

През 1993 година Код формулира термина OLAР ”Providing OLAP to User- 

Analysts: An IT Mandate- Предоставяне на OLAP на анализаторите на потребителите: 

IT-мандат” и привлича вниманието на много специалисти върху въпросите на 

разработването на многомерни модели. OLAP терминът представлява съкращение на

- 93 - 

“On-Line Analytical Processing” (Аналитична обработка на данни в реално време). 

Изследванията на Код са спонсорирани от компанията Arbor Software. 

Концепцията за многомерния модел на данни, който може да бъде представен в 

релационна база данни е описан от Ралф Кимбал. Концепцията придоби популярност и 

на пазара се появиха софтуерни продукти с ROLAP архитектура. С еволюирането на 

двете технологии започна голям дебат за това коя е по-добрата архитектура за OLAP 

приложения. Всъщност всяка има своите положителни и отрицателни страни. Коя от 

двете е най-добрата зависи от изпълнението, мащабируемостта, използване на 

ресурсите, основните изисквания за отчетите и от вида на данните. 

Първият ROLAP продукт- MicroStrategy DSS Agent излиза на пазара през 1994г. 

Почти цялата обработка на данните се извършва от multi-pass SQL — подходящ подход 

за много голями бази данни. Недостатъкът е твърде бавното изпълнение на 

отправените заявки. 

Около средата на 1994 IBM интегрира уникалната технология на Metaphor 

(прекръстена на DIS) с бъдеща IBM технология. Продуктът все още се поддържа заради 

останалите лоялни клиенти, а IBM го пускат под името IDS, но почти не го рекламират. 

Креативните концепции на Metaphor не са загубени и Information Advantage, Brio, 

Sagent, MicroStrategy и Gentia са повлияни от него. 

През 1995 Holos 4.0 е пуснат на пазара. Първият хибриден OLAP продукт, 

позволяващ на едно приложение едновременен достъп до релационни и многомерни 

бази данни. През същата година Oracle придобива Express. Първото значително 

придобиване в сектора на OLAP продуктите. Express се превърна днес в хибриден 

OLAP продукт и се конкурира успешно както с многомерните, така и релационните 

OLAP инструменти. 

Първият продукт, който предоставя многомерно и релационно отчитане от 

динамично вградените кубове е BusinessObjects 4.0 и излиза на пазара през 1996. През 

следващата година Microsoft обявява OLE DB за OLAP. Проектът носи кодовото име 

Tensor, и се превърна в "промишлен стандарт” OLAP API, преди още излизането на 

пазара на каквато и да е поддръжка на продукта. 

През 1998 IBM DB2 OLAP Server е пуснат на пазара. Тази версия на продукта 

Essbase съхранява всички данни под формата на една релационна схема, в DB2 или 

други релационни бази данни, но все още прилича повече на един бавен MOLAP ( 

Многомерен OLAP), отколкото на ROLAP. През тази година се основава Hyperion 

Solutions. Компаниите Arbor Hyperion Software “се сливат”, осъществявайки първото 

голямо консолидиране на OLAP пазара. 

Lotus е следващата компания, която навлиза на пазара на електронни таблици за 

многомерни модели с Improv. Той е пуснат в употреба на машината NeXT, но когато е 

пренесен на Windows, Excel вече е прекалено голяма заплаха и продажбите на Improv 

са малки. Lotus, както и CA с Compete, раздвижва пазара с Improv, но това не е 

достатъчно и новото му разработване се спира. Microsoft прибавя PivotTables към Excel. 

Това е най-широко използваната възможност за анализ на многомерни модели в света, 

по простата причина че има много потребители на Excel. Excel 2000 включва поусъвършенствана 

версия на PivotTables, която може да се използва и като десктоп 

OLAP и като клиент на Microsoft Analysis Services. 

През 1999 започват доставките на Microsoft OLAP Services. Проектът носи 

кодовото име Plato и използва технология придобита от компанията Panorama Software 

Systems през 1996 година. По ирония през първите си шест месеца Microsoft OLAP 

Services е един от малкото OLAP сървъри, които нямат разработен клиент за 

електронни таблици. Основното предложение на Microsoft се появява през юни 1999 

год. в Excel 2000. Продуктът Microsoft OLAP Services е пазарен лидер в сегмента 


- 94 - 

OLAP сървъри поради лесното му инсталиране, високотехнологичната архитектура за 

съхраняване на данни (ROLAP/MOLAP/Hybrid), огромната и добра поддръжка. 

6. Развитие на OLAP технологиите от 2000 година до наши дни 

През 2000 година Microsoft променя името на продукта OLAP Services на 

Analysis Services без всякаква основателна причини, с което създава голямо объркване 

на пазара. През тази година се обявява и XML за Analysis. Стартира инициатива за 

създаване на един много продаваем, независим от платформа, XML-базиран OLAP API 

продукт, която се ръководи от Microsoft (по-късно към проекта се присъединява 

Hyperion). 

През 2000 SAP Business Information Warehouse (BW) започва да се доставя в 

България. Осигурява всички необходими инструменти за моделиране, извличане, 

съхранение и достъп до данните. Даните от различни източници могат да се 

комбинират с цел разширяване на анализационните възможности. 

Oracle започва да доставя продукта-наследник на Express през 2001 година. 

Шест години след придобиването на продукта Express, Oracle започва да доставя 

продукта Oracle9I OLAP, от който се очаква евентуално да наследи Express. Подробна 

информация за маркетинговата политика на Oracle може да бъде намерена на 

www.oracle.bg и във в-к Computerworld. 

В наши дни Hyperion и други BI производители подготвят от известно време 

отварянето на своите сървъри за потребностите на OLAP приложенията. Целта е освен 

многомерни бази от данни за източник на анализите да бъдат ползвани и релационни и 

неструктурирани данни. На 02.05.2006 в-к Computerworld публикува информация – 

(http://www.computerworld.bg )– за коалицията между Hyperion и Microsoft които ще 

работят при Business Intelligence решенията. Конкурентите възнамеряват да съгласуват 

продуктите си за анализи и отчети, за да улеснят своите клиенти при реалзирането на 

хетерогенни решения. Чрез това споразумение Hyperion u Microsoft практически за 

първи път ще работят комплексно заедно, като изключим дейностите им по 

стандаризирането на XMLA. Досега Microsoft работеше в съюз с конкурентите Business 

Objects и Cognos. Сътрудничеството на Hyperion с Microsoft, не е добра новина за тези 

производители. Продуктовата стратегия на Hyperion е по-силно ориентирана към 

управление на бизнес производителността (BPM), което в момента се отъждествява с 

управление на финансите. Cognos, Business Objects, и други Microsoft партньори 

държат също на BPM пазара. Ще има ли потърпевши в това сътрудничество ще покаже 

времето. 

7. Теми за целите на допълнителното научно изследване 

MOLAP системите трябва да се справят с проблема свързан с липсата на данни. 

Проблемът е известен под названието “разпръснатост на данни” или “неплътност 

на структурите с данни”. Повече то 90% клетки в многомерния куб могат да бъдат 

празни ако дадени продукти не са били продадени в специфични региони и 

следователно не съществува продажна цена за съответната комбинация. Как 

софтуерните продуктите разрешават този проблем е един от най-важните критерии за 

оценка на MOLAP софтуерните системи. 

Техниката за съхраняване на данни трябва да разгледа много фактори, които могат в 

допълнение често да се променят: 

- профил на данните и обем (брой на D-структурите и атрибути на D-структурите, 

видове данни) 

- неплътност на структурите с данни (в кои D-структури / комбинации от Dструктури)

- 95 - 

- честота на промяната в началните данни (колко често MDDBMS ще бъде 

актуализирана) 

- честота на промяната в многомерния модел (D-структури, членове на Dструктурите) 

- достъп за писане на данни и т.н. 

В идеалния случай MDDBMS ще избере оптимална структура на данните, в 

зависимост от изброените фактори. Съществуващите системи, са базирани предимно на 

двуслойни структури на данните [1,2,3]. Един подход за съхраняване на многомерните 

данни е преобразуването в едномерен векторен масив. За справяне с “неплътните 

структурите с данни” са необходими допълнителни техники за компресиране. В 

повечето търговски MDDBMS се използва двуслойна техника на съхраняване в която 

плътните масиви са индексирани от една структура, която съдържа комбинации от 

непълни данни. Двуслойната структура на по-високо ниво е изградена от комбинации с 

разпръснати данни и е използвана за да посочи масива (с оставащите плътни 

комбинации), който съдържа желаната информация. В долния слой всички плътни Dструктури 

(време, регион, продукт) се съхраняват с техните данни. Вторият слой 

съдържа неплътни D-структури като индексна структура, съдържаща указания за 

кубовете с плътни данни намиращи се на по-ниско ниво. 

Втори проблем е трансфера на транзакционната концепция, както тя е позната и добре 

приемана в релационния свят към технологията за обработка и анализ на многомерни 

модели. Всички търговци на MOLAP, рекламират свободен достъп за писане в техните 

MDDBMS, основно в условия на “способност на много потребители”. В 

действителност, повечето MOLAP продукти са ограничени до позволен достъп за 

четене на много потребители и позволен достъп за писане само на един потребител. 

MDDBMS блокира за достъп цялата база данни по време на актуализирането на 

информацията. Блокирането на достъп на цялата база данни не е много подходящо 

решение, от друга страна взаимозависимостите на данните, превръщат дефинирането 

на блокиращите инструменти в труден за решаване проблем [7, 8, 9, 10]. 

Много търговци на MOLAP, имат неясна представа за транзакционните концепции, 

което не е изненадващо, защото няма общ консенсус (нито в бизнеса, нито в 

изследователската общественост), кои аспекти от теорията на релационната транзакция 

са необходими в MDDBMS и как те могат да бъдат прехвърлени в практиката. 

Промените в кубовете с данни, могат да бъдат извършени, при прилагане на 

многовариантен причинно-следствен анализ. Често те изисква актуализиране на 

агрегираните резултати или мярите, които са изчислени (например общите разходи за 

ремонт, изчислени, като сума от частични разходи и заплати) върху вече променени 

данни. Посочените зависимости правят актуализирането значително по-трудно. 

Понататъшно изследване заслужават следните направления –атомарност, 

съгласуваност, изолираност и стабилност. 

Зависимостите между подробните данни, съвкупните данни и мярите, усложняват 

представата за съгласуваност. Ако условието е стриктно интерпретирано, 

съгласуваност може да бъде постигната само ако всички свързани данни са 

актуализирани едновременно, което е изключително трудно да бъде постигнато по 

време на работа, тъй като преизчисленията може да отнемат дълго време. Ако бъде 

реализиран едновременен контрол, посредством блокираща техника, трябва да бъдат 

дефинирани блокиращите способи и подаващите се на блокиране гранули с данни. 

Както беше споменато по-горе, блокирането на достъп на цялата база данни не е много 

подходящо решение. Взаимозависимостите на данните, превръщат дефинирането на 

блокиращите гранули в труден за решаване проблем. 


- 96 - 

Свързана с гореспоменатите проблеми е стратегията за актуализиране т.е., когато 

данните (съвкупности и мяри), трябва да бъдат актуализирани, съгласно промените в 

подробните данни или в модела данни (като нови членове на D-структури) Подобно на 

теорията за еволюция на схемите в OODBMS, могат да бъдат прилагани различни 

стратегии: незабавно актуализиране или отлагане на актуализацията и т.н. За 

гарантиране на непротиворечивостта при опцията за отлагане на актуализацията, могат 

да са необходими допълнителни концепции, като прегледи, филтри или пускови схеми. 

Достъпът на много потребители до базата данни, изисква повече отколкото MDDBMS 

може да предложи понастоящем. Транзакционната концепция е свързана с много други 

въпроси, като възстановяване, структурите на данните (напр. многослойни структури) и 

т.н. Има проблеми свързани с базите данни, които са решени чрез системите за 

управление на релационни бази данни (RDBMS), но които все са само частично 

реализирани в MDDBMS, като: 

- редактиране 

- възстановяване (което е свързано с транзакционната концепция) 

- концепциите за отчети 

- разпределени бази от данни 

Последната точка съдържа в себе си допълнителни проблеми, като фрагментация, 

разпределяне, прозрачност и т.н. Двата гореспоменати проблема (структурите на 

данните и транзакционната концепция), трябва също да поддържат функцията 

разпределение. Накрая, създаването на многомерен модел от различни източници на 

данни е интересен и обещаващ предмет на по-нататъшни изследвания [4]. 

Тъй като съществуват множество архитектури и различни модели на данни, е от 

изключителна важност да бъдат предложени методи за моделиране на OLAP 

приложения, независещи от изпълнението. Тази цел остава извън целите и подкрепата 

на индустриалната общност, тъй като всички методологии, предложени от 

производители на продуктите и независими консултанти, използват модели, 

характерни за структурата или инструментите на техните софтуерни продукти през 

целият процес по разработване (включително концептуалната разработка). От друга 

страна, всеки от изследователските подходи дефинира свое собствено виждане за 

многомерен модел на данни, като използва различни терминология и семантични 

елементи. Няма общоприето разбиране по въпросите 

o какво принадлежи към една многомерна схема; 

o поради което и няма общоприет от всички DML (data manipulation language). 

o или общоприет от всички DDL (data definition language). 

За целите на общата дискусия e необходимо използването на единна терминология: 

o D-структури - нива на D-структури и класификационни взаимовръзки 

o Факт, мяра 

с цел идентифициране и изследване на дискутираните проблеми. 

В тази насока предоставяме таблица описваща термините използвани в SAP BW и в 

изследователските многомерни модели (MDM). 

MDM SAP BW 

Факт Ключови показатели 

Атрибути на 

дименсии (D – 

структура) 

D-структура 

(Дименсия) 

Характеристика/ 

Навигационни атрибути/ 

Отчетни атрибути/ 

(външна) Йерархия 

Дименсия / 

Основни данни/ 

Текстови данни 

Йерархични данни / (SID данни)

- 97 - 

Табл. 1. Термини използвани в SAP BIW 

От гледна точка на науката и на концепцията за база данни, съхраняването и 

обработката на данни в многомерни модели е новаторска дисциплина със специални 

нужди, дори ако вече установените концепции могат да се използват в един нов 

контекст. OLAP доставчиците се опитват да „завладеят” предни позиции в бъдещия 

пазар с бързи, но много често непълни приложения. Теория с единна терминология, 

усилия за стандартизиране и т.н. предстои да бъде представена и приета от научната и 

индустриалната общност. 


OLAP пазарът се характеризира с висока динамика и иновации. 

Изследователските дейности изискват продължително изследване на новите софтуерни 

продукти с цел предоставянето на необходимите концепции. Доставчиците трябва да 

обръщат необходимото внимание на изследователската общност, с цел да бъдат 

заместени „прототипните системи” с финансирани продукти, които удовлетворяват 

изискванията на бързо развиващите се информационни технологии. Качеството на 

стратегическите бизнес и управленски решения, взети следствие използването на 

OLAP, е значително по-високо и те са много по-навременни, отколкото взетите по 

традиционния начин решения. 

Конкурентноспособността на дружествата и способността им да се разрастват и просперират ще 

бъде пряко свързана с качеството, ефективността и разпространителната способност на възможностите 

им за OLAP. По тази причина IT организациите в рамките на малките и големи дружества трябва да се 

подготвят да предоставят стабилна OLAP поддръжка за своите организации. 


1. Вълова И., От гръцките символи до съвременните OLAP софтуерни решения, 

Computerworld, № 22, 9, 2006. 

2. Вълова И., OLAP-теория и приложни постижения, Computerworld, № 23, 7-8, 2006. 

3. Вълова И., Релационни OLAP продукти - традиция и новаторство, Computerworld, 

№ 27, 7-8, 2006. 

4. Вълова И., Mногомерни OLAP решения – в търсене на единна технология, 

Computerworld, № 29, 8-9, 2006. 

5. Valovа I., Zhechev B., Valov V. Overview of research and software approaches for 

multidimensional data analysis, “Cybernetics and information technologies”, ISSN 1311- 

9702, vol.4, No1, IIT-BAS, Sofia, 2004, 26-34, 2004. 

6. Valov V., Zhechev B., Valova I. Development of technologies for data processing and the 

place of OLAP, ISBN 954-683-324-X, UNITECH’05, 24-25 November 2005, Gabrovo, 

Bulgaria, pp. 236-240. 

7. Valovа I., Hypercubes in Computer Science, NVNA- Jubilee Conference 17-18 May 

2006, Varna, Bulgaria (in print). 

8. Valova I., Reflecting changes in multidimensional models. Evolution of multidimensional 

scheme, NVNA- Jubilee Conference 17-18 May 2006, Varna, Bulgaria (in print). 

9. Valovа I., Advanced Technologies and Software Products for Data Processing and Their 

Use in Real Economy, Balkan Conference of Young Scientists, ISSN 1311-9419, 16-18 

June 2005, Plovdiv, Bulgaria, 493-499, 2005. 


- 98 - 

10.Valovа I., Study of some issues related with creation of multidimensional models. 

Maintaining of multidimensional scheme structure type “star”, Balkan Conference of Young 

Scientists, ISSN 1311-9419, 16-18 June 2005, Plovdiv, Bulgaria, 485-492, 2005. 

Institute of Computer and Communication Systems 


Acad. G. Bonchev str., bl. 2, 

1113 Sofia 

*Institute of Control and System Research 



1113 Sofia 

BULGARIA 

E-mail: vania@icsr.bas.bg

- 99 - 




BULGARIA 

ALGORITHMS OF WORK OF NODES ON THE PROTOCOL 

FOR 2PL WITH PRIMARY COPIES IN DISTRIBUTED 

DATABASE MANAGEMENT SYSTEMS 

SVETLANA VASILEVA 

Abstract. The paper views algorithms for concurrency control in Distributed database 

management systems (DDBMS) with data replication. The following algorithms are 

worked out on the base of Two-phase-locking (2PL) protocol with primary copies: 

algorithm for synchronization of the processes in taking resource in the distributed 

system; algorithm for transaction management based on the 2PL with the primary copy 

protocol for the phase on the global ratification; algorithm for transaction management 

for one-version model of distributed database (DDB) solving the problem for 

serialization of the distributed schedule; algorithm for transaction management for twoversion 

model of DDB. 

Key words: transactions, distributed databases, two-phase locking (2PL), concurrency 

control, lock table, scheduler, Two-version 2PL protocol. 

АЛГОРИТМИ НА РАБОТА НА ВЪЗЛИТЕ ПО ПРОТОКОЛА ЗА 2PL С 

ПЪРВИЧНИ КОПИЯ В РАЗПРЕДЕЛЕНА СИСТЕМА ЗА УПРАВЛЕНИЕ 

НА БАЗИ ОТ ДАННИ 

Направеният анализ в [1] и [2, с.872] показа, че в системите с разпределени бази 

от данни (РБД) механизмът на управлението на паралелното изпълнение на 

транзакциите трябва да осигурява: съгласуваност на елементите от данни; завършване 

на всяка елементарна операция в границите на установен интервал от време; 

устойчивост към отказите във възлите и свързващите линии; високо ниво на 

паралелност, удовлетворяващо съществуващите изисквания за производителност на 

разпределената система (РС); невисоко допълнително ниво на потребление на 

процесорно време и другите системни ресурси; удовлетворителни работни показатели 

на мрежовите съединения, имащи голяма продължителност на времето на задържане; 

липса на допълнителни ограничения върху структурата на елементарните операции. 

Освен това, разпределената система (РС) за управление на БД (РСУБД) с 

репликация на данните трябва да осигури и съгласуваност на многото копия на 

данните, съхранявани в различните възли. В работата се обсъжда синхронно 

обновяване на реплицираните елементи от данни. Разпределената транзакция 

осъществява достъп до данните, съхранявани в няколко места. Всяка от транзакциите 

се разделя на няколко подтранзакции – по една за всеки възел към данните, на които се 


- 100 - 

осъществява достъп. В отдалечените възли субтранзакциите се представят от агенти. 

Ако графикът на изпълнение на транзакциите във всеки от възлите е подредим, то 

глобалният график (обединение на всички локални разписания) също е подредим, при 

условие, че последователностите на локалното подреждане са идентични [2, с.872]. 

Затова е необходимо всички субтранзакции да са в един и същи ред в еквивалентния 

последователен график на всички възли. 

Организацията на управлението на паралелното изпълнение на транзакциите в 

системите с БД може да бъде осъществено по един от трите протокола: Двуфазна 

блокировка - за да прочете или да промени елемент от данни, транзакцията трябва да го 

блокира, за да няма конфликт с друга транзакция, искаща достъп до него; 

Хронометраж – използване на времеви маркери - глобално подреждане на 

транзакциите, така че по-старите (с по-малка стойност на времевия маркер) в случай на 

конфликт да получат приоритет; Проверка на достоверността – предполага се, че в 

системата възникват рядко конфликти, затова се изключват задържанията гарантиращи 

подредимостта. 

При последните два метода, ако паралелните транзакции често четат и записват 

едни и същи елементи данни, то ще има често и рестартове (rollbacks), което може да 

доведе до по-дълги отколкото при схемата на блокиране задържания [2, с.938]. Затова в 

доклада се разглежда основно организирането на управлението на паралелното 

изпълнение в РСУБД по механизма на двуфазната блокировка (two-phase locking – 

2PL). Протоколите за 2PL в РСУБД с репликация на данните са: централизиран 

протокол за двуфазна блокировка; 2PL с първични копия (2PL на главното копие); 

разпределен протокол за 2PL; 2PL на болшинството копия. Протоколите са 

анализирани подробно в [3]. Най-лесен за реализация е централизираният протокол за 

2PL, но най-големият му недостатък е, че централният възел (на който е единственият в 

РС организатор на заданията, т.нар в 2PL протоколите диспечер на блокировките и 

единствената таблица на блокировките) става тясното място в системата - отказ в 

централния възел води до нарушаване на работата на РС. В тази връзка се предлагат 

работни алгоритми за реализация на протокола за 2PL с първични копия. Той е едно 

развитие на централизирания протокол, който преодолява недостатъците му чрез 

разпределяне на диспечера на блокировките по няколко възела [2, с.874-875]. В процеса 

на репликацията за всеки копируем елемент от данни едно от копията се избира за 

първично (нар. още главно копие) (primary copy), а всички останали са вторични (slave 

copy). Изборът на „първичния” възел, т.е. възелът управляващ блокировката на 

първичното копие на елемента от данни, не зависи от това дали съдържа първичното 

копие [пак там]. За разлика от механизма на централизираната 2PL, при разглеждания 

протокол, ако се обновява елемент от данни, координаторът на транзакциите трябва да 

определи къде се намира първичното копие и да изпрати заявката за блокировка към 

съответния диспечер на блокировките. При обновяването на елемент от данни е 

достатъчно да се установи изключителна блокировка само на първичното (главното) му 

копие. След като първичното копие бъде обновено, внесените изменения могат да 

бъдат разпространени върху всички вторични копия [2, с.875]. 

Описание на алгоритмите за работа на възлите в РСУБД 

1. Алгоритъм за синхронизация на процесите при отделяне на ресурс в РС по [4] 

според протокола за 2PL с първични копия: 

1.1 Възел Si изпраща заявка до възел Sk за намерението си да блокира елемент от 

данни x j със съобщението reqi(x j , type_lock, num_t). Аргументът num_t има стойност 

num_t = concat(ci, i), където ci е стойността на брояча на транзакциите в Si.

- 101 - 

1.2 Получавайки съобщението reqi(x j , …), диспечерът на блокировките LMk в Sk 

проверява в таблицата на блокировките LTk дали исканата блокировка е допустима в 

съответствие с правилото: 

- Ако реплицираният елемент е 

свободен или е блокиран с “rl” и 

type_lock=”rl” 

- Във всички останали случаи 


=> 

блокировката 

е допустима; 

– 

недопустима. 

1.3 Ако блокировката е допустима, то диспечерът на блокировките поставя в 

таблицата на блокировките съответния запис за елемента x j и изпраща съобщение за 

предоставяне на исканата блокировка към възела заявител Si. 

1.4 Ако блокировката е недопустима, диспечерът на блокировките LMk поставя 

заявка за нея в опашката qk на чакащите „пред” x j , разрешение за 

блокировка транзакции. 

Работата на първичен възел по този алгоритъм е илюстрирана на фиг.1. 

Фиг. 1. Работа по алгоритъм 1 в първичен възел Sк 

В доклада се разглеждат традиционни транзакции – такива, които се 

характеризират със свойството ACID (атомарност, съгласуваност, изолираност, 

дълговечност). Затова след локалната ратификация, провеждана в първичните възли, 

към които се обърнал възела-инициатор на дадената транзация се извършва глобална 

ратификация - откриване на глобални конфликти на ратифицираната транзакция. 

2. Алгоритъм за управление на транзакциите по протокола за 2PL с първични 

копия за провеждане на фазата на глобалната ратификация по [4 и 7]: 

2.1 Диспечерът на транзакциите ТМi във възeла-инициатор Si заявява 

необходимите блокировки под ръководството на диспечерите на блокировките LMk в 

първичните възли Sк. 

2.2 Координаторът на транзакциите (ТСi) във възел Si иницииращ глобалната 

транзакция Тi(num_t) я разделя на подтранзакции Тil(num_t) използвайки информацията 

в глобалния системен каталог. ТСi изпраща субтранзакциите Тil в съответните възли Sl

- 102 - 

чрез службата за обмен на данни. Ако Тi предвижда обновяване на данни, то ТСi трябва 

да осигури обновяването на всички копия. 

Подтранзакциите Тil извършват необходимите изчисления и записват 

резултатите в личното работно пространство (ЛРП). 

2.3 Локалната ратификация се свежда до проверка на условието за нормален 

завършек на субтранзакцията – за определен лимит от време тя да е завършила работата 

си, в определения възел-изпълнител DMl. При завършване на локалната ратификация 

във възлите-изпълнители DMl се образуват опашки от транзакции по реда на номера им 

num_t. Извършва се полуфиксация на транзакциите и полуфиксираните транзакции 

изпращат съобщения „ready2 il” на възлите-инициатори. 

2.4 Във възлите-инициатори Si се насочват от възлите-изпълнители DMl 

формиращите се опашки от транзакции стоящи в нарастващ ред на номерата им. Във 

връзка с транспортните задържания при доставката на съобщенията една и съща 

опашка в различните TMi може да бъде нееднаква в смисъл на брой членове в 

опашката, но редът на следване на членовете в нея се запазва. 

2.5 По реда на изпълнение на транзакциите възелът победител изпраща 

съобщения commit на всички други възли (решение за фиксация) и всички транзакции 

последователно се фиксират, след което резултатите от транзакциите се презаписват от 

ЛРП в РБД. Обновяват се всички копия на елемента x j , ако има операция . 

2.6 Диспечерът на глобалната транзакция ТМi във възела-инициатор Si изпраща 

съобщения до първичните възли Sk за освобождаване на блокировките на елементите x j , 

използвани от транзакцията. 

3. Алгоритъм за управление на транзакциите за моноверсионен модел на РБД 

решаващ задачата за сериализуемост на разпределения план чрез протокола за 2PL с 

първични копия по [4 и 7]: 

3.1 При постъпване на команда start (за изпълнение на транзакция Тi n (n=num_t)) 

в ТMi чрез службата за обмен на данни се изпращат заявки до първичните възли Sk 

reqi(x j ….) за блокиране на съответните елементи от данни: 

- Ако първичното копие на елемент x j е свободно, то транзакцията Тi n го блокира 

(диспечерът на блокировките LMk в Sk поставя в таблицата на блокировките съответния 

запис) и изпраща съобщение за потвърждение на блокировката на x j към ТMi в Si; 

- Ако x j не е свободен, TMi (т.е. Ti n ) получава от LMk в Sk съобщение wait(x j ), 

транзакцията Тi n застава в подредена опашка според номера си num_t в LTk [1, с.916]. 

3.2 Когато транзакция Тi n инициирана в Si получи потвърждение за блокировка 

на x j , координаторът на транзакциите ТСi изпраща чрез службата за обмен на данни 

подтранзакциите Til n , свързани с x j във възлите-изпълнители Sl. 

3.3 Подтранзакциите Til n във възлите изпълнители ТМl обработват копията на x j , 

записват резултата от обработката в личното работно пространство (ЛРП) и изпращат 

на възела-инициатор ТMi съобщение с готовност за фиксация. 

3.4 При постъпване на съобщение commit във възела-изпълнител Sl, резултатите 

от ЛРП се пренасят в БД (write DB). Съдържанието на ЛРП се ликвидира. 

3.5 При постъпване на съобщение за откат от Тi n в Sl, съдържанието на ЛРП се 

ликвидира (abort PS). 

3.6 При постъпване на команда commit(Тi n ) или rollback(Тi n ) мениджърът на 

транзакцията Тi n ТМi освобождава блокировките на всички x j използвани от Тi n , като 

изпраща до съответните първични възли Sk искания за освобождаване на блокировките 

на първичните копия на x j . 

3.7 При освобождаване на първично копие в Sk се проверява има ли на опашката 

qk транзакция Тp g с минимален номер, чакаща блокировката му. Ако има, то елементът

- 103 - 

се блокира от нея, LMk изпраща потвърждение за блокировката му на съответния възел 

инициатор Sp опашката се придвижва с едно място напред (q_shift). 

4. Алгоритъм за управление на транзакциите за двуверсионен модел на РБД 

решаващ задачата за сериализуемост на разпределения план чрез протокола за 2PL с 

първични копия по [4], [5] и [6, с.156-157] 

Многоверсионните методи за управление на паралелните транзакции съхраняват 

версията на данните, подлежащи на изменение. В повечето случаи може да се извършва 

четене на данните без съответстващата синхронизационна блокировка. Това позволява 

да се повиши скоростта на изпълнение на заявките за четене и да се намали 

вероятността от появата на взаимоблокировки [6]. “Терминът версия се отнася до 

стойността на елемента от данни, продуциран от транзакция, която е или активна или 

фиксирана” (завършила с commit). “Така, ако LM реши да назначи определена версия 

на х при операция read[x], стойността, която се връща не е тази, която е продуцирана от 

транзакция, прекъсната с abort.”[7] 2V диспечер на блокировките използва 3 вида 

блокировки: readlock (rl), writelock (wl) и certifylock (cl) [6 и 7]: 

rl се установява върху текущата версия на елемента от данни х, непосредствено 

преди прочитането й; 

wl се установява върху х преди да се създаде нова (незавършена) версия на х; 

cl се установява непосредствено преди изпълнението на последната операция на 

транзакцията (обикновено commit) по отношение на всеки елемент от данни, който тя е 

записала. Ако Ti е записала х, но още не е фиксирала, то тези 2 версии на х са на Тi 

преди да е записала изображението на х и стойността на х. 

Тези блокировки се регулират от матрицата на съгласуваността [6 и 7]: 

rl wl cl 

rl да да не 

wl да не не 

cl не не не 

4.1 При постъпване на съобщението start (за изпълнение на транзакция Ti n ) в Si, 

TMi изпраща съобщение до първичния възел Sk reqi(x j , type_lock, num_t) за блокиране 

на съответния елемент от данни. 

4.2 Получавайки съобщението reqi(x j , type_lock, num_t) първичният възел LMk 

проверява дали елементът е свободен (т.е. дали транзакция го е блокирала с rl, wl или 

cl): 

4.3 Ако елементът е свободен, то транзакцията Ti n го блокира (диспечерът на 

блокировките LMk в Sk поставя в таблицата на блокировките съответния запис) и 

изпраща разрешение за съответната блокировка на x j . 

4.4 Ако елементът не е свободен (т.е. друга транзакция е поставила запис в LTk 

wl(Tp g ), rl(Tp g ) или cl(Tp g ): 

4.4.1 Ако type_lock = wl(x j ) и x j е блокиран с wl или cl, 

- то Тi n „застава” в подредена опашка според номера си „пред” x j . 

- в противен случай LMk поставя срещу x j wl(Ti n ), превежда writen[x j ] във 

writen[x j n] и изпраща writen [x j n] на възела-инициатор ТMi. 

4.4.2 Ако type_lock = rl(x j ), LMk проверява в LTk притежава ли вече Ti n 

блокировка wl(x j ), ако това е така, 

- то LMk превежда readn[x j ] в readn[x j n] и изпраща readn[x j n] на ТMi; 

- иначе (по таблицата на съгласуваността) Ti n „застава на опашка пред” x j според 

номера си, за да изчака, докато може да постави rl(x j ) и когато я получи, LMk ще 


- 104 - 

превърне readn[x j ] в readn[x j g], където x j g е най-скорошната (т.е. единствената 

фиксирана) версия на x j и ще изпрати readn[x j g] на TMi. 

4.5 При прочитане на команда commit(Ti n ) във възела инициатор ТMi, се изпраща 

заявка commit(Ti n ) – ci n във всички първични възли, обслужващи транзакцията Ti n . 

4.6 Когато LMk получи ci n , посочваща, че Тi n приключва с фиксация : 

4.6.1 Проверява в LTk за блокировки wli n : 

- Ако има елементи от данни, блокирани с wli n и с блокировки rlp g , притежавани 

от други транзакции, 

* То Ti n изчаква на опашка „пред” тези x j , за да изчака освобождаването на rlp g и 

да превърне своите wli n (x j ) в cl; 

* Иначе LMk превръща wli n (x j ) в cli n (x j ). 

4.6.2 Когато Ti n получи всички потвърждаващи блокировки cl на първичните 

копия на x j в Sk за определен лимит от време, възлите-изпълнители DMl получават 

потвърждение за фиксация от TMi. 

4.6.3 Ако за определен лимит от време Ti n не получи своите cl в Sk, то е 

възможна взаимоблокировка на Ti n с друга транзакция Tp g , която по времето, когато Ti n 

се е опитвала да превърне своите wli n (x j ) в cli n (x j ), пък се е опитвала да трансформира 

своите rlp g (x j ) в wlp g (x j ). Затова се стартира подалгоритъм за разкриване и разрешаване 

на взаимоблокировки, който работи по метода на хронометраж. (Транзакциите с помалки 

номера n, т.е. започнали по-рано работата си, да я приключат, а за по-младите се 

прилага рестарт). 

4.7 При постъпване на потвърждение за фиксация във възел–изпълнител DMl, 

резултатите от ЛРП се пренасят в БД (write_DB). 

4.8 При команда rollback(Ti n ), TMi изпраща до възлите-изпълнители Sl 

съобщения backil(x j ). Съдържанието на ЛРП на Til n се ликвидира. Присвоеният на Til 

номер се ликвидира. 

4.9 Si изпраща до съответните първични възли Sk съобщения за освобождаване 

на елементите, блокирани от Тi n – unlocki n (x j ). В таблиците на блокировките LTk 

записите за елементите x j остават чисти. 

4.10 Аналогично на 3.7. 

Алгоритъмът на работа на първичен възел Sk (диспечерът на блокировките LMk) 

е илюстриран на фиг.2. 

Представените тук алгоритми са разработени на базата на протокола за 2PL с 

първични копия и позволяват: 

- Синхронизация на транзакциите в РСУБД при едновременния им достъп до 

разделяеми елементи от данни, като се извършва сериализация, така, че във всеки 

момент от време само 1 транзакция да може да извършва действие на елемент от данни; 

- Глобална ратификация на паралелно изпълняваните разпределени транзакции; 

- Решение на задачата за сериализуемост на разпределените транзакции при 

моноверсионен модел на РБД и при двуверсионен модел на РБД. 

За получаване на количествени оценки на ефективността на представените в 

доклада алгоритми, предстои разработване на имитационен модел на РС и сравняване с 

резултатите от симулирането на другите протокола за 2PL в РБД с репликация на 

данните.

- 105 - 

фиг. 2. Работата на първичен възел Sk по алгоритъм 4 


1. Г. Гарсиа-Молина, Д. Ульман, Д. Уидом. Системы баз данных. М., Вильямс, 2003. 

2. Т. Конноли, К. Бегг. Базы данных. М.-СПб-Киев, Вильямс, 2003. 

3. П. Милев, С. Василева. Проблеми при алгоритмите за управление на транзакциите в 

разпределени системи за управление на бази от данни. (Състояние и перспективи). 

VIII международна конференция на асоциацията „Тензор” по диференециална 

геометрия, системен и комплексен анализ и информатика. Варна, 2005. 

4. Н. Гасанова. Разработка алгоритмов управления транзакциями, основанных на 

методе временных меток в расспределенных базах данных. Автореферат, 2005. 

5. П. Чардин. Многоверсионность данных и управление паралельными транзакциями. 

http://www.citforum.ru/database/articles/multiversion 

6. Ph., Bernstein, V. Hadzilacos, N. Goodman. Concurrency control and recovery in 

Database Systems. http://www. itap.purdue.edu/homes/sunil/syllabi/542/book/images 

7. http://dbserver.kaist.ac.kr/~mhkim/cs662-05spring.dir/ozsu-chap11.pdf 

Shumen University “Bishop Konstantin Preslavski”, College - Dobrich 

Dobrotica 12 

9300 Dobrich 

BULGARIA 

E-mail: svetlanaeli@abv.bg 


- 106 -

- 107 - 




BULGARIA 

WIRELESS SENSOR NETWORKS WITH DYNAMIC 

NETWORK TOPOLOGY 

VASIL STOYANOV 

Abstract. Wireless sensor networks with dynamic topology are discussed. Basic 

networks topologies – star, tree and mesh are analyzed. It is proposed a method 

for building the tree sensor network, which reduces the nodes resource 

requirements. The average time for changing the network topology and the 

average throughput are analyzed in case of different initial conditions. 

Key words: coordinator, end device, router, tree topology. 

СЕНЗОРНИ МРЕЖИ С РЕКОНФИГУРИРАНЕ НА МРЕЖОВАТА 

ТОПОЛОГИЯ 


Сензорните мрежи (СМ) представляват ниско скоростни безжични мрежи, 

предоставящи възможност за безжична връзка между множество автономни устройства 

за мониторинг на определени параметри на средата и/или управлени на други 

устройства. 

Сензорните мрежи са изцяло базирани на стандарта IEEE 802.15.4, който 

дефинира протокол за връзка между устройства посредством радио комуникационен 

канал в PAN (Personal Area Network) мрежа. Радио връзката се осъществява на 

свободните радио честоти 2.4GHz, 915MHz или 868MHz. За реализиране на 

комуникация между два възела в рамките на една и съща мрежа, стандартът използува 

множествен достъп до средата, с откриване на носещата честота и механизъм за 

избягване на колизиите (CSMA-CA). Използуването на стандарта IEEE 802.15.4 

позволява изграждането на сензорни мрежи, включващи в състава си до 65536 

устройства, свързани в мрежова топология звезда, дървовидна топология или смесена 

топология. 

Основната градивна единица на всяка сензорна мрежа е устройството. 

Устройствата в СМ се делят на устройства, поддържащи пълен набор функции Full 

Function Device (FFD) и на устройства с ограничен набор от функции Reduced 

Function Device (RFD). 


- 108 - 

2. Описание на метод за реконфигуриране на мрежовата топология при 

сензорни мрежи 

Сензорните мрежи предоставят възможност за свързването на стационарни и 

мобилни устройства благодарение на функционалните възможности на мрежовия 

протокол. Мрежовият протокол предоставя възможност на устройства да изграждат 

мрежа, да се асоциират с вече съществуваща СМ или да напускат съответната мрежа, 

на която са принадлежали. Всичко това предполага силно изразена динамика в 

мрежовата топология, което от своя страна поставя въпроса за решаване на редица 

комуникационни проблемите, свързани с нея. 

Разглежданият метод за реконфигуриране на мрежовата топология при СМ е 

ориентиран към мрежи с дървовидна, строго йерархична топология (фиг.1). 

Фиг.1 

При дървовидната топология сензорната мрежа е изградена от три типа 

устройства: координатор, рутер(и) и крайни устройства. Координаторът представлява 

устройство с пълен набор от функции (FFD устройство), което е отговорно главно за 

формиране на съответната сензорна мрежа и задаване на някои ключови параметри на 

мрежата. Рутерът представлява FFD устройство, което изпълнява основни мрежови 

функции – предаване на данни и контролни съобщения през мрежата, използувайки 

различни йерархични стратегии за намиране на оптимален път между възела изпращач 

и възела приемник. Крайните устройства представляват устройства с общо 

предназначение, с пълен (FFD) или ограничен (RFD) набор от функции, които се явяват 

листа в дървовидната мрежова топология. В разглежданият тип сензорни мрежи, 

крайните устройства не могат да комуникират директно помежду си. Потокът от 

даннови и контролни съобщения задължително преминава през координатор или 

рутер(и), които формират еднозначно определен път между крайните устройства, 

осъществяващи комуникация (фиг.2).

- 109 - 

Фиг.2 

Основната цел на разглеждания метод е да се предостави възможност на 

устройства с ограничени хардуерни ресурси, поддържащи стандарта IEEE 802.15.4, да 

участвуват в изграждането на сензорни мрежи с динамична мрежова топология. За 

конкретните разглеждания под ограничен хардуерен ресурс (визирайки устройствата, 

които изграждат мрежата) ще се разбира ограничение по отношение на паметта за 

данни, съдържаща мрежова конфигурационна информация. Обикновено размерът на 

тази памет е в границите [128B ÷ 1kB]. 

Реализираният метод използува 16 битов вътрешен мрежов адрес за адресиране 

на отделните устройства на мрежово протоколно ниво. Всяко устройство също така 

притежава уникален 64 битов MAC адрес, който се използува при присъединяване на 

съответното устройството към дадена сензорна мрежа. 

Същността на метода се състои в следното: 

- Координаторът формира сензорна мрежа. Координаторът е с фиксиран мрежов 

адрес ADDRCoordinator = 0x8000. 

- При формиране на сензорната мрежа рутерите (възлите от дървовидната 

топология) изграждат двоично дърво за търсене с максимлна дълбочина 

MaxDepth = 8. 

- Мрежовите адреси на рутерите се задават при присъединяване на рутер към 

съществуваща мрежа съгласно формулата: 

[AddrHi = 2 MaxDepth – n -1 , AddrLo = 0x00], 

ParentChildCount= 0 

ADDRRouter = [AddrHi = AddrHiParent +2 MaxDepth – n -1 , AddrLo = 0x00], 

ParentChildCount =1 

Φ, ParentChildCount=2 

където: 

- AddrHi – старша част на адреса 

- AddrLo –младша част на адреса 

- MaxDepth – максимална дълбочина на дървото 

- n – ниво на дървото (n = 0..7) 


- 110 - 

- ParentChildCount – брой устройства, асоциирани към съответен 

родителски възел (координатор или рутер) 

- 16 битовия мрежов адрес на всяко едно устрйство се разделя на две части – 

старша част (AddrHi), съдържаща старшата част на адреса на рутера, към 

който устройството е асоциирано; младша част (AddrLo)– адрес на крайното 

устройство(пореден номер в интервала [1..255]). При така формирания 

мрежов адрес, дадена сензорна мрежа може да включва в състава си до 255 

рутера, като всеки рутер може да асоциира до 255 крайни устройства. 

- Мрежовите адреси на крайните устройства се формират при асоцииране на 

устройството към определен рутер – ADDREndDev = ADDRRouter + SEQNum, 

където: 

o ADDREndDev – адрес на крайно устройство 

o ADDRRouter – адрес на рутер 

o SEQNum – пореден номер - цяло число в интервала [1..255]. SEQNum се 

инкрементира след всяко успешно присъединяване на крайно 

устройство към съответната сензорна мрежа. 

- Не се налага съхраняване на адреса на родителя, като част от мрежовата 

конфигурационна информация – последният е известен във всеки един момент 

от време, в резултат от начина на формирането на мрежовия адрес. 

- Не се налага поддържане на таблица на съседство (таблица, съдържаща 

адресите на крайните устройства, директно свързани към съответния възел от 

мрежата – координатор или рутер). 

На фиг.3а и фиг.3б е представена примерна сензорна мрежа, при която се 

извършва реконфигуриране на мрежовата топология в резултат на промяна на 

позицията на едно от крайните утройства. 

Addr = 0x8000 

Addr = 0x4000 Addr = 0xC000 

Addr = 0x4001 

Addr = 0x4003 

Addr = 0xC001 

Addr = 0x4001 

Addr = 0x8000 

Addr = 0x4000 Addr = 0xC000 

Addr = 0x4002 

Addr = 0x4002 

Фиг.3а Фиг.3б

- 111 - 

3. Резултати 

Основните параметри, които са изследвани при реализацията на метода са: 

средно време за промяна на мрежовата топология Тreavg, и максимална 

пропускателна способност Cmax. 

Средното време за промяна на мрежовата конфигурация Тreavg е равно на 

сумата от времената за получаване на информация за свободните адреси на крайни 

устройства за даден рутер (към който съответно крайно устройство прави опит да се 

присъедини) и времето необходимо за присъединяване на устройството: 

Тreavg = ∑ТReqFreeAddr + Tassoc 

Таблица 1. Средно време за реконфигуриране при различен брой крайни 

устройства 

Брой крайни устройства Тreavg, ms 

1 3.2 

2 6.1 

4 14.3 

8 27 

16 50 

32 112 


Разработеният метод предоставя възможност за изграждане на сензорни мрежи 

без да е необходимо съхраняване на обемна информация, свързана с мрежовата 

конфигурация. Това от своя страна значително редуцира изискванията по отношение на 

ресурса памет при хардуерните устойства, изграждащи мрежата. Поради естеството на 

мрежовата топология и начина на задаване на мрежовите адреси е необходимо всяко 

устройство да съхранява единствено назначения му 16 битов мрежов адрес, както и 

уникалния 64 битов MAC адрес. Процесът на рутиране на пакети в една такава мрежа 

се свежда до намиране на път в двоично дърво за търсене. Максималният брой 

мрежови устройства през, които трябва да премине даден пакет за да достигне 

съответно устройство приемник в най-лошия случай е равен на 2*MaxDepth, т.е 16. 


1. IEEE P802.15 Working Group. Part 15.4: Wireless Medium Access Control (MAC) 

and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks 

(LR-WPANs), 2003. 

2. ZigBee Alliance. ZigBee Specification, 2005. 

3. Nilesh Rajbharti, Microchip Technology Inc.. Microchip Stack for the ZigBee 

Protocol 

. 


- 112 -

- 113 - 




BULGARIA 

WEB SERVICE BASED SYSTEM FOR CUSTOMER 

RELATIONSHIP MANAGEMENT 

VELIN KRALEV, NINA SINYAGINA 

Abstract. In this article customer relationship management systems (CRM) are 

described. The model of CRM system which uses web services is proposed. The 

relational database scheme is presented that storage information about customers. 

New trends for development of CRM systems are presented. 

Key words: customer relationship management, web service, database. 

СИСТЕМА ЗА УПРАВЛЕНИЕ НА ВЗАИМООТНОШЕНИЯ 

С КЛИЕНТИ ИЗПОЛЗВАЩА УЕБ УСЛУГИ 


Системите за управление на взаимоотношения с клиенти – CRM (Customers 

Relationship Management) е втората по важност инициатива поемана от организациите 

във връзка със съхраняването на информацията и осигуряването на сигурността на 

данните [1]. От маркетингова гледна точка, управлението на взаимоотношения с 

клиенти е бизнес подход, който има за цел да създава такива взаимоотношения и да ги 

развива в бъдеще. CRM често се асоциира с използването на информационни 

технологии, като средство за маркетингова стратегия. В този аспект CRM обединява 

потенциала на новите информационни технологии с новите маркетингови виждания за 

връзките и взаимоотношенията на организациите със своите клиенти [2]. 

Въпреки че съществуват множество CRM софтуерни пакети, които поддържат 

тази стратегия, това не е технология само по себе си. По-скоро, това е цялостна 

промяна в разбирането на организациите, които вече поставят ударението основно 

върху своите клиенти. На практика CRM е маркетингова стратегия от една страна, 

която има за цел да постави клиента в центъра на свързаните с организациите процеси, 

а самата технология CRM позволява да бъде реализирана тази стратегия [3]. 

В средата на 80-те години на миналия век за първи път са били въведени 

системите за управление на лична информация – PIM (Personal Information Management 

System) и системите за управление на контакти – CMS (Contact Management System). И 

двата вида системи са предоставяли възможности за организиране и управление на 

данните за клиенти (име на клиента, телефон(и) за връзка, адрес и други). Едва в 

средата на 90-те години на миналия век, започват да се развиват системите за 

управление на взаимоотношения с клиенти – CRM. Следващото поколение на CRM 


- 114 - 

системите ще се базират на уеб услуги, като по този начин могат да се използват 

всички предимства предоставяни от глобалната мрежа Интернет. Изграждането на 

приложения чрез уеб услуги, позволява те да бъдат лесно интегрирани, бързо 

конфигурирани за нуждите на организациите и разширяват значително кръга на 

потребителите, които могат да ги използват. 

CRM системите значително намаляват времето за достъп до различни видове 

информация свързана с клиентите. Това бързодействие се постига чрез съхраняването 

на всички данни на едно централизирано място. Достъп до тях може да се осъществява 

както през Интернет, от страна на самите клиенти, така и от информационни системи, 

внедрени в самата организация, използваща CRM системата [4]. 

Полезността на една CRM система зависи от полезността на компонентите, 

които я изграждат. Колкото по-полезен, по-мащабируем и по-гъвкав е всеки отделен 

компонент на тази система, толкова тя е по-полезна. Целта на разработчиците в 

момента е насочена към свързването на различни "затворени" системи с цел споделяне 

на общи данни между тях. Според [5] данните са "валутата" на 21-ви век и тези 

организации, които могат успешно да използват своите данни, ще преуспяват. 

Обхващането на всички аспекти на CRM системите само в една статия е невъзможно, 

затова тук се разглежда функционалната част на една CRM система обработваща само 

основната информация за клиентите. Целта на настоящата статия е, да се изследват 

основните компоненти и функции на CRM системите и да проектира софтуерен 

приложен модул, съхраняващ и обработващ информация за клиенти. Част от 

функционалността на предложеният модул да бъде реализирана с помощта на 

съществуващи уеб услуги. 

2. Същност на CRM системите 

CRM системите са разработени, за да събират, съхраняват и анализират данни 

свързани с клиентите, да оптимизират продажбите по отношение на време и 

количество, да подпомагат дейността на отдела за работа с клиенти и други процеси, 

които водят до повишаване на маркетинговата ефективност. Освен осъществяване на 

тези цели, CRM системите помагат на бизнеса да използва технологични и човешки 

ресурси в следните насоки: осигуряване на по-ефективен отдел за връзка и обслужване 

на клиенти, по отношение на време и брой служители; увеличаване на продажбите; 

откриване на нови клиенти; и други. Освен изброените аспекти, внедряването на една 

CRM система предоставя възможност за автоматизиране на цял диапазон от функции, 

като се избягва изпълнението на повтарящи се задачи, а в същото време се предоставя 

достъп до данни от всяко място и по всяко време. 

Някой от предлаганите CRM софтуерни пакети на пазара са: Dynamics CRM 3.0 

на фирмата Microsoft, Daffodil CRM на Daffodil Software, Clientele CRM на Epicor и 

други. Компании като Salesforce, NetSuite и SAP планират да пуснат онлайн софтуерна 

поддръжка на своите програми за управление на взаимоотношения с клиенти. 

За да бъде една CRM система наистина ефективна, не е достатъчно само 

закупуването и инсталирането на специализиран софтуер. Необходимо е 

организацията, която е решила да използва CRM системата, първо да реши какъв вид 

информация ще съхранява за своите клиенти, как и къде да бъде съхранена тази 

информация и как ще бъде използвана тя. Начините за взаимодействие с клиентите от 

страна на организацията могат да бъдат различни – електронна поща, уеб сайт, 

специализирани центрове за връзка и други. Събирането на потоци от данни между 

действащи системи (например система за продажби или инвентаризационна система) и 

аналитични системи, могат да помогнат на организациите, да получат по-цялостен

- 115 - 

изглед за всеки свой клиент и да определят къде е необходимо предлагането на подобри 

услуги за този клиент. 

3. Компоненти и основни функции на CRM системите 

Приложната архитектура на CRM системите се състои от три части: 

операционна (operational) – чрез нея се извършва автоматизация на основните бизнес 

процеси (маркетинг, продажби, обслужване); аналитична (analytical) – чрез нея се 

извършва анализиране на поведението на клиентите; сътрудническа (collaborative) – 

чрез нея се осигурява информацията за осъществяване на контакт с клиента (основни 

данни за клиента, телефон(и) за връзка, електронна поща, факс, адрес и други). 

CRM системите се характеризират със следните свойства: 

• мащабируемост – способността да бъдат използвани за много цели и да бъдат 

надеждно разширени, ако е необходимо да се добави нова функционалност към 

тях; 

• производителност – способността да се извърши процес в системата на фонов 

режим, без да се изисква намеса на служител (например автоматизиран отговор 

на клиент чрез електронна поща); 

• поверителност – способността за криптиране на личните данни на клиента, а 

също така и възможност за унищожаване на документи с цел предпазване от 

злоупотреба с тях; 

• комуникация по много канали – способността за осъществяване на връзка с 

клиента по много начини и чрез различни устройства (телефон, WAP, Интернет 

и т.н); 

• единна база от данни – способността за централизирано съхраняване на 

информацията свързана с клиента; 

• достъпност – способността на клиентът самостоятелно, бързо и лесно да получи 

достъп до информацията от която се нуждае; 

• актуалност – идентифициране на клиентът и моментален достъп до неговия 

профил при осъществяване на контакт с него. Профилът на всеки клиент се 

формира на базата на цялата съхранена информация за него, от всички звена на 

организацията; 

• оперативен маркетинг – способността за изпращане към клиента на 

персонализирани маркетингови предложения (например автоматизирано 

генериране и изпращане на персонализирани електронни писма); 

• анализ – способността за анализ, чрез който се извършва групиране на 

клиентите, с цел формиране на различни маркетингови стратегии за отделните 

групи клиенти (сегменти); 

4. Схема на CRM система използваща уеб услуги 

На Фиг. 1 е представена схема на връзките между различните компоненти на 

CRM система използваща уеб услуги. Предложена е трислойна архитектура на 

софтуерната система, която се състои от слой за данни, приложен слой (съдържащ кода 

за управление на данните или т.нар. "бизнес логика") и клиентски слой, който 

представлява инсталирания софтуерен модул при клиента. 

При еднослойна архитектура на приложението, файлът или файловете на базата 

от данни се разполагат на същия компютър на който се разполагат и файловете на 

самото приложение. 

При двуслойната архитектура (клиент/сървър), клиентският компютър изисква 

данни от компютъра-сървър, който съхранява както файловете на базата от данни, така 

и машината на базата от данни за достъп до тях. В зависимост от реализацията на 


- 116 - 

самата система, сървъра може да извършва по-голямата част от обработката на данните. 

По този начин един мощен сървър може да осигури услуги за обработка на данни на 

няколко клиента. Двуслойната архитектура притежава следните предимства в 

сравнение с еднослойната: надеждна система за сигурност; цялост (интегритет) на 

данните; възможности за архивиране; управление на ограниченията върху достъпа и 

данните; управление на транзакции и други. 

При логическата трислойна архитектура има само два физически слоя, но самото 

приложение е разделено на три отделни елемента: данни, код за управление на данните 

и клиентско приложение. Логическият трислоен модел има два съществени 

недостатъка. Първо, необходимо е да се копира частта от програмата управляваща 

данните върху клиентската машина, което значително ще понижи производителността. 

Второ, когато множество потребители модифицират едни и същи данни, няма лесен 

начин по който могат да се обработят възникналите конфликти при обновяване на 

данните. 

І. СЛОЙ ДАННИ 

База от данни и 

система за управление 

на бази от данни (СУБД) 

ІІ. ПРИЛОЖЕН СЛОЙ 

Приложен сървър 

ІІІ. КЛИЕНТСКИ СЛОЙ 

Компютър при клиента 

CRM модул 

Проверка за валидност 

на лична карта 

Фиг. 1. Схема на CRM система, използваща уеб услуги. 

Уеб услуга за 

проверка на ЕГН 

Уеб услуга за 

населени места 

Физическата трислойна архитектура е следващата стъпка след клиент/сървър 

архитектурата. При нея частта от програмата, управляваща данните е преместена на 

отделен компютър-сървър, наречен сървър на приложението или приложен сървър. 

Всички клиентски програми са проектирани да взаимодействат с него. Приложният 

сървър, от своя страна комуникира със системата за управление на бази от данни, 

която може да бъде инсталирана на същия компютър или на друг компютър, специално 

предназначен за тази цел. Поради това, клиентските машини не се свързват директно 

към сървъра за бази от данни, а индиректно посредством приложния сървър. 

Предимството на трислойната архитектура е, че при промяна на бизнес логиката на 

приложението, се извършват корекции само върху приложния сървър, без да се налага 

промяна на клиентските приложения. Недостатък е, че реализирането на системи с 

трислойна архитектура е значително по-сложно отколкото на системи с архитектура 

клиент/сървър. 

За създаване на предлаганата CRM система, беше избрана трислойна 

архитектура. Част от функционалността на системата е реализирана чрез

- 117 - 

предварително създадени уеб услуги, съответно за проверка коректността на единен 

граждански номер (ЕГН), и втора, която връща списък с населените места в Република 

България. 

5. Кратко описание на работата със CRM система 

На Фиг. 2 е представена примерна сесия на работа с разработената система. 

Изпраща заявка към услугата place_names_rb, 

като получава йерархичен списък на 

населените места в Р. България 

Фиг. 2. Сесия на работа със софтуерния модул . 

Предава ЕГН като параметър 

на уеб услугата check_pn за 

проверка 

Стартира сайт http://nbds.mvr.bg/ 

за проверка валидността на 

номер на лична карта 

Софтуерната система предоставя функции за въвеждане на нови и коригиране на 

вече въведени данни за клиенти. Клиентите са разделени на два типа – "юридически 

лица" и "физически лица". За всеки тип клиент се предоставят следните основни 

функции – "Търсене", "Добавяне" и "Актуализиране". 

Потребителят има възможност за избор на населено място от предварително 

генериран списък – Фиг. 2. Този списък се създава с помощта на предварително 

реализирана уеб услуга (get_all_places), която връща наименованията на областите, 

общините към тях и съответно населените места към всяка община в Република 

България. Получените данни се трансформират и визуализират в дървовидна структура, 

от която потребителя има възможност да избере желаното населено място. 

За проверка на валидността на лична карта, към момента на писане на 

настоящата статия Министерството на вътрешните работи на Република България, не е 

предоставило тази възможност като уеб услуга. Предоставен е сайт на който може да се 

направи проверка за валидност на лична карта – http://nbds.mvr.bg/, но това изисква 

допълнителни усилия по копиране и прехвърляне на данните от софтуерния модул към 


- 118 - 

специален контрол за целта. Реализираната система използва функции от приложния 

програмен интерфейс (API) на операционната система Windows, за да зареди 

автоматично по-горе цитирания сайт в уеб клиент. След натискане от страна на 

потребителя на бутона "Справка", се копира стойността на полето "Лична карта / 

Номер" в системния буфер (clipboard) за временни данни (с цел спестяване на 

операциите по селектиране и копиране на въведената стойност), след което може да 

бъде направена съответната проверка. 

За проверка на въведения от потребителя ЕГН, софтуерната система предлага 

две възможности. Първо, потребителят има възможност да натисне бутона "Есграон", 

който ще зареди сайта: http://www.grao.bg/esgraon.html, на който има възможност да се 

провери дали ЕГН е валиден. Второ, при включена опция за проверка на ЕГН, при опит 

да се напусне полето "Единен граждански номер" се извършва проверка на въведената 

стойност, която се предава като параметър на вече съществуваща уеб услуга (check_pn). 

Отговорът от уеб услугата може да бъде "валиден", "невалиден" или друг символен низ, 

съдържащ описание на грешката направена в ЕГН (например "невалиден месец, 

позиции 3 и 4"). 

6. Схема на релационната база от данни "Клиенти" 

Данните за клиентите се съхраняват в релационна база от данни с име 

"Клиенти", която е представена схематично на Фиг. 3. 

Фиг. 3. Схема на релационната база от данни "Клиенти".

- 119 - 

Таблицата “Клиенти” съдържа поле “тип_клиент”, което определя дали клиентът 

е “юридическо лице” или е “физическо лице”. Според тази категоризация останалите 

характеристики за клиента се записват съответно в таблицата “клиенти_юл” – 

съхранявща допълнителна информация за юридически лица, и в таблицата 

“клиенти_фл” – съхраняваща допълнителна информация за физическите лица. Типа на 

връзките между таблиците “клиенти” и “клиенти_юл”, съответно таблиците “клиенти” 

и “клиенти_фл” е едно-към-едно (1:1), което налага ограничението, че в таблицата 

“клиенти_юл” или “клиенти_фл” не може да бъде цитиран повече от един път вече 

въведен клиент в таблицата “клиенти”. Типа на връзката между таблиците “клиенти” и 

“контакти” е едно-към-много (1:М), защото един клиент може да има повече от един 

контакт (например мобилен телефон, служебен телефон, електронна поща и т.н.). 

Аналогична е вързката между таблиците “клиенти” и таблицата “адреси”, която също е 

от тип едно-към-много (1:М). Един клиент може да има адрес за връзка и постоянен 

адрес. Таблицата “лица” съхранява информация за лицата свързани с юридическото 

лице (например лица отговорни за стопански операции, упълномощени лица и други). 


Реализирането на една мащабна CRM система с всички нейни аспекти е огромна 

по обем задача. Затова в настоящата статия беше разгледана реализацията на частта 

“сътрудничество” на CRM системата, т.е. съхраняването и обработването на данните за 

клиентите. Беше предложена схема на софтуерна система, използваща уеб услуги за 

реализация на част от функциите. Създаването адаптивна CRM система, базирана на 

уеб услуги е новаторска идея, която изисква провеждането на допълнителни 

експерименти и по-нататъшна изследователска работа. Такава система би могла да се 

използва за съхраняване и обработване на информация, събирана от различни 

източници и използвана по различни начини. Тенденциите в развитието на CRM 

системите е, те да бъдат предоставяни като уеб услуги. Това ще позволи на различни 

организации да използват тези системи с цел управление на взаимоотношенията с 

клиентите. 


1. P. Greenberg. CRM at the Speed of Light, Mcgraw-Hill Osborne Media, 2004. 

2. A. Payne. Handbook of CRM, Butterworth-Heinemann, 2005. 

3. J. Reynolds. A practical Guide of CRM, CMP Books, 2002. 

4. J. Scott, D. Lee, Microsoft CRM 3, For Dummies, 2006 

5. P. Hagen. Creating the Relationship-Centric Organization, Idealware, 2006 

Department of Informatics 

South-West University "Neofit Rilsky" – Blagoevgrad 

66, Ivan Mihailov Str. 

2700 Blagoevgrad 

BULGARIA 

E-mail: velin_kralev@abv.bg 


- 120 -

- 121 - 

© Journal of the Technical University at Plovdiv 



BULGARIA 

ON MODIFICATION OF THE ITERATIVE 

SELF-ORGANIZING DATA ANALISYS TEACHINIQUE 

ALGORITHM 

RADOSLAVA KRALEVA, VELIN KRALEV 

Abstract. In the present paper one of the most popular classical self-organizing 

clustering methods – ISODATA (Iterative Self-Organizing Data Analysis Techniques 

Algorithm) is considered. It is proposed a modification implemented by changes in two 

of the restriction conditions of ISODATA algorithm. There are presented the received 

results of the work of the both algorithms on the same input data. The presented 

modification can be used for detailed distribution of samples in clusters. 

Key words: pattern recognitions, self-organizing mode, clusters. 

ВЪРХУ ЕДНА МОДИФИКАЦИЯ НА ИТЕРАТИВНИЯ 

САМООРГАНИЗИРАЩ СЕ МЕТОД ЗА АНАЛИЗ НА ДАННИ 


Човек може да разпознае сред тълпата свой приятел, символите в думите, да 

различи цветовете, да различи любима песен. Нашите сетива улавят сигнали - 

светлинни или звукови и след това ги модулират и съхраняват в нашата памет във вид 

на прости обекти. След което чрез тези прости обекти може да се възстанови 

приблизително запаметения сигнал или събитие. Животните и птиците, също като 

хората, могат да различат себеподобните си, храната си. Този процес на възприемане и 

познание, се нарича разпознаване. Класификацията (групирането) на изходните данни 

към определен клас, чрез определяне на съществени признаци или свойства 

характеризиращи тези данни измежду останалите несъществени детайли. Под 

понятието образ обикновено се разбира модел, начин, стил закономерност, начин на 

действие. Основната цел на въвеждането на понятието е използуването му в процеса на 

установяване на съответствия, т.е при доказването на идентичността, аналогията, подобието и 

сходството на обектите по пътя на сравнението (съпоставянето). [1]. 

2. Терминология 

Основната задача на разпознаването на образи се състои в построяването на 

ефективни процедури на базата на систематични, теоретични и експериментални 

изследвания за класифициране на формализирани описания и обекти в съответстващите 

им класове [2]. При разпознаването на образите се използват два основни процеса – 


- 122 - 

идентификация и класификация на обектите. При първия процес обектите се 

разпределят по отделни уникални класове, а при втория – се извършва разпределянето 

на обектите по класове в зависимост от техните прилики и свойства (това е същинското 

разпознаване). Класификацията се реализира по два начина или чрез обучение с учител 

или чрез самообучение (нарича се още обучение без учител). Една система се обучава 

(training), когато в резултат на изпълнението на опити е настъпило изменение във 

вътрешната й структура, е довело до промяна в поведението й като цяло [3]. При 

самоорганизиращите методи за класификация, процесът на групиране на векторобразите 

в класове се нарича кластеризация От това наименование произлиза 

наименованието клъстер, под което се разбира група от обекти (образи), образуващи в 

пространството компактна област с център на определено разстояние от центровете на 

останалите области. Система (устройство), която служи за различаване на процеси, 

явления, обекти и т.н. се нарича разпознаваща система (устройство). Когато на входа на 

такава система попадне нов образ, е необходимо тя да вземе решение за 

принадлежността му към определен клас (клъстер). Образът се отнася към този клас, за 

който разстоянието (най-често евклидовото разстояние) между неговия център и 

разглеждания образ е минимално. Центърът, e един или няколко идеализирани 

представители (еталони, прототипи), които могат да се разглеждат като представители 

на всеки клас. 

3. Итеративен СамоОрганизиращ се Метод за Анализ на Данни. 

Кластеризацията е мощен инструмент в съвременната обработка на 

изображения. Така например тя се прилага за изработването на топографски карти на 

земната повърхност, базирани на снимки от спътници; при анализ на фотографски 

изображения; при разработване на мултиспектрални анализи за химични изследвания и 

т.н. Алгоритми от този тип се прилагат върху оскъдни или трудно получени данни. 

Един от алгоритмите за кластеризация (a clustering algorithm) е Итеративния 

СамоОрганизирац се Метод за Анализ на Данни – ИСОМАД (Iterative Self Organizing 

Data Analysis Techniques Algorithm – ISODATA). Той е предложен от Бел и Хол през 

1965 г., с цел за дадено множество от N образа (точки) в n-мерното пространство, да се 

намерят K на брой центрове на клъстери с помощта на набор предварително 

дефинирани евристични характеристики. При този алгоритъм се изпълняват процедури 

за намиране на най-подходящите центрове на клъстерите, чрез итеративни 

приближения, докато не бъдат удовлетворени предварително зададените критерии.. 

ИСОМАД от своя страна е достатъчно гъвкав и позволява при необходимост 

параметрите на критериите да бъдат коригирани, с цел увеличаване на прецизността 

при изпълнение. 

Тези параметри са: 

• N – параметър определящ броя на входните образи; 

• K – параметър определящ очаквания брой клъстери; 

• I – параметър определящ максималния брой итерации; 

• L – параметър определящ максималния брой двойки центрове, които 

могат да бъдат обединени (lumping) 

• θN – параметър определящ минималния брой елементи влизащи във всеки 

клъстер (използва се за ликвидиране на ненужните клъстери);

- 123 - 

• θS – параметър определящ максималното стандартно отклонение за всеки 

клъстер (използва се в операцията разцепване); 

• θC – параметър определящ минималното разстояние между два центъра на 

клъстери, т.е. това е параметър характеризиращ компактността (използва 

се в операцията сливане). 

Алгоритъмът ИСОМАД се състои от следните стъпки (подробно описание може 

да се намери в [3]): 

(Стъпка 1) Задават се центровете на клъстерите. (Стъпка 2) Разпределят се образите по 

клъстери. (Стъпка 3) Премахват се онези клъстери, чиито брой образи, влизащи в тях е 

по-малък от предварително зададен параметър. (Стъпка 4) Всички центрове на 

останалите клъстери се локализират и коригират. (Стъпка 5) Изчислява се средното 

разстояние между образите във всеки клъстер и съответният им център. (Стъпка 6) 

Пресмята се обобщеното средно разстояние. (Стъпка 7) Изпълнението на алгоритъма 

продължава с операциите сливане или разцепване на клъстери. В зависимост от 

получения и очаквания брой клъстери, както и от номера на текущата итерация и 

максималния брой итерации се определя дали алгоритъмът да премине към изпълнение 

на следващата стъпка, или да прескочи няколко стъпки. (Стъпка 8) За всеки клъстер се 

изчислява стандартното отклонение на образите, влизащи в него по всяка от 

координатните оси. (Стъпка 9) Намира се максималното средноквадратично 

отклонение. (Стъпка 10) Използвайки тази информация заедно с параметрите за 

максимално стандартно отклонение и текущия брой клъстери, се извършва разцепване 

на клъстера с максималното стандартно отклонение. Ако е извършено разцепване, 

алгоритъмът преминава към Стъпка 2. В противен случай, параметрите L и θC се 

използват за осъществяване на операцията сливане на двойки клъстери (Стъпки 11 - 

13). На последния етап (Стъпка 14) се определя дали алгоритъмът ще приключи, или 

ще бъде увеличен номера на текущия цикъл на итерацията с единица и ще се премине 

към стъпка 1 или 2. 

4. Нашата модификация 

Предимствата на алгоритъма ИСОМАД се дължат на способността му да 

отстранява клъстерите с малък брой елементи, да разцепва онези от тях, които имат 

несъвместими свойства и да обединява други, които притежават сходни такива. 

Изходните резултати обаче зависят изцяло от входните параметри N, K, I, L, θN, θS, θC. 

Освен това този алгоритъм е неприложим при голям набор от клъстери и се прилага 

само върху образи разположени линейно в хиперпространството. 

В резултат на много тестове достигнахме до извода, че разпределянето на 

образите по клъстери при класическия алгоритъм ИСОМАД, може да бъде подобрено. 

Ако разгледаме внимателно алгоритъма установяваме, че в 7 и 10 се съдържат еднакви 

условия за проверка, които се отнасят до това дали текущия брой на клъстерите (NC), е 

два пъти по-малък от очаквания, т.е. NC ≤ K / 2. 

Ще илюстрираме само тези две стъпки от алгоритъма [3]: 

Стъпка 7: Ако текущата итерация е последна, то параметърът определящ 

минималното разстояние между два клъстера θC = 0 и следва стъпка 11. 


- 124 - 

Ако текущия брой на клъстерите е по-малък от половината от очаквания брой, 

т.е. NC ≤ K / 2 (много малко клъстери), се преминава към стъпка 8. 

Ако текущата итерация има четен пореден номер или броя на получените 

клъстери е по-голям от удвоената стойност на очаквания брой, т.е. NC > 2K 

(твърде много клъстери), се преминава към стъпка 11. 

В противен случай изпълнението на алгоритъма се преустановява. 

Стъпка 10: Ако за някое максимално средно-квадратично отклонение 

( j 1,..., N ) 

σ = на j-тия клъстер са изпълнени условията σ j > θS 

, т.е. 

jmax c 

максималното средно-квадратично отклонение е строго по-голямо от 

максималното стандартно отклонение за j-тия клъстер и 

а) средната стойност на разстоянията D j между обектите е строго по-голямо от 

обобщеното средно разстояние D , т.е. D j > D , и текущият брой на обектите 

попадащи в j-тия клъстер Nj е строго по-голям от 2( 1) 

N 

max 

θ + , където θN е 

минималния брой образи, които могат да принадлежат на един клъстер, т.е. 

( 1) 

N j > 2 θ N + ; 

или 

б) получения общ брой на клъстерите NС е по-малък от NC ≤ K 2, 

то клъстерът 

с център zj се разцепва на два нови клъстера с центрове zj + и zj – , като съответно 

се добавя и изважда зададена константна величина γj към максималната 

компонента на вектора σ j . За стойност на γj може да се вземе максималната 

max 

средно квадратична компонента, т.е. γ = σ , 0 < k < 1. 

j 

k jmax 

Препоръчителна стойност за k е 0,5, тъй като стойността на γj трябва да бъде 

достатъчно голяма, за да се отличават разликите в разстоянията между образа и 

двата нови центъра, и същевременно да бъде достатъчно малка, за да не 

настъпят промени в общата структура на процеса на клъстеризация. След което 

се изтрива стария център zj и NC се увеличава с 1. 

Ако разцепването е извършено на тази стъпка се преминава към Стъпка 2. 

В противен случай се изпълнява следващата стъпка.

- 125 - 

Фиг. 1. Схематично представяне на стъпки 7 и 9 от ИСОМАД. 

Стъпка 7 е стъпка на разклонение в алгоритъма, при която има три 

възможности: едната е да се премине към разцепване на клъстери; другата – към 

сливането им; третата – към безусловен изход от алгоритъма. 

Модификация на алгоритъма се състои в промяната на условията в Стъпка 7 и в 

Стъпка 10. На местата в алгоритъма, в които се проверява дали текущия брой на 

клъстерите NC е достигнал половината от очаквания резултат от потребителя, т.е. 

NC≤ K 2 , да бъде заменено с условието: NC≤ K . 

С тази промяна се запазва цялостната концепция на алгоритъма, т.е. получената 

модификация може да се прилага в процеса на идентификацията. С тази промяна се 

цели да се постигне по-детайлно разпределяне на образите с общи свойства по класове, 

което при първоначалния вариант на алгоритъма се достига трудно, тъй като ИСОМАД 

зависи изцяло от входните параметри, които имат евристичен характер. Не винаги е 

лесно определянето на броя на класовете (клъстерите), на които може да се разделят 

образите от едно изображение 1 . От ограничителните условия се вижда, че преди да 

бъдат променени, броят на очакваните клъстери няма да бъде достигнат, защото 

алгоритъмът ще спре своето изпълнение след като са получени половината клъстери. В 

1 Изображение – обект подложен на процеса разпознаване. 


- 126 - 

този случай, за да бъдат установени класовете на разпределение на образите, експертът 

ще трябва да въведе два пъти повече, от този които смята че има. 

5. Експериментални резултати 

Всички експерименти са проведени с помощта на специално разработен софтуер 

с графичен потребителски интерфейс, работещ под ОС Widows 98, NT, XP, за 

компилирането на продукта е използван компилатор на Borland. Последователността на 

стъпките на двата алгоритъма са програмирани на ниско ниво. Въвеждането на 

образите става посредством кликане на мишката върху координатната система или от 

клавиатурата, като нагледно се визуализират върху координатна система. След 

изпълнението на който и да е от двата алгоритъма, върху координатната система 

точките се разпределят по клъстери, като всеки клъстер формира единен обект. Тъй 

като целта на тази статия е да представи предложената модификация, то за тестване на 

ИСОМАД и на неговата модификация, тук ще разгледаме само опростени схеми от 

образи в Таблица 1 са представени малка част от използваните модели, както и 

резултата от изпълнението на двата алгоритъма. 

Таблица 1. Таблица на част от опитите с ИСОМАД и предложената модификация. 

Задачата за разпознаване на образи се състои в построяването на ефективни 

изчислителни средства на базата на систематични теоретични и експериментални 

изследвания за класифициране на формализирани описания и обекти в 

съответствуващите им класове [4]. Както може да се види от таблицата, след 

прилагането на ИСОМАД и на предложената модификация върху едни и същи входни 

данни, резултатът (броя на получените клъстери) е различен. При първия алгоритъм 

броя на получените клъстери след провеждането на всички опити рядко надвишава 

половината от очаквания броя клъстери, и ако това стане то не е с повече от 1. От тук 

може да заключим, че за да получим желания брой от клъстери за съответната схема, 

трябва да въведем стойност, която да я надвишава, като трябва да се вземе предвид, че 

входните данни зависят от познанията на експерта, който ги въвежда.

- 127 - 

При предложената модификация, както се вижда от Таблица 1, сме задали 

приблизителна стойност за очаквания брой на клъстерите. След изпълнение на 

модифицирания алгоритъм, обаче получаваме максимално количество клъстери, 

надвишаващо предварително зададеното, които реално съществуват на съответната 

схема. Неудобството тук е, че е необходимо повече време за изпълнение. 

На Фиг. 2 е представена съпоставката между очаквания брой на клъстерите и 

получения при двата алгоритъма съгласно схемите от Таблица 1. 

Фиг. 2. Диаграма на очаквания и получения брой клъстери. 


В тази статия е разгледана модификация на самоорганизиращия се метод за 

анализ на данни (ИСОМАД), получен след промяна в две от ограничителните му 

условия. Представени са част от направените опити за изследване на поведението на 

двата алгоритъма при еднакви входни параметри. Изводът, който може да се направи 

след проведените експерименти, е че въведените промени доведждат до по-детайлно 

разпределяне на образите по клъстери. 


1. M. Todorova, D. Birov. „The Recognition as an Approach in the Learning of Computer 

Science”, Proceeding of the Thirty Fifth Spring Conference of the Union of Bulgaria 

Mathematicians Borovets, April 5-8 2006, p. 449-454 

2. Ю. И. Журавлев, И. Б. Гупенич. „Разпознавание, классификация, прогноз. 

Математичекие методы и примение”, Вып. 2, Москва, Наука, 1982, 302 с. 

3. C. L. Looney. “Pattern Recognition Using Neural Networks – Theory and Algorithms for 

Engineers and Scientists”, Oxford University Press, New York, 1997, p 40-47. 


- 128 - 

4. М.Todorova, N.Siniagina, Interrelation of Teaching of the Pattern Recognition and 

Discrete Mathematics, 7-th International Conference on Discrete Mathematics and 

Applications, Proceedings of the Seventh International Conference, Vol. 7, стр.157 – 164, 

2005, 


South-West University "Neofit Rilsky" - Blagoevgrad 



BULGARIA 

E-mail: rady_kraleva@hotmail.com

- 129 - 




BULGARIA 

THE WEB SERVICES LIKE AN INSTRUMENT OF 

BUILDING THE DISTRIBUTED SOFTWARE SYSTEMS 

VELIN KRALEV 

Abstract. In this article are described the web services like an instrument of building the 

distributed software systems. There are presented the common technology related with 

them - XML, WSDL, SOAP and UDDI. Two web services are suggested for personal 

number checking and other for giving information about the populated places in the 

Republic of Bulgaria. Software applications using the previous described web services 

are presented. 

Key words: web service, distributed software system, xml, wsdl, soap. 

УЕБ УСЛУГИТЕ КАТО СРЕДСТВО ЗА ИЗГРАЖДАНЕ 

НА РАЗПРЕДЕЛЕНИ СОФТУЕРНИ СИСТЕМИ 


Уеб услугите (web services) свързват различни софтуерни програми, които се 

изпълняват на отдалечени точки от земното кълбо. Те правят възможно пренасянето на 

огромни количества данни, като чрез тях се постига по-бърза и по-продуктивна 

комуникация, както между фирми, така и между отделни потребители. Текстовобазираното 

виртуално пространство не поддържа добре взаимодействията между 

софтуерните приложения. Необходим е по-ефикасен метод, който позволява на 

софтуерните приложения да взаимодействат директно едно с друго, без да бъде 

необходима намесата на потребител. Тези приложения трябва да могат да откриват, да 

осъществят достъп и автоматизирано да взаимодействат с други приложения. Уеб 

услугите подобряват използването на Интернет, като позволяват комуникация между 

софтуерни приложения, които могат да се свързват директно и да се интегрират като 

части от една голяма софтуерна система [1]. 

Уеб услугите позволяват на софтуерни компании и потребители да предоставят 

свои услуги (или приложения) по стандартен начин за всички клиенти. Те могат да 

бъдат реализирани на различни платформи и до тях може да се осъществява достъп от 

произволно място в света [2]. 

Това е бързо налагаща се технология, която има потенциала да промени начина, 

по който работи Интернет за бизнес цели. Използването на уеб страници за въвеждане 

на данни от страна на клиенти (отделни лица, наричани също B2C – business-tocustomers, 

приложения) е добро, но не и за компании (наричани B2B – business-tobusiness, 

приложения) [3]. 


- 130 - 

Интернет все още е смесица от трудно работещи заедно технологии. Далеч подобре 

би било, ако услугите получени по Интернет, можеха да работят заедно, като 

така подобряват продуктивността и опита на крайния потребител. Чрез уеб услугите 

много софтуерни компании и разработчици твърдят, че ще направят "революция" в 

начина, по който разработчиците създават приложения, а също така и начина на 

придобиване и използване на тези приложения. Уеб услугите предоставят достъп до 

услуги и данни отвсякъде и по всяко време. Три елемента се съдържат в идеята 

"навсякъде, по всяко време". Първо, необходимо е да има постоянен достъп до 

Интернет. Второ, необходимо е уеб услугите да предоставят функционалност чрез 

Интернет. И трето, уеб услугите могат да имат за обект всяко устройство, проектирано 

да работи с уеб услуги (персонален компютър, джобен компютър или мобилен 

телефон). 

Чрез уеб услугите, разработчиците на софтуер могат да изграждат своите 

приложения, като използват вече съществуваща функционалност. Това позволява 

съсредоточаване върху самото бизнес решение (софтуерния продукт, който се 

разработва) и не толкова върху инструментите за неговото създаване. Организациите 

използващи автоматизирани софтуерни системи, който не могат да комуникират 

помежду си, могат да използват уеб услуги, като чрез тях осигурят съвместимост 

между различни приложения. По този начин "закритият" вид на системите може да се 

запази, а тяхната функционалност да бъде "открита". Други системи могат да използват 

тази функционалност, позволявайки с това на организациите да изградят цялостно 

бизнес решение. 

Като обобщение за уеб услугите може да се каже, че са дискретни, 

самостоятелни и универсални приложения, които предоставят своята функционалност 

чрез уеб интерфейс. Като под уеб интерфейс не се разбира уеб страница, а приложение, 

което комуникира с останалата част от света чрез дистанционно извикване на 

процедури (Remote Procedure Calls – RPC) [2]. 

2. Технологии и термини свързани с уеб услугите 

Програмите, които взаимодействат една с друга във виртуалното пространство, 

трябва да могат да откриват информацията, която им дава възможност да се свързват, 

да се договорят за специфични характеристики на услугите, като сигурност и надежден 

обмен на съобщения. Стандартите на уеб услугите се проектират и разработват така, че 

да бъдат "разширяеми", т.е. каквото и да се въведе в бъдеще, да може да се използва. 

По този начин се появяват нови стандарти и технологии [2]. Следва кратко описание на 

основните термини и технологии свързани с уеб услугите. 

Разширяем език за маркиране – (Extensible Markup Language – XML). XML, 

подобно на езика за маркиране на хипертекст (Hypertext Markup Language - HTML), 

произлиза от стандартен обобщен език за маркиране (Standard Generalized Markup 

Language - SGML). Една от характеристиките на SGML е разделянето на формата от 

съдържанието, т.е. формата се описва независимо от съдържанието на документа. Този 

принцип на езиците за маркиране се използва при уеб услугите. Чрез него се разделят 

данните в един документ от схемата, която описва тяхната структура и техния тип. 

XML е основата върху, която са изградени уеб услугите. Той осигурява формата за 

описание, съхраняване и пренасяне на данни, обменяни чрез уеб услуги. Използва се и 

за създаването на технологии за уеб услуги, които обменят данни. Комуникацията 

между различни уеб услугите се осъществява чрез обмен на форматирани инстанции на 

XML документи, които пренасят данни. Те се описват, като се използват XML схеми, 

които дефинират различни типове от данни и структурата на самият документ. 

Основното предимство, което XML предлага на уеб услугите, е независимост на

- 131 - 

данните, т.е. типовете данни и структурите не са обвързани с основните реализации на 

услугите. За да се извлече полза от независимостта на данните е необходимо 

приложенията да преобразуват данни в XML и да трансформират данни от XML в 

естествения им формат. 

Език за описание на уеб услуги – (Web Service Description Language - WSDL). 

WSDL осигурява механизъм, чрез който дефинициите на уеб услугите са достъпни за 

външния свят. Той описва типове данни и структури за уеб услуги и как те да се 

съгласуват в обменяните съобщения. WSDL е дефиниран по начин даващ възможност 

елементите му да бъдат разработвани отделно и да могат да се комбинират при 

създаване на подробен WSDL файл. Типовете данни и структурите могат да бъдат 

споделяни между множество съобщения, както и самите дефиниции на услугите. 

WSDL описва интерфейсите и в рамките на даден интерфейс асоциира всяка услуга с 

основно приложение. За да се постигне комуникацията при уеб услугите, WSDL ги 

съгласува с комуникационните и транспортни протоколи. При взаимодействие на уеб 

услуги и двете страни споделят общ WSDL файл. Подателят използва този файл, за да 

генерира съобщение в съответния формат и да използва подходящия комуникационен 

протокол. Получателят от своя страна използва същия файл, за да разбере как да 

получи и анализира съобщението и как да го съгласува с основните обекти или със 

софтуерна програма. 

Протокол за достъп до обекти – (Simple Object Access Protocol – SOAP). След 

като е дефиниран интерфейса за уеб услуги е необходим начин за комуникация между 

тях с цел обмен на съобщения. SOAP дефинира общ формат за XML съобщения. 

Проектиран е като механизъм, който може да бъде разширен така, че да обхваща 

допълнителни характеристики, функции и технологии. SOAP представлява 

еднопосочна асинхронна технология за изпращане на съобщения, която може да бъде 

използвана за дистанционно извикване на процедури, документно-ориентирано 

публикуване и други. Този протокол е дефиниран на много ниско ниво на абстрактност 

и той може да бъде съгласуван с произволен брой софтуерни системи, включително 

приложни сървъри, системи за управление на бази от данни и пакетни приложения [1]. 

SOAP специфицира формата на заявката и формата на нейните параметри, той е 

свързан само със съобщението и не налага изисквания към самите уеб услуги и техните 

потребители. 

Универсално описание, откриване и инсталиране – (Universal Description, 

Discovery, and Integration - UDDI). UDDI е стандарт за публичен регистър за 

"складиране" на информация и за публикуване на уеб услуги (http://www.uddi.org). Като 

примери за UDDI регистри могат да се открият в Интернет на адреси: 

http://www.xmethods.net и http://uddi.microsoft.com [2]. UDDI регистърът може да бъде 

претърсван по различни критерии за категоризиране с цел намиране на информация за 

фирми, предлагащи специфични услуги. Виртуалното пространство се нуждае от 

UDDI, за да се осигури хранилище с информация за уеб услуги, като по този начин 

създатели и потребители да имат възможност да се откриват взаимно. Така различни 

потребители ще могат да осъществяват достъп до реализации на уеб услуги навсякъде 

по света. [1]. 

3. Разпределена разработка чрез уеб услуги 

Уеб услугите променят начина, по който е необходимо да се възприемат 

разпределените софтуерни системи (distributed software systems). Идеята на 

разпределеното изчисление е да се разделят функционалните компоненти на една 

софтуерна система, като с това се постига по-добро разпределение и сигурност на 

работното натоварване. 


- 132 - 

Дистанционното извикване на процедури (RPC) през Интернет не е нищо ново. 

Това, което прави уеб услугите новаторски, е идеята, че различни клиенти и различни 

сървъри, могат да използват такива услуги. Без значение е езика на който са 

реализирани, или вида и операционната система на устройствата на които се намират. 

Те позволяват на приложенията да споделят данни и функционалност по един 

универсален начин. Много модели на разпределена разработка са базирани на системи 

със "затворена" функционалност. Интегрирането на различни системи е все още много 

трудно, но нуждата от това е значителна. Като пример може да се посочи 

обединяването на мащабна счетоводна система с производствена система. Чрез уеб 

услугите, функционалните компоненти на една софтуерна система са изложени пред 

много потребители. Потребител, например може да бъде уеб сайт, който от своя страна 

използва уеб услуги, осигурени от други доставчици. 

Основните елементи на уеб услугите са самите услуги, клиентите, развойните 

инструменти и сървърите. На Фиг. 1 е представена идеята как различни приложения, 

сървъри и уеб услуги комуникират помежду си. 

мобилен 

телефон 

PDA 

сървър 


уеб 

услуги 

сървър 

Фиг. 1. Топология на уеб услугите. 


сървър 


На Фиг. 1 може да се видят клиенти, които са свързани с уеб услуги, които от 

своя страна са свързани със сървъри. Когато един клиент се свързва с уеб услуга, за да 

получи данни от сървър, той се явява потребител (консуматор) на уеб услугата. 

Възможно е също така даден сървър да използва уеб услуга, за да получи данни от друг 

сървър. В този случай сървъра също се явява като консуматор на услугата. Част от 

услугите могат да бъдат "вътрешни", а други "външни" за информационната система на 

дадена организация [2].

- 133 - 

4. Използвани технологии и софтуерни продукти 

В настоящата статия ще бъдат представени реализациите на две уеб услуги, 

съответно за проверка на единен граждански номер (ЕГН) и втора, предоставяща 

информация за населените места в Р. България. Обемът на настоящата статия не е 

достатъчен, за да се разгледат подробни всички използвани технологии и софтуерни 

продукти, затова те ще бъдат само представени. 

За създаването на уеб услугите и примерното приложения, е използвана 

визуалната среда за проектиране и събитийно-ориентирано програмиране – Developer 

Studio 2006 на фирмата Borland. Системата за управление на релационни бази от данни 

– Microsoft SQL Server 2005 е използвана за съхраняване на информацията за 

населените места, необходима при реализацията и използването на втората уеб услуга. 

За създаването на динамични уеб страници и уеб услуги е използвана машината за 

обработка на скриптове – ASP (Active Server Pages), съвместно с уеб сървъра Internet 

Information Server (IIS) на фирмата Microsoft. Използваната технология е .NET, която 

има за цел: бързо и лесно разработване, внедряване и съвместимост на приложения [2]. 

5. Уеб услуга за проверка валидността на единен граждански номер (ЕГН) 

Единният граждански номер се състои от десет цифри, като първите шест са 

датата на раждане, следващите три са поредност на раждането (число между 000 и 999), 

като деветата цифра е четна за момче и нечетна за момиче. Десетата цифра е контролна 

и се изчислява като цифрите от 1 до 9 се умножат съответно по теглата: 2, 4, 8, 5, 10, 9, 

7, 3 и 6, тяхната сума се раздели на 11 и се вземе остатъка от делението. Алгоритъмът е 

реализиран във функция с име check_pn (виж. Фиг. 2). Тази функция приема като 

параметър символен низ с дължина десет знака, съдържащ единният граждански номер, 

който ще бъде проверен за валидност. 

Фиг. 2. Функцията check_pn, реализирана на езика Object Pascal. 

Функцията check_pn е реализирана като метод на клас. Нейната декларация се 

предхожда от атрибута [WebMethod]. Този атрибут определя, че метода на уеб услугата 

ще бъде достъпен от външни приложения, който ще могат да го използват. 

6. Уеб услуга предоставяща информация за населени места в Р. България 

За реализацията на тази уеб услуга беше създадена база от данни "nasmesta", 

която притежава три таблици, съответно таблица за областите, таблица за общините и 

таблица за населените места. Връзката между таблиците "области" и "общини" е еднокъм-много. 

Връзката между таблиците "общини" и "населени места" също е едно-къммного. 

Функцията get_all_places е реализирана също като уеб метод (виж Фиг. 3). 


- 134 - 

Фиг. 3. Функцията get_all_places, реализирана на езика Object Pascal. 

Във функцията се декларират три променливи, съответно Conn – за връзка към 

базата от данни, DS – за съхраняване на получените данни от сървъра в паметта и DA – 

за свързване между източника на данни и тези данни, които са съхранени в паметта. В 

защитен режим (try...except блок) се извършват операциите по създаването и 

настройването на обектите, след което метода Fill на обекта DataAdapter (DA), активира 

връзката до сървъра за бази от данни (променливата Conn) и изтегля данните от 

таблицата "tbl_oblasti", след което ги предоставя на обекта DataSet (DS). Функцията 

връща получените данни в паметта на извикващата програма, като трансформира 

обекта DS в XML формат. 

7. Използване на реализираните уеб услуги 

Когато се извика адреса на услугата без параметри, ASP.NET връща описанието 

на услугата във вида, показан на Фиг. 4А. 

Фиг. 4А. Методи на уеб услугата. Фиг. 4Б. Описание на уеб услугата.

- 135 - 

Показани са имената на методите, достъпни от потребителя на уеб услугата. 

Също така е визуализирана описателна информация за всеки един от показаните 

методи. Когато потребителя избере препратката "Service Description" (описание на 

услугата), се показва страницата представена на Фиг. 4Б. На нея се вижда описанието 

на услугата в XML формат, познато като WSDL код на услугата (виж т.2). Това 

описание се използва от инструменти, които могат автоматично да генерират класове, 

скриващи специфичните параметри по извикването на уеб услугата. Тези класове се 

наричат прокси класове. Предложените методи на Фиг. 4А, могат да бъдат тествани, 

като се избере някой от тях (например check_egn), след което от страницата показана на 

Фиг. 5А се въведе стойност за ЕГН в текстовото поле и се натисне бутона Invoke. 

Резултата от изпълнението е показан на Фиг. 5Б. 

Фиг. 5А. Тестване на уеб услугата. Фиг. 5Б. Резултат от тестване. 

Всяко приложение, което ще използва дадена уеб услуга е необходимо да 

изпълни три стъпки за това: Първо, откриване на уеб услугата (това е процеса по 

получаване на информация за уеб услугата, т.е. необходимо е да се открият достъпните 

методи, свойства, типове, параметри и т.н. WSDL документа (виж Фиг. 4Б) трябва да 

бъде разгледан за всяка уеб услуга, която ще се извиква, защото чрез този документ, 

уеб услугите описват себе си на приложенията, които ще ги използват. Второ, 

създаване на прокси клас, реализиран като междинен слой, между HTTP SOAP заявката 

към уеб сървъра и кодът, който се пише за отправяне на тази заявка. Трето, използване 

на прокси класа, за извикване на методи на уеб услугата. Прокси класът изпълнява 

ролята на обект заместител на уеб услугата и декларира методи, които могат да бъдат 

извиквани от консумиращото приложение, което пък от своя страна извиква методи на 

уеб услугата. Дефинират се два начина за извикване на методи на уеб услугата. Може 

да се направи синхронно или асинхронно извикване на методи. Синхронните методи 

имат същите имена като тези предоставяни от уеб услугата, например check_pn(). 

Асинхронното извикване на методи изисква два метода за всеки метод на уеб услугата. 

Дефинират се чрез използването на следния формат: Begincheck_pn и Endcheck_pn. 

На Фиг. 6 е представено примерно приложение, което използва уеб услуги, за да 

визуализира на потребителя исканата от него информация. Когато се избере област от 

секцията "Списък на областите", се извиква метода get_obstini на уеб услугата, който 

изисква да му бъде предаден параметър от символен низ, съдържащ името на избраната 

област. Този метод се обръща към сървъра за бази от данни и извлича списък на 

общините към избраната област. Този списък чрез генерирания прокси клас се предава 

на списъчния контрол за визуализиране. По аналогичен начин протича процеса при 


- 136 - 

избор на община и съответно визуализиране на списъка с населени места в секцията 

"Списък на населените места". 

Фиг. 6. Сесия на работа с приложение, използващо уеб услуги. 


В заключение ще отбележим, че когато софтуерните системи се разработват като 

съвкупност от различни уеб услуги, може да се извлече полза от използването на тези 

уеб услуги и за други цели. Както идеята на обектно-ориентираното програмиране е, да 

се създават компоненти, които други разработчици да могат да използват, като ги 

свързват в своя изходен код, по подобен начин уеб услугите издигат тази идея на ново 

ниво, като предоставят възможност да бъде използвана тяхната функционалност, 

осигурена чрез общ интерфейс. Когато се използват повторно вътрешни и външни 

услуги, продуктивността на разработването на софтуерни продукти се увеличава 

значително. 


1. E. Newcomer. Understanding Web Services: XML, WSDL, SOAP and UDDI, Addison 

Wesley Professional, 2002. 

2. X. Pacheco. Delphi for .NET Developer's Guide, Sams, 2004. 

3. M. Cantu. Mastering Delphi 6, Sybex, 2001. 


South-West University "Neofit Rilsky" – Blagoevgrad 



BULGARIA 

E-mail: velin_kralev@abv.bg

- 137 - 




BULGARIA 

ALGORITHM FOR PROPAGATION TO BASE 

CONJUNCTIONS FOR THE 2P-METHOD FOR QUERY 

PROCESSING IN DEDUCTIVE DATABASE SYSTEMS 

VELKO ILTCHEV 

Abstract. An algorithm for propagation to base conjunctions has been proposed. The 

appropriate data structures for holding the original and the propagated rule sets have also 

been described. The algorithm finds an implementation in the 2P-Method for query 

processing in deductive database systems, developed by the author of this paper. 

Key words: deductive databases, query processing, algorithms. 

АЛГОРИТЪМ ЗА ТРАНСЛАЦИЯ ДО БАЗОВИ КОНЮНКЦИИ 

ЗА 2P-МЕТОД ЗА ОБРАБОТКА НА ЗАПИТВАНИЯ 

В ДЕДУКТИВНИ БАЗИ ДАННИ 


Една дедуктивна система за бази данни дава възможност за дефиниране на 

система от правила, с чиято помощ да бъде извличана допълнителна информация от 

фактите, съхранявани в конвенционална база дани. За дефиниране на системата от 

правила се използва език за логическо програмиране (със синтаксис, подобен на езика 

ProLog). Дедуктивен механизъм, вграден в системата и наричан още инферентна 

машина, интерпретира системата от правила, като по този начин извлича нови факти от 

базата данни. 

Обикновено в практиката, фактите се съхраняват в релационна база данни. 

Инферентната машина се явява надстройка над тази релационна база данни. Въз основа 

на зададените правила тя изпраща запитвания към релационната база данни, 

интерпретира отговорите и при необходимост ги използва за формиране на нови 

запитвания. За формирането на тези запитвания се използват стандартни декларативни 

езици за програмиране, като например SQL. От тази гледна точка инферентната 

машина може да бъде разглеждана като езиков процесор, транслиращ системата от 

правила (описани на език за логическо програмиране, като напр. ProLog) в запитвания 

към релационната база данни (описани на декларативен език като напр. SQL). 

Методите за обработка на запитвания в дедуктивни бази данни могат да бъдат 

класифицирани в две групи, в зависимост от посоката на движение на инферентния 

процес (от фактите към запитването или обратно): 

- низходящи методи - при тях инферентната машина тръгва предиката, свързан 

със запитването, и се опитва, посредством субституция на аргументите му, да намери 

валидни факти в базата данни. При този подход не се генерират излишни факти, както 


- 138 - 

това става при възходящите методи. Недостатък на низходящите методи е, че в общия 

случай те извличат информацията от базата данни запис-по-запис. Затова те не могат да 

използват ефективно мощните множествени операции от релационната алгебра като: 

селекция, проекция, join и др. 

- възходящи методи - при тях инферентната машина тръгва от фактите, като 

прилага правилата за да генерира нови факти. След като фактите бъдат генерирани, те 

се сравняват с главата на правилата, свързани със запитването. Този подход позволява 

да бъдат използвани ефективно множествените операции: селекция, проекция, join и 

др., което прави инферентния процес множествено-ориентиран. Недостатък на 

въззходящите методи е, че отначало се генерират всички факти, голяма част от които 

не съответстват на подаденото запитване. Това е неефективно при големи бази данни. 

За целта трябва да се търси стратегия за генериране само на фактите, отговарящи на 

подаденото запитване. 

Статията предлага една такава стратегия, разработена от автора и наречена от 

него 2P-метод, както и алгоритъм за транслация до базови конюнкции за този метод. 

2. Терминология 

Съгласно дефинициите, дадени в [2]: 

- extensional database - е крайно множество от положителни факти. На практика 

тези факти обикновено се съхраняват в таблици на релационна база данни. Терминът 

extensional database ще бъде превеждан оттук-нататък като външна база данни и ще 

бъде съкращаван като EDB. 

- intensional database - е крайно множество от породени релации, дефинирани 

посредством множество от правила. Терминът intensional database ще бъде превеждан 

оттук-нататък като вътрешна база данни и ще бъде съкращаван като IDB. 

- database predicate - той съответства на релационна таблица от външната база 

данни, при което аргументите му съответстват на атрибутите на тази релационна 

таблица. Терминът database predicate ще бъде превеждан оттук-нататък като предикат 

от базата данни и ще бъде съкращаван като dbp. 

- rule-defined predicate - това е предикат, дефиниран посредством правило. Той 

се състои от глава, която представлява един единствен позитивен литерал, и тяло, което 

е поредица от dbp и rdp предикати, разделени със запетаи. Главата и тялото са 

разделени посредством :- . Терминът rule-defined predicate ще бъде превеждан оттукнататък 

или като дефиниран посредством правило предикат, или за по-кратко като 

правило, и ще бъде съкращаван като rdp. 

- base conjunction - това е множество от dbp предикати в опашката на правило. 

Терминът base conjunction ще бъде превеждан оттук-нататък като базова конюнкция и 

ще бъде съкращаван като bc. 

Алгоритъм за транслация на базови конюнкции в изрази от релационната 

алгебра е даден в [5]. За описанието му ще бъде използвана следната IDB: 

rdp1(X, Y, Z) :- dbp5(X, T), rdp3(R, Y), dbp4(Z, R, T), rdp4(Y, T, Z). 

rdp1(X, Y, Z) :- dbp1(X, Z, X, Q), rdp2(Q, Y). 

rdp2(X, Y) :- dbp3(Y, _, X). 

rdp3(X, Y) :- dbp1(X, c, Y, _). 

rdp3(X, Y) :- rdp2(Y, Q), dbp2(Q, _, X). 

rdp4(X, Y, Z) :- dbp2(X, Z, R), dbp3(Y, R, _). 

Очевидно, тялото на rdp4 представлява базова конюнкция. За да бъде то 

обработено, трябва да бъдат приложени следните операции от релационната алгебра: 

- join между релационните таблици, кореспондиращи на dbp2 и dbp3, по атрибут 

номер 3 от dbp2 и атрибут номер 2 от dbp3. Причината е, че и двата аргумента са 

означени с едно и също име - R.

- 139 - 

- проекция на първите два атрибута на dbp2 и на първия атрибут на dbp3; 

- селекция, единствено при положение, че съществува аргумент, свързан с 

константа, в главата на правилото или в неговото тяло. 

Съгласно с казаното дотук, релационният израз за rdp4 е: 

π (dbp2 dbp3) 

1,4,2 

3=2 

При това положение запитването: 

:- rdp4(c, b, Z). 

предизвикващо следното свързване на константи към агрументи: 

rdp4(c, b, Z) :- dbp2(c, Z, R), dbp3(b, R, _). 

ще бъде транслирано в: 

Съгласно дефинициите, дадени в [1], един аргумент е свързан (bound), ако той 

получава ограничен набор от стойности. Това може да стане ако е изпълнено едно от 

следните три условия: 

- аргументът е константа; 

- аргументът е свързан вследствие на разпространението на свързването от 

главата към тялото на дадено правило; 

- аргументът участва в dbp, който има поне един свързан аргумент. 

Съгласно последното условие, един dbp е определен, ако притежава поне един 

свързан аргумент. 

Допълнителни дефиниции, дадени в [1]: 

- adornment (свързване) за даден предикат p с n на брой аргументи, представлява 

стринг a с дължина n от азбуката {b,f}, където b е съкращение от bound (свързан), а f е 

съкращение от free (свободен). Редът на аргументите е фиксиран. Начинът на записване 

е p a π c,b,2 (( σ 1=c 

dbp2) 3=2( 

σ 1=b dbp3) ) 

. 

- sideways information passing (sip), което ще бъде превеждано като хоризонтално 

разпространение на информацията, описва как свързването на аргументите се предава 

от главата на правилото към тялото му или към други правила. Неформално 

погледнато, SIP-графът за дадено правило или програма дава последователността, в 

която трябва да бъдат пресметнати предикатите от тялото на правилото. 

Нека имаме рекурсивното правило: 

rdp1(X, Y) :- dbp1(X1, X), rdp1(X1, Y1), dbp1(Y1, Y). 

и запитването: 

:- rdp1(v, Y). 

Тогава SIP-графът, със съответното свързване е: 

rdp1 bf (X, Y) :- dbp1(X1, X), rdp1 bf (X1, Y1), dbp1(Y1, Y). 


- 140 - 

Очевидно, аргументът X1 на предиката rdp1 в тялото на правилото е свързан, 

защото: 

- аргументът X на левия dbp1 е свързан с константа, вследствие на 

разпространението на свързването от главата на предиката към тялото му; 

- следователно левият dbp1 е определен, защото е предикат от базата данни и 

има един свързан аргумент; 

- следователно другият аргумент X1 на dbp1 също е свързан, защото участва в 

предикат от базата данни с поне един свързан аргумент; 

- следователно аргументът X1 на rdp1 също е свързан, вследствие на 

разпространението на свързването от dbp1. 

Аргументът Y1 на rdp1 е свободен, защото за него не е изпълнено нито едно от 

условията, упоменати по-горе. 

В такива случаи (рекурсивен предикат със свободни аргументи) предлагам да се 

генерира множество от записи, за този рекурсивен предикат, със свързани аргументи, 

заменени със стойности от ограничения набор от стойности и със свободни аргументи, 

заменети с NULL. Всеки един от тези записи ще бъде наричат оттук нататък заявка 

(request) и ще бъде записван във временната таблица на предиката, с цел - бъдеща 

обработка. 

3. 2P-Метод за обработка на запитвания 

Това е нов, стратифициран, възходящ метод. Наименувал съм го по този начин, 

тъй като процесът на дедукция преминава през две фази: фаза на разпъване и фаза на 

свиване. На всяка стъпка на итерацията, през всяка една от тези две фази, се изчислява 

диференциал, който представлява множество от нови факти и евентуално нови заявки. 

Този диференциал се записва във временната таблица на предиката, с цел - бъдещо 

използване. Алгоритмите за изчисляване на двата диференциала са различни, за всяка 

една от двете фази. 

Диференциалът от фазата на разпъване е резултат от хоризонталното 

разпространение на информацията от заявките, генерирани на предходната стъпка на 

итерацията. Той е обединение на две множества: 

- множество от факти, генерирани посредством транслация до базови 

конюнкции. Един възможен способ за генериране на тези факти е чрез пренаписване на 

рекурсивните правила, заменяйки предикатите, дефинирани посредством правило, с 

базови конюнкции. Друг способ, предложен в [4], е посредством итерация през графа 

на зависимостите, тръгвайки от базовите конюнкции и движейки се в посока към 

предиката, свързан със запитването; 

- множество от нови заявки, генерирано посредством SIP, при което свързаните 

аргументи идват от базова конюнкция, съставена само от определените предикати в 

тялото на правилото. Тази конюнкция ще бъде наричана оттук нататък определена част 

от конюнкцията (Distinguished Part of Conjunction (DPC)). Свободните аргументи се 

заменят с NULL. 

Така SQL-заявката, генерираща поредния диференциал от фазата на разпъване е: 

SELECT DISTINCT 

FROM BaseConjunction BC 

WHERE BC. IN 

( 

SELECT 

FROM expD CurrentExpandStep-1 

WHERE IS NULL

- 141 - 

) 

AND 

UNION 

SELECT DISTINCT , 

= NULL 

FROM DistinguishedPartOfConjunction DPC 

WHERE DPC. IN 

( 

SELECT 

FROM expD CurrentExpandStep-1 

WHERE IS NULL 

) 

AND 

Фазата на разпъване продължава, докато за поредния диференциал не се получи 

празно множество, или да е равен на предходния. 

Диференциалът от фазата на разпъване ще бъде означаван оттук нататък с 

expD StepNo , където StepNo е номера на поредната стъпка на итерацията. 

Диференциалът от фазата на свиване изчислява посредством заместване на 

срещанията на рекурсивните предикати в телата на правилата, с фактите, генерирани 

през време на фазата на разпъване. По този начин, цялото тяло на съответното правило 

се превръща в базова конюнкция, която генерира нови факти. Нарекъл съм това 

действие обратно заместване (reverse substitution). 

Така SQL-заявката, генерираща поредния диференциал от фазата на свиване е: 

SELECT DISTINCT 

FROM expD MaxExpSteps-CurrentShrinkStep ED, BaseConjunction BC 

WHERE ED. IN 

( 

SELECT 

FROM expD MaxExpSteps-CurrentShrinkStep-1 

WHERE IS NULL 

) 

AND 

UNION 

SELECT 

FROM expD MaxExpSteps-CurrentShrinkStep 

WHERE IS NOT NULL 

Фазата на свиване продължава, докато за поредния диференциал не се получи 

празно множество. 

Диференциалът от фазата на свиване ще бъде означаван оттук нататък с 

shrD StepNo , където StepNo е номера на поредната стъпка на итерацията. 

Използването на оператора DISTINCT в SELECT-клаузата повишава 

допълнително ефективността на метода, тъй като отстранява повтарящите се факти на 


- 142 - 

възможно най-ранен етап (още в момента на тяхното генериране). Най-голямото 

повишаване на ефективността обаче се получава вследствие на вложената операция 

SELECT. Тя се използва за отделянето само на тези факти, които съответстват на 

заявките, генерирани през поредната стъпка от фазата на разпъване. Само отделените 

по този начин факти се използват при обратното заместване в базовите конюнкции 

(виж след оператор AND във WHERE-клаузата). Това намалява значително броя на 

ненужните факти, предавани и препредавани към следващите стъпки на итерацията. За 

сравнение, при методите с пренаписване се отстраняват само ненужните факти извън 

конуса на решението. В предлагания метод освен тези факти се откриват и отстраняват 

и ненужните факти вътре в самия конус на решението, при това на възможно най-ранен 

етап на итерацията. 

4. Алгоритъм за транслация до базови конюнкции 

За целта ще бъдат дефинирани следните структури от данни: 

PredicateType(PredicateID, Args, ArgsCount, IsDBP) 

за съхранение на един предикат от тялото на правилото. Цялото тяло от своя 

страна е масив от тип PredicateType. 

HeadType(PredicateID, Bindings, ArgsCount, IsDBP) 

Всяка система от правила може да бъде разделена на групи от правила, които 

имат за глава един и същи предикат. Структурата HeadType съдържа информацията за 

една такава глава, както и за свързванията на аргументите при положение, че 

предикатът е извикан от тялото на друго правило. Тези връзки се съхраняват в елемента 

Bindings, който е от тип: 

ArgBindings(OriginalName, SubstitutedName) 

Създадена е и допълнителна структура: 

SubstitutionsTable(Table, ArgsCount) 

за съхранение на връзките в тялото на правилото. Елементът Table също е от 

тип ArgBindings. 

Разработени са две взаимно-рекурсивни подпрограми, които извършват 

транслацията на задатената система от правила във функция на предиката, свързан със 

запитването. 

Първата от тях е: 

void LanguageProcessor::PropagatePredicate(PredicateType 

Predicate) 

{ 

HeadType Rules[20]; 

int RulesPointer, RulesCount; 

TCursor Cursor; 

// Селектира подмножество от правила, чиято глава 

// съответства на предиката, който подпрограмата получава 

като аргумент. 

ExecSQL(&Cursor, 

"select ID from RulesTbl where HeadPredID = :PHeadPredID 

and Typ = 1", 

Predicate.PredicateID); 

RulesPointer = 0; 

for(Cursor->First() ; !Cursor->Eof ; Cursor->Next())

- 143 - 

{ 

Rules[RulesPointer].PredicateID = Cursor- 

>FieldByName("ID"); 

RulesPointer++; 

} 

RulesCount = RulesPointer; 

// За всяко от селектираните правила 

for(RulesPointer = 0 ; RulesPointer < RulesCount ; 

RulesPointer++) 

{ 


"select ArgName \ 

from RuleHeadArgsTbl \ 

where RuleID = :PRuleID \ 

order by ID", 

Rules[RulesPointer].PredicateID); 

// Свързва аргументите от главата с аргументите на 

предиката, 

i = 0; // от който е станало извикването 

for(Cursor->First() ; !Cursor->Eof ; Cursor->Next()) 

{ 

Rules[RulesPointer].Bindings[i].OriginalName = 

Cursor->FieldByName("ArgName"); 

Rules[RulesPointer].Bindings[i].SubstitutedName = 

Predicate.Args[i].ArgName; 

} 

Rules[RulesPointer].ArgsCount = i; 

} 

// Рекурсивно извиква подпрограмата, обработваща опашката 

на правилото 

for(RulesPointer = 0 ; RulesPointer < RulesCount ; 

RulesPointer++) 

PropagateRule(Rules[RulesPointer]); 

} 

Тази подпрограма селектира най-напред подмножество от правила, чиято глава 

съответства на предиката, който тя получава като аргумент. След това, за всяко едно от 

селектираните правила, подпрограмата извършва: 

- свързване на аргументите от главата на правилото с аргументите на предиката, 

от който е станало извикването. Това се налага, тъй като независимо дали това е 

предикатът, свързан със запитването, или е предикат от тялото на друго правило, 

агрументите му са: или свързани с константи и/или преименувани вследствие на 

хоризонталното разпространение на информацията. 

- извикване на подпрограмата PropagateRule(HeadType Head) за 

обработка на тялото на всяко едно от селектираните правила. 

Тази втора подпрограма е: 

void LanguageProcessor::PropagateRule(HeadType Head) 

{ 


- 144 - 

int i; 

int PropagatedRuleID; 

PredicateType RuleBody[20]; 

int RBPointer, RBLength, ArgsCount, OutputRuleReper; 

OutputRuleReper = OutputRulePointer; 


// Селектира предикатите от тялото на правилото 


"select R.BodyPredID, P.Typ \ 

from RuleBodiesTbl R, PredicatesTbl P \ 

where R.RuleID = :PRuleID and R.BodyPredID = 

P.ID", 

Head.PredicateID); 

RBPointer = 0; 


{ 

RuleBody[RBPointer].PredicateID = Cursor- 

>FieldByName("BodyPredID"); 

RuleBody[RBPointer].IsDBP = (Cursor->FieldByName("Typ") 

== 1); 

RBPointer++; 

} 

RBLength = RBPointer; 

// За всеки един от предикатите от тялото на правилото 

for(RBPointer = 0 ; RBPointer < RBLength ; RBPointer++) 

{ 


"select ArgName \ 

from RuleBodyArgsTbl \ 

where RuleBodyID = %d \ 

order by ID", 

RB[RBPointer].PredicateID); 

// Извършва субституция на аргументите му 

i = 0; 


{ 

RuleBody[RBPointer].Args[i] = 

SubstituteArgument(Cursor->FieldByName("ArgName"), 

Head); 

i++; 

} 

RuleBody[RBPointer].ArgsCount = i; 

} 

for(RBPointer = 0 ; RBPointer < RBLength ; RBPointer++) 

if(RuleBody[RBPointer].IsDBP || 

(RuleBody[RBPointer].PredicateID == 

GoalPredicate.PredicateID))

- 145 - 

{ // Ако това е предикатът свързан със запитването 

OutputRule[OutputRulePointer] = RuleBody[RBPointer]; 

OutputRulePointer++; 

} 

else PropagatePredicate(RuleBody[RBPointer]); // Влизане 

в рекурсия 

// Записва транслираното вече правило 

OutputRulesTable.Add(OutputRule, OutputRulePointer); 

// Възстановява позицията на показалеца по тялото на 

правилото 

OutputRulePointer = OutputRuleReper; 

} 

Тази подпрограма обработва тялото на правилото, чиято глава получава като 

аргумент. За целта подпрограмата селектира предикатите от тялото на полученото 

правило и за всеки един от тях: 

- извършва субституция на аргументите му, като за целта използва 

информацията от SubstitutionsTable; 

- ако поредният предикат е предикат от базата данни, то подпрограмата прескача 

на следващия предикат от тялото на правилото; 

- ако поредният предикат е дефиниран посредством правило, то: 

- подпрограмата инициализира репер, с цел - съхраняване на позицията на 

показалеца по тялото на правилото, където ще бъде извършено разпъване; 

- подпрограмата извиква рекурсивно PropagatePredicate 

(CurrentBodyPredicate) за да обработи подмножеството от правила, които имат 

за глава текущия предикат CurrentBodyPredicate. 

След връщането от рекурсия, подпрограмата PropagateRule( ) записва 

транслираното вече правило в таблицата с изходни правила и възстановява показалеца 

по тялото на правилото. 


Предлаганият в статията алгоритъм има специфично приложение, а именно в 

2P-метода за обработка на запитвания в дедуктивни бази данни. 

2P-методът от своя страна формира същия конус на решението както и 

методите, използващи пренаписване. Така той постига същия оптимизационен ефект, 

както и тези методи, когато става въпрос за отстраняване на фактите, намиращи се 

извън конуса на решението. Предимството предложения нов метод е, че освен фактите 

извън конуса на решението се откриват и отстраняват и ненужните факти вътре в самия 

конус, при това на възможно най-ранен етап на итерацията. Това става благодарение на 

въведената допълнителна селекция, при изчисляването на диференциалите от фазата на 

свиване. Тази селекция намалява значително броя на ненужните факти, предавани и 

препредавани към следващите стъпки на итерацията. 

Предлаганият алгоритъм за транслация до базови конюнкции е предназначен за 

реализация на езици от високо ниво, поддържащи рекурсия, като напр. C++ и Pascal. 

Последните са удобни за използване и като host-езици, за изпращане на SQL-заявки 

към външната база данни. 

За тестване на алгоритъма за транслация до базови конюнкции и 

съответнстващия му 2P-метод, е разработена програмна среда, съдържаща: текстови 

редактор за програмата на логически език; езиков процесор, реализиращ описания 

алгоритъм; връзки към стандартни машини за релационни бази данни. 


- 146 - 


1. C. Beeri and R. Ramakrishnan. On the Power of Magic, Proceedings of the sixth ACM 

SIGACT-SIGMOD symposium on Principles of Database Systems, pp. 269-284, ISBN: 0- 

89791-223-3, San Diego, California, United States, 1987, ACM Press New York, NY, 

USA. 

2. S. Ceri, G. Gottlob and L. Tanka. Logic Programming and Databases, Springer-Verlag, 

ISBN 3-540-51728-6, Berlin. 

3. V. Iltchev. Bottom-Up Method for Processing Recursive Sets of Rules, International 

Conference on Computer Systems and Technologies, pp. II.18.1-II.18.6, ISBN 954-9641- 

33-3, 19-20 June, 2003, ACM-acmbul&UAI, Sofia, Bulgaria. 

4. V. Iltschev. Bottom-Up Method for Processing Nonrecursive Sets of Rules, 13-th 

International DAAAM Symposium, pp. 223-224, ISBN 3-901509-20-1, 23-26 October, 

2002, Vienna University of Technology, Vienna, Austria. 

5. J. Ullman. Implementation of logical query languages for databases, ACM Transactions on 

Database Systems (TODS), Vol. 10, No 3, September 1985, pp. 289 - 321, ISSN: 0362- 

5915. 




4000 Plovdiv 

BULGARIA 

E-mail: iltchev@tu-plovdiv.bg

- 147 - 




BULGARIA 

STORAGE, MANIPULATION AND RETRIEVAL 

OF ORDERED XML INTO/FROM 

RELATIONAL DATABASES 

VELKO ILTCHEV 

Abstract. The paper proposes a relational database model for holding structure and items 

of ordered XML-documents. The appropriate algorithms for storing, manipulating and 

retrieving of data, implemented as procedures in C++ as a host-language, have also been 

described. 

Key words: XML, relational databases, XPath, information retrieval. 

СЪХРАНЕНИЕ, ОБРАБОТКА И ИЗВЛИЧАНЕ 

НА ПОДРЕДЕН XML В/ОТ РЕЛАЦИОННИ БАЗИ ДАННИ 


XML е съкращение от eXtensible Markup Language, което в превод означава - 

разширяем език за описание на документи [3]. Той дава възможност данните да бъдат 

съхранявани в техния естествен вид, така както са в оригиналния документ. Най-често, 

структурата на тези данни нарушава изискванията на Първа нормална форма при 

релационните бази данни. Затова и системите, съхраняващи данни с подобна структура 

са известни още като NF 2 -бази данни, което е съкращение от NonFirstNormalForm. 

При тях, вместо за модел на базата данни, напр. ER-модел, се говори за 

граматика, описваща структурата на документите. Двата най-разпространени начина за 

описание на тази структура са: 

- посредством DTD, съкращение от Data Type Definition [4] 

- посредством XSD, съкращение от eXtensible Stylesheet Definition [5]. 

В статията ще бъде използван XSD, като по-нов способ, даващ възможност попрецизно 

да бъдат дефинирани брой на включвания на даден възел в родителски възел, 

да бъдат дефинирани пространства от имена и други. Предлаганите в статията 

алгоритми са приложими и при документи, дефинирани посредством DTD. 

Както вече бе споменато, предимството на съхраняването на данни в XMLформат 

е опростената структура, близка до тази на оригиналния документ. Основният 

проблем обаче е, че тези данни се съхраняват обикновенно под формата на текст, което 

от своя страна води до бавно търсене, вмъкване и изтриване на информация. 

В противовес на това, релационни бази данни имат сложна структура, НО 

търсенето, вмъкването и изтриването на информация е бързо. 


- 148 - 

Затова, целта на множество съвременни разработки в тази област е комбинация 

на предимствата на двата подхода: XML-структура на данните, близка до естествената, 

съхранявана обаче в релационна база данни, с цел - използване на бързите алгоритми за 

търсене, обработка и извличане на информация, характерни за релационните бази 

данни. 

Тази статия предлага модел на релационна база данни, подходящ за съхранение 

както на самите документи, така и на тяхната структура. Описани са също така и 

разработените от автора алгоритми, за: обработка на XPath [6], търсене, обработка и 

извличане на информацията от така предложената структура на релационна база данни. 

2. Структура на данните 

В [2] е предложена следната структура на релационна таблица: 

XMLDataTbl(ID, TagName, NodeValue, ParentID) 

с цел: 

- съхраняване на информацията във възлите на документа, 

- съхраняване връзките между самите възли. 

В същата публикация се предлага, вместо име на таг, да се използва пътеката до 

този таг. Причината е, че имена на тагове могат да се повтарят на различни нива в 

структурата на документа. Предлага се също така, тази пътека да се съхранява не като 

стринг, а в отделна таблица, отново с авторекурсивна връзка между полетата. По този 

начин, в таблицата с данните, описана по-горе е достатъчно да се записва само ID на 

тага, тъй като той носи информация и за пътеката до него. 

С настоящата статия предлагам, в тази втора таблица, описваща структурата на 

документа, да се съхранява и допълнителна информация за: 

- името на релационната таблица; 

- името на полето от тази релационна таблица; 

- типа на това поле 

които съответстват на дадения таг. Важно е да се отбележи, че съответствието 

таг→поле от базата данни, е еднозначно. Така, предлаганата структура на тази таблица 

ще изглежда по следния начин: 

XMLStructTbl(ID, TagName, TableName, FieldName, FieldType, ParentID) 

Това ще доведе и до следната промята в таблицата с данните, чиято структура 

вече ще бъде: 

XMLDataTbl(ID, TagNameID, NodeValueID, ParentID) 

При извличане на информация, най-напред през TagNameID се намират 

таблицата, полето и неговия тип, а стойността му е в ред, сочен от NodeValueID. Този 

начин на представяне има и още едно предимство, а именно, че типът на полето 

NodeValueID е атомарен - цяло число, независимо от различния тип данни в отделните 

възли. 

Предлагам също така, когато при извличането на информацията за host-език се 

използва C++ или Pascal, стойността на възела да бъде извличана в променлива от тип 

Variant. Този тип е имплементиран като клас в библиотеките на повечето модерни 

компилатори. Това дава възможност да бъде унифицирана подпрограмата, извършваща 

извличането на информацията. 

3. Способи за номериране на възлите на XML-документ 

За пример ще бъде използвана следната XSD-схема, описваща структурата на 

един закон от областта на правото:

- 149 - 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Съгласно тази схема, един закон има име и поне един, а може и повече членове. 

Един член може да съдържа директно законовия текст или да съдържа поне една, а 

може и повече алинеи, като всяка една от тях има име и законов текст. 

#текст 

име 

2 

име 

член 

3 

4 5 

текст 

#текст #текст 

име 

#текст 

закон 1 

7 

име текст 

#текст 

алинея 

9 

#текст 


фиг. 1. Глобална номерация на възли 

8 

член 

10 

6 

име 

#текст 

алинея 

11 

12 13 

текст 

#текст

- 150 - 

3.1. Глобална номерация на възли 

При глобалната номерация, на всеки възел се присвоява число, показващо 

абсолютната позиция на този възел в цялото дърво на документа. Удобен за 

извършване на такъв тип номериране е алгоритъмът за обхождане на възлите в 

дълбочина. Схемата на документ, номериран по този начин, е дадена на фиг. 1. 

За съхраняване на тази допълнителна информация се налага следната промяна в 

таблицата с данните: 

XMLDataTbl(ID, TagNameID, NodeNumber, NodeValueID, ParentID) 

Добавено е полето NodeNumber, което съхранява абсолютната позиция на 

текущия възел в цялото дърво на документа. 

3.2. Локална номерация на възли 

При локалната номерация, на всеки възел се присвоява число, показващо 

относителната позиция на този възел спрямо възлите, с които той има пряк-общ 

родител. Удобен за извършване на такъв тип номериране е алгоритъмът за обхождане 

на възлите в ширина. Схемата на документ,номериран по този начин,е дадена на фиг. 2. 

Абсолютната позиция на възела в целия документ може да бъде възстановена, 

тъй като са известни възлите, на които той е наследник. 



XMLDataTbl(ID, TagNameID, NodeIndex, NodeValueID, ParentID) 

Добавено е полето NodeIndex, което съхранява относителната позиция на 

текущия възел спрямо възлите, с които той има пряк-общ родител. Този индекс се 

нуждае от опресняване при всяко вмъкване или изтриване на възел. 

#текст 

име 

1 

име 

член 

2 

1 2 

текст 


име 

#текст 

закон 1 


#текст 

алинея 

#текст 

3.3. Номерация на Dewey 

Този способ за номериране е предложен за първи път от Melvil Dewey, като 

система за класифициране на библиотечна информация [1]. При този способ, на всеки 

възел се присвоява вектор, съдържащ пътя от корена на документа, до този възел. 

Удобен за извършване на такъв тип номериране отново е алгоритъмът за обхождане на 

възлите в дълбочина. Схемата на документ, номериран по този начин,е дадена на фиг.3. 

Абсолютната позиция на възела в целия документ може да бъде възстановена, 

тъй е известен пътят до всеки един възел. 

член 

фиг. 2. Локална номерация на възли 

1 

1 

2 

2 

3 

име 

#текст 

алинея 

3 

1 2 

текст 

#текст

- 151 - 



XMLDataTbl(Dewey, TagNameID, NodeValueID, ParentID) 

Вижда се, че първичният ключ ID е сменен с полето Dewey, което съхранява 

векторa, съдържащ пътя от корена на документа, до текущия възел. Тъй като този 

вектор има уникална стойност за всеки един възел от дървото, то той може да се 

използва и за първичен ключ на таблицата. 

#текст 

При вмъкване или изтриване на възел за всеки един от тези три способа, се 

налага преномериране на възлите, което изглежда по начина, даден на фиг.4. 

фиг. 4. 

име 

1.1 

име 

член 

1.2 

1.2.1 1.2.2 

текст 


име 

#текст 

закон 1 

1.3.1 

а) б) 


#текст 

алинея 

1.3.2.1 

#текст 

#текст 

Възли, които трябва да бъдат преномерирани, след вмъкване на възел, при: 

а) глобална номерация, б) локална номерация, в) номерация на Dewey 

4. Модификация на Локалната номерация на възли 

Целта на предлаганата модификация е да се намали броят на възлите, които се 

налага да бъдат преномерирани, при вмъкване или изтриване на възел. 

За постигането на тази цел предлагам, допълнителното поле в таблицата с 

данните да се използва за създаване на свързан списък на възлите, с които текущия 

възел има пряк-общ родител. За тази цел това поле няма да съдържа абсолютна 

позиция, както е при глобалната номерация или индекс, както е при локалната 

номерация, а номера на предходния възел от списъка и по точно, стойността на полето 

му ID. Тя се съхранява в новото поле PrevNodeID. Първият възел в този списък има 

стойност на това поле 0. Така структурата на таблицата с данните добива следния вид: 


член 

1.3.2 

фиг. 3. Номерация на Dewey 

1.3 

име 

#текст 

алинея 

1.3.3 

текст 

1.3.2.2 1.3.3.1 1.3.3.2 

в)

- 152 - 

XMLDataTbl(ID, TagNameID, NodeValueID, PrevNodeID, ParentID) 

Вижда се, че в нея има двойна авторекурсивна връзка: 

- първо, с прекия родител, посредством полето ParentID; 

- второ, с предходния възел от списъка, посредством полето PrevNodeID. 

Предимството на тази структура е, че при вмъкване на възел се налага 

"преномериране" само на възела, преди който е извършено вмъкването. Това 

"преномериране" се изразява в пренасочване (промяна на стойността) на полето 

PrevNodeID. 

4. Алгоритми 

Алгоритмите ще бъдат описани посредством програмен код на C++, използван 

като host-език за отправяне на параметризирани заявки към релационната база данни. 

За последното ще бъде използвана функцията: 

ExecSQL(TCursor *Cursor, AnsiString SQLStatement, TParam 

Parameters); 

която получава SQL-израз и параметри, както и указател към курсор, в който 

връща резултата от заявката. 

Предполага се и наличието на клас TXPath, обекти от който ще се използват за 

съхраняване на XPath-изрази. Този клас има методи: 

bool TXPath::Reset(void); 

bool TXPath::GetNextTag(AnsiString &TagName); 

bool TXPath::GetTagValue(AnsiString &NodeValue); 

които са тривиални и няма да бъдат разглеждани в тази статия. 

4.1. Алгоритъм за търсене. 

XML-документите имат рекурсивна структура. Възможно е обаче търсенето в 

тях да бъде реализирано постедством итеративен алгоритъм, както това е направено в 

следната подпрограма: 

int XPathFind(TXPath &XPath, TCursor &Cursor) 

{ 

int TagID, NodeValueID; 

AnsiString TagName, NodeValue; 

TCursor TagCursor, ParentCursor; 

ExecSQL(&ParentCursor, "select ID from XMLDataTbl where 

TagID = 1"); 

TagID = 1; XPath.Reset(); 

for( ; ; ) 

{ 

if(!XPath.GetNextTag(TagName)) return TagID; // 1 

ExecSQL(&TagCursor, 

"select ID \ 

from XMLStructTbl \ 

where ParentID = :PParentTagID and TagName = 

:PTagName", 

TagID, TagName); 

if(TagCursor.IsEmpty()) return 0; 

TagCursor.First(); 

TagID = TagCursor.FieldByName("ID");

\ 

} 

- 153 - 

XPath.GetTagValue(NodeValue); 

NodeValueID = GetValueID(TagID, NodeValue); 


"select ID \ 

from XMLDataTbl \ 

where TagID = :PTagID and NodeValueID = :PNodeValueID 

and ParentID in (select ID from ParentCursor)", 

TagID, NodeValueID); 

ParentCursor = Cursor; 

} 

В нея, безкрайният цикъл се инициализира с данните от корена на XMLдокумента 

TagID = 1. Цикълът продължава, докато не бъдат анализирани всички части 

на пътеката (виж. // 1). Следващата SQL-заявка извлича тага на наследника, от който се 

интересуваме (съгласно зададената пътека XPath). След това се извлича 

идентификатора на стойността във възела, при положение, че в пътеката има зададено и 

условие. Това става с помощта на следната подпрограма: 

int GetValueID(int TagID, AnsiString NodeValue) 

{ 

AnsiString TableName, FieldName; 


XMLStructTbl.Locate("ID", TagID); 

TableName = XMLStructTbl.FieldByName("TableName"); 

FieldName = XMLStructTbl.FieldByName("FieldName"); 


"select ID from :PTableName where :PFieldName = 

NodeValue", 

TableName, FieldName, NodeValue); 

Cursor.First(); 

return Cursor.Field[0]; 

} 

чието действие е тривиално и затова няма да бъде обсъждано. Накрая, посредством 

втората SQL-заявка, се извлича информацията за наследниците. Така полученият 

курсор, става родител (ParentCursor), за следващото завъртане на цикъла. 

4.2. Алгоритъм за вмъкване на възел 

bool XPathInsert(TXPath&XPath,AnsiString NodeValue,AnsiString 

NewNodeValue) 

{ 

int TagID, NodeID, NodeValueID, PrevNodeID, ParentNodeID, 

NewNodeID, NewNodeValueID; 



- 154 - 

TagID = XPathFind(XPath, &Cursor); // 1 

if(!TagID) return false; 

NodeValueID = GetValueID(TagID, NodeValue); // 2 

XMLDataTbl.Locate("NodeValueID", NodeValueID); 

NodeID = FieldByName("ID"); 

PrevNodeID = FieldByName("PrevNodeID"); 

ParentNodeID = FieldByName("ParentNodeID"); 

NewNodeValueID = InsertValue(TagID, NewNodeValue); // 3 

XMLDataTbl.Insert(TagID, NewNodeValueID, ParentNodeID); 

NewNodeID = FieldByName("ID"); 

ExecSQL("update XMLDataTbl \ 

set PrevNodeID = :PPrevNodeID \ 

where ID = :PID", 

PrevNodeID, NewNodeID); 

ExecSQL("update XMLDataTbl \ 

set PrevNodeID = :PPrevNodeID \ 

where ID = :PID", 

NewNodeID, NodeID); 

} 

Подпрограмата получава пътека до и стойност на възела, преди който ще бъде 

извършено вмъкването, както и стойността на възела, който ще бъде вмъкнат. В блока 

от оператори (// 1) се намира тагът на възела, преди който ще се извършва вмъкването. 

В (// 2) се извлича идентификаторът на този възел, както и на възлите, с които той е 

свързан. В (// 3) се добавя новия възел, като резултат се получават неговият 

идентификатор, както и идентификаторът за неговата стойност. В следващите две SQLзаявки 

се извършва пренареждане на връзките на на вмъкнатия нов възел и на текущия 

възел. 

Алгоритъмът за изтриване на възел действа по подобен начин и затова, поради 

липса на място няма да бъде разглеждан в настоящата статия. 

4.3. Алгоритъм за извличане на XML-документ 

int XPathRetrieve(TCursor &Cursor) 

{ 

int NodeID; 

TCursor ChildCursor; 

Cursor.Locate("PrevNodeID", 0); // Намира началото на 

списъка 

for( ; ; ) 

{ 

NodeID = Cursor.FieldByName("ID"); 

// Вкарва данните от възела в изходния документ 

OutputDoc.InsertData(NodeID); 

ExecSQL(&ChildCursor, 

"select ID from XMLStructTbl where ParentID = 

:PParentID",

- 155 - 

NodeID); 

if(!ChildCursor.IsEmpty()) 

XPathRetrieve(ChildCursor); // Рекурсивно извикване 

if(!Cursor.Locate("PrevNodeID", NodeID))break;//Взема 

следващия елем. 

} 

} 

В случая той е реализиран рекурсивно. Подпрограмата получава курсор, 

изчислен на предишното ниво на рекурсия. Първоначално подпрограмата се 

инициализира с курсор, с TagID = 1, тоест - с корена. 

Подпрограмата обхожда елементите на получения курсор, следвайки свързания 

списък, посредством безкрайния цикъл for( ; ; ). За всеки елемент (възел) от този 

списък, най-напред се извеждат данните му, след което, посредством SQL-заявката, се 

отделят наследниците, в нов курсор ChildCursor. Ако този курсор не е празен, то се 

извършва рекурсивно извикване на подпрограмата, като за параметър й се подава 

курсорът с наследниците. След връщане от рекурсията се взема следващият елемент от 

списъка на братята на текущият възел. Ако няма такъв - излиза се от цикъла и от 

подпрограмата, съответно - от текущото ниво на рекурсия. 


Предлаганата в статията модификация на способа за локална номерация на 

възлите снижава до минимум броя на възлите, които трябва да бъдат преномерирани, 

при вмъкване или изтриване на възел в подреден XML-документ. Този брой се снижава 

до точно два възела и е независим от броя на възлите, с които засегнатият възел има 

пряк-общ родител. 

Предлаганата модификация е удобна за реализация върху произволна, 

стандартна SQL-машина за бази данни. Пакетът от съпътстващи алгоритми може да 

бъде реализиран като библиотека от подпрограми на host-език, поддържащ рекурсия, 

като например C++ или Pascal. Възможна е и нерекурсивна версия на алгоритъма за 

извличане на информацията, като за целта се симулира стек от курсори. За 

реализацията му може да се използва временна таблица, с репери в нея, които пазят 

номера на поредната стъпка на итерацията. 

Библиотеката може да се използва като основа за създаване на езикови 

процесори за обработка на XQuery запитвания, както за извършване на XSLT 

трансформации. 


1. L. M. Chan and J. S. Mitchell. Dewey Decimal Classification: Principles and 

Application, Third edition, 2004, ISBN 0-910608-72-5. 

2. I. Tatarinov, S. D. Viglas, K. Beyer, J. Shanmugasundaram, E. Shekita and C. Zhang. 

Storing and querying ordered XML using a relational database system, Proceedings of the 

2002 ACM SIGMOD international conference on Management of data, Madison, 

Wisconsin, USA, June 03-06, 2002, pp.204-215, ISBN: 1-58113-497-5. 

3. World Wide Web Consortium. Extensible Markup Language (XML) 1.0 (Fourth 

Edition), W3C Recommendation 16 August 2006, edited in place 29 September 2006, 

http://www.w3.org/TR/2006/REC-xml-20060816/ 


- 156 - 

4. World Wide Web Consortium. Datatypes for DTDs (DT4DTD) 1.0, W3C Note 13 

January 2000, http://www.w3.org/TR/2000/NOTE-dt4dtd-20000113/ 

5. World Wide Web Consortium. XML Schema Part 0: Primer Second Edition, W3C 

Recommendation 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-0- 

20041028/ 

6. World Wide Web Consortium. XML Path Language (XPath) Version 1.0, W3C 

Recommendation 16 November 1999, http://www.w3.org/TR/1999/REC-xpath-19991116/ 




4000 Plovdiv 

BULGARIA 

E-mail: iltchev@tu-plovdiv.bg

- 157 - 




BULGARIA 

VALUATION OF AV-PROGRAMS EFFECTIVENESS 

SIMEON MOEV, PETKO BAKALOV 

Abstract. The antivirus (AV) protection is a mandatory software element in any 

Windows-based computer system. This article makes an attempt to compare together and 

estimate the effectiveness of several AV programs by means of different criteria. 

Key words: antivirus software, malware, Trojan horse, virus, worm . 

ОЦЕНКА ЕФЕКТИВНОСТТА НА AV-ПРОГРАМИ 


Днес огромното множество на злоумишлените програми (malware – от malicious 

software) експлоатира изключително разнообразни тактики и цели. Броят на всички 

видове вредни програми е трудно да се фиксира. Приблизително се оценяват над 

550 000 (около 230 000 за DOS и около 320 000 за Windows и други OS) [3]. Бурният 

ръст на този вид IT-продукти доведе и до промяна в класифицирането им. Масовото 

схващане сега е, че към malware спадат вируси (viruses), троянски коне (Trojan horses - 

trojans), червеи (worms), шпионски програми (spyware), измами (hoaxes). Сигурно то 

може да бъде коментирано и променяно. Както може да бъде оспорено и разделението 

само при вирусите на 10 вида [1]. 

Въпреки относителността на класификациите и бройката, едно е сигурно – 

деструктивните програми са способни и нанасят реален вреден ефект на милиони 

потребители в глобалната мрежа [2]. И срещу тях обезателно трябва да се вземат мерки. 

Антивирусните програми са едно от задължителните средства в борбата срещу 

различните malware. Разнообразието при тези защитни средства е голямо, може да се 

каже объркващо. Някои от тях се равиват в пакети от програми със специфични, 

допълващи се функции, но стават тежки, консумират доста системни ресурси. Други 

изтъкват свята компактност и бързина. Оценката коя да бъде предпочетена се превръща 

в нещо достатъчно комплицирано 

2. Цел и методика на работа 

Целта на настоящата проверка беше да се направи сравнение на няколко от найизползваните 

сега у нас антивирусни (AV) програми, чрез което да се подпомогне 

изборът на крайния потребител, работещ в домашни условия или в малък офис. За 

големите, корпоративни мрежи (при всичката условност на българските мащаби), 

условията са различни - там може да се разчита на скъпи, комплексни защитни решения 

и помощта на подготвен мрежов администратор. 


- 158 - 

Всяка от проверяваните AV-програми беше самостоятелно инсталирана на РС с 

параметри: CPU Duron 1300MHz, RAM 384MB, HD 40GB, Windows XP SP2. 

За целите на експеримента бяха използвани три архива – с 6850 вируси, с 680 

троянски коне и с 450 червеи. Общ брой malware – 7980. Всяка от програмите сканира 

всеки един от архивите след като е обновена с най-новите за деня вирусни дефиниции. 


Архивите съдържат следните типове заразени файлове: .exe, .com, .class, .php, 

.dll, .htm, .cgi, .mrc, .msp, .cip, .gtx, .stb, .tfc, .bat, .vbs, .txt, .cpl, .pif, .scr, .obj. Те са взети 

от форуми и сайтове с цел тестване на антивирусен софтуер. 

Освен основния критерий - брой откривани malware, за всяка антивирусна 

програма бяха наблюдавани и параметрите: 

- ползвана памет - колко оперативна памет ангажират мадулите на AV. 

Резултатите са получени от free-програмата ActMonProcessMonitoring. 

- бързината на работа - чрез скоростта за проверка на 10 000 разнотипни файла. 

Най-важните резултати са представени в следната таблица: 

Таблица 1. Обобщени резултати 

Ran Deflt Deflt Full Full RAM 1 RAM 2 

Application k Abs. Omit Abs. Omit (KB) (KB) Points 

Panda Titanium 

115,46 

2006 Antivirus 1 7 688 292 7 688 292 90,612 8 61 100 

BitDefender 9 Pro 2 7 287 693 7 287 693 41,760 48,876 61 94 

McAfee 2006 3 7 181 799 7 181 799 56,524 84,324 58 17 

F-Secure 6.0 4 7 175 805 7 175 805 58,936 79,825 58 25 

Kaspersky 6.0 

Steganos AV 

5 7 169 811 7 169 811 17,504 23,284 64 49 

2006 6 7 163 817 7 166 814 32,580 33,248 48 29 

Norton AV 2006 

PC-cillin Internet 

7 7 018 962 7 021 959 28,024 77,604 55 34 

Security 2006 8 6 977 1003 6 977 1003 48,642 63,512 58 47 

Nod32 2.51.20 9 5 997 1983 6 730 1250 18,056 38,476 60 116 

AVG 7.1 10 6 073 1907 6 552 1428 14,624 39,664 52 26 

Speed 

file/sec 

Класирането е според основния критерий - общ брой открити malware. 

Означенията на колоните са както следва: 

- Deflt Abs / Full Abs - открити malware в режим по подразбиране / режим с 

пълни настройки; 

- Deflt Omit / Full Omit – пропуснати malware в споменатите два режима; 

- RAM1 / RAM2 – използвана оперативна памет в покой / при сканиране 

- Points – точки, получени от допълнителни показатели като наличие на международни 

сертификати, честота на обновяване, удобство при инсталиране и работа, хелп, 

поддръжка и др. 

Получените резултати са обработени статистически чрез продукта Analise-it 

v.173 [5], който разширява възможностите на популярния MS Excel. Статистическата 

обработка показва някои характерни зависимости при работа на AV-програмите. 

Илюстрацията на фиг.1 показва усредненото нарастване на използваната 

оперативна памет в режим на сканиране.

- 159 - 

Фиг.1 Необходима RAM в режими на покой и на сканиране 

Оставянето на AV да работи с подразбиращи се настройки (default) може да 

доведе до увеличаване броя на пропуснатите malware. Следващата илюстрация посочва 

средна разлика от 122 между двата режима. 

Фиг.2. Пропуснати malware в режими default и full 

Кривите от фигури 3 и 4 демонстрират зависимостите при класирането на 

наблюдаваните продукти. Макар и с отклонения, очертава се тенденцията по-добрите 

да използват повече RAM. А фиг.5 потвърждава ръстът в употребата на оперативна 

памет. 


- 160 - 

Фиг.3. Зависимост класиране / брой открити malware 

Фиг.4. Зависимост класиране / използвана RAM 

Фиг.5. Зависимост изолзвана RAM / открити malware

- 161 - 

Получените резултати не претендират за изчерпателност. Съзнаваме, че в тях 

има доста ограничения. Например: броят на използваните malware не е висок, 

възможно е да се включат и други AV-програми, а също и нови критерии като цена, 

удобство при ползване и др. Но въпреки това могат да се използват като отправна точка 

при избора на персонална AV-защита. Те могат да се съпоставят с други класации, 

правени периодично от различни фирми или организации. За сравнение, в таблицата 

по-долу са показани резултати от два подобни теста. 

Таблица 2. AV-тестове от други източници 

Класи- Oт www.av-comparatives.org [3] Oт www.toptenreviews.com [4] 

ране AV програма AV програма 

1 AntiVirusKit (AVK) v.16.0.7 BitDefender v.10 

2 AntiVir PE v.7.01 Kaspersky v.6.0 

3 F-Secure v.6.12.90 F-Secure 2006 

4 Kaspersky v.6.0 PC-cillin 2006 

5 TrustPort AV v.2.0 Nod 32 v.2.51.26 

6 Nod 32 v.2.51.26 McAfee 2006 

7 Norton AV v.12.2 Norton AV 2007 

8 BitDefender Prof. V.9.5 AVG Pro v.7.1 

9 Norman Virus Control v.5.81 eTrust EZ v.7.1 

10 McAfee v.11.0 Norman Virus Control v.5.81 


Опитът за оценяване ефективността на AV програми показа, че трудно може да 

се наложи категорична класация при тях. Получените резултати бързо се променят във 

времето и винаги могат да се оспорят по някой критерий. По-добрите показатели не са 

задължително притежание на по-скъпи или изискващи повече системни ресурси 

защитни средства. Съществуват разлики в използваните алгоритми за откриване на 

malware, както и в базата данни с техни описатели. Това прави сравнението на AV 

сложен и бързопроменящ се процес. При тези условия, за да се обективизира изборът 

на антивирусен софтуер, трябва да се държи сметка за: 

- предлагането на пакет от защитни програми (AV, spyware, adware, firewall), 

които имат единен интерфейс и поддръжка; 

- наличието на повече международно признати сертификати; 

- съвместимостта на конкретната AV-програма с вече инсталирани други 

защитни продукти. 


1. Л. Кландер. Защита от хакери, СофтПрес, 1999. 

2. К. Дънам. Компютърни вируси. Диагностика и защита, АлексСофт, 2001. 

3. www.av-comparatives.org 

4. www.toptenreviews.com. 

5. www.analyse-it.com 


- 162 - 

Department of Electronics, Computer Systems and Automation 

Technical College “J.Atanasov” 



4000 Plovdiv, BULGARIA 

E-mail: simon18@mail.bg, petkobakalov@gmail.com

- 163 - 




BULGARIA 

AN ENHANCED STATIONARY PHASE METHOD (SPM) 

APPROXIMATION FOR THE ASYMPTOTIC CALCULATION 

OF THE SCATTERED ELECTRIC FIELD FROM A FINITE 

RECTANGULAR PLATE 

CH. G. MOSCHOVITIS, E. G. PAPKELIS, H. T. ANASTASSIU, 

K. T. KARAKATSELOS, I. CH. OURANOS , P. V. FRANGOS 

Abstract. The enhanced Stationary Phase Method (SPM) approximation we present here 

appears to be a rather fast and attractive alternative in order to calculate the scattered 

electric field from a perfectly conducting rectangular plate of finite dimensions. Such 

rectangular plates could model propagation in a modern high frequency wireless 

communication network. A comparison is made with other methods such as numerical 

integration. 

Key words: stationary phase method, asymptotic approximation, scattered electric field. 

1. Introduction 

Propagation in an urban outdoor environment which consists of three dimensional 

scatterers (walls) is the main goal of our research. Provided that both transmitter and receiver 

are located below rooftop level, this scenario pertains to propagation circumstances related to 

modern high frequency communication wireless networks. Such environment could be 

modeled through the prerequisite problem of an electromagnetic (EM) wave which is 

assumed to be incident on a perfectly conducting rectangular plate of finite dimensions. 

Modifying appropriately the equation of the vector potential A, which is calculated by using 

physical optics (P.O) current density approximation, we can apply SPM approximations 

resulting in calculating the vector potential A and eventually the total electric field E at the 

observation point R(x,y,z). The novel, important feature, of our approach is the inclusion of 

the edges contribution to the resulting asymptotic expressions, not being documented in the 

literature ([1]-[3]) for a double integral. Furthermore, in order to check the accuracy of our 

asymptotic calculations, standard (e.g. Gaussian) numerical integration was used to compare 

the results. 


- 164 - 

2. Description of the stationary phase method 

Fig. 1. Rectangular plate, schematic 3D layout. 

� � � � � � � � 

R = R ⋅ R = r − ( x′ 

⋅ x + y′ 

⋅ y) 

= ( x − x′ 

) ⋅ x + ( y − y′ 

) ⋅ y + z ⋅ z 

(1) 

� 

� R 

1 

� � � 

R = = 

⋅ ( x − x′ 

) ⋅ x + ( y − y′ 

) ⋅ y + z ⋅ z (2) 

R 

2 

2 2 

( x − x′ 

) + ( y − y′ 

) + z 

TE and TM y-z plane projection calculations indicate the following results according 

to Physical Optics (P.O.) current density calculations: 

Fig. 2. Rectangular plate, TE rhythm y-z plane projection. 

The incident electric field is calculated via equation 

� � � 

Ei = η ⋅ H 0 ⋅ y ⋅ cosϑi 

+ z ⋅sinϑi 

⋅ exp − j ⋅ k y ⋅ sinϑi 

− z cosϑi 

Hi = x ⋅ H0 

⋅ exp[ 

− j ⋅ k( 

y ⋅sinϑi 

− z cosϑi 

) ] 

� � 

� � 

P. 

O 

� 

J = ⋅ n × H = y ⋅ 2 ⋅ H ⋅ exp − j ⋅ k ⋅ y′ 

⋅ sinϑ 

s 

( ) [ ( ) ] 

2 i z= 

0 

0 

y= 

y′ 

[ ] 

while the scattered electric field is calculated by using equation: 

i 

(3) 

(4) 

(5)

� 

E 

s 

� 

H 

⎛ 

∫ ⎜ 

V '⎝ 

⎛ 

⎜ 

'⎝ 

- 165 - 

() r = − j ⋅ k ⋅ ⎜ M ( r′ 

) × R + J ( r′ 

) − J( 

r′ 

) 

s 

� 

μ 

ε 

() r = j ⋅ k ⋅ ⎜ J ( r′ 

) × R + M ( r′ 

) − M ( r′ 

) 

∫ 

V 

� 

� 

H 

s 

ε 

μ 

� � ⎞ 

[ { ⋅ R} 

⋅ R] 

⎟ ⋅ G( 

r, 

r′ 

) 

⋅ dV 

′ 


⎟ 

⎠ 

� � ⎞ 

[ { ⋅ R} 

⋅ R] 

⎟ ⋅ G( 

r, 

r′ 

) 

( r) 

= j ⋅k 

⋅ J ( r′ 

) 

∫ ( × R) 

( ) 

V ' 

� 

⎟ 

⎠ 

� 

⋅G 

r, 

r′ 

⋅dV 

′ 

2 

( x − x′ 

) + ( y − y′ 

) 

⋅ dV 

′ 

� � 

1 

� � 

J ( r′ 

) × R = 2H ⋅ ( − jk ⋅ ( y′ 

⋅ i ) ) 

⋅{ 

− z ⋅ ( x − x′ 

0 exp sinϑ 

) + x ⋅ z} 

(8) 

2 2 

+ z 

� 

H 

� 

s 

c a 

2 

j ⋅ k ⋅ 2H 

0 

() r 

( x − x′ 

) + ( y − y′ 

⋅ 

) 

= ∫ ∫ 

4π 

1 

� � 

⋅{ 

− z ⋅ ( x − x′ 

) + x ⋅ z} 

⋅ 

2 2 

+ z 

dx′ 

⋅ dy′ 

⋅ exp 

⎛ 

⎜ − jk⎜⎛ 

y′ 

⋅ sinϑi 

+ 

⎝ ⎝ 

2 

2 

( x − x′ 

) + ( y − y′ 

) + z ⎟⎞ 

⎞ 

⎟ 

⎠⎠ 

y′ 

= d x′ 

= b 

2 

Fig. 3. Rectangular plate, TM rhythm y-z plane projection. 

Ei = x ⋅ E0 

⋅exp[ 

− j ⋅k 

( y ⋅sinϑi 

− z cosϑi 

) ] 

� � 

� 

H i 

E0 

� � 

= − ⋅ ( y ⋅ cosϑi 

+ z ⋅ sinϑi 

) ⋅ exp[ 

− j ⋅ k( 

y ⋅sinϑi 

− z cosϑi 

) ] 

η 

� P. 

O 

J s 

� 

= 2 ⋅ n × H i z= 

0 

y= 

y′ 

� E0 

= x ⋅ 2 ⋅ ⋅cosϑi 

⋅ exp[ 

− j ⋅ k ⋅ y′ 

⋅sinϑi 

] 

η 

� 

⎛ � 

E () ∫ ⎜ ( ′ 

s r = − j ⋅ k ⋅ 

⎜ 

M r ) × R + 

V '⎝ 

μ 

� � ⎞ 

[ J ( r′ 

) − { J( 

r′ 

) ⋅ R} 

⋅ R] 

⎟ ⋅ ( ′ ) ⋅ ′ 

⎟ 

G r, 

r dV 

ε 

⎠ 

� 

⎛ � 

H () ∫ ⎜ ( ′ 

s r = j ⋅ k ⋅ 

⎜ 

J r ) × R + 

V '⎝ 

ε 

� � ⎞ 

[ M ( r′ 

) − { M ( r′ 

) ⋅ R} 

⋅ R] 

⎟ ⋅ ( ′ ) ⋅ ′ 

⎟ 

G r, 

r dV 

μ 

⎠ 

� 

H 

s 

() r = j ⋅k 

⋅ J ( r′ 

) 

� 

2E 

∫ ( × R) 

⋅G( 

r, 

r′ 

) 

V ' 

� 

� 

⋅dV 

′ 

0 

( r′ 

) × R = ⋅ cosϑ 

⋅ exp( 

− jk ⋅ ( y′ 

⋅ sinϑ 

) ) 

J i 

i 

η 

1 

2 

( x − x′ 

) + ( y − y′ 

) 

2 

+ z 

2 

⋅ 

� 

(6) 

(7) 

(10) 

(11) 

(12) 

(13) 

(14) 

(15) 

� 

(9) 

{ z ⋅ ( y − y′ 

) − y ⋅ z}

- 166 - 

(16) 

1 

� � 

⋅{ 

− z ⋅ ( y − y′ 

) − y ⋅ z} 

⋅ 

c a 

� 

2 

2 

j ⋅ k ⋅ 2E 

2 

0 

H () r 

( x x′ 

) ( y y′ 

) z 

s = ⋅ cosϑ 

− + − + 

i 

dx′ 

⋅ dy′ 

4π 

⋅η 

∫ ∫ 

y′ 

= d x′ 

= b 

⋅ 

⎛ 

jk y i ( x x ) ( y y ) z 

⎞ 

⎜ − ⎜⎛ 

2 

2 2 

exp ′ ⋅ sinϑ 

+ − ′ + − ′ + ⎟⎞ 

⎟ 

⎝ ⎝ 

⎠⎠ 

(17) 

By combining the TE and TM formulas we step into a single alternative formula 

which may calculate the vector potential A for the combination of TE and TM rhythms which 

is described below: 

− μ0 

� 

� 

A( 

x, 

y, 

z) 

= ⋅[ 

x ⋅ ( E0θ 

⋅ cosφ 

i − Ε 0φ 

⋅ cosθ 

i ⋅ sin φi 

) + y ⋅ ( E0θ 

⋅ sinφ 

i + E0φ 

⋅ cosθ 

i ⋅ cosφi 

)] ⋅ 

2π 

⋅η 

c 

a 

2 

2 2 

− j⋅k 

⋅ ( x− 

x') 

+ ( y− 

y') 

+ z 

⋅ ∫ 

y′ 

= d 

j⋅k 

⋅( 

x'⋅ 

K + y'⋅L 

) 

e e 

∫ 

2 

2 2 

x′ 

= b ( x − x') 

+ ( y − y') 

+ z 

dx' 

dy′ 

(18) 

where 

K = sinθ ⋅ cosφ 

(19) 

i 

i 

L = sinθ i ⋅sinφi 

(20) 

This equation is reduced to a simplified, yet complex expression by utilizing the 

accurate asymptotic result obtained from [2] for the case of a single integral. By combining 

) 

= I 

o 

+∞ 

− I 

( x) 

⋅ exp( 

jkf ( x) 

) ⋅ dx − F( 

x) 

⋅ exp( 

jkf ( x) 

) ⋅ dx − FF( 

x) 

⋅ exp( 

jkff ( x) 

) 

I ′ = ∫ F 

∫ 

∫ 

−∞ 

where 

a 

− I 

−b 

2 ⋅π 

⎛ ⎡ π 

I o = sgn o 

k ⋅ f ′′ 

⋅ F( 

x ) ⎜ ( ) { ( ) } ⎟ 

( ) 

⎢ 

′′ 

o ⋅ exp j k ⋅ f xo 

+ ⋅ f x 

x 

⎥ 

o 

⎝ ⎣ 4 

⎦⎠ 

( a) 

2 

⋅exp{ 

jk ⋅ f ( a) 

} + o( 

) 

′ ( a) 

F( 

b) 

2 

⋅ ⋅ exp{ 

jk ⋅ f ( b) 

} + o( 

) 

f ′ ( b) 

+∞ 

a 

⎤⎞ 

+∞ 

−b 

⋅ dx = 

(21 

1 F 

Ia = − ⋅ 

jk f 

− 

k 

(23) 

′ 

I− b = Ib 

= 

1 

jk 

− 

k 

(24) 

Double integral terms are far more complicated to compute utilizing the results of the 

single integral onto appropriately modified functions: 

j⋅k 

⋅ f ( xs 

, ys 

) 

I[ 

0] 

≅ F( 

xs 

, ys 

) ⋅ e ⋅ 

k ⋅ 

j ⋅ 2 ⋅π 

⋅δ 

2 

4A 

⋅ B − C 

(25) 

1 

A = ⋅ f ′′ xx( 

xs 

, ys 

) 

2 

(26) 

1 

B = ⋅ f ′ 

yy ( xs 

, ys 

) 

2 

(27) 

C = f ′′ x , y 

(28) 

xy 

( ) 

s 

s 

(22)

- 167 - 

⎧+ 

1 

⎪ 

δ = ⎨−1 

⎪ 

⎩ 

− j 

, 

, 

, 

2 

4A 

⋅ B > C , A > 0 

2 

4A 

⋅ B > C , A < 0 

2 

4A 

⋅ B < C 

(29) 

where the stationary point (xs,ys) is defined by: 

( ) ⎟ ⎛ 

x ⎜ 

s , y s = 

⎜ 

x + 

⎝ 

K ⋅ z 

2 2 

1− 

K − L 

, y + 

L ⋅ z ⎞ 

2 2 

1− 

K − L ⎠ 

(30) 

and the functions on which the method is applied are: 

F s s 

( x , y ) = 

2 

1 

⎛ ⎛ K ⋅ z ⎞⎞ 

⎛ ⎛ L ⋅ z ⎞⎞ 

⎜ 

2 

x − ⎜ x 

⎟⎟ 

+ ⎜ y − ⎜ y 

⎟⎟ 

+ z 

2 2 

2 2 

1 K L 

⎜ ⎜ 

+ 

⎜ ⎜ 

+ 

⎟⎟ 

⎟ 

1 K L 

⎟ 

⎝ ⎝ − − ⎠⎠ 

⎝ ⎝ − − ⎠⎠ 

(31) 

⎛ K ⋅ z ⎞ ⎛ L ⋅ z ⎞ 

( xs, 

y ) = ⎜ x 

⎟K 

⎜ y 

⎟ 

⎜ 

+ 

L − 

2 2 ⎟ 

+ 

⎜ 

+ 

2 2 ⎟ 

⎝ 1− 

K − L ⎠ ⎝ 1− 

K − L ⎠ 

f s 

2 

⎛ ⎛ K ⋅ z ⎞⎞ 

⎛ ⎛ L ⋅ z ⎞⎞ 

2 

− ⎜ x − ⎜ x 

⎟⎟ 

+ ⎜ y − ⎜ y 

⎟⎟ 

+ z 

2 2 

2 2 

1 K L 

⎜ ⎜ 

+ 

⎜ ⎜ 

+ 

⎟⎟ 

⎟ 

1 K L 

⎟ 

⎝ ⎝ − − ⎠⎠ 

⎝ ⎝ − − ⎠⎠ 

′ 

I = 

o 

For the case of a double integral, the main terms will be transformed into: 

2⋅π 

⋅ F( 

x ′ o, 

y ) ⋅ 

2 

∂ f 

k ⋅ 2 

∂x′ 

x′ 

= x , y′ 

= y′ 

o 

2 

⎛ ⎡ 

⎤⎞ 

⎜ ⎢ 

⎪⎧ 

2 

π ∂ f ⎪⎫ 

⋅exp 

( ) 

⎥⎟ 

⎜ 

j k ⋅ f x ′ o, 

y + ⋅sgn⎨ 

2 ⎬ 

⎢ 

4 

⎥⎟ 

⎝ ⎣ 

⎪⎩ 

∂x′ 

x′ 

= x y′ 

= y′ 

⎪⎭ 

o , ⎦⎠ 

1 F( 

a, 

y′ 

) 

−2 

I′ 

⋅exp{ 

⋅ ( , ′ 

a = − ⋅ 

jk f a y ) } + o( 

k ) 

jk ∂f 

∂x′ 

(34) 

x′ 

= a, 

y′ 

= y′ 

( b, 

y′ 

) 

I ′ b = 

1 F 

⋅ 

jk ∂f 

∂x′ 

⋅ exp 

− 

k 

(35) 

x′ 

= b, 

y′ 

= y′ 

2 

{ jk ⋅ f ( b, 

y′ 

) } + o( 

) 

where xo the solution of equation: 

∂f 

( x′ 

, y′ 

) 

= 0 

∂x′ 

x′ = xo 

, y′ 

= y′ 

By defining the following set of functions, furthermore appliance of the method may 

calculate the terms for the edges of the plate, not documented for the case of a double integral. 

∂f 

′ ( 01) 

( y′ 

) 

= 0 

(37) 

∂y′ 

∂f 

′ 

( 02) 

∂f 

′ 

∂y′ 

( 03) 

∂y′ 

( y′ 

) 

( y′ 

) 

y′ 

= y 

y′ 

= y 

y′ 

= y 

01 

02 

03 

= 0 

= 0 

2 

(32) 


(33) 

(36) 

(38) 

(39)

F′ 

( 01) 

2π 

2 

∂ f 

k 2 

∂x′ 

( y′ 

) = 

F( 

x , y′ 

) 

⎛ 

⎜ ⎪⎧ 

2 

π ∂ f 

⋅exp 

j ⋅ sgn 

⎜ ⎨ 2 

4 

⎝ ⎪⎩ 

∂x′ 

f ′ y′ 

= f xo 

, y′ 

( ) ( ) 

x′ 

= xo 

, y′ 

= y′ 

x′ 

= xo 

, y′ 

= y′ 

⎪⎫ 

⎞ 

⎟ 

⎬ 

⎪⎭ 

⎟ 

⎠ 

o 

⋅ 

- 168 - 

( 01) 

(41) 

F′ 

( 02) 

( y′ 

) 

1 F 

= − ⋅ 

jk ∂f 

∂x′ 

( a, 

y′ 

) 

x′ 

= a, 

y′ 

= y′ 

( y′ 

) = f ( a y ) 

( y′ 

) = 

1 

⋅ 

F( 

b, 

y′ 

) 

f ′ , ′ 

( 02) 

(43) 

F′ 

( 03) 

jk 

∂f 

∂x′ 

( y′ 

) = f ( b y ) 

f ′ , ′ 

x′ 

= b, 

y′ 

= y′ 

( 03) 

(45) 

By defining the rest of the terms we have presented a new method for the case of the 

asymptotic double integral calculation based on results obtained from the single integral 

mathematical formulas. 

I 

= 

+∞ +∞ 

j⋅k⋅ 

f ( x′ 

, y′ 

) 

[] 1 = F( 

x′ 

, y′ 

) ⋅ e 

∫∫ 

−∞x′ 

= a 

2 ⋅π 

2 

∂ f ′ ( 02) 

k ⋅ 2 

∂y′ 

⎛ ⎡ 

⎜ 

⋅ exp ⎢ 

⎜ j k ⋅ f ′ ( 

⎜ ⎢ 

⎝ ⎣ 

I 

02) 

y′ 

= y02 

( y ) 

02 

⋅ F ′ 

( 02) 

dx′ 

⋅ dy′ 

= 

( y ) 

02 

⎧ 2 

π ⎪∂ 

f ′ ( 

+ ⋅ sgn⎨ 

2 

4 ⎪⎩ 

∂y′ 

j⋅k 

⋅ f ( x′ 

, y′ 

) 

[] 2 = F( 

x′ 

, y′ 

) ⋅ e 

= 

+∞x′ 

= b 

∫∫ 

−∞ 

−∞ 

2 ⋅ π 

2 

∂ f ′ ( 03) 

k ⋅ 2 

∂y′ 

⎛ ⎡ 

⎜ 

⋅ exp ⎢ 

⎜ j k ⋅ f ′ ( 

⎜ ⎢ 

⎝ ⎣ 

03) 

y′ 

= y03 

( y ) 

03 

⋅ F ′ 

( 03) 

⋅ 

( y ) 

02) 

dx′ 

⋅ dy′ 

= 

03 

⎧ 2 

π ⎪∂ 

f ′ ( 

+ ⋅ sgn⎨ 

2 

4 ⎪⎩ 

∂y′ 

⋅ 

03) 

y′ 

= y02 

y′ 

= y03 

⎫⎤⎞ 

⎪ ⎟ 

⎬ 

⎥ 

⎥ 

⎟ 

⎪⎭ 

⎟ 

⎦⎠ 

⎫⎤⎞ 

⎪ ⎟ 

⎬ 

⎥ 

⎥⎟ 

⎪⎭ 

⎟ 

⎦⎠ 

(40) 

(42) 

(44) 

(46) 

(47)

I 

j⋅k⋅ 

f ( x′ 

, y′ 

) 

[] 3 = F( 

x′ 

, y′ 

) ⋅ e 

= 

y′ 

= d 

∫ 

−∞ 

y′ = d a 

− ∞ x′ 

= b 

( I ′ − I ′ − I ′ ) 

0 

∫ ∫ 

a 

⋅ dy′ 

= 

[ 3. 

1] 

− I[ 

3. 

2] 

− I[ 

3. 

3] 

b 

dx′ 

⋅ dy′ 

= 

- 169 - 

= I 

y′ 

= d 

I[ 

3 . 1] 

= ∫ I o ⋅ dy′ 

= 

−∞ 

1 F ′ ( 01) 

( d ) 

⋅ 

jk ∂f 

′ ( 01) 

⋅ exp{ 

jk ⋅ f ′ ( 01) 

( d ) } 

∂y′ 

y′ 

= d 

(49) 

y′ 

= d 

I[ 

3 . 2] 

= ∫ I a ⋅ dy′ 

= 

−∞ 

1 F ′ ( 02) 

( d ) 

⋅ 

jk ∂f 

′ ( 02) 

⋅ exp{ 

jk ⋅ f ′ ( 02) 

( d ) } 

(50) 

∂y′ 

y′ 

= d 

y′ 

= d 

I[ 

3 . 3] 

= ∫ I ′ b ⋅ dy′ 

= 

−∞ 

1 F′ 

( 03) 

( d ) 

⋅ 

jk ∂f 

′ ( 03) 

∂y′ 

⋅ exp{ 

jk ⋅ f ′ ( 03) 

( d ) } 

I 

= 

j⋅k 

⋅ f ( x′ 

, y′ 

) 

[] 4 = F( 

x′ 

, y′ 

) ⋅ e 

( I′ 

− I′ 

− I′ 

) 

o 

y′ 

= c 

a 

y′ 

= c x′ 

= b 

a 

b 

⋅ dy′ 

= 

y′ 

= d 

I[ 

4. 

1] 

− I[ 

4. 

2] 

− I[ 

4. 

3] 

+∞ 

1 F( 

′ 01 

[ ] )( c) 

. 1 = ∫ I′ 

⋅ dy′ 

= − ⋅ 

= 

+ ∞ 

∫ 

+∞ 

∫ ∫ 

dx′ 

⋅ dy′ 

= 

(51) 

{ jk ⋅ f } 

I 4 

y′ 

= c jk ∂f( 

′ 01) 

∂y′ 

⋅ exp ′ 

o 01 

y′ 

= c 

+∞ 

1 F( 

′ 02 

[ ] )( c) 

. 2 = I ′ ⋅ dy′ 

= − ⋅ 

( )() c 

(53) 

{ jk ⋅ f } 

I 4 ∫ a 

y′ 

= c jk ∂f 

( ′ 02) 

∂y′ 

⋅ exp ′ 02 

(54) 

y′ 

= c 

+∞ 

1 F( 

′ 03 

[ ] )( c) 

. 3 = I′ 

⋅ dy′ 

= − ⋅ 

( )() c 

{ } 

∫ b ⋅ exp jk ⋅ f( 

03)() 

c 

(55) 

jk ∂f( 

′ 03) 

I 4 ′ 

y′ 

= c 

∂y′ 

y′ 

= c 

The final result for the modified stationary phase method is obtained through equation: 

I = I[ 

0] 

− I[ 

1] 

− I[ 

2] 

− I[ 

3] 

− I[ 

4] 

(56) 


(48) 

(52)

- 170 - 

3. Results 

Table 1. SPM and Numerical Integration Simulation Parameters 

Symbol Quantity Value 

λ Wavelength 0.3m 

r Observation distance r < Fresnel area 1 

Fresnel area 1 < r < Far Field area 1 

r > Far Field area 1 

φi Angle of incidence 225 o 

θi Angle of incidence 45 ο 

φs 

Observation angle 

θs Observation angle 0 o – 90 o 

E0θ Constant related to emitted field (θ) 1 V/m 

E0φ Constant related to emitted field (φ) 1 V/m 

a-b x axis plate dimension 20λ, 40λ, 60λ, 80λ 

c-d y axis plate dimension 20λ, 40λ, 60λ, 80λ 

Furthermore, in order to check the accuracy of our asymptotic calculations, standard 

(e.g. Gaussian) numerical integration was used to compare the results. Due to complex 

calculations, a simulating application was developed using Matlab’s symbolic toolbox which 

is barely able to handle the exhaustive calculations needed. SPM and numerical integration 

results for the total scattered electric field are presented here for the frequency of 1GHz, and a 

rectangular plate with side length equal to 40λ. Elevation and azimuth angles were assumed 

equal to 45 degrees. 

Comparison charts in Figs. 4 – 6 below indicate reasonable convergence between the 

asymptotic results of the SPM method, drawn with solid line, and the numerical results of 

standard integration, drawn with dashed line. More simulation results were obtained 

according to the simulation parameters of table 1, and showed satisfactory agreement. 

Fig. 4. Total Electric Filed for 40λ plate side, Far Field area. 

45 ο

- 171 - 

Fig. 5. Total Electric Filed for 40λ plate side, Fresnel area. 

Fig. 6. Total Electric Filed for 40λ plate side, Near Field area. 

4. Conclusions 

Even though rather complicated mathematical formulas are involved in the proposed 

SPM method, it is very important that this technique is much faster than the numerical 

integration (namely, SPM in this case is about 40 times faster). This is very important this is 

e.g. for a propagation problem in an urban outdoor environment, in which case many 

scatterers (walls) and multiple reflection phenomena are present. The SPM method presented 

here appears to be very attractive for the calculation of vector potential and electric field in 

various radio propagation simulation tools. 


- 172 - 

REFERENCES 

1. C. A. Balanis, "Antenna Theory: Analysis and Design", John Wiley & Sons, New York, 

1996, pp. 922-926. 

2. Graeme L. James, Geometrical Theory Of Diffraction for Electromagnetic Waves, UK, 

IEE 1976, pp. 30-42. 

3. David C. Jenn, Radar and Laser Cross Section Engineering, American Institute of 

Aeronautics and Astronautics, Inc. Washington, 1995, pp. 29-33. 

National Technical University of Athens, School of Electrical and Computer Engineering, 

Division of Information Transmission Systems and Materials Technology, 

Radar Systems and Remote Sensing Laboratory, 

9 Iroon Polytechniou Str. 15773 Zografou, Athens, Greece 

phone: +30210-772-3694 ;fax: +30210-772-2281; 

E-mail: pfrangos@central.ntua.gr

- 173 - 




BULGARIA 

SIMPLESCALAR SIMULATION TOOL 

MARIA MARINOVA, ELENA DUNCHEVA 

Abstract. The SimpleScalar tool set includes sample simulators ranging from fast 

functional simulator to detailed, dynamically scheduled processor model that 

supports non-blocking cache, speculative execution and branch prediction. Using 

the Simplescalar tools, users can build modelling applications that simulate real 

programs running on a range of modern processors and systems. The simulators 

generate statistics for different parameters – cycle per instruction, instruction per 

cycle, branch prediction speed, cache misses, hit ratio in table look-aside buffer, 

and other. 

Key words: SimpleScalar, superscalar processor, out-order execution. 

СИМУЛАЦИОННА ТЕХНИКА SIMPLESCALAR 


Симулацията е изключително мощна приложна методология, чийто основни 

цели са: да опише структурата на изследваната система чрез създаване на нейн модел; 

да даде необходимата информация за изграждането на достоверна хипотеза или теория 

за поведението на системата; да послужи като средство за предсказване на ефекти, 

породени от промяна в системата или в правилата на нейното функциониране.[1] 

Симулационната техника SimpleScalar[2] ни предоставя възможност за симулиране 

изпълнението на суперскаларен процесор. Тази симулационна среда включва няколко 

симулатора, чрез които могат да се симулират различни компютърни архитектури. 

Базовата архитектура на симулатора се основава на суперскаларния(СС) процесор 

MIPS R10000, който изпълнява на всеки такт 4 64-разрядни инструкции. При този 

процесор е реализирано динамично подаване на инструкциите към свободните 

конвейри и подава инструкциите неподредено(out-order). Към симулатора е включен 

пакет от реални тестиращи програми(т.нар. benchmarks), които се подават за 

изпълнение от суперскаларния процесор. 

2. Симулатори от SimpleScalar 

Симулаторът за неподредено изпълнение (sim-outorder) е най-усъвършенствания 

и детайлен симулатор. Генерира статистики за процесор, изпълняващ неподредено 

инструкции с кеш от първо и второ ниво и оперативна памет, реализирана чрез 

опашката Load/Store. Основни модули в симулатора са RUU и Load/Store буфер – фиг.1. 


- 174 - 

Спекулативно подаване и изпълнение на инструкциите се осъществява от 

устройството RUU (Register Update Unit). Използва буфер за преподреждане, за да 

преименува автоматично регистрите и да задържи резултатите на неизпълнените 

инструкции. Всеки такт буферът за преподреждане записва резултатие на завършилите 

инструкции в регистровия файл. 

Системната памет използва Load/Store буфера. Записаните стойности се 

преместват в опашката при спекулативен запис. Четенето се изпраща до системната 

памет само, когато са известни адресите на всички предишни записи. Може да се чете 

от системната памет или по-ранна записана стойност, присъстваща в буфера, ако 

адресите им съвпадат. Спекулативното четене може да генерира непопадения в кеша 

(misses), докато условния преход е неизвестен. 

Фиг.1 Конвейр на sim-outorder 

Главният цикъл на симулатора е разположен в sim_main() и изглежда по следния начин: 

ruu_init(); 

for (;;) { 

ruu_commit(); 

ruu_writeback(); 

lsq_refresh(); 

ruu_issue(); 

ruu_dispatch(); 

ruu_fetch(); 

} 

Цикълът се изпълнява по един път за всеки симулиран машинен такт. Ако 

конвейера се обърне, вътрешно-фазовата синхронизация може да се управлява само с 

едно преминаване през всяка фаза. При извикване на exit(), симулаторът извършва 

longjmp() към main(), за да генерира резултати. 

Фазата на извличане е реализирана в ruu_fetch(). 

FETCH 

Mispredistion (from 

Writeback) 

To Instruction Fetch 

Queue 

Устройството за извличане определя как процесора извличане машинните 

инструкции, взимайки в предвид стойността на програмния брояч, състоянието на 

логиката за предсказване на преходи (branch predictor) и неправилното предсказаните

- 175 - 

преходи, засечени от устройствата за преход. Всеки такт Фазата на извличане извлича 

инструкции само от един ред на кеша за инструкции. Извлечените инструкции се 

подават към опашката за изпращане (Dispatch Queue) и се изследва (line predictor), за да 

се определи правилният ред от кеша, който да е достъпен в следващият цикъл. 

Фазата за изпращане е реализирана в ruu_dispatch() и моделира декодирането 

на инструкция и преименуването на регистрите. 

Instruction from 

Instruction Fetch 

Queue 

DISPATCH 

To RUU or 

LSQ 

Функцията използва инструкциите от опашката (запълнена през фазата на 

извличане), указател към активно RUU, таблица за преименуване и състоянието на 

процесора. На всеки такт диспечерът изпраща инструкции от опашката за извличане 

(fetch queue) към опашката за планиране (scheduler queue). Ако се срещне неправилно 

предсказан условен преход започва въстановяване на пресъздаденото състояние в 

буфери на състоянието. В тази фаза RUU и Load/Store опашката (LSQ) се “захранват” с 

инструкции. Инструкциите за обръщение към паметта се разделят на две отделни 

инструкции (ADD и LOAD/STORE) и се подобрява проверката на зависимостите по 

памет. 

Фазата на подаване на инструкции се реализира от ruu_issue() и lsq_refresh(). 

RUU, LSQ REGISTER 

To Functional 

SCHEDULER 

Units 

MEMORY 

SCHEDULER 

Те моделират “събуждането” и подаването на инструкция конвейрите, като 

проследяват зависимостите регистър-памет. На всеки такт, процедурата по планиране 

открива инструкции, за които има вече готовите входове на регистрите. Подаването на 

готови инстукции за четене от паметта се блокира ако има по-ранен запис с нерешен 

действителен адрес в Load/Store опашката. Ако адреса на по-ранния запис съвпада с 

адреса на чакащото четене, записаната стойност се прочита (четенето е изпратено към 

системната памет). 

Фазата на изпълнение се реализира от ruu_issue(). 

Issued 

Instructions from 

Scheduler 

EXEC 

MEM 

Memory request to D -Cache 

Finished 

Instructions to 

Writeback 

Всеки такт процедурата получава толкова инструкции, колкото са изпратени от 

опашката за планиране (Scheduler Queue). Прави се проверка за налични функционални 

устройства и ако има такива, им се подават инструкциите. Накрая процедурата планира 

записа, използвайки латентността (latency) на функционалните устройства. Липсата на 

данни в буфера TLB, която блокира подаването на инструкции за обмен с паметта, се 

обслужва във фазата на отегляне. Латентностите на функционалните устройства са 

записани в дефинирането на fu_config[] в sim-outorder.c. 


- 176 - 

Фазата на запис се реализира в ruu_writeback(). 

Detected Mispredictions 

to Fetch 

Finished Instructions from 

Execute 

WRITEBACK Instructions ready to 

Commit 

На всеки такт се проверява опашката за завършили инструкции. Когато се 

открие завършила инструкция, се обхожда веригата на зависимостите между изходите 

на инструкциите, за да се маркират инструкции, които са зависими от завършилата 

инструкция. Ако зависима инструкция все още не е завършила, процедурата я маркира 

като готова за подаване. 

Фазата на запис открива и неправилно предсказани преходи, когато е срещнат 

такъв преход, тя връща състоянието обратно към контролната точка, отхвърляйки 

неправилно подадените инструкции. 

ruu_commit() управлява инструкциите от фазата на запис, който са готови да 

фазата на отегляне. 

Instructions ready to 

Commit from 

Writeback 

COMMIT 

Процедурата извършване подреден запис на инструкциите, обновява на 

кешовете за данни (или паметта) със записаните стойности и контролира 

непопаденията на данни в TLB. Процедурата задържа т.нар. “пенсионирани” 

инструкции, които са готови за отеглянев началото на RUU, докато главната 

инструкция все още не е завършила. Когато инструкция е в тази фаза, нейният резултат 

се премества в регистровия файл и ресурсите на RUU / LSQ съобщават, че тази 

инструкция е поправена. 

3. Симулации 

За симулиране изпълнението на суперскаларен процесор използвам 

симулационна техника SimpleScalar, чиято базова архитектура се основава на 

суперскаларния процесор MIPS R10000 и в частност симулатора sim-outorder, 

поддържащ неподредено подаване и изпълнение на инструкциите и генериращ времева 

статистика. Симулираната компютърна архитектура подава и изпълнява неподредено 

(out-of-order) инструкциите и има две нива кеш и оперативна памет. 

SimpleScalar предоставя възможност за симулиране на разнообразни тестиращи 

програми (т.нар. benchmarks), с които може да се тества производителността на 

различни процесорни архитектури.[3] 

3.1. Тестиращи програми 

• go - използва се за просто тестване на производителността на симулирания 

процесор.; 

• compress 95 – базирана е на стандартна компресия в UNIX. Версията на теста е 

модифицирана за тестване на паметта. При пускане на теста се генерира голям 

буфер с данни, чието съдържание се компресира. 

• Тестът на Дикстра е разработен въз основа на алгоритъма на Дикстра за 

откриване на най-краткия път между два възела в граф. 

• Тестът Риндаел е разработен на базата на алгоритъма за блоково шифриране, 

възприет като стандарт за криптиране. 

• Алгоритъм за криптографски хеш памети – тестиращата програма е 

разработена въз основа на SHA(Secure Hash Algorithm) алгоритъм.

- 177 - 

3.2. Резултати 

След симулацията на тестиращите програми от симулатора sim-outorder 

анализирамe следните параметри: 

sim_total_insn – брой изпълнени инструкции; 

sim_total_refs – брой изпълнени инструкции за обръщение към паметта; 

sim_total_loads - брой изпълнени инструкции за четене от паметта; 

sim_total_stores - брой изпълнени инструкции за запис в паметта; 

sim_total_branches - брой изпълнени инструкции за преход; 

sim_IPC – брой инструкции, които се изпълняват за един такт; 

sim_CPI – брой тактове, необходими за изпълнението на една инструкция; 

il1.accesses – брой обръщения към кеша от първо ниво за инструкции; 

il1.hits – честота на попадения в il1; 

il1.misses – честота на непопадения в il1; 

il1.replacements – брой замествания в il1; 

il1.writebacks – брой записи в il1; 

dl1.accesses – брой обръщения към кеша от първо ниво за данни; 

dl1.hits – честота на попадения в dl1; 

dl1.misses – честота на непопадения в dl1; 

dl1.replacements – брой замествания в dl1; 

dl1.writebacks – брой записи в dl1; 

ul2.accesses - обръщения към кеша от второ ниво; 

ul2.hits – честота на попадения в ul2; 

ul2.misses – честота на непопадения в ul2; 

ul2.replacements – брой замествания в ul2; 

ul2.writebacks – брой записи в ul2; 

itlb.accesses – брой обръщения към TLB за инструкции; 

itlb.hits – честота на попадения в itlb; 

dtlb.accesses - брой обръщения към TLB за данни; 

dtlb.hits – честота на попадения в dtlb; 

mem.page_mem – големина на страниците, разположени в паметта; 

mem.ptab_misses – брой на страниците, които липсват в паметта; 

Забележка: Симулираната процесорна архитектура има две нива кеш, който е 

разделен на кеш за инструкции и кеш за данни от първо ниво или второ ниво. 

Означенията са il1 и dl1 – кеш от първо ниво съответно за инструкции и за данни и il2 

и dl2 – кеш от второ ниво съответно за инструкции и за данни. Кешът за инструкции 

и кешът за данни на всяко ниво могат да се обединят, като се насочи кешът за 

инструкции към кеша за данни за всяко ниво и се използват аргументите за 

конфигуриране на кешовете за данни dl1 и dl2 и за двете нива. Симулираната 

процесорна архитектура използва обединен кеш от второ ниво с означение ul2. Също 

така и TLB е разделен на TLB за инструкции (itlb) и TLB за данни (dtlb). 

Стойностите на анализираните параметри, получени при симулация на 

описаните по-горе тестиращи програми са дадени в таблицата 1. 


- 178 - 

Таблица 1. Параметри на симулационната техника SimpleScalar 

go compress95 dijkstra rijndael sha 

sim_total_insn 1041989 3069412 55667370 38108159 13569524 

sim_total_refs 242297 1992888 19418083 12033940 2610960 

sim_total_loads 127289 163919 15022507 8989587 1995046 

sim_total_stores 115008 1828969 4395576 3044353 615914 

sim_total_branches 172983 260224 10000079 2240622 859096 

sim_IPC 1,9573 1,7439 1,869 1,9417 2,8234 

sim_CPI 0,5109 0,5734 0,535 0,515 0,3542 

il1.accesses 1087669 3100829 56135385 39241347 13704591 

il1.hits 1086398 3088192 55975880 38349316 13699763 

il1.misses 1271 12637 159505 892031 4828 

il1.replacements 777 12187 159021 891531 4358 

il1.writebacks 0 0 0 0 0 

dl1.accesses 222420 1963656 17647502 11835840 2534710 

dl1.hits 210537 1735202 17493696 11833396 2533936 

dl1.misses 11883 228454 153806 2444 774 

dl1.replacements 11371 227942 153294 1932 262 

dl1.writebacks 10365 225257 9884 672 254 

ul2.accesses 23519 466348 323195 895147 5856 

ul2.hits 17940 410976 321635 894141 5023 

ul2.misses 5579 55372 1560 1006 833 

ul2.replacements 1608 51276 0 0 0 

ul2.writebacks 1177 45542 0 0 0 

itlb.accesses 1087669 3100829 56135385 39241347 13704591 

itlb.hits 1087642 3100809 56135367 39241330 13704577 

dtlb.accesses 223139 1980663 19188662 11894346 2534770 

dtlb.hits 223019 1980458 19188640 11894332 2534759 

mem.page_mem 1128k 624k 188k 164k 124k 

mem.ptab_missses 282 164 75 49 31 

След направените симулации за визуализиране на получените резултати и полесното 

им анализиране следват графики. 

3069412 

1041989 

13569524 

total_ins 

38108159 

go compress95 sha rijndael dijkstra 

55667370 

фиг.2 Брой на изпълнените инструкции по време на симулацията. 

Най-много изпълнени инструкции има при алгоритъма на Дикстра, последван 

от алгоритъма на Риндаел и с най-малко инструкции е go. От тук става ясно, че найголяма 

заетост (производителност) на процесора има при алгоритъма на Дикстра.

- 179 - 

На следващата, фиг.3. се вижда, че параметърът брой обръщения към паметта 

има най-голяма стойност при програмите Дикстра и Риндаел, защото при тях има найголям 

брой изпълнени инструкции. 

242297 

2610960 

1992888 

total_refs 

12033940 

go compress95 sha rijndael dijkstra 

фиг.3 Брой обръщения към паметта. 

benchmarks 

8989587 

loads/stores 

rijndael 

15022507 

dijkstra 

1995046 

sha 615914 

163919 

compress95 1828969 

127289 

go 

115008 

3044353 

instructions 

sim_total_loads sim_total_stores 

19418083 

4395576 

фиг. 4 Обръщения към паметта 

Както и в предишните графики и тук параметрите запис и четене от паметта 

имат най-малки стойности при изпълнение на тестиращите програми go, compress95 и 

sha. При go и compress95 инструкциите за четене са значително по-малко от 

инструкциите за запис, докато при останалите програми се наблюдава обратното. 

859096 

260224 

172983 

2240622 

фиг. 5. Инструкции за преход 

total_branches 

10000079 

rijndael 

dijkstra 


sha 

compress95 

go

- 180 - 

Напълно логично и на фиг. 5 се вижда, че най-малко инструкции за преход се 

изпълняват при go и compress95. 

rijndael 

dijkstra 

sha 

compress95 

go 

0,515 

0,535 

0,3542 

0,5734 

0,5109 

1,9417 

1,869 

1,7439 

1,9573 

sim_CPI 

sim_IPC 

2,8234 

Фиг. 6 CPI - брой тактове, необходими за изпълнението на една 

инструкция и IPC – брой инструкции, изпълнени за един такт 

Най-добри резултати по отношение на параметъра IPC дава алгоритъмът за 

защита на данните (sha). За останалите benchmarks стойностите са близки. 

il1 

1087669 

1086398 

go 

777 

3100829 

3088192 

compress95 

12187 

13704591 

sha 

13699763 

4358 

56135385 

dijkstra 

il1.accesses il1.hits il1.replacements 

55975880 

159021 

rijndael 

фиг. 7 и фиг. 8 Честота на попадение в кеша за инструкции/данни от първо ниво. 

dl1 

222420 

210537 

11371 

10365 

1963656 

1735202 

227942 

225257 

go 

compress95 

2534710 

2533936 

sha 

17647502 

262 

254 

dijkstra 

17493696 

153294 

9884 

11835840 

rijndael 

39241347 

38349316 

11833396 

891531 

1932 

672 

dl1.accesses dl1.hits dl1.replacements dl1.writebacks 

Разглеждам заедно фиг. 7 и фиг. 8. Честотите на попадение в кеша за 

инструкции от първо ниво (фиг. 7) и в кеша за данни от първо ниво (фиг. 8) са много

- 181 - 

високи. Отново този параметър има най-големи стойности при Дикстра и Риндаел, 

които значително се отличават. 

ul2 

23519 

17940 

1608 

1177 

go 

466348 

410976 

compress95 

51276 

45542 

5856 

5023 

sha 

0 

0 

323195 

321635 

dijkstra 

0 

0 


895147 

rijndael 

894141 

0 

0 

ul2.accesses ul2.hits ul2.replacements ul2.writebacks 

Фиг. 9 

Наблюдава, че честотата на попадение в кеша от второ ниво (обединен е кеша за 

инструкции и кеша за данни) вече има най-големи стойности при програмите Риндаел 

и compress95, а Дикстра остава на по-задни позиции. 

rijndael 

dijkstra 

sha 

compress95 

go 

3100809 

3100829 

1087642 

1087669 

13704577 

13704591 

iTLB 

39241330 

39241347 

itlb.accesses itlb.hits 

фиг. 10 

56135367 

56135385 

Фиг. 10 и фиг. 11 представят честотите на попадение съответно в TLB за 

инструкции и в TLB за данни. И тук отново най-големи стойности за този параметър 

дават Дикстра и Риндаел. Параметрите, характеризиращи TLB за инструкции имат 

значително по-високи стойности от параметрите, характеризиращи TLB за данни.

compress95 

size, KB 

rijndael 

dijkstra 

sha 

go 

1128 

1980458 

1980663 

223019 

223139 

2534759 

2534770 

dTLB 

dtlb.accesses dtlb.hits 

624 

фиг. 11 

- 182 - 

11894332 

11894346 

mem.page_mem 

124 

19188640 

19188662 

188 164 

go compress95 sha dijkstra rijndael 

benchmarks 

фиг. 12 

Показва размера на страниците, които се намират в оперативната памет. За 

разлика от предишните графики тук най-голям е размера на страниците при програмата 

go, затова при нея има най-малко изпълнени инструкци. 

pages 

282 

164 

mem.ptab_missses 

31 

go compress95 sha dijkstra rijndael 

benchmarks 

фиг. 13 Брой станиците, които липсват. 

Най-големи стойности има при програмите go и compress95. Когато в 

оперативната памет има страници с голяма дължина, техният брой ще е по-малък, а 

75 

49

- 183 - 

това означава, че стойността на параметъра misses (липсващи страници) е голяма и това 

понижава производителността на процесора, която се изразява в брой инструкции за 

единица време. 


В резултат от направените симулации на програмите go, compress95, sha, 

dijkstra и rijndael и анализираните резултати, могат да се направят следните 

заключение, че ниската производителност при тестовете go и compress95 се дължи на 

големината на страниците, които се зареждат в оперативната паметта, защото по този 

начин се намалява честотата на попадение в паметта, а от там като цяло спада и 

производителността на процесора. 

1. M.Behar. “SimpleScalar Introduction” 

2. http://www.simplescalar.com 

3. http://www.spec.org/cpu 




4000 Plovdiv 

BULGARIA 

E-mail:mr_marinova@yahoo.com 



- 184 -

- 185 - 




BULGARIA 

A MODULE FOR A DYNAMIC PRESENTATION OF 

EXAMPLES IN ELECTRONIC TEXTBOOKS ON WEB 

PROGRAMMING – A METHOD FOR ITS REALIZATION 

YURI HOPTERIEV 

Abstract. This paper describes a module, designed for the dynamic presentation of 

examples in web format e-textbooks on languages that are interpreted by a browser on a 

client computer. The solution of a sample problem is presented by the module in terms of 

stages and steps. Using the possibilities of the web page and the functions of the browser, 

the learner is given an opportunity (i) to view the result of the solution at each stage, (ii) 

to make experiments on the model examples, (iii) to solve and test the assignments in the 

electronic textbook itself. The data structures and methods of realization of the module 

are described. 

Key words: web programming, e-learning, e-textbook. 

МОДУЛ ЗА ДИНАМИЧНО ПРЕДСТАВЯНЕ НА ПРИМЕРИ В 

ЕЛЕКТРОННИ УЧЕБНИЦИ ПО ПРОГРАМИРАНЕ ЗА ИНТЕРНЕТ – 

НАЧИН ЗА РЕАЛИЗАЦИЯ 


Развитието на дистанционното обучение [1] е свързано с използването на 

съвременните информационни технологии [4], предоставящи възможност за създаване 

на електронни курсове и учебници, които качествено се отличават от хартиените. В 

електронните учебни материали може да се включат функции, които до известна степен 

компенсират липсата на пряк контакт между студент и преподавател. В работата е 

разгледан модул, осъществяващ подход [2] за динамично представяне на примери в 

електронни учебници в уеб-формат по езиците, които се интерпретират от браузера на 

машината-клиент. 

2. Възможности на модула 

Посредством модула се представят учебни примери и се възлагат задачи, чието 

решаване се свежда до писане на HTML-код или скрипт. 

2.1. Представяне на примерна задача 

1) Извежда се условието на задачата и се показва очакваният резултат от 

решението. 


- 186 - 

2) Показва се процесът на решаване на задачата. Кодът на решението се 

представя в текстов редактор по етапи и по стъпки 2 . Стъпката е посимволно извеждане 

или изтриване на низ (в частност- един символ), представляващ малка част (подниз) от 

решението. Серията е последователност от стъпки (в частност- една стъпка), която се 

изпълнява без прекъсване във времето. Например първа серия от стъпки при 

създаването на уеб-страница може да бъде записването на началния и крайния тагове 

(Таблица 1). Всака стъпка може да вмъква или изтрива в написания до момента код. 

Редът и съдържанието на стъпките се определя от автора на учебника. Изискване: ако 

се предвижда даден подниз от кода да бъде изтрит, извеждането му също трябва да 

стане с отделна стъпка. Етапът е последователност от серии (в частност- една серия), 

която може да се разглежда като завършена част от решението. След края на всеки етап 

се показва резултат [2]. 

Таблица 1. Серия от стъпки 

Стъпка № 1 2 3 4 5 6 

Изведен 

код 

< 

< 

 

 

 

 

Изпълнението на стъпките се стартира от обучаемия, който чете обяснителен 

текст относно решението, съдържащ активни елементи 3 . При избор на АЕ се изпълнява 

серия от стъпки. За да се спазва редът на извеждане, във всеки момент от представянето 

на решението е изпълним само (най-много) един АЕ, съответстващ на прочетения до 

момента текст. След завършване на решението се показва резултат и на обучаемия се 

предоставя възможност да редактира готовия пример и да проверява резултата от 

експериментите си (Фиг. 1). 

Фиг. 1. Модулът, интегриран в страница на електронен учебник. 

2 Модулът реализира усъвършенстван вариант на описания в [2] подход, което налага предефиниране на 

понятията стъпка и етап и въвеждане на ново понятие- серия. 

3 Активен елемент (АЕ)- елемент, който реагира на предизвикано от мишката събитие.

- 187 - 

2.2 Възлагане на задача за самостоятелна работа 

1) Извежда се условието на задачата и се показва очакваният резултат от 

решението. 

2) На екрана се извежда среда за въвеждане и тестване на примери [2] (Фиг. 1). 

Модулът може да се използва самостоятелно за задачи, решението на които се 

изчерпва с един HTML-документ. При задачи, за чието решение са необходими два или 

повече файла, модулът се използва в комбинация с виртуален диск (ВД) [3], който 

съхранява файловете, осъществява връзките между тях и предоставя на обучаемия 

помощ при определяне на път към файл. 

3. Начин за реализация 

Модулът е реализиран под формата на динамична уеб-страница, което го прави 

удобен за интегриране в страниците на електронен учебник. 

3.1. Организация на интерфейса 

Използват се свойствата на уеб-страницата, възможността за динамична промяна 

на стойностите им и функциите на браузера. Информацията се представя на екрана в 

правоъгълни области, дефинирани с таг div и разположени в два слоя (Фиг. 2). 

Layer01 

Layer02 

Layer01_Left 

Първи слой 

Втори слой 

Layer02_Left 

Текстово поле 

Бутони за управление 

Layer01_Right 

Фиг. 2. Елементи на нтерфейса. 

Layer02_Right_Rect01 

Layer02_Right_Rect02 

Плаващ прозорец 

Съдържанието в правоъгълните области се променя посредством свойството 

innerHTML, а видимостта на всеки слой се определя от стойностите на свойствата 

visibility и z-index. Първият слой с идентификатор Layer01 по подразбиране е видим и 

има две подобласти- лява и дясна (Layer01_Left и Layer01_Right). В Layer01_Left се 

извежда условието на представяната задача. В Layer01_Right на фона на изобразен 

браузер е разположен плаващ прозорец (елемент iframe) с идентификатор winResult01, 

в който се показва очакваният резултат от решението. Вторият слой (Layer02) съвпада 


- 188 - 

по размери и (x,y)-координати с Layer01. Той става видим, когато се представя решение 

на задача. Разделен е на две подобласти- лава (Layer02_Left) и дясна, в която са 

разположени два правоъгълника (Layer02_Right_Rect01 и Layer02_Right_Rect02), 

съвпадащи по размери и (x,y)-координати, но с различна видимост (по подразбиране е 

видим Layer02_Right_Rect01). В Layer02_Left на фона на изобразен текстов редактор е 

разположено текстово поле (елемент textarea) с идентификатор codeEditor, в коeто се 

извежда и редактира решението на задачата. Обяснентелният текст с активните 

елементи е в Layer02_Right_Rect01. В Layer02_Right_Rect02 на фона на изобразен 

браузер е разположен плаващ прозорец (елемент iframe, имащ способността да 

интерпретира HTML-код) с идентификатор winResult02, в който се показва резултатът 

от решението, съдържащо се в текстовото поле codeEditor (Фиг. 1). Видимостта на 

Layer02_Right_Rect02 може да се сменя автоматично и ръчно. След завършване на 

решението codeEditor става достъпен за писане от клавиатурата. 

Посредством бутони (Фиг. 2) може да се преминава към следваща (предходна) 

задача, да се сменя видимостта на слоевете и да се показва резултат от решение, 

съдържащо се в codeEditor. 

3.2. Структури от данни 

Данните, необходими за представянето на една задача се съхраняват в обект от 

предварително дефиниран тип objectExample със следните свойства: 

1) txtProblem е стринг, съдържащ условието на задачата в HTML-формат. 

Стойността му се извежда на екрана посредством свойството innerHTML на 

Layer01_Left. 

2) codeSolution е стринг, съдържащ решението на задачата (HTML-код или 

скрипт). Стойността му се използва при показване на очакван резултат в winResult01 и 

при извеждане на решението в codeEditor. 

3) txtSolution е стринг (в HTML-формат), съдържащ обяснителния текст по 

решението с включени активни елементи. На всеки АЕ посредством таг span е 

присвоен един и същи идентификатор activeElem. Стойността на txtSolution се извежда 

на екрана посредством свойството innerHTML на Layer02_Right_Rect01, при което в 

уеб-страницата се създава масив от АЕ (activeElem). 

4) arraySteps е масив. Всеки елемент на arraySteps съдържа данни за една стъпка 

и е обект от предварително дефиниран тип objectStep със следните свойства: 

4.1) beginStep- начална позиция на подниза в codeSolution; 

4.2) lengthStep- дължина на подниза (при изтриване lengthStep е отрицателно 

число); 

4.3) posStep- позиция на вмъкване (или изтриване) в изведения до момента код. 

Стойността на posStep е сума от стойностите на lengthStep на изпълнените до момента 

стъпки, за които beginStep е по-малко от beginStep на текущата стъпка. 

5) arraySeries е масив за сериите. Всеки елемент на arraySeries е цяло 

положително число (брой стъпки в серия) или нула (край на етап). 

Редът на стъпките и сериите в решението на една задача се управлява с помощта 

на числовите променливи currentStep (за стъпките) и currentSeries(за сериите). 

При работа със списък от задачи може да се дефинира масив от обекти 

objectExample. 

3.3. Функции 

За динамично представяне на решението на задача се използват функциите: 

function adaptCode (htmlCode) 

действие:

- 189 - 

1) проверява htmlCode (стринг, съдържащ HTML-код) за препратки към други 

файлове и при наличие на протокол file адаптира съответната препратка за работа с 

виртуалния диск [3]; 

2) връща като резултат адаптирания код. 

Използва се при съвместна работа с ВД. 

function displayResult(winID, htmlCode) 

действие- извежда резултата от съдържанието на htmlCode в прозорец с 

идентификатор winID, използвайки способността на прозореца да интерпретира 

HTML-код. 

Използва се при показване на резултат в winResult01 и winResult02. 

function execStep() 

действие: 

1) изпълнява текущата стъпка (вмъкване или изтриване в codeEditor), данните за 

която се съдържат в arraySteps[currentStep] за текущата задача; 

2) увеличава currentStep с 1; 

function execSeries() 

действие: 

1) изпълнява N на брой пъти execStep(), където N=arraySeries[currentSeries] за 

текущата задача; 

2) при край на етап- displayResult(winResult02, codeEditor.value); 4 

3) увеличава currentSeries с 1; 

4) дава право за изпълнение на следващия активен елемент. 

Динамично представяне на решение: 

При първоначално зареждане на задача: 

currentStep=0; 

currentSeries=0; 

activeElem[0].onclick=”execSeries()”; 

При избор на първия изпълним активен елемент от обяснителния текст, се 

извиква execSeries() и започва интерактивният процес на извеждане на решението. 


Първите резултати от работата са приложени в електронен учебник 5 по HTML. 

Студентите имат възможност да експериментират с готовите примери и да въвеждат и 

тестват свои в рамките на самия учебник. Динамичното представяне на решение 

позволява да се проследи процесът на писане и тестване на кода. Новите функции 

разширяват възможностите на модула. Посредством стъпки, които редактират (вмъкват 

и изтриват) кода на решението, може да се представят примери, демонстриращи 

локализиране, откриване и отстраняване на допусната грешка. Съвместното използване 

на модула с виртуален диск [3] позволява решаването на задачи, включващи 

хипервръзки. 


Динамичното представяне на примери е резултат от пълноценно използване на 

свойствата на уеб-страницата и функциите на браузера. Модулът е създаден със 

4 При съвместна работа с ВД извикването е displayResult(winResult02, adaptCode(codeEditor.value));. 

5 Ю. Хоптериев, Въведение в HTML, http://e-school.hit.bg/html (от 01.11.2005 г.). 


- 190 - 

средствата на HTML, CSS и JavaScript и работи на браузер Iternet Explorer 6.0 или 

съвместим. 


1. Г. Тотков, Е. Сомова, Р. Донева. За дистанционното обучение и развитието му в 

България, Юбилейна научна сесия- 30 години ФМИ, ПУ “Паисий Хилендарски”, 

Пловдив, 3-4.11.2000, 266-271. 

2. Ю. Хоптериев. Един подход за представяне на примери в електронни учебници по 

програмиране за Интернет, Научно-приложна конференция по математика, 

информатика и компютърни науки, В. Търново, 12-13 май 2006 г., 468-472. 

3. Ю. Хоптериев. Модул за провеждане на упражнения и тестове в електронни курсове 

по информатика, разглеждащи операции с файлове и директории, 

ІІ национална конференция с международно участие по електронно обучение във 

висшето образование, Китен, 14-16 септември 2006 г., 106-108. 

4. G. Totkov. Virtual Learning Environments: Towards New Generations. Proceedings of the 

Intern. Conf. of Computer Systems and Technologies (e-learning), CompSysTech’2003, 

Sofia, Bulgaria, 19-20 June, 2003, P.2-1 – P.2-9. 

Department of Computer Technologies 

University of Plovdiv “Paisii Hilendarski” 

24, Tsar Asen Str. 

4000 Plovdiv 

BULGARIA 

E-mail: yurih@uni-plovdiv.bg

- 191 - 




BULGARIA 

STUDY OF TECHNICAL POSSIBILITIES OF NEW VERSION 

OF MS COM+ 

IVANKA VALOVA, BOZHAN ZHECHEV 

Abstract. In this paper are studied the technical possibilities of new version of COM 

technology – version 1.5. The improvements made as compared to COM+ 1.0 are studied 

and some of existing problems are discussed. The new improvements secure the full 

compatibility of COM+ 1.5 with components and applications of COM+ 1.0. Microsoft 

also added new features to existing services and laid the foundation for integration with 

Microsoft .NET services. The software application COM+ is a component of new 

Windows - Windows Vista and its knowledge and understanding is an investment in the 

future. 

Key words: COM+ 1.5, COM+ 1.0, Component Services. 

ИЗСЛЕДВАНЕ НА ТЕХНИЧЕСКИТЕ ВЪЗМОЖНОСТИ НА НОВАТА 

ВЕРСИЯ НА MS COM+ 

ИВАНКА ВЪЛОВА, БОЖАН ЖЕЧЕВ 


COM+ е името на COM-базираните услуги и технологии, за пръв път въведени с 

Windows 2000. COM+ участва и в новата версия на Windows, Windows Vista. COM+ 

обедини технологията на COM компонентите и предоставящия среда за приложенията 

Transaction Server (MTS) на Microsoft. COM+ автоматично управлява сложни 

програмни задачи, като: събиране на ресурси в пулове, публикуването и абонамент за 

събития, разпределени операции. 

COM+ 1.5 предлага редица подобрения в сравнение с COM+ 1.0. 

1. Комплексен потребителски интерфейс, който показва повече данни за всяко 

приложение 

2. Пълна поддръжка за наследените компоненти от предишната версия 

3. Управление на съществуващите приложения по-лесно и по-ефикасно. 

4. Подобрената поддръжка в организацията на изчакването на опашка, предоставя 

възможност за по-гъвкаво управление на изчакващите заявки, а обединяване и 

рециклиране означава по-добро управление на жизнения цикъл на дадено 

приложение. 

5. Сегментирането на дадено приложение в COM+ 1.5, превъзхожда COM+ 1.0, 

6. Изолирането на дадена транзакция може да бъде конфигурирано за подобряване 

на сигурността на транзакцията. 

7. COM+ 1.5 позволява да се представи всеки COM+ компонент като уеб-услуга, 

при положение че последният отговаря на определени критерии. 

Microsoft Windows XP пакетът включва следващата версия на COM+, която се 

нарича COM+ 1.5. Тази статия описва новите характеристики и възможности на COM+ 


- 192 - 

1.5. Подобрени са начините за използването на COM+ чрез отстраняване на някои от 

съществуващите проблеми в COM+ 1.0. Майкрософт са добавили нови характеристики 

към съществуващите услуги и са поставили основите за интегриране с Microsoft .NETбазираните 

услуги. Останалите подобрения осигуряват пълната съвместимост на COM+ 

1.5 с компонентите и приложенията на COM+ 1.0. 

COM+ версия 1.5 добавя нови характеристики, които са проектирани за да 

увеличат общата универсалност, наличност и лесно управление на COM+ 

приложенията, както за разработчиците така и за системните администратори. За 

улесняване на конфигурирането и внедряването на тези нови характеристики са 

добавени разширена документация и нови отчети към документацията на SDK, а 

помощните менюта са обновени в инструмента за администриране Component Services 

(Компонентни услуги). 

COM+ 1.5 е включен в операционните системи Microsoft Windows XP и 

Microsoft Windows Server 2003. Новите COM+ 1.5 характеристики не са налични в поранните 

платформи, например в Microsoft Windows 2000. В новата версия COM+ 

представя поддръжка за COM+ сегменти и позволява различни версии от COM+ 

приложения да бъдат инсталирани и конфигурирани на една и съща машина. Спестяват 

се скъпо струващите и отнемащи време усилия да се използват многобройни сървъри за 

да се управляват различни версии на дадено приложение. На една машина всеки 

сегмент (сектор) действа като виртуален сървър. След като се инсталира приложението 

се създават набори от сегменти, които насочват потребителите към логическите 

сървъри. 

2. Конкуриращи се технологии -CORBA, DCOM, EJB 

За опростяване на мрежовото програмиране и за да бъде реализирана основана на 

компонентите софтуерна архитектура се появиха като стандарти два модела на 

разпределени обекти - DCOM (Distributed Component Object Model) на Майкрософт и 

CORBA (Common Object Request Broker Architecture) на Object Management Group 

(OMG). От гледна точка на компонентите съществуват две конкуриращи се 

архитектури: Javasoft’s Enterprise JavaBeans и Microsoft’s COM. Голяма част от 

литературата смесва понятията разпределени обекти и компоненти. Полезна 

информация за разпределените обекти и компоненти може да бъде намерена в [1,6, 7,8] 

2.1 CORBA 

CORBA е рамка от разпределени обекти, предложена от консорциум от над 800 

дружества наречени Object Management Group (OMG), създаден през 1989 година. 

Организациите-членки варират от големи дружества като Sun Microsystems, до помалки 

като Visigenic/Inprise Software Corporation. 

CORBA служи като спецификация на междуплатформено програмно обезпечение за 

разпределени обекти. Има няколко търговски продукта, които прилагат стандарта 

CORBA. 

Кратък преглед върху CORBA архитектурата e направен в [5]. Работата е полезна за 

откриването на подробности относно синтаксиса за IDL (Interface Definition Language), 

използван от CORBA. Както беше споменато има няколко ORB приложения сред които 

Inprise Visibroker ORB е най-широко използваното. Описаниe на класовете и 

интерфейсите, поддържани от Visibroker за Java е направено в [10]. Техническа 

информация за Orbix ORB може да бъде намерена в [1].

- 193 - 

2.2 DCOM 

DCOM (Distributed Component Object Model) е разширение на COM, което 

предоставя взаимодействие между обектите изпълнявани на отделни компютри в 

дадена мрежа. DCOM използва мрежови протокол за обектно ориентиран RPC [3, 7]. 

DCOM скрива разположението на сървърния компонент от клиента, независимо дали 

той е на същата машина (вътрешен или външен процес) или на друга машина в друга 

част на света. При всички случаи начинът по който клиентския код се свързва с 

компонента и извиква неговите методи е един и същ. Всеки път когато един клиент се 

нуждае от услуга от отдалечен разпределен обект, той извиква метод приложен от 

отдалечен обект. Услугата, която отдалечения разпределен обект (сървъра) предоставя 

е капсулирана като обект, а интерфейсът на отдалечения обект е описан в IDL. DCOM 

сървър компонентите могат да бъдат разработени на различни програмни езици като 

C++, Java, Object Pascal (Delphi), Visual Basic и COBOL. DCOM се използва върху 

Windows платформа. 

2.3 EJB 

Технологията EJB (Enterprise JavaBeans) дефинира модел за разработване на Java 

компоненти, които могат да бъдат използвани повторно. Базирани на Java 

компонентния модел JavaBeans, EJB разширява компонентния модел, с цел поддръжка 

на сървърни компоненти. Сървърът предоставя работна среда за EJB контейнер, който 

действа като интерфейс между Enterprise Bean и външния свят. EJB bean не е достъпен 

от EJB клиент, всеки достъп е извършван чрез EJB контейнер [4]. 

Широко използван е сървърът BEA Weblogic Server 5.1 от BEA Systems [2]. 

3. COM+ 1.5- наследени приложения и компоненти 

COM+ 1.5 Explorer притежава подобрен потребителски интерфейс. При COM+ 

1.0 например, единственият начин да се познае начина на активиране на дадено COM+ 

приложение е да се извика таблицата за активиране и тя да бъде изследвана докато бъде 

открито необходимото приложение. COM+ 1.5 Explorer отнася различните икони към 

различните видове приложения и виждайки даденото приложение може да се разбере 

вида- сървър, библиотека или прокси-сървър. 

Приложения за услуги, четвъртият вид приложения, които са налични в COM+ 

1.5 имат отделна икона. Нова директория, която може да бъде открита в иконата My 

Computer наречена Running Processes, съдържа всички приложения, които се използват 

в даден момент, осигурявайки по този начин лесно администриране на изпълнението. 

COM+ 1.0 Explorer позволява да се управляват само конфигурираните 

компоненти. В реалния живот, конфигурираните компоненти често си взаимодействат с 

наследени COM компоненти, които са собствени или на трета компания-доставчик. В 

хетерогенна среда, разработчиците използват други инструменти в допълнение към 

COM+ Explorer, за целите на управлението на наследените компоненти. Тези 

инструменти включват DCOMCNFG, OLEView, Visual Studio или други разработени по 

поръчка на клиента инструменти. 

Разработчиците трябва да управляват два подхода за разполагане – единият използва 

експортирани COM+ приложения (MSI файлове), а другият се състои от необходимите 

за инсталирането на наследените компоненти. Предоставя се цялостна поддръжка за 

наследени приложения и компоненти в COM+ 1.5. Това позволява да се управлява 

всеки аспект от дадени наследени приложения и компоненти, толкова успешно, 

колкото и ако използвате DCOMCNFG или OLEView. 

При COM+ 1.5 Explorer, в My Computer има нова директория наречена DCOM 

Config.Тази директория е сродна с приложения на COM+. Директорията DCOM Config 


- 194 - 

съдържа всички регистрирани локални COM сървъри (EXE сървъри). Всеки локален 

сървър е наречен наследено приложение. За разлика от COM+ приложенията, не може 

да се разширява наследеното приложение до компонент, интерфейс или до методическо 

ниво. Директорията DCOM Config дава централизирана позиция от която да се 

управляват COM+ приложения и наследени локални сървъри, без да е необходимо 

прибягването до други инструменти. 

При натискане с десния бутон на мишката върху дадено наследено приложение 

и избирайки функция Properties от падащото меню, се отваря страницата на свойствата, 

която позволява да се управлява всеки аспект от наследеното приложение. General tab 

позволява да се променя името на приложението и да се задава ниво на достъп за 

входящи заявки към това приложение. Функцията Location tab позволява да се 

контролира дали да се стартира приложението на вашия компютър или на друг 

компютър в мрежата. Функцията Security tab позволява да се конфигурира достъпа, 

стартирането и промяната на оторизациите за достъп на всеки потребител. Функцията 

Endpoints tab позволява да се конфигурира транспортните протоколи за DCOM 

заявките. Функцията Identity tab позволява да се определя при каква идентификация за 

достъп да бъде стартиран сървъра, включително и системния акаунт (само за услуги). 

Ако дадено COM+ приложение използва наследените компоненти (неконфигурирани 

по време на процеса COM компоненти), тогава COM+ 1.5 Explorer 

позволява да се управляват също тези компоненти които са в обхвата на даденото 

приложение. Приложение на COM+ 1.5 има нова директория наречена Legacy 

Components. За да се добави наследен компонент към директорията се избира New от 

контекстното меню. COM+ 1.5 Explorer представя приложението Legacy Component 

Import Wizard, който позволява да се избират наследени компоненти и да се добавят 

към даденото приложение. Трябва да се отбележи, че точно както конфигурираните 

компоненти, наследените компоненти, могат да участват точно в едно COM+ 1.5 

приложение. 

Основното предимство на наследените компоненти като част от дадено COM+ 1.5 

приложение е по-лесното им разгръщане. Когато се експортира дадено COM+ 

приложение, неговият MSI файл съдържа наследени компоненти и техните настройки. 

Когато се инсталира MSI файл на друга машина, Windows Installer регистрира 

компонентите, което спестява проблема с писането на отделна инсталационна 

програма за всеки проект. 

Фиг.1. Свойства на наследените компоненти

- 195 - 

Страницата на приоритетите на наследените компоненти запознава с всяко съответно 

регистрационно вписване за дадения компонент- Фиг. 1. Може да се променят 

стойностите на настройки, които не са в противоречие с регистрационните настройки в 

самия компонент. Например, не може да се променя стойността на модела за 

последователна обработка, но може да се предостави име на псевдопроцес. Може да се 

повиши един наследен компонент в конфигуриран компонент. Извиква се менюто на 

наследения компонент, след това се избира функцията Promote-Фиг. 2. Наследеният 

компонент е отстранен от директорията наследени компоненти и е добавен към 

директорията компоненти в същото COM+ 1.5 приложение. 

Фиг. 2. Повишаване на категорията на наследен компонент 

4. Деактивиране на приложения и компоненти 

COM+ 1.5 Explorer позволява да се деактивират приложения и компоненти. 

Когато е деактивирано дадено приложение, всички опити на клиента да създаде 

компонент от съответното приложение са неуспешни при получаването на следното 

съобщение HRESULT: “Компонентът е деактивиран.” За да се деактивира дадено 

приложение трябва де се избере функция Disable от падащото меню. Когато 

приложението е деактивирано, се появява червено квадратче върху иконата на 

приложението в COM+ 1.5 Explorer. За активиране на деактивирано приложение се 

избира функция Enable (Фиг.3). 

Може да се деактивира само COM+ 1.5 приложения, наследените приложения не 

могат да бъдат деактивирани. Клиент който вече има отношения с даден COM+ обект 

не е засегнат от факта, че приложението е деактивирано, а само клиенти които се 

опитват да създадат нови обекти. Съответно може да имате деактивирано приложение 

което да работи неопределено дълго време. 

Може индивидуално да се деактивират компоненти. Всяко падащо меню на 

компонента има опцията Disabled. Деактивираният компонент има изобразено червено 

квадратче върху неговата икона. Всички опити на клиента за създаване на деактивиран 

компонент няма да бъдат успешни, като се получава съобщение уведомяващо, че 

компонентът е бил деактивиран. 


. 

- 196 - 

Фиг. 3. Активиране на деактивирано приложение 

Може да се деактивира всеки компонент в COM+ 1.5 приложението, включително и 

наследените компоненти (Фиг. 2). За да се активира един компонент, трябва да се 

избере функция Enable от падащото меню. Деактивирането на един компонент оказва 

влияние върху нови заявки към въпросния компонент; вече съществуващите отношения 

със други обекти не са засегнати. Статусът Активиран за приложението и компонента 

се съхранява в COM+ Catalog и следователно се поддържа дори когато се рестартира 

компютъра. 

Деактивирането на приложения или компоненти е полезно в два случая. 

Първият е когато внимателно се затваря едно приложение намиращо се на активен 

сървър, с цел извършването на работи по поддръжка или обновяване. Ако се затвори 

приложението, това може да доведе до неочаквани проблеми при работата в 

клиентските компютри, поддържащи работни отношения с приложението. Чрез 

деактивирането на приложението, се позволява на клиентите да приключат своята 

работа, докато новите активации вероятно се прехвърлят към друг компютър, 

предоставяйки по този начин възможността за извършване на поддръжка. 

Деактивирането на приложение е полезно при разработки и тестове. То предоставя 

гарантиран начин за неуспешни клиентски заявки и по този начин проверява дадената 

система за управлението на грешки в приложението от страна на клиента. 

5. Поставяне на приложенията в режим на пауза 

Поставяне на приложенията в режим на пауза е действие подобно на 

деактивирането на приложение, с изключение, че се използва за деактивирането само 

на точно определен текущ работен процес и режимът на пауза не се запазва при 

затваряне на приложението. За да се постави в режим на пауза един процес, се отваря 

директорията Running Processes и се избира функция Pause от менюто на 

приложението. За да се активира отново процеса, се избира функция Resume-Фиг. 4.

- 197 - 

Фиг. 4. Възобновяване активността на приложение 

6. Вид активиране на услуга 

COM+ 1.5 позволява да се конфигурира сървър приложение да работи като 

системна услуга. Правейки това е налице работещо приложение, веднага след като 

компютъра бъде включен, независимо от повикванията за активиране от страна на 

клиенти. Друга полза е, че работно приложение е единствения начин дадено 

приложение да работи под определен идентификационен системен акаунт. Системният 

акаунт е най-мощният акаунт на даден компютър. 

Activation tab на приложението съдържа клетка "Run application as NT Service" (Фиг.5). 

Когато се избира тази функция може да се конфигурират различни параметри на 

услугата, избирайки бутон Setup New Service, което спестява главоболия свързани с 

използването на аплет за услуги от контролния панел. 

Фиг. 5 Конфигуриране на работно приложение 

7. Подобрена поддръжка на изчакване 

Поредните компоненти при COM+ 1.0 изискват присъствието на контролер на 

домейна, за осигуряване на достъпа на изчакващата заявка. Ако няма контролер на 

домейна, трябва да се изключи COM+ 1.0 функцията идентифициране на приложение 

(None). COM+ 1.5 предоставя по-гъвкава възможност за конфигуриране на 

поддръжката на сигурността за изчакващи заявки, чрез разделянето им от стандартните 


- 198 - 

синхронни заявки. Функцията Queuing tab позволява да се конфигурира ясно контрола 

на достъп за изчакващите заявки –Фиг. 6. 

Следните опции са налични: 

Фиг. 6. Изчакване на приложение 

• Контрол за достъп на домейн контролера Microsoft Message Queuing (MSMQ), 

когато приложението е конфигурирано да използва контрол за достъп за синхронни 

заявки (когато контролът за достъп на приложението е настроен за всяка стойност с 

изключение на None). 

• Никога не удостоверявайте контрола за достъп на изчакващи заявки в това 

приложение. Като се избере тази опция, е позволено свободно да се използва 

изчакващи компоненти без домейн контролер. 

• Винаги да се удостоверява контрола за достъп на изчакващи заявки, независимо 

от настройките за контрола за достъп на даденото приложение. 

Функцията Queuing tab също позволява да се контролира максимален брой от 

едновременно функциониращи играчи, които приложението може да съдържа. (Играч е 

компонент , който връща обратно поредната заявка до вашия компонент.) Тъй като 

всеки играч е създаден върху отделна нишка, има завишени разходи на капацитет при 

създаването и поддръжката на един играч. В екстремни ситуации, дадено приложение 

може да спре да работи, ако броят на едновременно функциониращите играчи е 

прекалено голям (до няколко стотици). Когато се заложи ограничение за броя на 

играчите и това ограничение е изпълнено, приемникът спира създаването на нови 

играчи. По-скоро, изчакващите заявки остават в опашката на приложението за 

изпълнение, позволявайки по този начин на заявките които се обработват в момента да 

бъдат изпълнени и завършени. Поставянето на ограничение е също така добро и за 

целите на балансиране на натоварването и могат да бъдат използвани във връзка със 

обединяването на едно място на приложения. 

8. Предоставяне на уеб услуги чрез COM+ 

COM+ приложение може да се представи като XML уеб-услуга [6, 11] чрез 

COM+ 1.5. Лесно може да се създаде нова XML уеб-услуга извън съществуващите 

COM+ приложения и да се внедри XML уеб-услуги в нови COM+ приложения. Чрез 

избиране на клетката Uses SOAP в инструмента за администриране Component Services,

- 199 - 

може да се покаже COM+ приложение като XML уеб-услуга. Може да се създаде нова 

XML уеб-услуга извън съществуващите COM+ приложения и лесно да се внедри XML 

уеб-услуга в нови COM+ приложения. 

Поддръжката на уеб услуги е нова услуга на .NET платформата. Уеб услугите 

позволяват среден компонент в уебсайт да призовава методи от друг среден компонент 

в друг уеб сайт все едно, че двата компонента се намират на един сайт и на един и същи 

компютър. COM+ 1.5 представя всеки COM+ компонент като уеб-услуга, доколкото 

компонента съответства на ръководните принципи за дизайн на уеб-услуги. (Activation 

tab на приложението позволява да се конфигурира SOAP активирането за дадено 

приложение [12]. Всичко което трябва да се направи е да се определи виртуална 

директория за уеб-услугата, асоциирана с това приложение. COM+ осигурява 

необходимите адаптери като компонентна услуга, инсталира уеб-услугата с IIS и 

създава подходяща конфигурация на уеб-услугата и информационни файлове. 

Необходимо е да има Internet Information Server (IIS) инсталиран за да се стартира 

активиращия режим на SOAP за дадено приложение. 


COM+ е от съществено значение за бързото разработване на компоненти и за 

мащабируеми приложения. COM+ позволява на разработчиците да фокусират 

вниманието върху настоящите бизнес проблеми, вместо да прилагат процеси 

пломбиращи услугите, като управление на жизнения цикъл на обекти и приложения, 

поддръжка на транзакции, успореден мениджмънт, сигурност, несинхронизирани 

извиквания, събития и разполагане. COM+ 1.5 изглажда тези неравности, които COM+ 

1.0 притежава, а неговите характеристики са добро допълнение към арсенала за 

разработки. Тъй като COM+ е основата за всички .NET компонентни услуги няма 

съмнение, че това няма да бъде последната нова версия на COM+ пусната на пазара и 

Майкрософт ще продължи да добавя нови характеристики и способности към COM+ за 

да подобри и увеличи неговата интеграция с .NET. 

В тази статия се разглеждат възможностите на новата версия на COM – версия 

1.5 (COM+ 1.5 Explorer, Running Processes, DCOM Config, Legacy Components ), които 

се грижат за стандартните процедури, като оставят повече време на разработчиците да 

се концентрират върху бизнес компонентите. 

COM+ е за пръв път въведен с Windows 2000. Моделът COM+ е съставка на новата 

версия на Windows - Windows Vista. Неговото познаване и разбиране е инвестиция в 

бъдещето. 

Обект на бъдещи изследвания и статии ще бъде тестване и описание на новите 

опции за управление на жизнения цикъл на приложението, наречени обединяване и 

рециклиране (Pooling & Recycling tab ); до каква степен е подобрено изолирането на 

транзакции в новата версия на COM+; сегментиране с цел управление на COM+ 

приложенията. 


1. Baker, Seán. 1997. Distributed Objects using Orbix. ISBN: 0-201-92475-7. Harlow: 

Addison-Wesley Longman. 

2. BEA WebLogic Server Enterprise JavaBeans 1.1: http://www.weblogic.com/docs51/, 

2000. 

3. Chung, P. Emerald. Huang, Yennun. Yajnik, Shalini. Liang, Deron. Shih, Joanne C. 

Wang, Chung-Yih. Wang, Yi-Min. DCOM and CORBA Side by Side, Step by Step, and 

Layer by Layer http://www.cs.wustl.edu/%7Eschmidt/submit/Paper.html, 2000. 

4. Enterprise JavaBeans 1.1 Specification. http://java.sun.com/products/ejb/, 2000. 


- 200 - 

5. Hoque, Reaz.1999. CORBA for Real Programmers. ISBN: 0-12-355590-6. San Diego, 

Calif.: Academic. 

6. I. Valovа, B. Zhechev, Providing XML Web services with Microsoft COM, 

UNITECH’06, November 2006, Gabrovo, Bulgaria, 2006. 

7. Microsoft Corporation, Product information, evaluation, and technical developer 

resources, www.microsoft.bg 

8. Sessions, Roger. 1998. COM and DCOM: Microsoft’s Vision for Distributed Objects. 

ISBN 0-471-19381-X. John Wiley & Sons, Inc. 

9. Siegel, Jon. 1996. CORBA Fundamentals and programming. ISBN: 0-471-12148-7. 

United States of America. John Wiley & Sons, Inc. 

10. VisiBroker for Java 4.1 http://www.inprise.com/ [2000, August 23]. 

11. W3C, Extensible Markup Language (XML) - http://www.w3.org/XML/ 

12. W3C, Latest SOAP versions - http://www.w3.org/TR/soap/ 

Institute of Computer and Communication Systems 


Acad. G. Bonchev str., bl. 2 

1113 Sofia 

Institute of Control and System Research 



1113 Sofia

- 201 - 




BULGARIA 

INTELLIGENT VIRTUAL AGENTS 

-A NEW COMPUTER’S INTERFACE 

DILYANA BUDAKOVA, LUYDMIL DAKOVSKI 

Abstract. In this paper the main directions for intelligent virtual agent’s (IVA) modeling 

and realization are discussed. Great attention is paid to this direction, a proof of which is 

the big amount of articles, program systems and tools for modeling. The aims are 

exploring aspects of intelligent behavior and improving computer-human interaction. 

Classification of the elaborations is made in this issue. Solutions of more basic problems 

are pointed out. The latest elaborations in this area develop models of learning characters 

and personalities; models of embodied conversational agents; IVA’s recognizing human 

behavior, human interpretation of IVA’s behavior; IVA’s recognition of emotion from 

speech, from a human-computer dialogue with an intelligent tutoring system or an 

improvisatory e-drama; IVA’s expressing nonverbal behavior; assisting conversational 

agents. In this paper the focus is placed on the consideration of IVA as a new computer’s 

interface. 

Key words: intelligent virtual agent, emotional conversational agents, modeling, 

affective computing, recognizing and expressing behavior. 

ИНТЕЛИГЕНТНИ ВИРТУАЛНИ АГЕНТИ 

- НОВ ИНТЕРФЕЙС С КОМПЮТЪРА 

1.Въведениe 

Не е далеч времето, когато взаимодействието компютър-човек до такава степен 

ще се доближи до взаимодействието човек-човек, че в интелектуално отношение 

разликите ще бъдат незначителни. Основание за това твърдение може да се намери в 

масираните изследвания и получените обнадеждаващи резултати при разработването 

на разнообразни интелигентни виртуални агенти. 

Интелигентните виртуални агенти (ИВА) са програмно реализирани автономни 

агенти, които притежават графично построено човешко лице (често и тяло) и 

съществуват в 2D или 3D виртуална среда. Те притежават възможности интелигентно 

да взаимодействат със заобикалящата ги среда, в това число както и с други ИВА, така 

и с потребителите на съответното приложение. 

ИВА са резултат от съвместните усилия на изследователи в различни области на 

компютърните науки[1]: компютърна графика, изкуствен интелект, компютърна 

анимация, компютърни игри, моделиране на виртуални среди, компютърна обработка 

на естествени езици, когнитивно моделиране, човеко-компютърни системи, изкуствен 

живот и др.. Изследванията в това направление съвсем естествено привличат знания и 


- 202 - 

специалисти по когнитивна и социална психология при моделирането на емоции и 

невербални комуникации, по социология при моделирането на общества от хора и 

ИВА, по анатомия при разработката на хармонията между тялото и жестовете на 

агентите, дизайнери и артисти при реализацията на средства за взаимодействие с ИВА, 

на педагози при развитието на механизми за обучение на агентите и т.н. 

ИВА вече могат да се срещнат в web-базирани интерфейси, като приложения за 

персонални компютри или други персонални устройства на интерактивната телевизия. 

ИВА са привлекателни действащи лица в игри и забавления. Но те имат и сериозни 

задачи например като инструменти за психологически изследвания. Постигнатото 

развитие на ИВА им отрежда още днес място както в изследователски така и в 

индустриални приложения. [1] 

В настоящата статия се обсъждат някои от основните направления в развитието 

на изследванията на ИВА и се дискутира бъдещото им развитие като компютърен 

интерфейс. 

2. Очаквания на потребителите. 

Един от първите въпроси при работата над ИВА е в каква степен е успешен този 

нов интерфейс, как потребителите го приемат и дали ползата от него оправдава 

усилията за неговото разработване. В [2] е предложен въпросник за оценяване на 

виртуални агенти в конкретна среда. Оценяват се степента на информираност на агента, 

дали той е забавен и как се възприема. Посочени са фактори, които трябва да се имат 

предвид при създаването на ИВА. 

Външният вид на графично визуализирания ИВА е от съществено значение за 

начина, по който той ще се възприемане от потребителите. Това категорично се 

потвърждава от проведените експерименти със студенти [3], които е трябвало да 

избират агента, с който предпочитат да общуват. При експериментите е променян 

външния вид на агентите. 

Разработената виртуалната среда FearNot (населена от ИВА виртуална класна 

стая) [4] дава възможности да се наблюдават и обобщят предпочитанията и 

очакванията относно дизайна и използването на ИВА сред групи от 8 - 12 годишни 

деца. Събрани са данни от 345 деца чрез използването похвата дискусионен форум на 

класната стая. 

Освен дизайна съществено за предпочитанията на потребителите е и 

възможността ИВА да се обучават в процеса на взаимодействието както помежду си, 

така и с хората. Появява се нов вид взаимодействие между човека и компютърните 

приложения – взаимно обучение. Тепърва предстои да се разработва и оценява този вид 

взаимодействие, който може да бъде развиван в различни направления: да се разбере 

как хората се опитват да обучават ИВА, да се създават ефективно обучаващи се агенти, 

да се изучава самия процес на обучение и т.н. В [5] са представени резултати от 

направени наблюдения и анализи по някои от тези въпроси и е показана базирана на 

подсилване структура за обучение на ИВА. В статията са посочени редица интересни 

факти, като например, че хората се опитват да обучават ИВА като управляват неговото 

внимание, като му посочват целите на играта, опитват се да формулират инструкции, да 

използват наказанието като обратна връзка, да предлагат следващо действие и т.н. и са 

изведени препоръки към проектирането на агенти, които се учат по-добре и стават позабавни 

в резултат от обучението. 

3. Нов тип диалог човек-компютър. 

ИВА, които поддържат разговор в позната им ограничена област, съществуват 

отдавна. Основният инструмент за избиране на подходящи отговори в тази област е

- 203 - 

класификацията. В [6] е разгледан проблема за работа с потребителски въпроси, които 

са извън областта на знанията на агента. Предложени са архитектури за класификация 

на типовете отговори, и от там за избор на най-подходящия отговор. Оценките 

показват, че качеството на избор на отговор значително се подобрява, с което диалогът 

с потребителя става по-естествен и по-ангажиращ. 

Общуването лице в лице има значимо въздействие върху участниците в диалога. 

Те реагират като подсъзнателно включват подражание в поведението си, като с това 

създават субективно усещане за разбиране, подсилват връзката и изграждат доверие 

помежду си. Така диалогът получава ново качество. Това е причината породила редица 

опити да се създадат системи за диалог между човек и виртуален агент [7], които си 

поставят за цел да се създаде наситен цикъл „действие-разбиране” и/или „говоренеумение 

да се слуша” въз основа на наблюдението на събеседника и подражанието. 

фиг. 1. Виртуалният агент пресъздава разказвана от събеседничката история с 

подходящи мимики, жестове и интонация.[7] 

Съществен момент за качеството на такъв диалог е възможността виртуалният 

агент да разпознава емоцията в произнесената реч, в изображението на лицето или 

позата на индивида. 

Един от подходите към разпознаване на подмножество от емоции в изречени 

думи е развит в [8]. Подходът се базира върху интонационен модел (прозодични и 

акустични характеристики) за всяка емоция от подмножеството и свързването на 

модела с речевите примери. По характеристиките са структурирани йерархична група 

класификатори. Изводите са, че лексическата информация и получените 

информационни образци от прозодичните и акустични оценки на ниво дума пораждат 

сигурна класификация и разпознаване на емоциите. 

В [9] е описана система, която чрез примери от директен диалог се обучава да 

разпознава емоцията в диалога. ИВА идентифицира емоционалното състояние на 

събеседника, като резултата се подкрепя или отхвърля от двама обучени арбитри. 

Направен е опит да се определят и оценят правилно различията между индивидуалните 

емоционални състояния в сравнение с основната линия на неутрално състояние на 

събеседника. Експериментите са показали, че по характеристиките на диалога могат с 

голяма точност да се предскажат емоционални състояния като разстройване, объркване, 

отекчение 

В [10] са описани любопитни изследвания върху начини за откриване на емоция 

във виртуална драматична импровизация. Интересни са изследванията върху начина, 

по който метафорите могат да пренасят емоции. Авторите посочват, че модулът за 

откриване на емоцията може да се използва при създаването автоматизиран виртуален 

актьор, който разказва истории. 

Ролята на контекста е изключително важна при всеки диалог. Когато хората 

разговарят помежду си, те разчитат на това, което е било казано или направено преди. 


- 204 - 

Някои невербални действия могат да са двусмислени когато се разглеждат сами по себе 

си, но тяхното значение е очевидно, когато се разглеждат в контекста на използването 

им. В [11] е описана реализацията на контекстен модел на ИВА, който е проектиран да 

възприема, запомня и реагира на невербалните събития, които съпровождат диалозите. 

Често емоциите се крият в речта, в израза на лицето, в жестовете, т.е. в различни 

модалности. В реалния живот те често са смесени, скрити зад пози или маскирани. За 

правилното идентифициране и изразяване на емоциите от ИВА е необходимо 

изучаването на смесените емоции във всички модалности. Този въпрос е дискутиран в 

[12], където е описан експеримент за разпознаване на маскирани емоции на 

събеседници в телевизионни интервюта и последващото им симулиране чрез ИВА. 

Разговарящите с потребителя графично визуализирани ИВА с реалистични лица 

стават съществена част от много програмни системи. Въпросът е как хората възприемат 

и разбират емоцията на говорещия агент. В [13] се оценява зрителното разбиране от 

хората на изразените от ИВА емоции. При експеримента лицето на ИВА или човек се 

представя цялостно както е заснето на видеоклип или чрез специално подбрани за да го 

описват точки. Направените анализи показват, че долната част на лицето осигурява 

достатъчно добър емоционален ключ за правилното визуално възприемане на емоцията 

и че емоциите могат да се обхванат напълно и когато лицето е представено чрез 

множество подбрани точки. Други експерименти относно този проблем са описани в 

[14,15,16]. 

Фиг. 2. ИВА Леа изпълнява на естествен език презентации и обяснява възможности 

на софтуерни компоненти или web услуги .[17] 

Редица изследователи се фокусират върху идеята за създаване на асистиращи 

диалогови агенти (Assisting Conversational Agent ACA) [17,18]. Това са графично 

визуализирани ИВА, които имат за задача да помагат на потребителите на софтуерни 

компоненти и/или web услуги. Виманието на изследователите е насочено към 

диалогичната функционалност на агентите, към динамичното символно представяне на 

компонентите за обясняване, проблемите на посредничеството, определянето на 

начините за реагиране на агента и поддържането на обратна връзка с потребителя. 


В статията са дискутирани някои от основните проблеми при моделирането и 

реализирането на интелигентни виртуални агенти (ИВА). В един кратък материал не е 

възможно да се обхванат всички аспекти и проблеми, с които е свързано използуването 

на ИВА. Акцентирано е на онези от тях, които превръщат ИВА в интерфейс на 

недалечното бъдеще между човек и компютър.

- 205 - 

Дискутирани са следните моменти: очакванията и предпочитанията на 

потребителите към ИВА, начините за оценяване на вече създаден ИВА, разширяване на 

възможностите ИВА да се учат при общуването си с хората. Разгледани са проблеми на 

общуването между ИВА и човек: намирането на подходящ отговор, който е извън 

областта на знание на ИВА; включването на подражание при общуването, което 

изисква по-богат цикъл “действие-разбиране”; създаването на интонационни модели за 

разпознаване на емоцията в произнесени думи; създаването на архитектура за 

разпознаване на промяната в емоцията в хода на разговор; създаването на модул за 

разпознаване на емоцията в импровизация; възможността да се реализира контекстен 

модел на ИВА, с което се подчертава ролята на контекста за правилното разбиране на 

невербалното изразяване; проблемът за разпознаване и изразяване на емоцията по 

израза на лицето; разпознаването и изразяването на смесени емоции скрити в жестовете 

и израза на лицето. 


1. J. Gratch, IVA’2006, http://iva2006.ict.usc.edu/ 

2. Michael Kipp1, Kerstin H. Kipp2, Alassane Ndiaye1, and Patrick Gebhard1, 

Evaluating the Tangible Interface and Virtual Characters in the Interactive COHIBIT 

Exhibit, IVA 2006, LNAI 4133, pp. 434–444, 2006. 

3. Van Vugt, H.C., Konijn, E.A., Hoorn, J.F., and Veldhuis, J., Why fat interface 

characters are better e-health advisors., In: Gratch, J. et al (Eds.), IVA 2006, LNAI 4133, pp 

1-13, 2006. [pdf] 

4. L. Hall, M. Vala5, M. Hall, M. Webster, S. Woods, A. Gordon and R. Aylett, FearNot’s 

Appearance: Reflecting Children’s Expectations and Perspectives, IVA 2006, LNAI, 2006. 

5. Andrea Thomaz, Cynthia Breazeal, Teachable Characters: User Studies, Design 

Principles, and Learning Performance, IVA 2006, LNAI 4133, 2006. 

6. Ronakkumar Patel, Anton Leuski, David Traum, Dealing with Out of Domain 

Questions in Virtual Characters, IVA 2006, LNAI 4133, 2006. 

7. J. Gratch, A. Okhmatovskaia, F. Lamothe, S. Marsella, M. Morales, R. van der Werf, 

L. Morency. Virtual Rapport, IVA’2006, Marina Del Rey, CA, USA, August 21-23, 2006. 

8. M. Hoque, M. Yeasin, M. Louwerse. Robust Recognition of Emotion from Speech, IVA 

2006, Marina Del Rey, CA, USA, August 21-23, 2006. 

9. S. D'Mello, A. Graesser, Affect Detection from Human-Computer Dialogue with an 

Intelligent Tutoring System, IVA 2006, Marina Del Rey, CA, USA, August 21-23, 2006. 

10. L. Zhang, J. A. Barnden, R. J. Hendley, A. M. Wallington, Exploitation in Affect 

Detection in Improvisational E-drama, IVA 2006, Marina Del Rey, CA, USA, August, 2006. 

11. N. Pfleger, M. Loeckelt, A Comprehensive Context Model for Multi-party Interactions 

with Virtual Characters, IVA 2006, Marina Del Rey, CA, USA, August 21-23, 2006. 

12. S. Buisine, S. Abrilian, R. Niewiadomski, J.C. Martin, L. Devillers, C. Pelachaud, 

Perception of Blended Emotions: from Video Corpus to Expressive Agent, IVA 2006, 

Marina Del Rey, CA, USA, August 21-23, 2006. 

13. D. Zhigang, J. Bailenson, J.P. Lewis, U. Neumann, Perceiving Visual Emotions With 

Speech, IVA 2006, Marina Del Rey, CA, USA, August 21-23, 2006. 

14. Costantini, E., Pianesi, F., and Cosi, P, Evaluation of Synthetic Faces: Human 

Recognition of Emotional Facial Displays, Affective Dialogue Systems, Dybkiaer, L. 

Minker, W. and Heisterkamp, P. (eds.), 2004. 


- 206 - 

15. Costantini, E., Pianesi, F., Prete, M: Recognising emotions in human and synthetic 

faces: the role of the upper and lower parts of the face, Proc. of IUI’05, ACM Press (2005), 

20-27. 2005. 

16. Deng, Z., Bulut, M., Neumann, U., and Narayanan, S: Automatic Dynamic Expression 

Synthesis for Speech Animation, Proc. of IEEE Computer Animation and Social Agents 

2004, July 2004, pp. 267-274. 

17. J.P. Sansonnet, D. Leray, J.C. Martin, Architecture of a Framework for Generic 

Assisting Conversational Agents , IVA 2006, Marina Del Rey, CA, USA, August, 2006. 

18. http://www.limsi.fr/individu/jps/interviews 




4000 Plovdiv 

BULGARIA 

E-mail: dilyana_budakova@yahoo.com 

Center of Biomedical Engineering 

Bulgarian Academy of Science 

105 bl., acad. G. Bonchev Str. 

1113 Sofia, 

BULGARIA 

E-mail: seven_in@cablebg.net

- 207 - 




BULGARIA 

WEB 2.0 TECHNOLOGIES IMPACT ON ACTIVE LEARNING 

IN ENGINEERING EDUCATION 

MALINKA IVANOVA 

Abstract. Active learning strategies are effective in engaging learners and assisting them 

in creating their own learning experiences. These strategies can help educators develop 

new learning activities to engage learners in the online environment. Web 2.0 proposes 

technologies that let learners and educators collaborate and share information online in a 

new way - such as social networking sites, wikis, communication tools. Recent research 

reveals great interest to introduce Web 2.0 technologies and how they can be used in the 

engineering education. In this paper the main active learning strategies are discussed 

from the view point of their adaptation for using in online learning environment. The role 

of these strategies is analyzed and their influence on learner activation and motivation is 

presented. The Web 2.0 technologies are summarized and their impact on engineering 

education is shown. 

Key words: Web 2.0 technologies, active learning strategies, engineering education. 

1. Introduction 

For much of the last century, engineering education consisted primarily of a deductive 

top-down approach to learning that emphasizes the acquisition of knowledge. This philosophy 

often drives learners away from engineering. Active learning seeks to give learners increased 

responsibility for the learning process, to increase learner engagement and to provide them 

with the competencies they will need in their professional career. 

The 21st century needs a new kind of engineer. Not one who finds increasingly elaborate 

technical solutions, but creative problem solvers, who with social and environmental 

involvement are able to anticipate and adapt to the needs of industry. The main goal should 

not only to give the learners of knowledge, but to develop their competencies. According to 

the active learning model learners will discover new phenomena and concepts on their own, 

link them to previous knowledge, reflect and generalise to acquire conceptual understanding 

[1], [2]. Active learning redefines classroom practice from a static view of learning to a more 

dynamic view through project-based, collaborative, problem-based activities. Learners play a 

more vital role in creating new knowledge to be applied to other professional and academic 

contexts. Technology can play an important role in ensuring that learning is the result of 

dialogue and production of new knowledge and experience in new media for audiences 

beyond the classroom, making both course content and learner work more relevant. 

The Web 2.0 proposes new services and software and it transforms from a predominantly 

“read only” medium to one where anyone can publish and share content and easily collaborate 

with others. The Web 2.0 is already having an impact in class, as educators start exploring the 

potential of blogs, media-sharing services, and other social software, which, although not 


- 208 - 

designed specifically for e-learning, can be used to empower learners and create exciting new 

learning opportunities. These same tools allow educators to share and discuss innovations 

more easily and, in turn, spread good practice [3]-[9]. 

Recent research reveals great interest to introduce Web 2.0 technologies and how they 

can be used in engineering education. In this paper the main active learning strategies are 

discussed from the view point of their adaptation for using in online learning environment. 

The role of these strategies is analyzed and their influence on learner activation and 

motivation is presented. The Web 2.0 technologies are summarized and their impact on 

engineering education is shown. 

2. Active Learning Strategies 

Of the many active learning strategies available for use in the online learning 

environment, most have not been developed specifically for online instruction, but are 

currently used in traditional classrooms, and can be successfully adapted for facilitating 

online learning. Educators should choose instructional strategies that are most effective for 

accomplishing a particular educational objective. Below are some active learning strategies 

which have been effectively used in the traditional classroom and can likewise be used in the 

online learning environment: 

� Learning contracts. A learning contract is a formal agreement written by a learner 

which details what will be learned, how the learning will be accomplished, the period of time 

involved, and the specific evaluation criteria to be used in judging the completion of the 

learning. Learning contracts help the educator and learner share the responsibility for 

learning. Learning contracts can be extremely effective active strategy, because the learners 

are involved to discuss learning objectives and expectations. Sample learning contracts can be 

placed on a web page for the student to use as examples, and students can be encouraged to 

brainstorm ideas for learning contracts with their online peers as well as negotiate the final 

contract with the educator through utilizing email or online conferencing. 

� Lecture. The lecture is one of the most frequently used instructional methods in 

engineering education. Most educators agree that the purpose of lectures is to lay foundations 

as the student works through the subject, and good lecturers know their students and develop 

their lectures according to the students' needs. Lectures are most effective and activate when 

they are used in combination with other instructional strategies. Online lectures can be 

presented in a variety of ways: via notes, audio or video over the Internet. 

� Discussions. Discussion is the active learning strategy most favored by learners 

because it is interactive and encourages active, participatory learning. The discussion format 

encourages learners to analyze alternative ways of thinking and acting and assists learners in 

exploring their own experiences so they can become better critical thinkers. The Internet 

offers several modes for discussion including mailing lists, chat, forum, panel symposium and 

online conferencing programs. 

� Self-directed learning. Self-directed learning is learning initiated and directed by the 

learner and can include self-paced, independent, and individualized learning as well as selfinstruction. 

Self-directed learning places the responsibility for learning directly on the learner. 

Learners who take the initiative in learning and are proactive learners learn more and better 

than passive learners (reactive learners). Proactive learners enter into learning more 

purposefully and with greater motivation. The independent learner is one who is more 

involved and active within the learning process. Online learning supports the self-directed 

learner in pursuing individualized, self-paced learning activities. The learner, working at a 

computer at a convenient time and pace, is able to search and utilize the vast resources of the 

Internet research nearly any topic imaginable. Students can visit libraries and various 

institutes world-wide, talk to professionals, access recent research, and read newspapers and

- 209 - 

peer reviewed scholarly journals online. Students can write collaboratively with peers and 

even publish written and multimedia products on web pages. 

� Mentorship. The aim of mentorship is to promote learner development drawing out 

and giving form to what the student already knows. A mentor serves as a guide rather than a 

provider of knowledge and serves the function of introducing students to the new world, 

interpreting it for them, and helping them to learn what they need to know to function in it. A 

major benefit to online mentorship is the opportunity for frequent, convenient communication 

between mentor and student. Weekly or even daily journals and communications can be sent 

between mentor and student via e-mail, providing an ongoing “dialogue” which supports the 

development of the mentor relationship and offers numerous opportunities for timely 

feedback on student questions, concerns and issues. 

� Group-based learning. In small groups learners can discuss content, share ideas, and 

solve problems. They present their own ideas as well as consider ideas put forth by others. In 

this way, they can be exposed to a variety of viewpoints on a given subject. There are many 

small group formats that encourage and provide opportunities for interaction: The discussion 

group allows learners to reflect on a subject under discussion and present their view; Guided 

design focus is on developing learners’ decision-making skills as well as on teaching specific 

concepts and principles; Role playing involves recreating a situation relating to a real-world 

problem in which participants act out various roles. 

� Project-based learning. Online projects give students an opportunity to pursue their 

special interests and can be done individually or within groups. Projects also provide students 

with practical experience and a sense of accomplishment. Using projects in a learning activity 

makes the learning more relevant to the learners. Products can be shared with others in the 

class and critiqued. Group projects can include simulations, role playing, case studies, 

problem solving exercises, group collaborative work, debates, small group discussion, and 

brainstorming. 

� Collaborative learning. Collaborative learning is the process of getting two or more 

students to work together to learn. Students often work in small groups composed of 

participants with differing ability levels and using a variety of learning activities to master 

material initially developed by an instructor, or construct knowledge on substantive issues. 

Each member of the team is responsible for learning what is taught and for helping teammates 

learn. In the online environment collaborative work can be implemented by using social 

software or can be created social networks. 

� Case studies, Readings. The case study is a teaching strategy which requires learners 

to draw upon their past experiences, is participatory and has action components which are 

links to future experience. The key to a successful case study is the selection of an appropriate 

problem situation which is relevant both to the interests and experience level of learners and 

to the concepts being taught. The case report should include facts regarding the problem, the 

environmental context, and the characters of the people involved in the case. It should be 

factual, but also contain the opinions and views of the people involved. Learners should have 

access to the problem solution, but not until they have reached their own conclusions and can 

then compare their results with the actual decision taken to resolve the problem. In the online 

environment case studies can be presented on web pages and discussed in conferencing 

groups. Cases can be developed by class groups as collaborative projects. In addition, the vast 

resources of the Internet can be tapped by students and educators to contribute data, 

information and expert advice to case development and analysis. 

� Simulation-based learning. It is in which a person is placed into a scenario or situation 

and is directly responsible for the changes that occur as a result of their decisions. Recent 

developments in software, the Internet and virtual reality have created richer, more life-like 

learning experiences. Simulation in this context is a set of techniques and technologies to 


- 210 - 

create guided, interactive, and often “immersive” activities that recreate experiences of a realworld 

environment. These are used to amplify or replace actual experiences. 

� Experiential Learning. On the one hand the term is used to describe the sort of 

learning undertaken by students who are given a chance to acquire and apply knowledge, 

skills and feelings in an immediate and relevant setting. Experiential learning thus involves a 

direct encounter with the phenomena being studied rather than merely thinking about the 

encounter, or only considering the possibility of doing something about it. The second type of 

experiential learning is education that occurs as a direct participation in the events of life. 

3. Web 2.0 Technologies 

Web 2.0 includes web-based technologies that allows a “read/write” approach to the 

web and enables the learner to be both a consumer and producer of content and services. 

Learners are actively involved in a learning process as co-learners and co-authors in this type 

of environment. It enhances the opportunities for learners to collaborate and generate new 

knowledge or build expert domains by a community of practice. In engineering education can 

be used the following Web 2.0 technologies: 

� Blogging. A weblog or blog is a web-based publication consisting primarily of 

periodic articles. Blogging is increasingly finding a home in education, as not only does the 

software remove the technical barriers to writing and publishing online - but the “journal” 

format encourages students to keep a record of their thinking over time. Blogs also of course 

facilitate critical feedback, by letting readers add comments - which could be from educators, 

peers or a wider audience. 

� Video blogging. By combining use of two popular web services, Blogger 

(blogger.com) and YouTube (youtube.com), students can make research and produce video 

blog entry on a new media technology of their choice - anything from the social networking 

website MySpace to MP3 players like the iPod. 

� Podcasting. Podcasting is a means of distributing audio and video programs via the 

Internet that lets learners subscribe to a number of files, also known as “feeds”, and then hear 

or view the material at the time that they choose. A feed is usually in the MP3 audio format. 

Podcasting has become a popular technology in education, in part because it provides a way 

of pushing educational content to learners. Also student-produced podcasts are where it's at 

when it comes to educational podcasting. As with blogging, podcasting provides students with 

a sense of audience - and they are highly motivated to podcast. 

� Wikis. Educators are using many of these same tools to share their innovative uses of 

Web 2.0 applications and services, and to collaborate with colleagues and students. By using 

wiki software the site lets anyone add their details to the directory or update a previous entry. 

� Media sharing (Discussing/annotating images) . The photo-sharing site Flickr is also 

finding use within education - as it provides a valuable resource for students and educators 

looking for images for use in presentations, learning materials or coursework. Many of the 

images uploaded to Flickr carry a Creative Commons license, making them particular suitable 

for educational use - and the tagging of images makes it much easier to find relevant content. 

Students can also use Flickr to publish and discuss their digital photography and find images 

relevant to a particular subject for use in their coursework. And like blogging, the 

commenting function on Flickr allows for critical feedback. 

It also has a lesser-known feature that has many potential uses for teaching and learning: the 

ability to add annotations to an image. 

� Mashups. Combine nigh-value software and services from multiple sources into single 

new web-based applications. A mashup is a website or web application that seamlessly 

combines content from more than one source into an integrated experience and this is useful 

method to support educators and learners in collect and aggregate knowledge.

- 211 - 

Content used in mashups is typically sourced from a third party via a public interface or API. 

Other methods of sourcing content for mashups include Web feeds (e.g. RSS or Atom) and 

JavaScript includes. 

� Folksonomy. It is a neologism for a practice of collaborative categorization using 

freely chosen keywords. More colloquially, this refers to a group of people cooperating 

spontaneously to organize information into categories, typically using categories or tags on 

pages, or semantic links with types that evolve without much central control. The use of 

formally typed links is however rare. Folksonomy is rarely supported directly by text 

navigation facilities, web browsers, or other tools requiring types. 

� Social Networks. A social network is a social structure between actors, mostly 

individuals or organizations. It indicates the ways in which they are connected through 

various social familiarities ranging from casual acquaintance to close familial bonds. The 

educational potential of social software and services is huge. A social networking website is 

defined as any web service that: allows users to create web pages or profiles that provide 

information about themselves and are available to other users; and offers a mechanism for 

communication with other users, such as a forum, chat room, email, or instant messenger. 

4. Using Web 2.0 Technologies in Engineering Education 

The online learning environment allows educators and students to actively exchange 

ideas and information, work together on projects, from anywhere in the world, using multiple 

communication modes. Given the advantages and resources of this rich learning environment, 

how can multiple instructional strategies best be utilized for online learning through Web 2.0 

technologies? There is no simple, straightforward answer to this question, depending on 

specific situation, one solution will work best of given students. On Figure 1 is presented one 

model for using the Web 2.0 technologies in engineering education. 

Wiki 

Learni 

ng 

Bloggin 

Group 

-based 

learni 

Podcastin 

Selfdirected 

learnin 

Media 

Sharin 

Lectur Discussio Mentorshi 

Googl 

e 

Simulatio 

n-based 

learning 

Case 

Mashu Folksono 

Project 

-based 

learnin 

Active Learning 

Strategies 

Collaborati 

ve learning 

Experienti 

al 

Web 2.0 

Technologies 

Social 

Networ 

Fig. 1. Web 2.0 Technologies in and Active Learning Strategies in Engineering Education 


- 212 - 

5. Discussion and Future Work 

Active learning: increases motivation, students become involved in their own learning 

process and develop learning strategies, students become more creative, reactive and 

proactive, the effectiveness of contacts between students and teachers is improved, students 

learn to work autonomously and cooperative in teams. Web 2.0 technologies encourage 

implementation of active learning strategies and these technologies have great potential to 

change learning, communication and publishing practices in engineering education. With 

these extended technology opportunities come new challenges for educators. 

The investigations and analysis in this paper will support the future work which aim is 

to design and implement the online learning environment web 2.0 technology-based with 

models of active learning strategies. 

REFERENCES 

1. D. Brodeur, S.Hall, I. Waitz, E. Crawley, D. Newman. Active Learning, American 

Society of Engineering Education, National Conference, Albuquerque, June, 2001. 

2. J. Millis. Managing-and motivating-distance learning group activities, 

http://www.tltgroup.org/gilbert/millis.htm , 2000 

3. P. Graham. Web 2.0, http://www.paulgraham.com/web20.html, 2005. 

4. D. Hinchcliffe. The State of Web 2.0, Web Services Journal, 2006. 

A. Leene. The MicroWeb: Using MicroContent in theory and practice. MicroLearning 

5. conference, Innsbruck, Austria, 2006. 

6. M. Ivanova, E. Vasilyeva. Web 2.0: Conceptual Modeling of Application Design 

Strategy, International Scientific Conference Computer Science’2006, Istanbul, Turkey. 

7. L. Grant. Using Wikis in Schools: A Case Study, 2006, 

http://www.futurelab.org.uk/download/pdfs/research/disc_papers/Wikis_in_Schools.pdf 

8. M. Prensky. Delivering 21st Century tools, learning and skills education, Australian 

National Seminar, March 2006 

9. S. Downes. E-learning 2.0, eLearn Magazine, http://www.elearnmag.com, 2006. 

10. J. Banico. Web 2.0 Concepts and Technologies, http://www.rssrsssrsss.com, 2006. 

11. M. Kerres. Web 2.0 and its implication for eLearning, MicroLearning conference, 

Innsbruck, Austria, 2006. 

12. A.Bruckman. The future of e-learning communities. Communications of the ACM, 

45(4), pp. 60-63. 2002 

13. R. Hiltz, M. Turoff. What makes learning networks effective? Communications of the 

ACM, (45)4, pp. 56-59, 2002 

14. R. Felder, R. Brent. FAQs-3. Groupwork in Distance Learning. Chem. Eng. Education, 

35(2), 102-103 (Spring 2001). 

Technical University–Sofia, 

8, Kl. Ohridski Blv. 

1000 Sofia 

BULGARIA 

E-mail: m_ivanova@tu-sofia.bg

- 213 - 




BULGARIA 

СПЕЦИАЛНО ДООПРЕДЕЛЯНЕ НА ЛОГИЧЕСКИ 

ФУНКЦИИ: ОПТИМИЗАЦИОННА ПРОЦЕДУРА "БАЛАР" 

В ПОСЛЕДОВАТЕЛНОСТНИЯ СИНТЕЗ 

СПИРИДОН АРНАУДОВ 

В теорията и практиката на логическото проектиране едва ли има нещо, подобре 

разработено и по-широко известно от формалните описания на основните 

типове елементарни автомати - тригери тип О, Т, RS, JK, и използването им в 

конвенционалните процедури за синтез и анализ на синхронни последователностни 

схеми /ПС/. В продължение на повече от 30 години [5-18] теоретичната база и 

приложните аспекти на този въпрос са останали, според нас, удивително инвариантни. 

Това естествено е довело до устойчивата професионална представа, че всичко по тази 

тема е вече напълно 

и окончателно решено. 

Азбучни истини от теорията на крайните автомати са преобразуването на един 

тип тригер в друг и възможността произволна ПС да бъде синтезирана и реализирана 

само чрез един /който и да е / от четирите основни типа тригери. Естествено е да се 

постави въпросът: а защо тогава изобщо са необходими останалите три /които и да са / 

типа тригери ? Иначе казано, защо и до сега в теорията и практиката на 

последователностния синтез и при реализацията на ПС се използват почти равностойно 

и четирите типа тригери? Единственият разумен, по наше мнение, отговор може да 

бъде: от десетилетия се е утвърдила професионалната представа, че в някои ПС 

определен тип тригер обуславя съществени предимства - удобство при проектирането и 

простота при реализацията. Съществуват достатъчно основания да се приеме, че това 

твърдение е безусловно валидно за ПС от типа регистри /тригери RS, О/ и броячи 

/тригери JK, Т/ . Но за един достатъчно широк кръг от произволни ПС, например 

управляващи автомати, паритетът на четирите типа тригери, и по-специално на 

двувходовите спрямо едновходовите тригери, е дискусионен и може да бъде обект на 

специално оптимизационно изследване. 

СПЕЦИАЛНО ДООПРЕДЕЛЯНЕ НА ВЬЗБУДИТЕЛНИТЕ ФУНКЦИИ НА 

ДВУВХОДОВИТЕ ТРИГЕРИ 

Специалното доопределяне на непълно определени логически функции /лФ/ 

като една нова методология и алгоритмична технология в комбинационния синтез 

[4,3,2,1] може с успех да се приложи върху възбудителните функции на тригерите при 


- 214 - 

синтез на ПС. Между различните варианти за специално доопределяне приоритетно 

значение имат случаите, в които се установява двукратна импликативна релация 

еквивалентност /равенство или противоравенство/, защото при тях се намалява самият 

брой на подлежащите 

на реализация ЛФ. 

Този критерий за ранжиране е безусловно валиден при реализация на всяка ПС в 

произволна матрична среда - програмируеми логически матрици /ПЛМ/ и постоянни 

памети /ПП/ във всички техни разновидности, и е достатъчно значим за всяка друга 

среда на микроархитектурно ниво, например първична логика /AND, ОА, NAND, 

NOR, ХОR и др./. 

Специалното доопределяне има съществено значение за възбудителните функции 

на двувходовите тригери, които съдържат дефинитивна неопределеност, вследствие 

наличието на дублирани преходи. За целта след обичайното съставяне на кодираната 

таблица на преходите на синтезираната ПС може да се изпълни драйверна процедура за 

специално доопределяне на възбудителните функции на входовете R и S, К и J, след 

което се преминава към конвенционалната процедура за минимизация на тези функции. 

Този подход може да се третира само като технологичен, защото се прилага за търсене 

на ефективно частно решение във всеки отделен случай на синтез на конкретна ПС. 

Проблемът за специалното доопределяне на възбудителните функции на 

двувходовите тригери може да бъде разглеждан и в общ методологичен аспект и да 

бъде решен генерално за всяка ПС с произволно автоматно поведение. За тази цел бе 

извършено съответно аналитично изследване, с което бе установено еднозначно и 

общовалидно, че в произволна ПС специалното доопределяне позволява всеки 

двувходов тригер винаги и безусловно да се управлява само с една единствена 

възбудителна функция. 

Пълното аналитично изследване на този проблем може да бъде обект на 

интерес само за твърде ограничен кръг от елитни специалисти в съответната област. 

Затова то ще бъде докладвано на ежегодната международна научна конференция 

Systems for Automation of Engineering and Research и публикувано в сборника трудове 

Proceedings of SAER'99. В настоящата статия ще приведем само основните 

постановки и резултати от това изследване с оглед на тяхното място и значение в 

общата методология на последователностния синтез. 

Същността на изследвания проблем е формулирана в следното основно 

твърдение: 

ТЕОРЕМА БАЛАР. В произволна последователност на схема /краен автомат/, 

синтезирана с двувходови тригери /RS, JK/, всеки от тях винаги и безусловно може да 

се управлява само с една единствена възбудителна функция. 

В доказателството на теоремата се използват аналитични дефинитивни 

форми на възбудителните функции на двувходовите тригери, които до сега не са 

познати. Следствията от доказаната теорема могат да се представят в 

обобщен вид: 

Следствие 1. Специалното доопределяне на възбудителните функции на 

двувходовите тригери при синтез на произволна ПС редуцира винаги и безусловно 

тригера тип RS в тригер тип D, а тригера тип JK - в тригер типD или Т. 

Следствие 2. Общоизвестните елементарни трансформации на тригер тип RS 

в тип D и тригер тип JK в тип D или тип Т, които се използват самостоятелно и 

независимо от процедурата за синтез на конкретна ПС, се явяват частни случаи на 

доказаната теорема. 

Редукциите съгласно следствие 1 очевидно намаляват двукратно броя на 

необходимите възбудителни функции за управление на двувходовите тригери. При

- 215 - 

реализация на ПС в произволни матрични структури /ПП, ПЛМ/ това води безусловно 

до двукратно съкращаване на броя на управляващите линии към логическите входове 

на тригерите, т. е. на изходната размерност /разредност/ на комбинационния блок и на 

съответната част от информационната площ на матричната среда. Ако 

комбинационната логика на ПС се реализира в първична елементна база, заместването 

на двете възбудителни функции с една единствена води по принцип до изменение в 

сложността, оценена като брой прости импликанти. Известно е, че не съществуват 

точни априорни оценки за сложността на минималните форми на ЛФ. Поради това в 

нашето изследване е изказана и частично обоснована хипотезата, че сложността на 

единствената редуцирана възбудителна функция /D или Т/ ще бъде съизмерима със 

сумарната сложност на двете отделни възбудителни функции R и S, респ. K и J. 

Считаме, че резултатите от нашето изследване може да се разглеждат като 

определен принос в теорията на последователностния синтез и да се използват като 

практически подход за оптимална реализация на произволен краен автомат чрез 

специално доопределяне на възбудителните функции на елементарните автомати с 

два логически входа. Като наименование на доказаната теорема и на съответната 

алгоритмична процедура предлагаме означението БАЛАР /Базов АЛгоритъм за 

Автоматни Редукции/ , респ. BALAR (Basic ALgorithm for Automata Reductions). 

ПРОЦЕДУРАТА БАЛАР В МЕТОДОЛОГИЯТА НА 

ПОСЛЕДОВАТЕЛНОСТНИЯ СИНТЕЗ 

Ще се опитаме да представим в илюстративен вид нашето виждане относно 

мястото и влиянието на описаните изследвания спрямо методологията и технологията 

на последователностния синтез. 

По наше мнение съществува интересна и нетривиална аналогия между ролята 

и значението на теоремата БАЛАР в последователностния синтез и ролята и 

значението на теоремата на Де Морган в комбинационния синтез. 

Фиг. 1 - комбинационният синтез. Общоизвестната фундаментална теорема 

на Де Морган има поне две съществени приложения в комбинационния синтез: 

От една страна тя дефинира елементарните трансформации на един тип 

логически елемент в друг - И ⇔ ИЛИ-НЕ, ИЛИ⇔ И-НЕ. 

От друга страна, приложена заедно със закона за двойното отрицание в 

конвенционалната процедура за комбинационен синтез, тя преобразува 

дизюнктивните, респ. конюнктивните нормални форми в И - НЕ, респ. ИЛИ - НЕ 

форми, т. е. заменя елемент ната база И, ИЛИ, НЕ със среда И - НЕ, респ. ИЛИ -НЕ. В 

резултат от това базата И, ИЛИ, НЕ се елиминира като ефективна алтернатива за 

реализация на КЛС и остава само като спомагателен инструмент в логическото 

проектиране и изследване на КЛС. 

Фиг. 2 и 3 - конвенционалният последователностен синтез. Азбучно 

известните елементарни трансформации на един тип тригер в друг се извършват 

отделно и напълно независимо от конвенционалната процедура за 

последователностен синтез. В хода на тази процедура предварително избраният тип 

тригери по никакъв начин не може да бъде променен. В резултат на това за 

синтезираната ПС се получават специфични схемни реализации за всеки от основните 

типове тригери със значително различни оценки. 

Фиг. 4 и 5 - процедурата БАЛАР в последователностния синтез. Ако 

проектантът реши, изхождайки от някакви /независимо какви/ мотиви да синтезира 

произволна ПС чрез двувходови тригери /RS или JK/ и приложи оптимизационната 


- 216 - 

процедура БАЛАР за специално доопределяне на техните възбудителни функции, той 

винаги, безусловно и напълно независимо от своите желания или предпочитания, ще 

стига до едно и също решение - тригерите с два логически входа да се управляват 

само с по една логическа функция. В резултат от това за синтезираната ПС ще се 

получават винаги схемни реализации само за двата типа едновходови тригери, което 

гарантира оптимална реализация в матрична среда. 

Фиг. 6 - перспективите в послепователностния синтез. Съгласно 

доказаната теорема БАЛАР двувходовите тригери в произволна ПС винаги и 

безусловно може да се редуцират в едновходови. Нашето виждане е, че вследствие на 

това двувходовите тригери отпадат като ефективна алтернатива в процедурата за 

последователностен синтез и в този контекст стават ненужни. Считаме, че такъв 

подход напълно удовлетворява реалностите и обозримите перспективи в 

компютърната схемотехника и микроархитектура и в значителна част от цифровата 

електроника, където безспорно преобладават програмируемите логически среди от 

матричен тип. В тези условия последователностният синтез с едновходови тригери е 

единствената оптимална алтернатива. 

Щe подчертаем специално обаче, че двувходовите тригери запазват напълно 

своята значимост и приложимост в следните случаи: 

- като схемотехническа база /суровина/ за реализация на едновходовите тригери 

във всяка / в това число и матрична/ елементна среда; 

- като база за синтез и оптимална реализация на определени типове ПС /регистри, 

броячи/; 

- като равностойна и евентуално оптимална алтернатива за синтез на произволна 

ПС, но само в достатъчно редките и, по наше мнение, екзотични случаи на реализация в 

произволна първична елемент на среда. 

ЗАКЛЮЧЕНИЕ 

В статията е дефиниран проблемът за специално доопределяне на 

възбудителните функции на тригерите с два логически входа като оптимизационна 

възможност в синтеза на произволна последователност на схема. Приведени са 

основните постановки и резултати от извършеното аналитично изследване, в което е 

доказано, че във всяка последователност на схема /краен автомат/ с произволна 

функция на преходите всеки тригер с два логически входа /RS, JK/ може винаги и 

безусловно да се управлява само с една единствена възбудителна функция. В 

регулярни програмируеми логически среди от матричен тип / постоянни памети, PLA, 

РАИ това води до оптимална реализация вследствие двукратното намаляване на броя 

на функционалните линии, които управляват логическите входове на тригерите. 

Илюстрирано е виждането на авторите за ролята и мястото на доказаната 

теорема БАЛАР и на едноименната оптимизационна процедура в теорията и 

практиката на съвременния последователен синтез. 


1. Balkanjiev L., Arnaudov S., Partial relation and consistency in the special post 

determination of logical functions, Proceedings of the 11 th International Conference if 

System for Automation of Engineering and Research (SAER’97), 54-58.

- 217 - 

Balkandjiev L., Arnaudov S., Secial postdetermination of logical functions: 

Algorithmic procedure using integer numeric tabIes, Proceedings of the 12th International 

conference of System for Automation of Engineering and Research (SAER’98), 97-101. 

2. Балканджиев Л., Арнаудов С., Дескрипторните функции като аналитичен 

инструмент в специалното доопределяне, Автоматика и информатика, 1997, бр.5- 

6, 44-49 

3. Балканджиев Л., Арнаудов С., Специално доопределяне на логически функции, 

Автоматика и информатика, 1997, бр. 5-6,44-49. 

4. Даковски Л., Анализ и синтез на лигически схеми, София, Сиела, 1998. 

5. Working with programmable logic, Electronics World + Wireless world, Jan.1994, 49- 

56. Dec. 1993, 1017-1023, Nov. 1993, 905-911. 

6. Савелъев П., Коняхин В., Функционалъно логическое проектирование БИС, 

Москва, Высшая школа, 1990. 

7. Лазарев В., Пийлъ Е., Синтез управляющих автоматов, изд ІІІ, Москва, Энергия, 

1989. 

8. Киносита К., Асада К., Карацу О., Логическое проектирование СБИС, Москва, 

Мир 1985. 

9. Мурога С., Системное Проектирование СБИС, Москва, Мир, 1985. 

10. Баранов С., Синеев В., Автоматы и программируемые матрицы, Минск, 

Вышэйшая школа, 1980. 

11. Фридман А., Менон П., Теория и проектирование преключателъных схем, 

Москва, Мир, 1978. 

12. Гаврилов М., Девятков В., Пурпырев Е., Логическое проектирование 

дискретных автоматов, Москва, Наука, 1977 

13. Кисъов В., Теория на крайните автомати, София, Техника, 1976. 

14. Вавилов Е., Портной Г., Синтез схем элекронных цифровых машин, Москва, 

Сов. Радио, 1964. 

15. Гилл А., Введение в теорию конечных автоматов, Москва, Наука, 1966. 

16. Глушков В., Синтез цифровых автоматов, Москва, 1962. 

17. Phister M., Logical design of digital computers, New York, Tohn Willy & sons, 1958; 

на руски език – Киев, Техника, 1964. 


- 218 -

- 219 - 




BULGARIA 

STUDYING THE APPLICATION OF CAD SYSTEMS 

DOBRINKA PETKOVA, PETAR NENCHEV, KRASIMIR KRASTEV, 

VESELINA VASILEVA, PENKA NEDELCHEVA 

Abstract: The different approaches in making drawings of parts are conditioned by three 

main factors: complexity of parts; level of knowing of CAD-system and technical 

capacity of the means for their realization. 

The present work analyzes the results by methods of studying the realization of one 

object (drawing) by using the system AutoCAD. The Analysis is based on DHF file. It 

collects information determining the rationality of making of a drawing, which is 

compared with a “model”. A specific factor of rationality for every drawing has been 

determined. The results received enable to evaluate the level of rationality, as well as the 

effectiveness of AutoCAD application. 

Key words: drawing, analyze, methods of studying, coefficient of rationality. 

ИЗСЛЕДВАНЕ ИЗПОЛЗВАНЕТО НА CAD СИСТЕМИ 


Съвременната техника позволява бързо преминаване от традиционните ръчни 

методи на изработване на конструкторска документация към нови информационни 

технологии с използването на специализирани CAD-системи. Получената при това 

документация изцяло съответствува на стандартите по БДС и БДС ISO по качеството 

на изпълнение на документите. При такъв подход на конструиране използването на 

CAD-системи не отстранява чертежа като основа на конструирането. Компютърът при 

това служи за “електронен кадастрон”, което значително ускорява процеса за създаване 

на нови изделия. Компютърната графика се явява един от най-важните елементи на 

системата за автоматизирано проектиране на изделията. Тримерното компютърно 

моделиране дава на потребителя – конструктор възможност да използва естествения 

традиционен принцип на проектиране на изделието: от неговия пространствен модел 

към представяне в двумерното пространство, в това число и във вид на чертеж. За да се 

извърши преход от тримерно в двумерно пространство е необходимо най-напред да се 

овладеят от потребителите начините за изобразяване на детайл в двумерно 

пространство. 

В настоящата работа са използвани методите на двумерното моделиране в 

средата на графичната система за проектиране AutoCAD [1, 2, 3, 4, 5, 6]. 


- 220 - 

2. Кратко описание на използваната методика 

2.1. Първи етап от изследването 

В работата [7] са разгледани две схеми на изследване. Приета е първата схема – 

един обект на изследване, разработен със системата AutoCAD изпълнен от различни 

потребители. 

Обект на изследване се явяват предварително разработени шест прости детайли, 

зададени с двете си проекции. Ограниченият обем на доклада не позволява да се 

приложат всички детайли. 

На фиг. 1 е представен един от изследваните обекти – чертеж на детайл – 

вариант 5. 

5 

Фиг. 1. Изследван обект – детайл вариант 5 

В изследването участвуват девет начинаещи потребители, които са завършили 

напълно чертежа на детайла от вариант 5. 

За еталон са взети чертежите на детайла от вариант 5 на пет потребителя, 

познаващи много по-добре системата AutoCAD. 

2.2. Втори етап от изследването 

Вторият етап от изследването се явява оценка на създаденото с AutoCAD изображение, 

съдържащо се във файл. Задължително условие за работата на този етап е запис на 

файла с изображението в DXF формат. Този файл представлява пълна база данни за 

всеки чертеж. Развитието и усъвършенстването на системата AutoCAD с нови 

графични примитиви води до добавяне на нови групи данни в този файл.

- 221 - 

Всеки DXF файл включва много и разнообразна информация. Този факт прави 

непосредствения анализ на информацията във файла трудно изпълним, а при сложни 

изображения дори невъзможен. DXF файловете имат еднаква структура [1] и това 

позволява анализът им да се извършва лесно с програма за търсене на зададена 

информация. Те включват еднакви раздели с точно определени имена - HEADER, 

CLASSES, TABLES, BLOCKS, ENTITIES, OBJECTS, THUMBNAILIMAGE, които 

съдържат специфична информация, зависеща от изображението. В разделите са 

записани групи кодове със специфичен за файла формат. Анализът се базира на 

информация, която е записана в разделите BLOCKS (БЛОКОВЕ) и ENTITIES 

(ПРИМИТИВИ). 

Разделът BLOCKS (БЛОКОВЕ) включва блоковете, използувани при създаване на 

изображението. Съдържат се дефинициите на всички блокове, заедно с генериращите 

се анонимни блокове. Отделният дефиниран блок включва примитивите, които го 

съставят. Форматът на примитивите от този раздел е еднакъв с този от раздел 

ENTITIES. Всеки отделен примитив е разположен между елементите BLOCK и 

ENDBLK. Тези елементи се срещат само в раздела BLOCKS. 

Разделът ENTITIES (ПРИМИТИВИ) съдържа групата кодове на използуваните 

графичните примитиви и извиканите блокове, използувани за създаване на 

изображението в чертежа. Форматът за разполагане на графичните примитиви в този 

раздел е същият като в - раздел BLOCKS. 

Анализът на DXF файла се извършва по програмен път. Създадена е програма, която 

открива и отчита зададена информация. Информацията се записва или е записана 

предварително в отделен файл и програмата ползува този файл при търсенето. 

Записаната информация във файла може да се променя. Тя се определя от поставената 

при анализа задача. Програмата чете DXF файла и търси информацията и отразява 

получените резултати. Създадената програма използува таблична форма на представяне 

на информацията. 

При анализ на рационалността се търси и отчита записана информация в споменатите 

два раздела на DXF файла. Анализът се отнася за определени примитиви, изграждащи 

записаното във файла изображение. Разгледани са примитивите: LINE, CIRCLE, 

DIMENCION и POLYLINE. 

На база изведената матрица (1) в работата [7] е определен коефициента на 

рационалност по формула (1): 

КR = KL +2 x (КC + KD) + 3 x KPL, където (1) 

Σ PL 

Σ LЕ 

KL = - коефициент на примитива линии; 

Σ PС 

КC = Σ СЕ - коефициент на примитива окръжности; 

Σ PD 

KD = Σ DЕ - коефициент на примитива размери; 

Σ PPL 

KPL= Σ PLЕ 

- коефициент на примитива полилинии. 


- 222 - 

В числителя на посочените коефициенти сумите PL , PС , PD и PPL са съответно 

суми от примитивите за линии, окръжности, размери и полилинии от файловете на 

потребителите. В знаменателя сумите LЕ, СЕ, DЕ и PLЕ са суми от примитивите, взети 

от еталона. Множителят пред първото, второто и трето събираемо от формула (1) 

отчита степента на тежест на разглежданите примитиви. 

Прието е, във формула (1) използването на линия да има степен на тежест, равна 

на 1, за окръжност и оразмеряване – степента на тежест е равна на 2 и за полилиния - 

степен на тежест - равна на 3. Тези степени на тежест са приети на база анализ на броя 

операции за построяване на примитив, сложност на изпълнение на обектите, 

ресурсоемкост на техниката и др. 

Общият брой линии ( L ), общият брой окръжности ( C ), общият брой размери 

( D ) и общият брой полилинии ( PL ) се определя съответно чрез броя синтактични 

конструкции LINE, CIRCLE, DIMENSION и POLYLINELINE, записани в анализирания 

файл. 

3. Резултати от анализа на изследването 

Определянето на рационалността на изчертаване на чертеж на детайл с помощта 

на AutoCAD изисква следната последователност на работа: 

- създаване и запис на чертежа във файл с DWG формат; 

- запис на чертежа във файл с DXF формат; 

- преглед на големината на файловете; 

- обработка на DXF файла с програма за търсене – откриват се броя символи, 

определящи стойностите на параметрите във формула (1); 

- изчислява се относителния коефициент на рационалност КR на чертежа по 

формула (1) с получените данни от DXF файла. 

Резултатите, получени от обработката на създадените 14 файла са дадени в табл. 

1, 2 и 3. 

Таблица 1. Размер на обработваните файлове в [KB] (килобайта) 

Потребител № DWG формат DXF формат 

1 40 169 

2 45 196 

3 33 68 

4 41 169 

5 33 67 

6 34 70 

7 33 67 

8 40 118 

9 42 172 

10 46 62 

11 44 168 

12 33 69 

13 37 68 

14 42 65

- 223 - 

Файловете са създадени от различни потребители. Различават се по размер 

поради факта, че използуваните средствата за създаване на изображението отразяват 

познанията и умения за работа на съответния потребител. 

За определяне коефициентите на еталона е използвана средноаритметичната 

стойност на резултатите от чертежите на детайла на пет потребителя, познаващи много 

по-добре системата AutoCAD. Получените данни за коефициентите LЕ, СЕ, DЕ и PLЕ са 

представени в табл. 2. 

Таблица 2. Определяне на коефициентите LЕ, СЕ, DЕ и PLЕ за еталона 

Примитиви 

10 11 

Потребител № 

12 13 14 

Σ Коефициенти 

LINE 78 85 77 50 96 386 LЕ = 77,2 

CIRCLE 1 1 1 1 0 4 CЕ = 0,8 

DIMENSION 12 12 12 12 12 60 DЕ = 12,0 

POLYLINE 1 1 1 10 0 13 PLЕ = 2,6 

Резултатите на девет начинаещи потребители, завършили напълно чертежа на 

детайла са представени в табл. 3. 

Таблица 3. Определяне на общия брой примитиви за всеки потребител 

Примитиви 

1 2 3 


4 5 6 7 8 9 

LINE 95 102 88 101 90 85 73 105 94 

CIRCLE 2 1 1 1 1 1 1 0 0 

DIMENSION 12 12 12 12 12 12 12 11 12 

POLYLINE 1 1 1 1 3 3 4 1 1 

След обработка на данните от табл. 2 и 3 се определят относителните коефициенти на 

рационалност KR за всеки потребител. Получените резултати са представени в табл. 4. 

Таблица 4. Определяне на коефициента на рационалност KR по формула (1) 

Коефициенти 

1 2 3 


4 5 6 7 8 9 

КL LINE 1,23 1,32 1,14 1,31 1,17 1,10 0,95 1,36 1,22 

КC CIRCLE 2,50 1,25 1,25 1,25 1,25 1,25 1,25 0,00 0,00 

КD DIMENSION 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 

КPL POLYLINE 0,38 0,38 0,38 0,38 1,15 1,15 1,54 0,38 0,38 

KR 9,38 6,98 6,79 6,96 9,13 9,06 10,06 4,35 4,37 

Сравнението на резултатите от табл. 4 показва различни коефициенти KR. Това е 

поредно доказателство за различните подходи при реализирането на един и същ обект 

(чертеж) от различни потребители. Максимална стойност на KR получава потребител 

№7. Този резултат е вследствие на коефициента КPL. 


- 224 - 


Получените резултати и направения анализ на база разработената методика за 

изследване използването на програмния продукт AutoCAD [7] показват приложимостта 

и за оценяване ефективността на работа на потребителите. Критерий за съпоставимост 

е максималната стойност на KR. 


1. AutoCAD 14 БИБЛИЯ. Част ІІ. – Изд. Алекс Софт, 1998. – 432 с. 

2. Д. Петкова, М. Пенев, В. Василева. Създаване на тримерни модели в CAD системи, 

“АМТЕХ–2005”, Русе, Научни трудове, т.44, серия 2 “Прогресивни 

машиностроителни технологии”, ISBN 1311-3321, 10-12 ноември, 2005, с.540–545. 

3. М. Пенев, Д. Петкова, В. Василева. Сравнение при изграждане на 3D модели в 

CAD системи, “АМТЕХ–2005”, Русе, Научни трудове, т. 44, серия 2 “Прогресивни 

машиностроителни технологии”, ISBN 1311-3321, 10-12 ноември, 2005, с. 534–539. 

4. М. Пенев, Д. Петкова, К. Кръстев. Методика и анализ при проектирането в 

тримерно пространство, В сб. доклади на Международна научна конференция 

Trans&motauto’05+, В. Търново, т.4, ISBN 954.9322-12-2, 23-25 ноември, 2005, 

с.13–16. 

5. Д. Петкова, В. Петков, Д. Драганов, П. Ненчев. Проектиране на 

детайли с методите на проекционното чертане и с геометричното 3D 

моделиране, В сб. доклади на Международна научна конференция 

“UNITEX’05”, Габрово, 24-25 ноември 2005, с. ІІІ-287–292. 

6. М. Пенев, Д. Петкова. Оценка ефективността на изобразяване на 2D детайли в 

AutoCAD, HCTech’05, ноември, 2005, сп. “Машиностроене & Електроника”, София, 

ISSN 0025-455х, Машиноинтелект ЕООД, с. 73 – 75. 

7. Д. Петкова, П. Ненчев, К. Кръстев, М. Рачева. Методика за изследване 

използването на програмния продукт AutoCAD, В сб. доклади на Международна 

научна конференция Trans&motauto’06, Варна, 26-27 октомври, 2006, с. 31-33. 

Department of Machine Elements and Technical Drawing 

Department of Applied Information 

Technical University – Gabrovo 

4, Hadji Dimitar Str. 

5300 Gabrovo 

BULGARIA 

E-mail: dpetkova@tugab.bg

- 225 - 




BULGARIA 

VHDL MODELS OF SENSORS WITH ANALOG INPUT AND 

DIGITAL OUTPUT 

ATANAS KOSTADINOV 

Abstract. VHDL (Very high speed integrated circuit description language) has been used 

to build sensor models with analog input and digital output. There have been created and 

tested temperature sensors models of MAX 6666/MAX 6667, MAX 6676/MAX 6677 

produced by MAXIM Integrated Products Inc., TMP 03/ TMP 04 produced by Analog 

Devices Inc., as well as intelligent opto sensor TSL 230R produced by American firm 

TAOS Inc. (Texas Advanced Optoelectronic Solutions ). Input signal for above 

mentioned sensors is realized as analog type, while output signal is realized as 

digital one. 

The models have been verified using VHDL simulator ModelSim XE III/Starter 6.1e. 

Key words: VHDL, sensors, VHDL simulator. 

VHDL МОДЕЛИ НА СЕНЗОРИ С АНАЛОГОВ ВХОД И ИМПУЛСЕН 

ИЗХОД 


Сензорите са електронни елементи, които преобразуват определени физически 

величини (температура, скорост на въртене, осветеност, влажност, налягане и др.) в 

електрически сигнал. За да може информацията постъпваща от сензора да се съхрани в 

памет, както и да се обработи от микропроцесор е необходимо тя да бъде в цифров вид. 

Ако изходът на сензора е от аналогов тип, то трябва да се използва АЦП (Аналоговоцифров 

преобразувател), за да се извърши необходимото преобразуване. Съществуват 

сензори, на изхода на които информацията се получава непосредствено в цифров вид, 

т.е. при тях не е необходимо допълнително преобразуване на сигнала при изграждане 

на микропроцесорни системи. Като специална група сензори може да се обособи 

групата на т.нар. “интелигентни сензори”, които освен преобразователният елемент 

съдържат и електронни схеми, които извършват първоначална обработка на 

информацията и осигуряват по-голяма степен на функционалност [1]. 

Сензорите са част от състава на всяка една вградена микропроцесорна 

система [2]. От важно значение при изграждането на подобни системи е проверката на 

тяхната работа. Това се извършва чрез създаване и тестване на опитни образци на 

вградената система. Опитните образци биват реални – изградени от съответни 

интегрални схеми или виртуални – модели на тези системи създадени и описани чрез 

съответни езици. Виртуалните модели имат определени предимства в сравнение с 

физическите модели, като те са: 


- 226 - 

1.1. По-лесно и по-бързо е реализирането на виртуалните модели – не се изисква 

закупуването на електронни компоненти, създаването на печатни платки, запояването 

на елементите и т.н.; 

1.2. Не се отделят вредни вещества при реализирането им, както и не се 

използват материали, които са опасни за човешкото здраве; 

1.3. При промяна на свързването на елементите, не е необходимо създаването на 

нова платка или запояване на допълнителни проводници. Това, което се извършва е 

корекция във файла, определящ връзките между електронните елементи; 

1.4. Наличието в компютърната мрежа Интернет на IP (Intellectual property, 

интелектуална собственост) електронни елементи, в това число микропроцесори и 

микроконтролери. Някои от създадените IP модели са достъпни и без заплащане; 

1.5. Възможност за използване на компютърна техника през целият период на 

проектиране на микропроцесорна система, а не само при създаване на програмното 

осигуряване. Това позволява изследване на различни възможни комбинации от 

използваните електронни компоненти, което от своя страна води до получаване на 

системи с различни характеристики. Компютърната техника и подходящо програмно 

осигуряване е това, което помага на инженера-проектант да подбере най-подходящата 

микропроцесорна система за конкретното приложение от всички съществуващи 

решения; 

1.6. Получените резултати при симулирането на създадените виртуални модели, 

са много близки или идентични с тези, които биха се получили в резултат от 

проверката на физическите модели; 

1.7. Някои от фирмите производителки на програмируеми интегрални схеми 

предлагат достъпни университетски програми [6]. В резултат от участието в тях може 

да се получи дарение под формата на програмни и/или апаратни средства за създаване 

и проверка на реализираните виртуалните модели; 

Най-често използваните езици за описание на апаратната част са езиците VHDL 

и Verilog. Освен тях се използва и езикът Системен С (System C). Създадените 

виртуални модели се проверяват като се използват HDL (Hardware description language, 

език за описание на апаратната част) симулатори. 

2. Създадени модели на сензори 

Използван е VHDL за създаването на модели на температурни сензори 

MAX 6666/MAX 6667 и MAX 6676/MAX 6677 произведени от фирма MAXIM 

Integrated Products Inc., TMP 03/ TMP 04 произведени от Analog Devices Inc., както и 

интелигентният оптичен сензор TSL 230R, произведен от TAOS Inc. Подобен подход 

може да се види в публикуваните научни доклади и създадените модели [3, 4, 5, 9]. 

Последователността от действия използвани при създаване на VHDL моделите 

може да бъде обобщена в следните основни стъпки: 

• Разучаване на техническата документация за съответния сензор; 

• Създаване на VHDL модела, като използваното описание е от т.нар. 

поведенчески тип. Задава се сигнал с име s, който съществува в списъка от сигнали, 

които запускат създаден процес в поведенческото описание (структура, която се 

изпълнява паралелно), а същевременно той е включен и във VHDL израз от типа “s 

приема стойност не (not) s след (after) ...”. Това позволява създаването на непрекъснат 

генерационен процес, т.е. води до появата на правоъгълни импулси на изхода; 

• Промяната в коефициента на запълване, характерен за споменатите 

температурни сензори, се извършва чрез използването на два различни израза от типа 

“s приема стойност не s след ...”;

- 227 - 

• При интелигентният оптичен сензор TSL 230R са използвани няколко на 

брой израза от типа “s приема стойност не s след ...”, задаващи различната честота на 

генерираните правоъгълни импулси при съответен набор от двоични комбинации на 

входните сигнали s0, s1, s2 и s3, както и при конкретна стойност на светлинния 

интензитет (Ее); 

• Задават се границите измение на температурата (интензитета на 

светлината), при които работи сензора. При превишаването на тези граници, не се 

произвеждат правоъгълни импулси, т.е. сензорът спира своята работа; 

• Извършва се симулиране на създадените модели и се съхраняват, както 

получените времедиаграми, така и тестовите въздействия при които те са снети; 

• Допълнително, може да се повиши точността на модела, чрез отчитане на 

на съществуващите зависимости на генерираните импулси от промяната на 

захранващото напрежение, температурата (за TSL 230R), фабричните толеранси и др.; 

По предложеният алгоритъм са моделирани следните типове сензори: 

2.1. Температурните сензори MAX 6666/MAX 6667 производство на фирма 

MAXIM Integrated Products Inc. При тях произведените правоъгълни импулси са от вида 

показан на Фиг.1[8] . 

Фиг. 1. Правоъгълни импулси получени от сензорите MAX 6666/MAX 6667, 

kъдето продължителността на интервала t1 е постоянна и е равна на 10 mS, a 

продължителността на t2 е модулирана от температурата по формула (1) [8] 

0 ( C) 

235 − ( 400 t1) 

/ t2 

Temperatur e = × 

(1) 

При създаването на модела, трябва да определим зависимостта на 

продължителността на t2 като функция на температурата. Затова след математически 

преобразувания на формула 1 се получава равенство 2. 

400× 

t 

= (2) 

t2 0 

1 

( 235 − Temperature( 

C ) 

Последното е използвано в създадения модел, който е симулиран прилагайки 

следното тестово въздействие. 

run 200 mS 

force t -35 

run 200 mS 

force t 120 

run 200 mS 

force t 200 

run 200 mS 


- 228 - 

Получените резултатите от симулацията са представени на Фиг.2, където с t е 

отбелязана температурата, а с dout – изходът, на който се получава информацията от 

сензора. Температурният обхват, в който работи създадения модел, както и реалния 

електронен елемент, е от - 40°C до +125°C. 

Фиг. 2. Правоъгълни импулси получени от MAX 6666 VHDL модела. 

2.2. Температурните сензори MAX 6676/MAX 6677, също произведени от 

фирма MAXIM. Тук изходните импулси са с формата показана на Фиг. 3 [8]. 

Фиг. 3. Правоъгълни импулси получени от сензирете MAX 6676/MAX 6677, 

където стойността на интервала t1 e равна на 0.24 mS, а продължителността на t2 е 

модулирана от температурата по формула 3 [8]. 

0 ( C) 

= . 15× 

( t / t ) − 273. 

15 

398 1 2 

Temp (3) 

След математическо преобразуване на горното равенство, получаваме 

формула 4. 

t1 

× 398. 

15 

t 2 = 

(4) 

Temp 

0 ( C) 

+ 273. 

15 

Формула 4 е приложена в реализирания модел. 

Работният температурният обхват на този модел, както и на реалният 

електронен елемент, е от -40°C до +125°C. За симулирането на модела е използвано 

тестово въздействие, представено по-долу. Получените времедиаграни, в резултат на 

проверката на модела, са показани на Фиг. 4. 

run 5 mS 

force t -35 

run 5 mS 

force t -50 

run 5 mS 

force t 120 

run 5 mS 

force t 200 

run 5 mS

- 229 - 

Фиг. 4. Правоъгълни импулси получени от MAX 6676 VHDL модела. 

2.3. Температурните сензори TMP 03/ TMP 04 произведени от фирма Analog 

Devices Inc. Генерираните изходни правоъгълни импулси са с форма показани на 

Фиг.5 [7]. 

Фиг. 5. Правоъгълни импулси получени от сензорите TMP 03/ TMP 04, 

където продължителността на Т1 е с номинална стойност от 10 mS, а стойността на Т2 

се променя по формула 5 [7], която е представена по-долу. 

0 ⎛ 400× 

T1⎞ 

( C) 

= 235 − ⎜ ⎟ 

⎝ T 2 ⎠ 

Temperatur e 

(5) 

След математически преобразувания на равенство 5, получаваме формула 6. 

400× 

Т1 

2 = (6) 

235 − Temperature 

Т 0 

( C) 

Тази формула е използвана при създаването на модела. 

Температурният обхват на работа на модела и на самия сензор е от - 55°C до 

+150°C. Използваното тестово въздействие е представено на следващите редове, а 

получените резултати са показани на Фиг.6. 

run 150 mS 

force t -50 

run 150 mS 

force t -60 

run 150 mS 

force t 120 

run 150 mS 

force t 200 

run 150 mS 

Фиг. 6. Правоъгълни импулси получени от TMP 03 VHDL модела. 

2.4. Интелигентният оптичен сензор TSL 230R, произведен от фирма 

TAOS Inc. [10]. При него на изхода се получават правоъгълни импулси, с различна 


- 230 - 

честота зависеща от двоичния набор подаден на входовете s0, s1, s2 и s3, както и от 

стойността на Ее (интезитета на светлината). Използваната тестова последователност за 

проверка на модела е представена на редовете по-долу, а на Фиг.7 са показани 

резултатите получени при симулацията на VHDL модела. 

Тези резултати са сравнени с получените чрез създадения програмен симулатор 

за сензора TSL 230 (еднотипен с TSL 230R), зареден от страницата на фирмата 

производител. Създаден е и по-точен модел, при който са отчетени влиянието на 

температурата, промяната на захранващото напрежение, фабричните толеранси и др. 

върху честотата на генерираните правоъгълни импулси. 

force s0 0 

force s1 0 

force s2 0 

force s3 0 

force oe 1 

run 300 mS 

force s0 1 

force s1 0 

force s2 0 

force s3 0 

force oe 0 

run 300 mS 

force s0 0 

force s1 1 

force s2 0 

force s3 0 

run 300 mS 

force s0 1 

force s1 1 

force s2 0 

force s3 0 

run 300 mS 

force s0 1 

force s1 1 

force s2 0 

force s3 0 

force oe 1 

run 300 mS 

Фиг. 7. Правоъгълни импулси получени от TSL 230R VHDL модела.

- 231 - 


3.1. Създадени са VHDL модели на сензорите MAX 6666/MAX 6667, 

MAX 6676/MAX 6677, TMP 03/TMP 04 и TSL 230R. 

3.2. Предложен е алгоритъм, по който могат да се създават модели и на други 

подобни сензори с аналогов вход и импулсен изход. 

3.3. Формулите определящи продължителността на генерираните правоъгълни 

импулси, взети от техническата документацията на сензорите, са точно приложени в 

създадените и изследвани модели. За модела на TSL 230R резултатите са много близки 

сравнени с тези получени от програмния симулатор на същия сензор. 

3.4. Работата на всички реализирани модели е проверена със симулатора 

ModelSim XE III/Starter 6.1e. 


Бъдещата работа в тази насока ще бъде свързването на създадените VHDL 

модели с други такива, при което ще се реализират различни цифрови устройства и 

системи. 


1. P.J. Boltryk, C.J. Harris and N.M. White. Intelligent sensors – a generic software 

approach, Journal of Physics: Conference series 15, 2005, 155-160. 

2. De Micheli G., R. Gupta. Hardware/Software Co-Design, Proceedings of IEEE, 85(3), 

Vol.85, No. 3, 1997, 349-365. 

3. K. S. Karim, P. Servati, N. Mohan, A. Nathan and J.A. Rowlands. VHDL-AMS 

Modeling and Simulation of a Passive Pixel Sensor in a-Si:H Technology for Medical 

Imaging, Proceedings of IEEE ISCAS 2001, Sydney, Australia, Vol. 5, 2001, 479-482. 

4. E. Markert, M. Schlegel, M. Dienel, G. Herrmann and D. Muller. Modeling of a new 

acceleration sensor as part of a 2D Sensor Array in VHDL-AMS, Proceedings of 2005 NSTI 

Nanotechnology Conference & Trade Show, Anaheim CA, USA, Vol.3, 2005, 399-402. 

5. A. Tetelin, H. Levi, B. Mongellaz, C. Pellet. Behavioral modeling of a humidity sensor 

using an analog hardware description language, Proceedings of Modeling and Simulation of 

Microsystems conference, Puerto Rico, USA, 2002, 140-143. 

[6] http://www.altera.com 

[7] http://www.analog.com 

[8] http://www.maxim-ic.com 

[9] http://web.umr.edu/~daryl/nsfccli/models.htm 

[10] http://www.taosinc.com 

Electronics, Computer systems and Automation section 

John Atanasoff Technical Colege – Plovdiv 

71A, Br. Buckston Str. 

4004 Plovdiv 

BULGARIA 

E-mail: nasko67@mail.orbitel.bg

Telecommunications & Computer Engineering - Технически ...

Create successful ePaper yourself

Delete template?

Save as template ?