CC BY
106
КОМПЬЮТЕРНЫЕ НАУКИ А
УДК004.7
МЕТОД АНАЛІЗУ ТА ПІДВИЩЕННЯ ЕФЕКТИВНОСТІ РОБОТИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ БАЗОВИХ СТАНЦІЙ СТАНДАРТУ LTE
ГЛОБА Л.С. , ЛИСЕНКО Д.С. , АЛЄКСЄЄВ М.О.
Пропонується метод підвищення ефективності функціонування програмного забезпечення базових станцій стандарту LTE на фізичному рівні, який за допомогою модифікованої діаграми потоків даних IDEF0/IDEF1 з розширеним набором параметрів опису процесу виконання завдань, удосконалення комплексу методів аналізу, тестування та оптимізації використання апаратних ресурсів дозволяє скоротити час розробки, знизити вартість проектування програмного забезпечення та задовольнити вимоги стандарту функціонування базових станцій стандарту LTE.
1. Вступ
Активний розвиток електронних засобів комунікації вимагає постійного створення нових систем і відновлення вже існуючих для відповідності до стандартів, що швидко змінюються. У зв’язку з тим, що стандарт LTE є новим, на даний час ще не існує засобів розробки, які б дозволяли автоматизувати всі етапи процесу створення програмного забезпечення. Приріст продуктивності при збільшенні кількості обчислювальних ресурсів для складної обчислювальної системи, якою є базова станція стандарту LTE, неможливо отримати без модифікації існуючих методів побудови розкладів виконання паралельних алгоритмів. Метою роботи є створення математичного забезпечення і програмного інструментарію на його основі для проектування прикладних програм базових станцій стандарту LTE, що дозволить підвищити ефективність їх функціонування, раціонально використовувати наявні апаратні ресурси, а також задовольнити вимоги стандарту LTE.
Необхідно вирішити такі задачі: 1) удосконалити формалізований опис процесу функціонування програмного забезпечення базових станцій стандарту LTE; 2) запропонувати методи аналізу та оцінки ефективності процесу функціонування програмного забезпечення базових станцій стандарту LTE; 3) реалізувати запропоновані методи у програмному інструментарію для відладки, налагодження та тестування програмного забезпечення базових станцій стандарту LTE.
2. Модель функціонування програмного забезпечення базових станцій стандарту LTE
В роботах [ 1 -3 ] запропонований підхід до проектування програмного забезпечення, що ґрунтується на розбивці системи на модулі, які мають стандартний інтерфейс взаємодії, що дозволяє працювати з ними надалі як з однотипними об ’ єктами й значно спрощує процес розробки й тестування. Згідно з розробленим підходом робота системи поділяється на логічно завершені етапи, які надалі називаються завданнями.
Специфікою процесу функціонування програмного забезпечення базових станцій стандарту LTE є :
- процес роботи включає велику кількість математичних розрахунків, що виконуються у реальному часі з мінімальним втручанням з боку користувача;
- обробка даних являє собою дискретний процес, поділений на етапи обробки фреймів даних;
- час, відведений для обробки одного фрейму, є сталим та задається вимогами стандарту;
- в межах обробки одного фрейму набір процедур для обробки даних та їх послідовність має сталий характер;
- час, для кожної процедури обробки даних є сталим та відомий заздалегідь.
- в межах обробки одного фрейму відносини передування завдань є сталими та відомі заздалегідь;
Введемо деякі позначення: множину завдань позначимо як W = {®і,®2,...,юп}, множину об’єктів - виконавців позначимо R = {Ro,Ri,...,Ri}. Система може бути побудована таким чином, що для деяких завдань як вхідні дані можуть виступати вихідні дані інших завдань. Тому задамо у множині W для кожного з завдань ®є W деяку множину P її попередників, причому для деяких завдань P = 0 .
Кожне із завдань у свою чергу може складатися з набору інших завдань, таким чином дозволяючи описати роботу системи на деяких рівнях її функціонування. Сценарій оброблювання таких завдань буде являти собою один з інструментів інтеграції програмних компонентів у єдину систему, який і відтворює опис на структурному рівні процесу обробки радіосигналу.
Набір завдань та дані для обробки радіосигналу складають прототип обчислювальної системи (рис.1).
Керування
прототипом
Початок виконання завдання.
Дані для обробки
Завершення виконання завдання. Результати обробки
Завдання
Рис. 1. Взаємодія завдань
72
РИ, 2012, № 3
Блок керування прототипом містить у собі:
- базу даних завдань;
- компоненти, які виконують обробку завдання;
- консоль керування прототипом (або керування виконанням сценаріїв процесів обчислень).
База даних завдань містить у собі:
- унікальні ідентифікатори завдань;
- ідентифікатори, що визначають взаємозв’язки між завданнями;
- спосіб виконання завдання для визначення, наприклад, рівня емуляції, що використовується при функціонуванні системи (визначається - виконується завдання на реальному обладнанні чи використовується програмна емуляція).
Математичне визначення завдання у вигляді відображення однієї множини в іншу, при якім одному значенню аргументу може відповідати тільки одне значення функції, у цьому випадку не підходить. Необхідним є представлення завдання у вигляді абстракції, як описом якої виступають вимоги до процесу обробки даних. Наприклад: «Завдання f1 отримує на вході ідентифікаційний код, результатом його виконання є інформація щодо способу обробки даних», тому можна зробити визначення:
Завдання - це набір операцій, що виконуються об ’ єктом-виконавцем на підставі вхідних параметрів, результатом виконання якого є набір вихідних параметрів.
Фізично завдання представляється у вигляді програмного коду. Кожне з них характеризується своїм набором робочих параметрів, які у свою чергу поділяються на вхідні, внутрішні й вихідні, інтерфейси доступу. Визначимо ці поняття:
Вхідні - це параметри, передані об’єкту-виконавцеві перед виконанням завдання.
Вихідні - це параметри, отримані об’єктом-виконав-цем як результат виконання завдання.
Внутрішні - це параметри, використовувані об ’ єктом-виконавцем у процесі виконання завдання.
Інтерфейс доступу - це правило обробки завдання, що фіксує поданий набір вхідних і одержуваний набір вихідних параметрів.
Інтерфейс доступу являє собою сукупність точок активності, які можна й потрібно розділити на точки входу й виходу. Це необхідно зробити з таких міркувань. Розглянемо приклади: 1) завдання передає вихідні параметри потоку, відмінному від того, в якому виконання розпочалося; у цьому випадку перший потік завершується (або припиняє свою роботу), передача даних виконується перед завершенням роботи; 2) завдання являє собою побудову набору даних для обробки, які передаються іншому об’єкту-виконав-цю, що стає активним. Т аким чином, точка входу - це
правило обробки завдання, що фіксує набір його вхідних параметрів.
Точка виходу - це фіксований набір вихідних параметрів завдання. Інтерфейс доступу - це пари (точка входу, точка виходу).
Отримана модель завдання графічно представлена на рис. 2.
Зображену на рис. 2 графічну нотацію структурної моделі завдання покладено в основу модифікації стандартів IDEF0 з метою використання розширеного опису завдання при відображенні:
- послідовності виконання завдань;
- залежності між завданнями;
- елементів опису мультипотокового функціонування.
Рис. 2. Структурна модель завдання
З метою урахування специфіки роботи програмного забезпечення базових станцій стандарту LTE спрощено діаграму функціонування за рахунок невикористання правила однакового направлення стрілок та параметрів управління й механізму, оскільки ця інформація не впливає на планування процесу обчислень при обробці сигналів базовою станцією стандарту LTE.
Математично структурна модель завдання представляється в такий спосіб:
Ei = f(Ej,Rn,P(0),
де Ei - множина вихідних параметрів {уі,У2,—,Ут} точки активності за номером і, причому уі є Y -області припустимих значень вхідних параметрів; Ej - множина вхідних параметрів {xi,x2,...,xk} точки активності за номером j, причому xj є X - області припустимих значень вихідних параметрів; Rn є{Ro,Ri,...,Ri} - об’єкт-виконавець;
Рю = {Рі,Р2,...,pn}, pm є W- множина попередників завдання ю , що виконується; W = {юі,®2,...,юп} -множина завдань.
РИ, 2012, № 3
73
Завдання систематизуються відповідно до їх логічної належності до будь-якого більш складного завдання, яке назвемо модульним. Поєднуючи такі завдання в порядку звертання до них у модульні, будуємо так зване дерево завдань (рис.3). Об’єднання завдань у модулі дозволяє знизити складність системи, спростити її подальший супровід та тестування.
Опис логіки функціонування системи дозволяє на самих ранніх етапах її проектування побудувати певну послідовність можливих переходів між завданнями в системі, яку назвемо прототипом функціонування інформаційної системи.
Рис. 3. Поєднання групи завдань у модуль
Такий прототип можна подати у вигляді графа (рис.
4), що являє собою дерево завдань для одного обчислювального процесу в системі або ліс завдань для множини обчислювальних процесів складної системи. При побудові дерева завдань на базі сценарію виконання певного обчислювального процесу вершини ідентифікуються з завданнями, а переходи між завданнями представляються дугами, які ідентифікують імена завдань, що необхідно виконувати. Таким чином, переходи між завданнями визначаються внутрішньою логікою функціонування системи й описуються в термінах завдань, а граф можна позначити як G = (Sn,Sa), де Sn = {n;,i = 1..N} - множина вузлів, які представляють завдання, та
Sa = {(ni,nj)|ni ^ nj} - скінченна множина дуг, що є відносинами передування завдань.
Прототипування системи спрощує процес уточнення постановки задачі проектування обчислювальної системи, дозволяє уточнити всі її інтерфейси з замовником, без написання великого обсягу програмного коду. Для цього використовується модифікована діаграма стандарту IDEF0, на основі якої можливо проаналізувати обчислювальний процес і визначити параметри його функціонування.
Оскільки базова станція одночасно може обслуговувати декілька користувачів у певний момент часу, процес обчислень може бути поділений на декілька незалежних потоків завдань, які відповідають за обслуговування окремого користувача, тобто потоки завдань є незалежними. Обробка кожного потоку завдань може бути поділена на фрейми (порції вхідних даних), послідовність виконання завдань для обробки яких є залежною. Обробка даних поточного фрейму залежить від закінчення процесу обробки даних попереднього фрейму. Обробка даних у межах одного
фрейму може виконуватись паралельно. Прикладом такої обробки є розділення виконання перетворення Фур’є для великої частини сигналу на декілька невеликих завдань, які можливо виконати паралельно. Таким чином, обробку фрейму можна графічно описати у вигляді діаграми, представленої на рис. 4, де вершини ідентифікують собою конкретні завдання, а ребра, відносини передування завдань.
При функціонуванні базова станція виконує обробку цифрового сигналу для кожного з абонентів, залежно від кількості підключених антен. При цьому графи для кожного з обчислювальних процесів (обслуговування абонента, формування сигналу для антени та інші) утворюють дерево конкретного обчислювального процесу, а для системи в цілому - ліс обчислювальних процесів, який являє собою модель обчислювального процесу обробки цифрового сигналу базової станції стандарту LTE.
Рис. 4. Граф обчислюваного процесу обробки одного фрейму
Складання розкладу виконання усіх завдань, що входять у ліс обчислювальних процесів, який би ефективно використовував усі наявні апаратні ресурси, є важливою умовою ефективного функціонування базової станції в цілому.
3. Метод підвищення ефективності функціонування базових станцій стандарту LTE
Метод підвищення ефективності функціонування базових станцій стандарту LTE, що пропонується у роботі, включає п’ять етапів. На першому етапі отримуються дані про параметри функціонування програмного забезпечення. Вони можуть бути введені вручну, якщо програмне забезпечення ще не створене або дані отримані у ході протоколювання його роботи. На другому етапі створюється математична модель програмного забезпечення, що розробляється у вигляді діаграми функціонування (див. п. 1). На третьому етапі створена діаграма функціонування аналізується, що дозволяє виявити помилки проектування та сформувати рекомендації щодо підвищення ефективності роботи програмного забезпечення. На четвертому етапі в процес функціонування програмного забезпечення вносяться необхідні зміни та вибирається спосіб оцінки їх ефективності. Це може бути повторний запуск зміненого програмного забезпечення на реальній системі або використання повної чи часткової ему-ляції. При цьому створена діаграма функціонування програмного забезпечення виступає у ролі шаблону, що спрощує процес написання коду завдяки можли-
74
РИ, 2012, № 3
вості використання різних рівнів емуляції та постійному накопиченню бази тестових векторів.
Структурну схему розробленого методу підвищення ефективності функціонування базових станцій стандарту LTE наведено на рис. 5.
3.1.Аналіз діаграми функціонування програмного забезпечення базової станції стандарту LTE
Складність розробки й наступного супроводження програмного забезпечення базових станцій стандарту L TE спричиняє необхідність розробки методів і інструментарію, що спрощують цей процес. Ключовим моментом пропонованої методології є створення діаграми функціонування програмного забезпечення. Це дозволяє здійснити раннє прототипування й виявити недоліки системи, що розробляється на ранніх етапах проектування. Наступне використання отриманої
діаграми дозволяє реалізувати ефективне тестування, що спрощує внесення змін і пошук помилок не тільки у програмному а, й у апаратному забезпеченні. Такий підхід до створення прототипу системи знижує матеріальні витрати й прискорює процес розробки системи.
У ході роботи були сформовані принципи побудови діаграми функціонування програмного забезпечення, що дозволяють описати широке коло систем. Запропонована методологія передбачає розбивку системи, що проектується, на окремі блоки з описаним форматом даних на вході й виході кожного блоку. Надалі будується діаграма зв’язків, що описує взаємодію між блоками.
Створена діаграма функціонування програмного забезпечення може бути використана на декількох етапах розробки системи. Розроблений алгоритм представлення діаграми функціонування у вигляді кінце-
Рис. 5. Структурна схема методу підвищення ефективності функціонування базових станцій стандарту LTE
Діаграма функціонування Кінцевий автомат
забезпечення базової станції стандарту LTE
РИ, 2012, № 3
75
вого автомата дозволяє провести аналіз топології системи програмного забезпечення, що розробляється (рис. 6) з використанням теорії графів:
- проаналізувати досяжність завдань діаграми для перевірки працездатності системи із застосуванням таких підходів: обхід графа в глибину; обхід графа завширшки;
- зробити знаходження найкоротшого шляху між двома вузловими точками діаграми для оцінки часових характеристик і рівня завантаження системи, використовуючи: алгоритм Форда; алгоритм Дейкст-ри; алгоритм Беллмана-Форда, алгоритм Флойда -Уоршелла;
- застосувати алгоритми пошуку критичних шляхів і побудови шляхового покриття. Це може бути корисним у методах аналізу поведінки прототипу системи, що розробляється, а так само в методах оптимізації циклів при розпаралелюванні програм з використанням алгоритму пошуку найкоротшого шляху, методу мінімального потоку, методу найбільшого паросполу-чення;
- провести аналіз циклічної структури й перелік шляхів графа обчислювального процесу для оцінки часу виконання внутрішніх циклів у системі, оцінки частоти виконання різних типів завдань, виявлення ієрархії циклів. Намітити способи оптимізації системи, використовуючи алгоритм оцінки частоти на основі циклічних ділянок, алгоритми перелічення шляхів.
3.2. Урахування мультипотоковості при аналізі діаграми функціонування програмного забезпечення базової станції стандарту LTE
Використання досить потужних процесорів та достатньої кількості пам’яті як апаратного забезпечення при розробці базових станцій стандарту LTE дозволяє, в деяких випадках, виділити частину обчислювальних ресурсів для забезпечення функціонування операційної системи та використовувати при розробці програмного забезпечення таку високорівневу абстракцію, як потоки виконання обчислень. Це спрощує структуру коду, його відладку та дозволяє провести розробку за менший час та з меншою кількістю помилок. Для забезпечення опису мультипотоковості необхідно додати до опису діаграми функціонування такі елементи як початок і завершення потоку.
В деяких випадках важливим етапом функціонування є процес взаємодії з користувачем. Цей процес також може бути описаний в рамках діаграми функціонування шляхом додавання завдань, особливістю яких є те, що вони виконуються користувачем. Щоб відрізняти на діаграмі такі завдання, будемо позначати їх колом на відміну від інших, позначених трикутником (рис. 7).
Рис. 7. Позначення завдань залежно від типу виконавця
Починаючи виконання послідовності обчислень та користуючись даними діаграми функціонування від точки старту, «виконавче ядро» повинно створити початковий потік. Початок потоку позначений на діаграмі жирною стрілкою, як показано на рис.8.
Рис. 8. Точка старту й запуск першого потоку
Запуск додаткового потоку в процесі виконання послідовності обчислень діаграми показаний на рис.9. Після обробки завдання f у системі виникає ще один потік «2» і процес обчислень розпаралелюється.
1
*
Рис. 9. Запуск потоку
У процесі роботи системи виникають ситуації, що вимагають зупинки вже запущених потоків. Така операція на діаграмі позначена лінією, яка закінчується квадратом. Зупинка останнього запущеного потоку служить ознакою завершення виконання послідовності обчислень діаграми (рис.10).
В системі може бути запущено більш одного потоку, тому для визначення належності дуги графа до потоку використовується номер або ідентифікатор потоку, зазначений на стрілці, що з ’ єднує точку входу й точку виходу. Для посилення наочності використано також виділення кольором дуг графа, що належать одному потоку.
і
Рис. 10. Завершення потоку
Необхідно враховувати, що некоректна побудова діаграми може призвести до неоднозначностей у програванні, зациклення й виникнення інших станів, що робить неможливим подальшу інтерпретацію сценарію. У цьому випадку необхідно проаналізувати причини виникнення збою й забезпечити користувача рекомендаціями до його усунення. Т акий аналіз, у тому числі й до запуску виконання послідовності обчислень діаграми, повинен бути реалізов аний у складі «виконавчого ядра» і є його необхідною частиною.
Розглянемо процес інтерпретації «виконавчим ядром» діаграми, представленої на рис .11. Описана система
76
РИ, 2012, № 3
містить у собі чотири завдання, які виконує користувач, причому він має можливість послідовно переходити між завданнями F1, F2, F3, а також зупиняти процес переходу й повертатися до початкового стану до завдання F1 за допомогою завдання F4, яке використовується для навігації. Кожний процес переходу між завданнями супроводжується виконанням відповідного завдання. Два потоки, що використані в системі, позначені цифрами 1, 2.
Рис. 11. Фрагмент діаграми функціонування з використанням потоків даних
Почавши виконання послідовності обчислень зі стартової точки входу, позначеної зафарбованим кружком, і створивши початковий потік «1», «виконавче ядро» приступає до обробки завдання f0, у результаті чого створюється ще один потік «2». Кожний з потоків, що виконується паралельно, викликає відображення відповідного інтерфейсу користувача. У результаті на екрані користувача відтворюються два завдання F4 і F1, і користувач має до них доступ одночасно. Потрапляючи у завдання, яке потребує втручання користувача, потік зупиняється, очікуючи від користувача здійснення вибору або введення даних.
Таким чином, у кожному потоці в певний момент часу існує одне активне завдання. Назвемо вказівник на таке завдання «фокусом вводу». Набір завдань, що перебувають в «фокусі вводу», одночасно формує екран користувача. На рис .12 схематично зображено один з етапів функціонування системи, який відповідає стану початку роботи.
Інтерфейс користувача має свої точки виходу, які являють собою суму точок виходу вхідних до нього завдань. Інтерфейс користувача, представлений рис.13, містить два завдання F1, F4 і три точки
виходу, що належать двом різним потокам. Після здійснення користувачем вибору в одному з потоків інтерфейс користувача переформовується «виконавчим ядром».
Інтерфейс користувача і ^ і
і і 1 і і і і і і F1 1 / і
і 1 і і і 1 і і і 1 ( F4 )Щ л f—ЯЛ
Рис. 12. Інтерфейс користувача. Перший етап
Точки виходу так само групуються по потоках і доступні тільки в тому випадку, коли конкретний потік очікує вводу від користувача, наприклад у ситуації, що описана діаграмою на рис.12, при виборі користувачем точки виходу А. Точка виходу, позначена літерою B, стає недоступною на час, доки потік займається обробкою завдання f2, і повертається в активний стан тільки під час переходу до завдання F2, при цьому інтерфейс користувача буде виглядати так (рис.13).
г 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 L !і— ЁНг д j^f4\
Рис. 13. Інтерфейс користувача. Другий етап
Визначення доступності для користувача точок виходу, зміна їх стану залежно від старту й зупинки в системі потоків, а так само ухвалення рішення щодо видимості для користувача завдань є задачею «виконавчого ядра».
Послідовний запис інтерфейсів користувача, що генеруються при здійсненні ним вибору їх складових частин, наочно ілюструє роботу всієї системи й може
Рис. 14. Фрагмент діаграми процесу обчислень
РИ, 2012, № 3
77
бути використаний для опису процесу виконання обчислень. Така діаграма представлена на рис.14. На ній відображені всі стани системи, що виникають у результаті дій, здійснюваних над нею користувачем, а також завдання, які оброблені в процесі переходів між цими станами.
Рис. 15. Фрагмент графічного інтерфейсу користувача інструментарію «FFTDesigner» для створення і аналізу діаграми функціонування
Для створення і аналізу діаграми функціонування у роботі був реалізований інструментарій у вигляді програми «FFTDesigner». Це є програмний засіб для створення, редагування та аналізу функціонування програмного забезпечення базових станцій стандарту LTE. Він має графічний інтерфейс (рис.15), який у інтерактивному режимі дозволяє користувачу описати діаграму функціонування програмного забезпечення базової станції стандарту LTE, відобразити її у графічному вигляді, провести аналіз топології створеного графа, внести необхідні зміни у разі необхідності та зберегти результати роботи у вигляді XML файлу для подальшого використання.
Висновки
Вперше запропоновано метод підвищення ефективності функціонування програмного забезпечення базових станцій стандарту LTE на фізичному рівні, який завдяки використанню модифікованої діаграми потоків даних IDEF0/IDEF1 з розширеним набором параметрів опису процесу виконання завдань, удосконаленню комплексу методів аналізу, тестуванню та оптимізації використання апаратних ресурсів дозволив скоротити час розробки, знизити вартість проектування програмного забезпечення та задовольнити вимоги стандарту функціонування LTE - базових станцій.
Розроблено та випробувано на прикладі бездротового широкомовного процесора Transcede M84000 інструментарій аналізу якості програмного забезпечення, який базується на запропонованій математичній моделі програмного забезпечення базової станції, дозволяє сформувати рекомендації з його оптимізації на основі аналізу топології графа функціонування системи; проаналізувати завантаженість системи; оцінити можливість і доцільність використання паралельних обчислень; виявити помилки проектування й слабкі місця системи; провести аналіз працездатності програмного забезпечення в динаміці.
Література: 1. Харрисон П., Филд А. Функциональное программирование. М.: Мир, 1993. 2. Lawrence C Paulson. Foundations of Functional Programming : University of Cambridge, 1995. 3. Харольд Абельсон, Джеральд Джей Сассман. Структура и интерпретация компьютерных программ: Добросвет, КДУ, 2010.
Надійшла до редколегії 03.09.2012
Рецензент: д-р техн. наук, проф. Безрук В.М.
Глоба Лариса Сергіївна, д-р техн. наук, проф., зав. каф. Інформаційно-телекомунікаційних мереж Інституту телекомунікаційних систем НТУУ «КПІ». Адреса: e-mail: lgloba@its.kpi.ua, тел. (044) 4068299.
Лисенко Дмитро Сергійович, аспірант Інституту телекомунікаційних систем НТУУ «КПІ». Адреса: e-mail: lgloba@its.kpi.ua, тел. (044) 4068299.
Алексеев Микола Олександрович, канд. техн. наук, с. н. с., доц. каф. Інформаційно-телекомунікаційних мереж Інституту телекомунікаційних систем НТУУ «КПІ». Адреса: email: nick@its.kpi.ua, тел. (044) 4068299
78
РИ, 2012, № 3
