As of August 2024, International Journal "Notes on Intuitionistic Fuzzy Sets" is being indexed in Scopus.
Please check our Instructions to Authors and send your manuscripts to nifs.journal@gmail.com. Next issue: September/October 2024.

Open Call for Papers: International Workshop on Intuitionistic Fuzzy Sets • 13 December 2024 • Banska Bystrica, Slovakia/ online (hybrid mode).
Deadline for submissions: 16 November 2024.

Private talk:NFNI-2009

From Ifigenia, the wiki for intuitionistic fuzzy sets and generalized nets
Jump to navigation Jump to search

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

През 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 Техническа и помощна документация ? ?
n+7 Web приложение за интерактивна симулация на обобщени мрежи през стандартен web browser ? ?
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, поради неговата популярност, ефективност и наличие на добри оптимизиращи компилатори.