Private talk:NFNI-2009

Състояние на научните изследвания

През 2005 година започва разработката на четвъртото поколение софтуерен симулатор за ОМ, програмиран на C++, Java (...) с елементи на XML, JavaScript (...).

Цели на проекта

Първа цел

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

Първите опити за създаване на такава платформа датират от средата на 1990-те години и понастоящем се работи над четвъртото, и най-перспективно от технологична гледна точка, поколение софтуер за ОМ, който се пише на съвременни популярни и динамично развиващи се програмни езици като C++, Java, XML,... Към момента в известна степен са разработени и сървърната, и клиентската част на платформата и е изготвена спецификация и работен план за оставащите задачи (например създаване на гъвкав потребителски интерфейс, туулбокс за Matlab/Octave за ОМ, детайлна софтуерна документация и др.).

Финализирането на работния план е изключително важна цел, която стои не само пред участниците в проекта, но и в по-общ план пред цялата българска и световна общност на ОМ-моделиране. От изпълнението й зависи не само изпълнението на проекта, но в известен смисъл и бъдещето на тази научна област, която има широкопризнат приложен потенциал, но към момента в по-голяма степен е развита в теоретичен аспект.

Втора цел

Втората цел на проекта е, разполагайки със завършения през първата фаза програмен пакет за ОМ, да се доведат до вид на работещи симулации множеството конструирани и планирани за разработка през втория етап на проекта абстрактни модели. Изпълнението на тази цел е от също толкова критично значение за областта на ОМ, понеже ще даде възможност в голям мащаб да се демонстрират доказаните с математически методи предимства на моделирането с този инструментариум и да се извлекат ползите от тях. Към момента са правени няколко софтуерни симулации на ОМ-модели, сравнително опростени откъм постановка и/или изпълнение, поради ограниченията наложени от недовършената работа по пакета. Дори и при такива условия обаче апаратът на ОМ е давал по-добри резултати от апарати като GPSS, други видове мрежи на Петри, невронни мрежи.....

Видове дейности

• 1. Софтуерна разработка
  • Довършване на клиент-сървърната част на пакета според предварителна спецификация
    • Събиране на изискванията от различните заинтересовани лица (моделиери, потребители, разработчици)
    • Създаване на тестови модели
    • Визуализация на резултатите, потребителски интерфейс
    • Рабработка на toolbox за Matlab / Octave
    • ...

2. Моделиране

• Чертае се графичната структура на модела в удобен за потребителя графичен редактор, част от интерфейса на симулатора.
• Въвеждат се параметрите на модела: условия за преминаване на ядрата през преходите, начални стойности на характеристиките на ядрата, характеристични функции на ядрата, капацитети и приоритети на позициите и дъгите, условия за сливане и разцепване на ядра, параметри за време и продължителност и др.
• Стартиране на симулацията, с възможност за управление от потребителя (начало на симулация, пауза на определен интервал или при намеса от потребителя, пауза за въвеждане на вход от потребителя, продължаване на симулацията, задаване на условия за пауза или край на симулацията).
• По време на симулацията могат да се следят в реално време избрани от потребителя характеристики в графичен или табличен вид. Всички резултати от симулацията ще се записват в дневник (лог) с цел възпроизвеждане на същата симулация и по-детайлно изследване на резултатите от нея.
• Моделите ще могат да се запазват в XML и да се експортират в TeX и графични формати.

План за устойчивост

Освен това, очакваните резултати в областта на информатиката (ОМ-модели на експертни системи, невронни мрежи, ГРИД-среди, оптимизационни алгортми чрез мравчени колонии, генетични алгоритми и техники за разпознаване на образи и говор) ще се окажат своеобразна "научна инвестиционна стока", тъй като на свой ред ще могат да се внедрят в по-сложни модели от други области. Например, резултатите от моделирането на ГРИД-среди с ОМ могат да се използват в ..., ОМ-моделите на разпознаването на образи може да послужат за .... Накратко, приоритетното прилагане на симулатора за ОМ към обекти и проблеми от информатиката, ще даде възможност тази "инвестиция" бързо да се възвърне към софтуерния пакет под формата на класове, библиотеки, подпрограми, ..., т.е. външен програмен слой над ядрото на симулатора, елементи от който се викат при решаване на специфични подзадачи.

Работа по програмната реализация

Номер	Дейност	Време (човекомесеци)	Изпълнител
0	Система за управление на модули	6 - 12 (9)	?
1	Редактор за ОМ	?	Христо
2	Графична среда за симулация на ОМ		Митко
3	GNTP	4-6	Трифон, Калин
4	Връзка с Математика и Матлаб	12	?
5	Връзка с измервателни уреди	6 - 12 (9)	?
6	Мрежови оператори	6	?
7	Мрежови алгоритми	6	?
8	Многонишкова симулация (разпаралеляване)	12+	?
9	Поддръжка на потребители и права	3 - 6 (9)	?
10	Автоматичен превод на процедурни програми в ОМ модели	12	?
11	Компилатор за ОМ модели	?	?
12	Техническа и помощна документация	?	?
13	Портал за интерактивна симулация на обобщени мрежи през стандартен web browser	?	?
14	Load balancing за GNTicker Server	6	?
		90 + 4?

GNTP

Интерпретаторът за ОМ съществува в два варианта: самостоятелна конзолна програма (standalone) и сървърна програма (server). Самостоятелният вариант е удобен за напълно автоматизирано изпълнение на даден мрежов модел. Входът на интерпретатора се чете от файл, а на изхода излиза пълен списък с всички събития за всяка стъпка на мрежата. Недостатъкът на този вариант е липсата на възможност за потребителска намеса по време на изпълнение, както и за постъпкова и графична симулация. Проблемът се решава от по-разширения сървърен вариант, който позволява фин контрол върху изпълнението на няколко различни модела едновременно. Моделите могат да се контролират от различни по вид програми. Връзката клиент/сървър е реализирана върху мрежов протокол TCP/IP, като това позволява изпълняващата (server) и контролиращата (client) програма да са на отдалечени компютри. В момента възможността за контрол се използва от графичните среди за моделиране на ОМ Gennete и GenEdit за постъпкова интерактивна симулация на ОМ.

Съществуващия сървърен вариант на интерпретатора използва примитивен протокол за комуникация, който позволява само две операции: зареждане на модел и изпълнение на стъпка от мрежата. Това решение позволява практическото осъществяване на интерактивна симулация, но с много ограничено въздействие на потребителя. Реализираният протокол е тясно специализиран и не е удобен за разширение. За целта беше проектиран новият и по-гъвкав протокол GNTP (GNTicker Trace Protocol), на основата на протокола за пренос на уеб страници HTTP. Новият протокол позволява:

• Постъпково изпълнение на мрежов модел
• Изпълнение на мрежов модел до настъпване на дадено условие
• Възможност за въвеждане на ядра от клиента към интерпретатора
• Възможност за запитване за параметри от интерпретатора към клиента по време на изпълнение
• Контрол и съобщаване на грешки

Необходимо е разработването на програмна поддръжка на протокола GNTP за сървърния вариант на интерпретатора, както и за програмните среди Gennete и GenEdit.

Връзка с Mathematica и Matlab

В дефиницията на ОМ е заложена възможността за гъвкаво описание на характеристични функции и предикати. Дори модели с проста статична структура могат да имат сложни за пресмятане математически функции, включващи например решаване на диференциално уравнение, прилагане на нетривиален числен метод или символно преобразуване на израз. Тази необходимост налага предвиждане на възможност за свързване на интерпретатора към професионален софтуер за математически пресмятания. Като цел на задачата бяха избрани две от най-популярни софтуерни математически системи: системата за компютърна алгебра Mathematica и системата за числени пресмятания MATLAB.

За решаване на задачата ще бъдат разработени програмни адаптери за интерпретатора на ОМ към Mathematica и MATLAB. На базата им ще бъдат дефинирани нови примитивни функции, които подават към съответната система израз за изчисление. След получаване на резултат, той ще се връща за обработка на интерпретатора на ОМ и симулацията ще продължава с получените данни. Това ще позволи многократно и гъвкаво използване и на двете системи едновременно по време на симулация на даден модел.

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

Едно от най-важните приложения на ОМ е моделиране на реални процеси от различни научни области. В повечето случаи моделираните системи не са затворени и имат възможност да получават външно въздействие, както и да въздействат на околната среда. Досега използваната методология позволява симулация на реален процес чрез включване на допълнителен модел на околната среда. Подаването на данни към модела може да се осъществява например с:

• подаване на файл с предварително подготвени входни данни на базата на статистика
• използване на генератор на псевдослучайни числа със зададени параметри;
• използване на оператор за въвеждане на данни (напр. наблюдаеми симптоми или реакции).

Извличането на данни от модела може да се осъществява със:

• събиране във файл на характеристиките на ядрата, излизащи от мрежата;
• извеждане на съобщения, данни или инструкции при дадено събитие;
• събиране на статистика за състоянията на мрежата (брой и вид ядра във позиция).

От симулация може да се премине към управление на реалния процес, като за целта трябва да се реализира двупосочна връзка с външни устройства. Поради голямото разнообразие от възможности за свързване (интерфейси), в зависимост от конкретните уреди, се налага дефиниране на конкретен пример, за реализацията на който ще бъдат изградени необходимите връзки. Две от най-разпространените свързвания са, към които екипът ще се насочи, са:

• серийна връзка от тип точка-към-точка (ppp);
• мрежова връзка по протокол TCP/IP.

В рамките на задачата ще се определи пример за реален процес, който ще се контролира. Ще бъдат определени външните уреди, които ще бъдат управлявани с помощта на ОМ, и ще бъдат реализирани:

• обща функционалност за получаване на данни от външни устройства чрез получаване на ядра или извикване на примитивни функции,
• обща функционалност за подаване на команди към външни устройства чрез извеждане на ядра или извикване на примитивни функции,
• специфична функционалност, необходима за връзка с избраните външни устройства,
• демонстрация на работещ реален процес, контролиран от ОМ.

Многонишкова симулация (разпаралеляване)

Едно от основните предимства на ОМ като средство за описание на процеси е лекотата на описание на паралелни процеси. Наличните софтуерни средства за изпълнение на ОМ мрежови модели поддържат паралелност само на ниво "мрежа", тоест, независимите една от друга мрежи се изпълняват в отделни нишки на операционната система. По този начин активните характеристични функции в дадена стъпка от жизнения цикъл на ОМ модела се изпълняват последователно, на базата на техните приоритети, или на базата на други политики за определяне на последователността.

Съвременните възможности на лесно достъпния многопроцесорен / многоядрен хардуер отключват възможностите пред ОМ мрежовите интерпретатори да превърнат езика на ОМ в мощен инструмент за паралелно програмиране, достъпен за широк кръг от потребители неспециалисти в областта на паралелното програмиране.

Да предположим, че разполагаме с хардуер, поддържащ с n свободни изчислителни ресурса (процесори или ядра). Задачата се свежда до управление на опашка от всички активни характеристични функции в дадения дискретен времеви момент. Във всеки физически момент от изпълнението на мрежовата стъпка се изпълняват едновременно n характеристични функции. При приключване на някоя характеристична функция, освободения ресурс се заема незабавно от следващата функция в опашката.

Възникват интересни въпроси около синхронизацията на характеристичните функции. От допълнителни грижи имат нужда тези функции, които изменят една и съща стийност на характеристика на дадено ядро в един и същи ОМ цикъл. Възможни са различни подходи за разрешаване на такива конфликти. Например, възможно е да се изпълняват характеристичните функции стриктно в обратен ред на техния приоритет, което ще запази в крайна сметка само тази стойност на ядрото, поставена му от функцията с най-висок приоритет. Друга възможна политика е чисто и просто забрана за промяна на една и съща стойност на ядро от две характериситчни функции в даден цикъл. В такъв случай би следвало да се разбработят нови мрежови примитиви, които ХФ да използват за проверка дали имат "право" да променят някаква стойност на ядро в даден цикъл (canChange?). Изобщо е възможно контролът на синхронизацията да се остави в ръцете на моделиста.

Мрежовата стъпка приключва при завършване на всички характеристични функции.

Компилиране на ОМ модели

Интерпретаторът на ОМ позволява зареждането на описание на мрежов модел и постъпковото му изпълнение. Той е удобен за разработка на мрежови модели, понеже позволява на потребителя във всеки един момент от изпълнението да направи справка кои части от мрежата са активирани на дадена стъпка. Ако бъде открит проблем в логиката на модела, тя може сравнително лесно да бъде открита и коригирана. След като бъде завършен, ОМ моделът може да се разпространява под формата на XML файл. За да могат други потребители да симулират дадената мрежата, е необходимо да инсталират интерпретатора на ОМ, в който да заредят XML файла.

Алтернатива на този процес е компилирането на мрежови модели, т.е. генерирането на изпълнима програма на машинен език, която е еквивалентна на изпълнението на даден ОМ модел през интерпретатора. Предимства на тази идея са:

• самостоятелност — ОМ модел може да бъде разпространяван като самостоятелна програма, за изпълнението на която не е необходим интерпретатор
• специализираност — програмата ще изпълнява само логиката на дадения ОМ модел, поради което ще бъде по-бърза от пускането на същия модел през интерпретатора

Възможни подходи за решаване на тази задача са:

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

За реализация на компилирането на ОМ модели беше избран вторият подход и програмният език C, поради неговата популярност, ефективност и наличие на добри оптимизиращи компилатори.

IIT-BAS

Данни от ИИТ:

2. Списък на конференции: - Международна конференция по биометрика (USA, 2011) - WSEAS (2010, 2011, 2012) - BioID (2010 – Гърция, 2011) - iCEST (2010, 2011, 2012 – Сърбия, Македония, България) - AIMSA’2011 (България) - CompSysTech (2010, 2011, 2012 – България) - Автоматика и информатика (2010, 2011, 2012 – България)

3. Мероприятия, в организацията на които ще участваме: - AIMSA’2011 (България) - CompSysTech (2010, 2011, 2012 – България) - Автоматика и информатика ( 2009, 2010, 2011, 2012 – България)

4. Списания: - PAMI (Pattern Analysis and Machine Intelligence) - PRL (Pattern Recognition Letters) - PR (Pattern Recognition) - CIT (Cybernetics and Information Technologies)

5. Научни задачи:

- Разработка на методи за идентификация на хора по биометричните модалности on-line и off-line подписи и почерк - Разработка на методи за автоматична оценка на възрастта на лица във видео изображения с използване на антропометрични параметри - Разработване на интуиционистки размити методи за обработка на изображения и разпознаване на образи.