Private talk:NFNI-2009

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

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

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

Първа цел

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

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

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

Втора цел

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

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

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

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

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

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

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

GNTP

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

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

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

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

Връзка с Математика и Матлаб

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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