4.12. Побудова цифрових рель’єфно-батиметричних моделей

Розосереджені та однорангові мережі, побудовані на основі мережі Інтернет як транспортної інфраструктури, можуть знайти ефективне застосування в інших прикладних реалізаціях ІТ, зокрема в групі задач глобального екологічного моніторингу, для яких одним з важливих аспектів є низка технологій вимірювання та побудови цифрових рель’єфно-батиметричних моделей (ЦРБМ).

ЦРБМ — двомірний масив даних щодо висоти над рівнем моря та глибини, що являє собою розгортку поверхні планети у вигляді проекції Меркатора. На сьогоднішній день ЦРБМ поверхні Землі широко використовуються в геоінформаційних системах, системах навігації, задачах попередження та прогнозування лавин та селів, гравіметрії, побудови карт покриття мобільних операторів тощо.

Джерелами даних для побудови ЦРБМ є безпосередня топографічна та геодезична зйомка на місцевості, аерофотозйомка та радарне сканування земної поверхні з орбітальних супутників та станцій. Зокрема, мова йде про так звану «Радарно-топографічну місію» (SRTM — Shuttle Radar Topography Mission), протягом якої спеціально встановлений у вантажному відсіку шатлу «Endeavour» геодезичний радар з синтезованою апертурою проводив безпосередні вимірювання рельєфу.

Просторова роздільна здатність сучасних ЦРБМ найбільшого розрізнення становить до 30 кутових секунд для рельєфних даних та до 2 кутових хвилин для даних батиметрії. В той час як локальні ЦРБМ регіонального характеру можуть бути досить точними, оскільки не завжди отримуються шляхом прямих вимірювань з космосу, глобальні ЦРБМ для всієї земної поверхні страждають від похибок, пов’язаних з дискретизацією та квантуванням, накладенням даних від різних джерел, відхиленнями скануючого променю від нормалі до земної поверхні тощо.

На даний момент провадяться дослідження з метою отримання глобальної ЦРБМ з просторовим розрізненням до 10 метрів шляхом застосування прецизійних гравіметричних засобів. Існуючі локальні моделі такого розрізнення, як правило, побудовані на замовлення військових установ і є інформацією з обмеженим доступом.

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

Типове рішення задачі вдосконалення технологій побудови деталізованої ЦРБМ поверхні Землі з використанням даних SRTM залежить від конструктивних особливостей апаратури екологічного моніторингу та умов навколишнього середовища, але в цілому рішення можна віднести до одного з двох типів. Перший тип — повністю автономна інформаційно-замкнена система з періодичним видобуванням накопичених даних за допомогою операторів. Другий тип — централізована система, яка включає центральний сервер обробки даних, розмішений в головній організації з усією необхідною комунікаційною інфраструктурою та територіально розосереджена мережа віддалених датчиків з передавачами, кожен з яких має можливість з’єднання з центральним сервером.

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

Ми вважаємо, що традиційні підходи до проектування комп’ютерних мереж впливають на архітектурні рішення таких систем екологічного моніторингу. Під традиційними підходами ми розуміємо, зокрема, клієнт-серверну парадигму взаємодії вузлів мережі, яка домінувала в комп’ютерних мережах від самої їх появи і до початку XXI сторіччя.

В альтернативі-пропонується застосування архітектурних принципів побудови однорангових мереж для проектування комунікаційних структур та протоколів в задачах територіально розосередженого екологічного моніторингу.

Шляхом математичного моделювання було вибрано ділянку земної кори розміром приблизно 10×10 кілометрів з центром на південному узбережжі Кримського півострову — 4426’ північної широти, 3404’ східної довготи. Вибір даної місцевості зумовлений міркуваннями наочності, оскільки дана ділянка поєднує як поверхню Чорного моря, яка задовільно відповідає нульовому рівню стандартного геоїда міжнародної моделі WGS84, так і вміщує вершину гори Ай-Петрі (1234 м) з відповідними варіаціями схилів.

Деталізація рельєфної моделі проводилася шляхом сплайн-інтерполяції ділянок. З огляду на низьку обчислювальну складність було обрано алгоритм сплайну Катмулла-Рома, який побудований на основі кубічних Ермітових сплайнів:

де V₀,V₁— значення інтерпольованої функції в точках, які обмежують безпосередній відрізок інтерполяції, що обчислюється,

R— значення сплайну в точціX_posна відрізку (V₀,V₁),

V_p, V_s— значення інтерпольованої функції в точках, які передують і слідують за відрізком (V₀,V₁).

Реалізація програмного забезпечення для виконання інтерполяції із залученням суперкомп’ютерного кластеру НТУУ «КПІ» полягає в тому, що на першому етапі обчислюються (деталізуються) перерізи, які паралельні одній з координатних осей та включають в себе контрольні точки відповідної широти.

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

На другому етапі по отриманим деталізованим перерізам будуються всі перерізи, що паралельні осі довготи, оскільки контрольні точки для кожного такого перерізу вже були обчислені в попередньому етапі (рис.4.17).

Рисунок 4.17. Схема етапів обчислення деталізованого рельєфу

Зрозуміло, що завдяки сферичності Землі на крайніх перерізах масиву потрібно враховувати дані з протилежного краю. В той час як для крайніх південного та північного перерізу це не потрібно (оскільки наступні «перерізи» є, відповідно, точками Південного та Північного полюсу), для крайніх східних та західних перерізів (180-й меридіан) протилежний переріз підставляється в обчислення як наступний.

Окрему увагу було приділено питанню черговості обчислення ключових перерізів. Із залученням суперкомп’ютерного кластеру НТУУ «КПІ» була двічі виконана сплайн-інтерполяція однієї і тієї ж ділянки поверхні — коли в першу чергу обчислювались перерізи довготи, і коли в першу чергу обчислювались перерізи широти. Було встановлено, що дані деталізованого рельєфу, отримані по попередньо обчисленим перерізам довготи відрізняються від даних деталізованого рельєфу, отриманим по попередньо обчисленим перерізам широти несуттєво — різниця склала менше одиниці дискретизації вхідних даних (1 метр). Деталізований рельєф показано на рис.4.18.

Рисунок 4.18. Візуалізація вихідних даних рельєфної моделі (розмір ділянок складає 100×100 метрів).

При порівнянні результатів для уточненої моделі рельєфу, отриманих шляхом сплайн-інтерполяції, з даними реальної топографічно-геодезичної зйомки згідно з інформацією, наданою НДІ геодезії та картографії (рис.4.19), видно, що отримані результати цілком задовільно відповідають реальним, з поправкою на рельєфні деталі, що мають характерні розміри менші за дискретність вхідних даних SRTM. Отже, інтерполяція рельєфно-батиметричних даних дає можливість уникнути похибок, пов’язаних з дискретним характером та недостатньою роздільною здатністю вхідних значень. А це, в свою чергу, дозволяє суттєво зменшити кількість задіяної апаратури та персоналу для виконання топографічних зйомок ЦРБМ завдяки використанню розроблених в даній роботі методів підвищення ефективності однорангових мереж.

Рисунок 4.19. Топогеодезична структура місцевості за даними НДІ геодезії та картографії у вигляді ізоліній висоти (товсті лінії — 100 метрів, тонкі — 20 метрів)

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

В широкому класі задач екологічного моніторингу, пов’язаних зі збиранням, обробкою та передаванням великих масивів даних, доцільне одночасне застосування телевізійних інформаційно-вимірювальних систем (ТІВС) та технологій розосереджених мереж, оскільки ефективність вирішення будь-якої задачі екологічного моніторингу залежить від характеристик як вимірювальної апаратури так і апаратно-програмних засобів.

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

За допомогою ТІВС інформація про структуру, стан та властивості об’єктів різної природи, яка міститься в їх випроміненні, перетворюється в зображення, тобто формується функція розподілу освітленності в чутливій площині. При цьому зображення може існувати фізично у вигляді розподілу освітленості, отриманої вибіркою відліків з прив’язкою до координат ПЗЗ-матриці, у вигляді сукупності електричних сигналів чи віртуально у вигляді матриці цифрових кодів. Значення відліків характеризують освітленість піксела, а їх координати визначають геометричні характеристики зображення.

Загальна методика застосування ТІВС полягає в формуванні зображення, перетворенні його в цифровий код та у використанні програмних алгоритмів , які забезпечують необхідну точність вимірювання, надаючи унікальну можливість провадити вимірювання геометричних, динамічних та енергетичних параметрів об'єктів в реальному масштабі часу з високим просторовим розрізненням шляхом аналізу як власного випромінення, так і того, що відбилося або пройшло через об’єкт .

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

При створенні програмно-алгоритмічного забезпечення ТІВС найбільш критичними є питання про вибір режимів роботи процесора, рівня мов програмування та підходів до проектування програмного забезпечення.

Коли при розробці ПЗ ТІВС потрібно оперувати з нестандартними зовнішніми пристроями за допомогою портів вводу-виводу або коли вирішувана задача ставить вимоги до швидкості виконання операцій, тобто потрібна якнайбільша монополізація обчислювальних ресурсів процесора, то в такому випадку слід перенести найбільш критичні до часу виконання операції в привілейований режим, або режим ядра (kernel mode). В тому числі це відноситься до необхідності розробки спеціальних драйверів для сучасних багатозадачних ОС.

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

Сценарні мови програмування (scripting languages) є вузькоспеціалізованими, проте, при розробці ПЗ ТІВС їх можна застосувати, наприклад, для керування зовнішніми пристроями або для автоматизації виконання заданих послідовностей операцій.

Також при розробці програмного забезпечення ТІВС, що планується до використання на неспеціалізованих комп’ютерах, слід врахувати широку уживаність ОС Microsoft Windows або GNU/Linux, які у своєму складі містять досить розвинуті і потужні, а головне — стандартизовані бібліотеки інтерфейсу Windows GUI та QT/GTK відповідно.

Серед найбільше популярних на сьогодні клієнтів мережі BitTorrent виділяються дві раніше згаданих розробки —muTorrent та Vuze. Хоча множина клієнтів BitTorrent налічує кілька десятків програмних продуктів, вони або не надають можливості створювати користувацькі розширення, або є застарілими проектами, розробку яких припинено.

MuTorrent пропонує можливості безпечного розширення функціональності за допомогою так званого BTAPPS API. BTAPPS представляє собою множину вбудованих в muTorrent об’єктів для сценарної мови програмування JScript та інтерфейс до системного інтерпретатора JScript. Такий підхід дозволив авторам muTorrent з міркувань сумісності та безпеки не створювати та не інтегрувати з muTorrent власний інтерпретатор. Це дає можливість, по-перше, підтримувати сумісність з броузером Microsoft Internet Explorer, який рекомендовано використовувати для відлагодження проектів BTAPPS, а, по-друге, мати перевагу завдяки автоматичним оновленням системи безпеки ОС Windows, які стосуються підсистеми JScript.

Для створення розширень за допомогою BTAPPS з офіційного сайта muTorrent можна завантажити пакет розробника, який включає інтерпретатор Python, HTTP-сервер та прикладні бібліотеки для JScript, в тому числі JSON та AJAX.

Клієнт Vuze для мереж BitTorrent (попередня назва проекту — Azureus) написаний на мові програмування Java, завдяки чому Vuze є кросплатформним програмним забезпеченням. Також в Vuze реалізовано plugin-архітектуру, таким чином розробники програмного забезпечення мають змогу розширювати функціональність базового клієнта Vuze для реалізації власних обчислень або графічних надбудов. Очевидно, розширення також є кросплатформними, так як написані теж на мові Java.

Для створення розширень Vuze підійде будь-яке середовище розробки для мови програмування Java, наприклад пакет програм Eclipse з інтегрованим редактором та компілятором Java.

З точки зору задачі підвищення ефективності СООМ вибір між вищенаведеними двома варіантами має бути продиктований, по-перше, міркуваннями так званої «кривої навчання» (від англ. learning curve). В даному випадку це поняття позначає кількість часу, який потрібен середньому спеціалісту з розробки програмного забезпечення, для освоєння запропонованої мови програмування з інструментарієм розробки та реалізації поставленої задачі з їх допомогою. Крива навчання вважається крутішою, коли витрати часу для вирішення тієї самої задачі менші у порівнянні з альтернативними засобами.

По-друге, необхідно оцінити принципову можливість вирішення поставленої задачі засобами, що пропонує plugin-архітектура двох вищенаведених клієнтів мережі BitTorrent. Для безпосередньої маніпуляції списком вузлів необхідно, щоб інтерфейс розширень або дозволяв встановлювати черговість опитування після того як список отримано від сервера та іншого джерела (DHT, PEX) або, принаймні, дозволяв вибірково блокувати обмін даними з вузлами заданих класів локальності.

В результаті аналізу засобів розробки розширень для вищенаведених клієнтів мережі BitTorrent у вказаних аспектах було виявлено, що:

- Крива навчання при використанні BTAPPS крутіша, ніж для випадку Java за рахунок: а) інтеграції засобів розробки, відлагодження та публікації в єдиному пакеті BTAPPS порівняно невеликого об’єму, на відміну від низки засобів (Eclipse, JDK, Vuze PluginAPI тощо) різних виробників, з численними індивідуальними налаштуваннями; б) простішого, хоча і спорідненого, синтаксису мови JScript у порівнянні з повноцінною мовою Java;

- Жодний з проаналізованих інтерфейсів розширень не дає можливості прямої маніпуляції порядком опитування: а) в об’єктах ієрархії BTAPPS навіть з найвищим рівнем доступу розширення передбачено лише отримання списку вузлів рою, зміна будь-яких їх властивостей, включаючи вибіркове припинення зв’язку, наразі не реалізоване; б) в класах PluginAPI Vuze передбачена функція removePeer() для видалення вузлів рою з поточного завантаження, проте вона діє лише на вузли, що додані через той самий інтерфейс за допомогою функції addPeer(), будь-які інші засоби маніпуляції чергою також відсутні.

Нами запропоновано трьох-компонентну структуру програмного забезпечення для підвищення ефективності СООМ.

• Компонент, що реалізує CARMA та алгоритм визначення БМПЛ; даний компонент є службою, яка постійно виконується з періодичним поновленням вихідних даних для СМ НСМІ, і яка реалізована на відповідній кодовій базі алгоритмів та програмного забезпечення;

• Компонент, який відповідає за встановлення та зняття вибіркової фільтрації пакетів даних на основі наданих IPv4 адрес віддалених вузлів; практична реалізація компоненту здійснена в ОС Windows за допомогою IP Helper API та спеціального інтерфейсу IP Filter Driver, що є частиною підсистеми NDIS ОС Windows;

• Компонент, реалізований як надбудова до muTorrent через інтерфейси BTAPPS, яка звертається до перших двох компонент для формування та виконання пріоритетного опитування;

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