безпечення допускає додавання нових модулів з новими функціональними властивостями.
3.3 Інтеграція різнотипного вимірювального обладнання
Проблемою, що перешкоджає створенню масштабної територіально-розподіленої автоматизованої системи радіоконтролю, є використання радіочастотної службою радіовимірювального обладнання різних виробників, яке не тільки відрізняється за своїми технічними і метрологічними характеристиками, але і має різні протоколи управління. Програмне забезпечення, що постачається виробником апаратури, як правило, дозволяє вирішувати завдання радіоконтролю стосовно тільки до «свого» виду обладнання. У той же час в радіочастотних службах на даний момент є парк цілком працездатних приладів, придбаних у різних виробників і, отже, необхідна інтеграція різнотипних засобів вимірювань у структурі автоматизованої системи. Крім того, подібна інтеграція дає можливість використання сильних сторін тієї чи іншої апаратури, знижує небезпеку монополізму конкретного виробника.
Можливий варіант побудови системи з різнотипним обладнанням заснований на обміні даними між модулем програмного забезпечення - драйвером апаратури і рештою системи через БД РК. Завдання на вимірювання надходять в БД РК, драйвер апаратури повинен сканувати БД РК в очікуванні надходження нових завдань. Результати виконання поставлених завдань також зберігаються в БД РК. Таким чином, модуль драйвера апаратури працює безпосередньо з БД РК, при появі нового завдання він виконує необхідні для її вирішення дії з апаратурою, результати своєї роботи драйвер також заносить в БД РК.
На жаль, у запропонованого варіанту є кілька суттєвих недоліків:
кожен виробник драйвера апаратури зобов'язаний знати структуру БД РК. У базі даних повинні бути записи, призначені для обробки та зберігання даних, отриманих від певної апаратури. Використання апаратури нових виробників викличе появу додаткових проміжних таблиць, структура БД ускладнюватиметься;
- при будь-якій зміні структури БД, наприклад при появі нових типових завдань радіомоніторингу, буде потрібно звернення до виробника драйвера апаратури для внесення змін в код драйвера, що може бути не завжди можливим;
надання інформації про структуру БД стороннім організаціям не завжди бажано;
обмін даними з апаратурою проводиться через БД, що неминуче знижує продуктивність системи, і реалізувати такі можливості, як спостереження спектра сигналу в реальному часі, стає зовсім проблематичним.
Більш перспективний підхід заснований на поділі процесів роботи з апаратурою і з БД РК. Роботою апаратури і раніше безпосередньо управляє драйвер апаратури, але роботу з БД здійснює інше програмне забезпечення - модуль транслятора завдань. При цьому, враховуючи територіально розподілений характер системи, транслятор задач передає запити в драйвер апаратури і отримує результати вимірювання з мережевого протоколу.
У цьому випадку виробник драйвера апаратури зобов'язаний забезпечити роботу свого модуля по даному протоколу, який не прив'язаний безпосередньо до структури БД, а залежить тільки від вимірювальних завдань. По суті, драйвер апаратури в цьому випадку тільки лише виконує роль конвертора команд, що перекладає запити транслятора задач у внутрішні команд...
