Узагальнена функціональна структура агента складається з 5 блоків (рис.1):

Рисунок 1 – Узагальнена функціональна структура агента (S – сенсорна система, E – блок оцінки, D – блок прийняття рішень, A – виконавча система, C – блок інформаційної взаємодії з іншими агентами)

• S (sense) – сенсорна система; відповідає за отримання інформації про стан середовища, наприклад, у вигляді значень параметрів, які вимірюються датчиками сенсорної системи (температура, тиск, радіоактивність), або у вигляді зображень отриманих за допомогою відеокамери.

• C (communicate) – блок інформаційної взаємодії з іншими агентами; забезпечує обмін інформацією певного змісту та формату з сусідніми агентами.

• E (estimate) – блок оцінки; формує сигнал виграшу чи програшу на підставі інформації про поточний стан середовища та інформації від блоку інформаційної взаємодії.

• D (decide) – блок прийняття рішень; відповідає за вибір наступної дії, виходячи з інформації про успішність попередніх дій (приклад: автомат з лінійною тактикою, який забезпечує збіжність до виграшного рішенням в умовах стаціонарного випадкового середовища).

• A (actuate) – виконавча система; забезпечує виконання (реалізацію) вибраних дій (прийнятих рішень) (наприклад, реалізує переміщення агента в просторі в обраному напрямку)

Мультиагентні системи Многоагентні системи (мас) – об'єднання окремих інтелектуальних систем. Можна дати формалізоване визначення багатоагентної системи:

MAS = (A, E, R, ORG, ACT, COM, EV),                                                                  (1)

де MAS – многоагентних система, А – множина агентів, Е – множина середовищ, що перебувають у певних відносинах R і взаємодіють один з одним, формують деяку організацію ORG, що володіють набором індивідуальних і сумісних дій ACT (стратегія поведінки та вчинків), включаючи можливі комунікативні дії COM і можливість еволюції EV.

Щоб зробити МАС готовими до промислового застосування, некомерційна асоціація під назвою FIPA, запропонувала ряд норм і стандартів, які розробники мультиагентних систем повинні виконувати, щоб МАС були сумісним з іншими системами:

• Агент може зв'язатися з будь-яким іншим агентом

• Агент надає ряд послуг, які доступні будь-якому агенту в системі.

• Кожен агент зобов'язаний обмежити свою доступність від інших агентів.

• Кожен агент зобов'язаний визначити своє ставлення, контракти, і т.д. з іншими агентами. Таким чином, агент "знає" безпосередньо набір агентів, з якими він може взаємодіяти.

• Кожен агент містить зі своїм ім'ям свій шлях (поняття ID Агента). Тому, агенти, як передбачається, автономні, і немає обмежень на спосіб взаємодії.

Недоліки мас:

• Головний недолік МАС – непередбачуваність поведінки повної системи, заснованої на її складових компонентах.

• Безпека додатків. Оскільки немає ніякого "​​загального" управління безпекою, агент може діяти як порушник і використовувати систему як «шахрай».

• Модульний принцип. При класичній розробці програмного забезпечення об'єкти, які тісно взаємодіють, згруповані у модулі чи "пакети". Для кожного модуля визначені правила видимості. Це неможливо в МАС, тому що всі агенти повинні бути доступні один одному.

MadKit

В якості інструментального середовища розробки була обрана система MadKit. MadKit є набором пакетів, класів Java, які реалізує ядро агента, різні бібліотеки повідомлень і агентів. Вона також включає в себе графічне середовище розробки і стандартні моделі агента. Архітектура MadKit заснована на дуже маленькому ядрі. Базові служби, такі як: розподілена передача повідомлень, міграція або контроль - здійснюються агентами платформи для максимальної гнучкості. Компонентна інтерфейсна модель дозволяє встановлювати інтерфейси для різних агентів і керує ними в глобальному GUI.

Архітектура платформи MADKIT заснована на AGR (Agent / Group / Role) моделі, відомої як AALAADIN (рис. 2). Модель AGR заснована на трьох примітивних поняттях: агент, група і роль, які структурно з'єднані і не можуть бути визначені іншими примітивами.

Рисунок 2 – Модель AALAADIN

Агент – активний об'єкт передачі повідомлень, який грає ролі в межах груп. Агент може грати кілька ролей, і може бути членом декількох груп. Одна з найважливіших характеристик моделі AGR – те, що немає ніяких обмежень, накладених на внутрішню архітектуру агента, його поведінку, його можливості. Важливо, зробити модель настільки універсальною, наскільки це можливо.

Група – ряд агентів, які разом використовують деякі загальні характеристики. Агент може бути членом декількох груп в один і той же час. Важливою особливістю груп AALAADIN є те, що вони можуть вільно накладатися. Група може бути заснована будь-яким агентом.

Роль – абстрактне уявлення функціональної позиції агента в групі. Агент повинен відігравати роль у групі; агент може грати кілька ролей. Ролі локальні для груп, і агент повинен запросити роль для її виконання. Кілька агентів можуть грати одну роль. 

Модель агента в MadKit

Структура агента в MadKit наведена на рис. 3.

 

Рисунок 3 – Структура моделі агента в MadKit

Агент в MadKit складається з 4 обов'язкових розділів [24]:

• Розділ активації (activate section), що містить деякий програмний код, який буде виконуватися безпосередньо після створення агента.

• Розділ «життя» (live section), який містить основний програмний код, що описує поведінку агента. Зазвичай, цей розділ містить нескінченний цикл.

• Розділ «завершення» (end section), що містить певний код, який виконується, коли агент знищується.

• Графічний розділ (initGUI section), що містить опис компонента Java, що має використовуватися в якості графічного інтерфейсу агента, і призначений для заміни графічного інтерфейсу за замовчуванням.

MadKit не накладає на архітектуру агентів ніяких обмежень для досягнення максимальної універсальності програм.

Взаємодія агентів в MadKit

Взаємодія агентів в MadKit здійснюється за допомогою асинхронної передачі повідомлень. Агент може відправити повідомлення іншому агенту, який визначається його адресою або за допомогою широкомовного повідомлення, яке передається агентам, які грають певну роль в певній групі.

MadKit забезпечує декілька видів визначених повідомлень, таких як StringMessage, XMLMesssage і ActMessage. За допомогою останнього виду повідомлення можна визначити такі підвиди повідомлень: ACLMessages і KQMLMessages [24]. Також є можливість визначити свій власний клас повідомлення, який буде успадковуватися від класу повідомлення за замовчуванням. У кожного агента є своя «поштова скринька», в яку доставляються повідомлення і яку повинен перевіряти агент для отримання повідомлення.

Приклад агентно моделі процесу поширення вірусу

За допомогою системи MadKit створена агентно модель розповсюдження вірусів. Модельоване середовище являє собою набір об'єктів (скажімо, людей), певну кількість яких заражено вірусом, а інших – ні. Всі об'єкти рухаються певним чином в довільному напрямі. Зараження відбувається при безпосередньому зіткненні здорового і зараженого об'єктів або може відбутися в деякому радіусі від зараженого об'єкта.

Кілька станів модельованого процесу поширення вірусів показано на рис. 4. У цьому прикладі здорові об'єкти позначені зеленим кольором, заражені - червоним.

Рисунок 4 – Моделювання процесу пошишерення вірусу засобами інструментальної середи MadKit (анімація – розмір: 196 x 214 px; обсяг: 36.6 kb; кадров: 6; затримка між кадрами: 0.5с; кількість повторів: 6)

Паралельно візуальному моделювання покроково будується графік залежності кількості заражених об'єктів від часу.

За допомогою віконного інтерфейсу можна задавати початкові параметри моделювання.

Дана модель може бути застосована для вивчення наступних процесів:

• епідемія грипу в місцях скупчення людей;

• поширення чуток в соціальних мережах;

• поширення інформації в робочому колективі, студентській групі, групі родичів, у групі знайомих людей тощо.

Висновки

Інструментальне середовище MadKit є універсальною мультиагентної платформою. Цей інструментарій заснований на організаційній моделі AGR. Архітектура MadKit заснована на мікроядрі. Базові служби, такі як: розподілена передача повідомлень, міграція або контроль – реалізовані агентами платформи для досягнення максимальної гнучкості [23]. Компонентна інтерфейсна модель дозволяє встановлювати інтерфейси для різних агентів.

Є приклади вдалого використання MadKit у проектах, що стосуються широкого діапазону програм від моделювання гібридної архітектури для управління підводних роботів до оцінки соціальних мереж або дослідженню мультиагентної управління на виробничій лінії.

Методика, використовувана в MadKit, є досить простою у застосуванні.

Великою перевагою даного інструментального середовища є той факт, що вона не накладає ніяких обмежень на архітектуру агентів для досягнення максимальної універсальності додатків. Наприклад, зараз загальновизнаною є BDI-архітектура, а через деякий час, можливо, буде використовуватися інша нова архітектура інтелектуального агента. У даному випадку розробникам агентних систем не потрібно буде вивчати іншу інструментальну середовище для використання нової архітектури.

Взаємодія агентів здійснюється за допомогою повідомлень різних типів, також є можливість створювати свої типи повідомлень. Велику розмаїтість типів повідомлень можна віднести до позитивних характеристик середовища. Агенти можуть взаємодіяти як в мережі, так і на одному комп'ютері з однієї або різних сесій моделювання.

Система MadKit є зручним інструментом для розробки МАС, тому що вона має безліч візуальних елементів, які спрощують роботу. Наприклад, в MadKit є дерево відносин агентів, яка містить інформацію про те, до якої групи відносяться агенти, яку роль відіграють тощо, таблиця повідомлень, що містить відомості про агента-відправника, агента-одержувача, дату, час тощо, автоматично будується часова діаграма, є можливості для побудови візуалізації МАС.

Таким чином, принципових недоліків в інструментальному середовищі MadKit виявлено не було. MadKit відповідає сучасним вимогам і надалі планується застосування її для розробки моделей поведінки людини в соціально-економічному середовищі.

Особливості взаємодії комп'ютерів у обчислювальній мережі гетерогенної архітектури

На сьогоднішній день ІС середніх і великих підприємств в більшості випадків на практиці реалізуються на основі персональних комп'ютерів, об'єднаних у локальні обчислювальні мережі. Досить часто у користувачів персональних комп' ютерів таких ІС виникають різні прикладні задачі, які можуть успішно розв'язуватися різними прикладними програмними засобами. При цьому для найефективнішого розв'язання тих чи інших задач на персональних комп'ютерах робочих місць відповідних користувачів можуть встановлюватися різні типи операційних систем. Серед операційних систем, що встановлюються на персональні комп'ютери, найширшого використання набули операційні системи сімейства Microsoft Windows та сімейства Unix/Linux.

Після встановлення відповідних операційних систем на окремі персональні комп'ютери, які з'єднані між собою засобами локальної обчислювальної мережі, виникають задачі реалізації їх узгодженої роботи для взаємного обміну інформацією. Розв'язання таких задач є досить складною проблемою, особливо коли на окремих персональних комп'ютерах локальної обчислювальної мережі встановлені різнотипні операційні системи, тобто локальні обчислювальні мережі мають гетерогенну архітектуру.

Приклад фрагменту локальної обчислювальної мережі гетерогенної архітектури наведений на рис.10.6.

Рис.10.6. Фрагмент структури локальної обчислювальної мережі гетерогенної архітектури: 1 - персональний комп'ютер з операційною системою сімейства MS Windows; 2 - персональний комп'ютер з встановленою операційною системою сімейства Linux.

На практиці реалізація взаємодії персональних комп'ютерів у мережах, що містять фрагменти гетерогенної архітектури (рис.10.6), може здійснюватись за допомогою спеціального програмного забезпечення.

На сьогодні широкого використання набув програмний пакет Samba для операційних систем Linux, призначений для клієнтів мережі Microsoft Windows. Цей програмний пакет надає можливості персональному комп'ютеру з встановленою операційною системою Linux виконувати функції файл-сервера та принт-сервера у мережі Microsoft Windows. Крім цього, спеціальне програмне забезпечення - Samba-клієнт для операційної системи Linux - надає можливості персональному комп'ютеру (Linux-клієнту) підключатись до ресурсів, що надаються серверами мережі Microsoft Windows.

Відповідна об'єднана структура взаємодії персональних комп'ютерів у локальній обчислювальній мережі володіє низкою переваг:

1) оскільки в цілому операційна система Linux є більш стійкою за операційну систему MS Windows, підвищується надійність функціонування інформаційної управляючої системи загалом;

2) зменшуються витрати на придбання і використання ліцензійного програмного забезпечення для роботи під управлінням ОС MS Windows за рахунок використання програмного забезпечення для роботи під управлінням Linux, більшість з якого поширюється з ліцензією на вільне використання;

3) виникає можливість раціонального навантаження додатковими задачами Linux-сервера;

4) сервер Samba має можливість моніторингу і віддаленого управління персональними комп'ютерами у локальній обчислювальній мережі з використанням різних засобів протоколу SSH та з допомогою програмного пакету SWAT.

Як правило, встановлення програмного забезпечення сервера Samba не становить складної проблеми і здійснюється відповідними засобами операційної системи Linux, як і для інших типів програмного забезпечення. Найскладнішою задачею при налаштуванні роботи сервера Samba є створення чи редагування файлу конфігурації smb.conf. За структурою даний файл подібний до ini-файлів операційної системи Microsoft Windows.

Створення і редагування файлу конфігурації потребує спеціальної підготовки і високої кваліфікації спеціаліста, ознайомлення з відповідною технічною документацією. Для полегшення цієї роботи разом з програмним пакетом Samba постачаються приклади конфігураційних файлів, які знаходяться у каталозі /examples. Для більшості випадків їх можна використовувати як основу.

Практична реалізація взаємодії персональних комп'ютерів у локальній обчислювальній мережі гетерогенної архітектури потребує також розв'язання задач інформаційної безпеки. При використанні у структурі локальної обчислювальної мережі фрагментів архітектури, представлених на рис.10.6, задачі інформаційної безпеки можуть успішно розв'язуватись засобами програмного пакету Samba. Сервер Samba передбачає використання декількох типів безпеки. Так, спеціальна змінна encrypt password визначає, який механізм авторизації користувача буде використовуватись. У випадку, коли змінній encrypt password присвоєне значення no, авторизація користувачів проводиться, виходячи з їх облікових записів, які зберігаються у файлах /etc/passwd та /etc/shadow. При такому способі авторизації користувача паролі передаються засобами мережі у незакодованому вигляді. Це дещо спрощує процес настройки, однак сильно знижує безпеку системи в цілому. На додачу до цього, такий тип авторизації вимагає у ОС MS Windows додаткових змін у системному реєстрі. У випадку, коли змінній encrypt password присвоєне значення yes, авторизація користувача здійснюється з використанням файлу /etc/samba/ smbpasswd і передача паролів відбувається у закодованому вигляді.

Для зберігання паролів в операційних системах MS Windows та Linux використовуються різні методи: в MS Windows зберігаються закодовані паролі і при аутентифікації користувача здійснюється порівняння паролів.

В операційних системах Linux пароль, як такий, не зберігається, а у файлі shadow зберігається так званий хеш пароля, або, як в останніх версіях Linux - контрольна сума пароля, яка обчислюється за спеціальним алгоритмом. При аутентифікації користувача порівнюються хеш-образи паролів. Особливістю хеш-образу пароля є його незворотність, тобто знаючи хеш-образ неможливо за ним відновити пароль. Тому для ефективної роботи Samba необхідно створювати окрему базу паролів користувачів, і таким способом розв'язувати дану проблему. Для додавання нового користувача Samba у файл /etc/ samba/smbpasswd повинен існувати відповідний обліковий запис користувача і потрібно використати спеціальну програму smbpasswd.

Далі, для монтування ресурсів, що надаються сервером Samba, використовуються команди smbclient та smbmount.

Для програмного пакету Samba також розроблені і використовуються багато різних спеціальних програмних утиліт, які уможливлюють спростити конфігурування системи і здійснити розподіл доступу до ресурсів й тим самим значно полегшують роботу як звичайного користувача системи, так і системного адміністратора, а саме:

o утиліта для моніторингу Samba smbstatus;

o програма конфігурування Samba через Web-інтерфейс SWAT;

o програма управління паролями Samba smbpasswd;

o програма перевірки конфігураційного файла testparm;

o програма перевірки конфігурації принтера testprns;

o клієнт командного рядка smbclient та ін.

Використання програмних утиліт з пакету програмного забезпечення Samba разом з іншими сервісними програмами, що працюють під управлінням ОС Linux надає можливості користувачу найбільш ефективно управляти роботою інформаційної системи під управлінням ОС Linux.

Таким чином, шляхом застосування програмного пакету Samba може бути забезпечена практична реалізація взаємодії персональних комп'ютерів у локальній обчислювальній мережі гетерогенної архітектури.

Використання програмного пакету Samba надає можливості гнучкого й оперативного конфігурування гетерогенної мережі, що поєднує використання персональних комп'ютерів з встановленими операційними системами сімейств MS Windows - Linux.

На практиці досліджено, що метод реалізації взаємодії персональних комп'ютерів з різними операційними системами сімейств MS Windows - Linux, який ґрунтується на використанні програмного пакету Samba, забезпечує ефективний, швидкий, надійний і безпечний обмін інформацією між персональними комп'ютерами у локальній обчислювальній мережі.