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?

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

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

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

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

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