УДК 681.142.5
Бiльшiсть складних систем керування прямо чи побiчно зв'язанi з системами моделювання. Фактично кожна система керування на початковому та наступних етапах проходить крiзь стадiю побудови ⌡⌡ моделi. Звичайно на цому вплив системи моделювання на кiнцеву систему керування припиня≤ться. Як виявилось, застосовувати засоби моделювання корисно не тiльки на етапi розробки, а й в дiючий системi керування, що обумовлено великою кiлькiстю факторiв [1].
Залучення до складу системи керування пiдсистеми iмiтацiйного моделювання наклада≤ на не⌡ додатковi, особливi вимоги, що дозволя≤ видiлити окремий клас мiкросистем iмiтацiйного моделювання. Далi пiд мiкросистемами iмiтацiйного моделювання (МIМ) будемо розумiти пiдсистеми моделювання (ПСМ), якi вбудовуються в системи керування (СК) з метою пiдвищення ⌡х ефективностi.
По-перше, необхiднiсть в використаннi пiдсистеми моделювання в складi системи керування, викликана необхiднiстю прогнозування реакцi⌡ системи, якою керують, на потiк керування для штатних режимiв та при виникненнi непередбачених випадкiв у реальному масштабi часу.
Iсну≤ два основних варiанта використання мiкросистем моделювання в складi системи керування - вiдстежування та прогнозування.
Вiдстежування може використовуватися з метою виявлення зiпсування об'≤кту який моделю≤ться та з метою отримання невiдомих з технiчних причин параметрiв функцiонування. Структурна схема використання МIМ у варiантi вiдстежування вiдображена на рисунку 1. Треба зазначити, що в випадку виявлення зiпсування, моделювання може розпочинатись в будь який момент часу роботи системи керування, тому, що всi необхiднi параметри об'≤кта, дiяльнiсть якого моделю≤ться вiдомi i треба лише повести параметричну настройку моделi та iнiцiювати моделювання.
Випадок використання пiдсистеми моделювання з метою отримання невiдомих параметрiв бiльш складний. Моделювання повинно розпочатися в момент початку роботи систем i безперервно продовжуватись на протязi всього часу ⌡⌡ роботи. Якщо моделювання буде iнiцiйовано не в момент старту СК - система моделювання повинна мати спецiальнi засоби для погодження параметрiв моделi з параметрами реального об'≤кту.
При прогнозуваннi iмiтацiйна модель використову≤ться з метою аналiзу реакцi⌡ системи на потiк керування. Схема роботи МIМ в цому варiантi зображена на рисунку 2. Система моделювання отриму≤ з зовнiшнього генератора множину варiантiв команд керування, якi подаються на вхiд моделям. Отриманi результати моделювання передаються в систему керування для виявлення найбiльш вдалого варiанту програми керування.
Iншi варiанти використання мiкросистем iмiтацiйного моделювання звичайно ≤ комбiнацiями прогнозування та вiдстежування.
Вимоги до побудови пiдсистеми моделювання бiльшою мiрою вiдповiдають вимогам до побудови сучасного програмного забезпечення систем керування [1]:
· об'≤ктно-орi≤нтована технологiя програмування;
· графiчний iнтерфейс користувача;
· анiмацiя;
· вза≤модiя з зовнiшнiм оточенням в реальному часi;
· архiтектура клi≤нт-сервер;
· вiдповiднiсть стандартам.
· незалежнiсть вiд обчислювально⌡ платформи
Зважаючи на особливостi побудови пiдсистеми моделювання в складi системи керування слiд ще додати особливi вимоги:
· пiдтримка апаратно⌡ акселерацi⌡;
· розподiленiсть обчислень;
· особливий протокол вза≤модi⌡ з оператором.
Можлива структура МIМ, яка задовольня≤ всi вказанi вище вимоги, запропонована на рисунку 3.
Основними елементами МIМ ≤:
· ядро системи моделювання - програма за допомогою яко⌡ проводиться моделювання;
· репозiтарiй компонентiв - бiблiотека пiдпрограм, та ⌡х опис (об'≤ктно-орi≤нтована технологiя програмування);
· засоби керування експериментом - набiр методiв планування, налагодження та проведення експерименту;
· засоби вiдображення результатiв моделювання - набiр методiв, за допомогою яких можна отримувати результати моделювання.
Наявнiсть iнших елементiв залежить вiд необхiдностi та дикту≤ться вимогами до конкретно⌡ реалiзацi⌡ СК
· засоби розробки моделей - спецiалiзована оболонка розробника моделей (графiчний iнтерфейс користувача);
· iнтерфейс оператора - реалiзу≤ особливий протокол вза≤модi⌡ з оператором;
· засоби забезпечення розподiле-ностi моделювання - спецiальнi засоби за допомогою яких можна розподiляти планування експерименту мiж декiлькома обчислювальними пристроями;
· репозiтарiй моделей - бiблiотека готових до вжитку моделей (об'≤ктно-орi≤нтована технологiя програмування);
· графiчне вiдображення роботи моделi - анiмацiя процесу моделювання;
· мiст до реального об'≤кту - реалiзу≤ вза≤модiю з зовнiшнiм оточенням в реальному часi;
· апаратний акселератор - спецiалiзований пристрiй, за допомогою якого збiльшу≤ться швидкiсть виконання деяких ресурсо≤мких операцiй (пiдтримка апаратно⌡ акселерацi⌡).
Порiвняння iснуючих систем проведено згiдно з визначеними вимогами та запропонованою структурою.
Всi розглянутi системи моделювання виконанi за допомогою об'ектно орi≤нтовано⌡ технологi⌡ програмування. Звичайно використовуються мови програмування C++, Java, Smalltalk.
Особливий iнтерес представля≤ питання про наявнiсть графiчного iнтерфейсу з користувачем, та анiмацiя процесу моделювання. Бiльшiсть систем моделювання мають графiчний iнтерфейс, але цей iнтерфейс ≤ вбудованим в ядро системи моделювання, що не вiдповiда≤ визначенiй структурi МIМ. Як слiдство, використання таких систем моделювання обмежене колом обчислювальних платформ з графiчним iнтерфейсом користувача.
Вза≤модiя з зовнiшнiм оточенням в реальному часi в бiльшостi систем моделювання не забезпечу≤ться. Праця в реальному часi реалiзована в системах прогнозу погоди та моделювання вiртуально⌡ реальностi. При цому першi - повиннi закiнчувати моделювання до визначеного моменту часу [2-4] (iнакше моделювання не ма≤ сенсу), а другi - повиннi проводити моделювання не швидше та й не повiльнiше нiж масштаб реального часу [5]. Iншi з розглянутих систем моделювання не мають спецiалiзованих засобiв, за допомогою яких ⌡х можна вiднести до систем моделювання реального часу.
Архiтектура клi≤нт-сервер найбiльш розвинута в системi G2 [6]. Цю систему можна сприйняти як гарний приклад. Взагалi наявнiсть пiдтримки архiтектури клi≤нт-сервер властива риса бiльшостi систем моделювання, якi реалiзованi за допомогою специфiкацi⌡ CORBA, COM, EJB.
Вiдповiднiсть стандартам ≤ важливою складовою частиною вимог до МIМ. При побудовi систем моделювання повинно використовуватися декiлька стандартiв. В першу чергу це стандарт на мову програмування та використання стандартних бiблiотек методiв, що ма≤ особливе значення для мови програмування C++. Також iснують стандарти на представлення iнформацi⌡ та на вхiдну iнформацiю, що особливо помiтно в системах прогнозування погоди [2-4] та моделювання шляхового руху [7-11].
Незалежнiсть вiд обчислювально⌡ платформи в бiльшо⌡ мiрi не характерна для iснуючих систем моделювання, це пов'язано з тим, що системи моделювання розробляються та використовуються на однiй апаратнiй платформi, тому спецiально пiд не⌡ оптимiзованi. Дуже розповсюджена пiдтримка платформо-незалежностi за допомогою використання стандартно⌡ мови програмування C++[12], компiлятори до яко⌡ iснують для бiльшостi операцiйних систем. Найчастiше використову≤ться дуже поширений для багатьох платформ - компiлятор GCC. В такому разi, графiчна оболонка користувача реалiзу≤ться за допомогою стандарту X-Windows, реалiзацi⌡ якого ≤ для бiльшостi операцiйних систем. Цей пiдхiд припуска≤ перекомпiляцiю системи моделювання пiд конкретну операцiйну систему.
Iсну≤ ще один пiдхiд в реалiзацi⌡ платформо-незалежностi це використання iнтерпретуючих систем програмування, найбiльш поширеними з яких ≤ Smalltalk та Java. Використання Smalltalk менш поширене[13]. В разi використання Smalltalk система моделювання обмежуються колом апаратних платформ з графiчним iнтерфейсом. Згiдно з iдеологi≤ю цi≤⌡ мови можна вiдокремити графiчний iнтерфейс, але це дуже складно та не природно для цi≤⌡ системи програмування.
Використання Java поширене значно бiльше [14-16], це обумовлено декiлькома факторами. Найбiльш важливим них ≤ заявлена фiрмою виробником платформо-незалежнiсть цi≤⌡ технологi⌡ програмування. Наявнiсть iнтерпретаторiв Java для бiльшостi платформ робить цю технологiю дуже привабливою, якщо однi≤ю з цiлей створення системи моделювання ≤ платформо-незалежнiсть.
Оскiльки моделювання дуже ресурсо≤мкий процес, його можна прискорити, якщо використовувати спецiальнi апаратнi засоби. Використання спецiальних апаратних засобiв найбiльш поширене в спецiалiзованих системах моделювання [5,17-20]. Дiапазон цих засобiв почина≤ться з використання стандартних засобiв широкого вжитку, наприклад стацi⌡ Silicon Graphics Inc. [17], та заверша≤ться спецiалiзованими мiкропроцесорами [20]. При цому слiд зазначити, що спецiальнi апаратнi засоби можуть використовуватись як для пiдвищення швидкостi роботи всi≤⌡ системи моделювання (бiльш швидкiснi центральнi процесори) так i для пiдвищення швидкостi виконання окремих операцiй, наприклад, використання апаратних акселераторiв для побудови графiчних зображень [5].
Крiм того моделювання ма≤ дуже специфiчну властивiсть - необхiднiсть багаторазового прогону моделi з рiзними параметрами. Це вказу≤ на природну потребу розподiленого виконання процесу моделювання. Iсну≤ небагато систем, якi прямо використовують цю властивiсть. Пiд прямим використанням розумi≤ться розподiлення процесу моделювання на бiльш високому рiвнi - мiж конкретними обчислювальними пристроями. Пiд непрямим використанням може розглядатись тiльки використання механiзмiв розподiлення обчислень вбудованих в операцiйну систему, наприклад потокiв (Thread).
Iсну≤ небагато систем [6,12,16], в яких по≤днуються цi два пiдходи. В бiльшостi випадкiв використовуються тiльки засоби вбудованi в операцiйнi системи.
Дуже специфiчною ≤ вимога до особливого протоколу вза≤модi⌡ з оператором. Якщо система моделювання вбудову≤ться в систему керування, то в якостi оператора може виступати як оператор-людина так i програма керування. Зрозумiло, що для людини потрiбен графiчний зручний iнтерфейс користувача. Бiльшiсть систем моделювання реалiзу≤ цю вимогу, в дуже специфiчнiй формi [5,21]. Реалiзацiя спецiалiзованого iнтерфейсу, крiм графiчного iсну≤ тiльки в деяких системах моделювання [5,12,22]. Бiльш того в багатьох системах моделювання iнтерфейс з користувачем ≤ вбудованим в ядро системи керування, що виключа≤ можливiсть вiдокремлення графiчного iнтерфейсу вiд системи моделювання, отже цi системи не можуть вбудовуватися до систем керування, в яких вiдсутнi засоби роботи з оператором-людиною, що ≤ ⌡х недолiком. Тому ядро системи моделювання повинно мати програмний iнтерфейс для реалiзацi⌡ будь-якого типу iнтерфейсу з оператором.
В багатьох випадках результатом моделювання ≤ графiчне вiдображення самого процесу моделювання - анiмацiя. Iнодi графiчне представлення ≤ ≤диною цiллю самого моделювання [2-5]. Звичайно цей процес дуже ресурсо≤мкий, i коли вiдображення непотрiбно воно повинно легко вiдключатися вiд системи моделювання, що i iсну≤ в окремих випадках [2-4]. Деякi системи моделювання взагалi не потребують графiчного вiдображення процесу моделювання (але в якостi вихiдних даних мають графiчне зображення), наприклад системи прогнозування погоди [2-4].
Використання системи моделювання в складi дiючо⌡ системи керування потребу≤ протоколу вза≤модi⌡ мiж моделлю та реальним об'≤ктом. Особливо це важливо в разi моделювання з метою вiдстежування правильностi роботи об'≤кту. Пiдсистема моделювання повинна передбачати можливiсть включення до ⌡⌡ складу в якостi компонента моделi - реальних об'≤ктiв. В даному випадку важлива наявнiсть в системi моделювання стандартного iнтерфейсу моделi з iншими об'≤ктами системи керування. Звичайно це реалiзу≤ться за допомогою специфiкацiй CORBA, COM, EJB. Найбiльш розвинену пiдтримку цих специфiкацiй ма≤ тiльки одна з розглянутих систем - G2 [6].
Побудова МIМ виключно як особливо⌡ системи моделювання не ≤ оптимальним рiшенням, оскiльки така система може бути отримана в результатi розвитку яко⌡сь унiверсально⌡ системи моделювання. Подальший аналiз iснуючих систем моделювання виконаний з метою визначення найбiльш придатно⌡ унiверсально⌡ системи моделювання на засадi яко⌡ можна побудувати мiкросистему iмiтацiйного моделювання.
Виходячи з приведеного порiвняльного аналiзу, можна зробити висновок, що кожна з розглянутих систем моделювання не вiдповiда≤ всiм визначеним вимогам до вбудованих систем моделювання реального часу. Це вказу≤ на необхiднiсть розробки спецiалiзовано⌡ системи моделювання, за допомогою яко⌡ можуть бути розробленi спецiалiзованi системи iмiтацiйного моделювання, якi можна залучати до складу СК, що може стати окремою науковою задачею. В якостi прототипу може бути застосована платформо-незалежно⌡ системи моделювання [16].
1. Е.Л. Кулида, В.Г. Лебеде, А.М. Чесноков. Проектирование интеллектуальных систем поддержки операторов сложных объектов. - М: ОСП Автоматизированное проектирование ©1 / 1999г (http://www.osp.ru/ap/)
2. Real-time Forecast Model System of NWP Group/SNU. http://weather.snu.ac.kr/real/
3. Numerical Forecasts. http://www.net.utah.edu/models.html
4. Real-Time MM5. http://www.mmm.ucar.edu/mm5/mm5forecast/rtmm5.html
5. Real-Time Simulation User's Guide. http://bigben.larc.nasa.gov/policy/red/Red_Book.html
6. HLA Toolkit G2 Simulation & Modeling http://www.gensym.com
7. The Swarm Simulation System. http://www.santafe.edu/projects/swarm/index.html
8. Qi Yang. A Simulation Laboratory for Evalusation of Dynamic Traffic Management Systems. http://hippo.mit.edu/products/mitsim/index.html
9. Traffic Software Integrated Systems. http://www.fhwa-tsis.com/
10. Smartest. Simulation Modeling Applied to Road Transport European Sheme Tests. http://www.its.leeds.ac.uk/smartest/index.html
11. TSS Transport Simulations Systems. http://www.tss-bcn.com
12. InterSIM. http://www.syseca.thomson-csf.com/intersim.html
13. 'IDaSS' the Interactive Design and Simulation System. http://www.ics.ele.tue.nl/~ad/idass.html
14. Московский Государственный Технический университет им. Н.Э.Баумана. SYMHYD http://wwwcdl.bmstu.ru/PA9/simhyd/index.html
15. JavaJack: A Modeling System for Scientists and Engineers. http://cde.rpi.edu/JavaJack.html
16. В.В. Казимир, А. В. Пастухов. Платформно-независимая система имитационного моделирования. - В сб.: Працi першо⌡ науково-практично⌡ конференцi⌡ з програмування УкрПРОГ'98. - Укра⌡на, Ки⌡в, Кiбернетичний центр НАН Укра⌡ни, 1998.
17. Silicon Graphics, Inc. http://www.sgi.com
18. Real-time Hardware/Software Simulation. www.prim.com/realtime.html
19. VisSim. The Adept Web Store http://www.adeptscience.co.uk/as/products/mathsim/vissim/realtime.htm
20. Simulation Associates, Inc. Real-time simulation of the gyro dynamic of the stinger missile on thearts system with the starlight accelerator http://easai.com/strlite.htm
21. Frametome Technologies, Inc. Training Simulator. Advanced Power Plant training and Analysis Tool. http://www.framatech.com/marketing/itg-001.htm
22. Primary Simulation, Inc. PSI's Real-Time Simulation Packages. http://www.psism.com/simulatn.htm