Проектирование программного обеспечения тренажёрной системы на основе стандартных модулей Текст научной статьи по специальности «Компьютерные и информационные науки»

Список литературы

1. Каштанов В. А., Медведев А. И. Теория надежности сложных систем. Санкт-Петербург: ФИЗМАТЛИТ, 2010. 608 с.

2. Липаев В.В., Распределение ресурсов в вычислительных системах. М.: Статистика, 1979. 246 с.

3. Gillam, Lee Cloud Computing: Principles, Systems and Applications. NY: Springer, 2010. 518 с.

A.N. Privalov, A.K. Klepikov

MODEL FOR RESOURCE ALLOCATION "CLOUD" COMPUTING

Consider using "cloud" technologies in the automated training systems. An option of building an automated learning system based on the "cloud" technologies.

Key words: automated learning system, the "cloud" technology, the allocation of resources.

Получено 07.03.12

УДК 519.168

А.Н. Привалов, д-р техн. наук, проф, зав. кафедрой, [email protected] (Россия, Тула, ТГПУ им. Л.Н. Толстого), Ю.И. Богатырёва, канд. пед. наук, доц., (4872) 35-20-09, [email protected] (Россия, Тула, ТГПУ им. Л.Н. Толстого)

ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ТРЕНАЖЁРНОЙ СИСТЕМЫ НА ОСНОВЕ СТАНДАРТНЫХ МОДУЛЕЙ

Рассмотрена проблема разработки специального программного обеспечения тренажёрных систем на основе унифицированных программных модулей. Сформулированы модели оптимизации специального программного обеспечения по критерию минимума избыточности программных модулей. Сформулированы математические модели унификации программных модулей

Ключевые слова: тренажёрная система, программное обеспечение, унифицированный программный модуль, синтез типовых модулей.

В общем случае тренажерная система (ТС) включает в себя ряд взаимодействующих тренажеров, имеющих структуру, приведенную на рис. 1.

Рис. 1. Обобщенная структура тренажеров

В состав любого тренажера входит рабочее место обучаемого оператора, включающее имитаторы органов управления, имитаторы приборов управления, а также средства воздействия на оператора. Вычислительная среда (ВС) с программным обеспечением (ПО) предназначена для получения информации с имитаторов органов управления, текущих расчетов показаний приборов величин воздействий на оператора.

Сложность ВС ТС и её существенное влияние на эффективность функционирования ТС предполагает постановку и решение задачи по построению рациональной структуры системы программного обеспечения

Анализ особенностей ТС позволяет сделать вывод о перспективности модульного принципа построения программного обеспечения.

Иерархичность объектов моделирования неизбежно приводит к необходимости функционально-структурной декомпозиции моделирующих программ и представления в виде системы достаточно простых элементов-модулей.. Вполне естественно поставить в соответствие отдельным системам, подсистемам, устройствам реального объекта их адекватные модели -программные модули. Если в разных объектах используются одинаковые устройства или системы, то для их моделирования могут быть использованы одни и те же модули программ.

Программы, решающие задачи управления процессом подготовки операторов на тренажерных системах, объективного контроля психофизиологического состояния и работы операторов в процессе обучения, в значительно меньшей степени подвержены изменениям. В эту часть специального программного обеспечения изменения вносятся при разработке более совершенных и эффективных методов управления и контроля. Следовательно, структура и принципы построения специального программного обеспечения ТС должны обеспечивать возможность его доработки, как на стадии создания систем так и на стадии их эксплуатации.

При модульном построении программ задачи модификации решаются эффективно. Так, при изменении, например, отдельных систем объекта должны корректироваться лишь те модули, которые связаны с модернизируемыми элементами реального объекта, а также взаимодействующие с ним. Модульное программирование обеспечивает построение сложных программ на базе небольших программных блоков, каждый из которых выполняет законченную логическую функцию. Это позволяет организовать параллельную работу группы разработчиков и таким образом существенно ускорить сроки создания и испытаний программного обеспечения.

При разработке структуры программного обеспечения в первую очередь выделяются модули основных функциональных систем объекта и основных задач по управлению тренировкой; в модулях систем выделяются составляющие ее подсистемы; далее с учетом структуры реального объекта модули подсистем представляются в виде совокупности устройств (операций), устройства — в виде совокупности блоков и т. д. Таким образом, структура программного обеспечения отражает структуру реального объекта.

В настоящее время существуют в основном два подхода к созданию программного обеспечения тренажеров. При создании программ относительно небольшого объема преобладает индивидуальный подход к программе. При этом основная цель разработчиков состоит в получении результатов при минимальных собственных затратах; при этом практически не решаются вопросы оптимизации программ по затратам технических ресурсов ЭВМ; созданная программа в основном используется самим разработчиком.

Сопряжение такой программы с другими для решения новых комплексных задач, а тем более модернизация программы практически невозможны без личного участия ее разработчиков.

Другой подход к разработке специального программного обеспечения базируется на представлении программного обеспечения как совокупности унифицированных программных модулей (ПМ).

В этом случае комплекс функциональных программ может быть расчленен на множество достаточно автономных подсистем - ПМ, тесно взаимодействующие в процессе решения общей задачи. Для обеспечения

взаимодействия подпрограмм в едином комплексе широко используется иерархическая структура с несколькими уровнями подчиненности подпрограмм, при этом подпрограмма выполняет свою целевую задачу.

Следует учитывать, что при использовании модульного программирования в отдельных подпрограммах появляются элементы сопряжения и взаимодействия блоков, которые требуют определенных затрат оперативной памяти и времени. Дополнительные затраты памяти составляют 2.. .5% от объема сопрягаемых подпрограмм, а длительность исполнения программ при этом возрастает на 10. 15%.

Анализ особенностей ТС позволяет сделать вывод о перспективности модульного принципа при построении ПО ТС [1,3].

Сложность объектов моделирования неизбежно приводит к необходимости их функционально-структурной декомпозиции и представления в виде системы достаточно простых элементов-модулей. Вполне естественно поставить в соответствие отдельным системам, подсистемам, устройствам реального объекта их адекватные модели - программные модули ПО. Если в разных объектах используются одинаковые устройства или системы, то для их моделирования могут быть использованы одни и те же модули программ.

При создании ПМ с целью использования их для различных ТС неизбежно возникает проблема избыточности процедур в модулях обусловленная стремлением сделать модули в определенной степени универсальными.

Для определения рациональной степени избыточности сформулируем задачи синтеза оптимальных типовых модулей.

В качестве исходной информации для решения данных задач используется множество процедур обработки данных для каждой ВС ТС, множество информационных элементов, области их определения, множество констант, структурированные матрицы смежности и достижимости технологии обработки данных. Решение данной задачи можно разбить на четыре этапа [1].

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

На втором этапе осуществляется проверка связности выделенных общих информационных элементов и процедур обработки данных в графе технологии каждой задачи для различных ВС ТС.

На третьем этапе выделяются общие пути для всего множества задач и его подмножеств и на четвертом - определяются общие части (подграфы) для множества задач обработки данных и его подмножеств.

Исходными данными для постановки и решения данного типа яв-

ляются :

и = {и/, / = 1, L } - множество процедур обработки данных интегрированного графа технологии;

D = {//, Д = 1, ^ } - множество информационных элементов интегрированного графа технологии;

и/ = {//, / = 1,Ц} - множество процедур обработки данных графа технологии /-й задачи;

В, = {/ f,f = 1 (/ = 1 N)- - множество информационных элементов графа технологии /-й задачи;

Qi (/ = 1, N) - последовательности выполнения процедур при решении /-й задачи;

W = д - матрица взаимосвязей информационных элементов и процедур интегрированного графа технологии;

, (/ = 1, N) - матрица взаимосвязей информационных эле-

Ж/ =

ментов и процедур при решении /-й задачи;

Задача 1. Оптимизация ПО ВС ТС по критерию минимума суммарного числа неиспользуемых процедур при обращениях к программным модулям при решении заданного множества задач.

N Ц К V .

тЬ Ею/ X X Xх/ку

\х1У =1 /=1 к=1V=1

Ц К

,(4,-1)

(1)

Е Е хгкV ю'-1 _/'=1 к'=1

Задача 2. Оптимизация ПО ВС ТС по критерию минимума максимально возможного суммарного числа неработающих процедур в программных модулях для заданного множества задач обработки данных.

Ц К V

тштк ю Е Е Е

lx/v } И /=1 к=1V=1

' Ц К I . \

Е Е К'-1)

/ '=1 к '=1

(2)

где

V = 1, V - множество синтезируемых модулей;

Хк = 1, если /-я по порядку выполнения процедура решения /-й задачи входит в v-й модуль и вызывается с частотой к-го диапазона,

х1кл = 0 в противном случае;

м?к - значение к-го диапазона частоты использования процедур при решении /-й задачи.

Ограничения для данной задачи такие же, что и для задачи распределения процедур по модулям.

Использование минимаксных критериев обеспечивает гарантированный уровень качества синтеза для каждой из задач обработки данных заданного множества за счет минимизации максимальных значений рассматриваемых критериев синтеза. Необходимость обеспечения гарантированного уровня качества проектных решений для всех задач обработки данных из заданного множества определяет целесообразность использования данного подхода.

Рассмотренные задачи (1)-(2) являются нелинейными целочисленными задачами математического программирования. При разработке нового ПО используются не только вновь разрабатываемые ПМ, а также уже имеющиеся, применяемые в более ранних разработках ТС. Таких ПМ, выполняющих определенные функции, существует большое множество. Причем многие из них выполняют сходные функции или часть функций, которые могут реализовывать другие ПМ. Возникает задача определения такого минимального унифицированного ряда ПМ, которые могли бы обеспечить функционирование любого нового ТС (возможно с некоторой модификацией или избыточностью). Такой подход призван, в первую очередь, сократить время на разработку и реализацию нового ПО и уменьшить финансовые затраты на всех стадиях жизненного цикла (ЖЦ) ПО.

Технология подготовки данных и решения задач унификации ПМ включает математические модели, методы и программы решения задач унификации.

Одноуровневые задачи решаются в случае унификации ПМ ВС ТС одного вида, имеющихся или разрабатываемых.

Технологическая схема подготовки данных и решения одноуровневой задачи имеет вид, представленный на рис. 2.

Номенклатура программного обеспечения

Рис. 2. Технологическая схема подготовки данных и решения одноуровневой задачи унификации ПО

Задача может быть сформулирована в виде задачи целочисленного линейного программирования с булевыми переменными, в которой необ-

ходимо минимизировать суммарные затраты на разработку, реализацию и сопровождение программных модулей

X с°xi + X X cijxij ^ min , (3)

'УЛУ

ieU ieUje X (х,х..)

при ограничениях

х Xij = 1, j = 1, n; (4)

ieU

Xij < Xi; i = 1,m, j = 1,n (5)

Xi Xij e {0,1}, i = 1,m, j = 1,n (6)

ij

где U={1,2,... ,m} -множество типов ПМ;

[1, если i — й ПМ l применяется в ПО j — го типа;

X,.,. =-!

0, если нет;

V

X=

[1, если / - й ПМ входит в состав унифицированного ряда;

0, если нет;

С0 — вектор начальных затрат на разработку и отладку ПМ i-го ти-

па;

- матрица затрат на реализацию и сопровождение ПМ /-го типа

при применении их в ПО j-го вида;

Су=оо если ПМ /-го типа не применяются в ПО j-го вида.

Задача (3)-(6) относится к классу целочисленного линейного программирования с булевыми переменными и является статической задачей унификации с детерминированным спросом на изделия (ПМ) и однократным применением изделия (ПМ) в операционном цикле. Ограничения (4) устанавливает факт возможности применения только одного типа ПМ для решения некоторых видов задач из заданного множества и при условии, что оптимальный ряд типов ПМ обеспечит удовлетворение всех потребностей из множества и. Ограничения (5) следуют из физического смысла параметров оптимизации.

К наиболее эффективным методам получения точного решения задачи (3)-(6) относится метод ветвей и границ. Среди известных подходов к формализации алгоритма этого метода выделяется способ, основанный на сведении задачи (3)-(6) к задаче минимизации полинома от булевых переменных.

Для обеспечивают унификацию как самих ПМ, входящие в состав ПО ВС ТС, так и самого ПО для использования его в составе ТС можно предложить многоуровневые задачи. В этом случае цель унификации по экономическому критерию заключается в следующем - обеспечить функционирование ТС различных версий и модификаций с использованием ми-

163

нимального набора ПО, разработанного с применением минимального набора ПМ.

Двухуровневая задача может быть сформулирована следующим образом. Пусть

Х={1,2,... п} - множество версий ТС, использующих различное ПО;

и={1, 2,..., т}- множество типов ПМ, входящих в состав ПО, применяемого для определенной версии ТС.

Будем считать, что комплект ПО, используемый для удовлетворения некоего спроса (обеспечения функционирования различных ТС) в принципе может включать в себя разное число ПМ различного типа. Предположим, что комплект рассматриваемого ПО характеризуются значением некоторых К показателей и что для всякого комплекта где

число ПМ типа г в данном комплекте, значение показателя ^ k=1,...,K, при фиксированном j, j еХ, определяется по значению некоторой функции Ь^^ь.^п). Считаем, что комплект ПО удовлетворяет ТС но-

мер j, если выполняется соотношение ...^Щ > Ь^, k=1,...K где Ь^,

k=1,...,K, - известные величины. Каждому комплекту ПО можно поставить в соответствие вполне конкретную ТС. Причем, количество типов комплектов ПО, отличающихся друг от друга значениями соответствующих показателей, равно количеству типов ТС, в которых они могут применяться. Предположим также, что для всякого г еи известны величины g0i и с означающие соответственно начальные затраты на проектирование ПМ типа г и затраты на реализацию одного такого ПМ. Через gj(q) обозначим

затраты на сопровождение комплекта ПО ^ь... ), где q = Xqi, при обес-

печении этим комплектом j-ой ТС.

Необходимо формально записать задачу выбора ПМ, позволяющих сформировать комплекты ПО, которые с наименьшими затратами выполнят все функции обеспечения ТС определенного вида. Чтобы вычислить величину суммарных затрат, необходимо знать, из каких типов ПМ состоит комплект ПО, обеспечивающий ТС каждого вида.

Введем переменные х„ е {0,1,2,...}, г еП, j е X . Величина х„ , при-

нимая неотрицательные целые значения, указывает на то, сколько ПМ типа г входит в комплект ПО, удовлетворяющий ТС видаj. Понятно, что для переменных х„ должны выполняться следующие ограничения:

вида комплект ПО, то величина затрат, связанная с обеспечением этим комплектом ТС j-го вида, вычисляется по формуле

т

г=1

Понятно также, что если (х1 j,...,хщ) - удовлетворяющий ТС ]-го

£ с1ху + gj(£ ху )• (7)

¡еП ¡еП

Однако одних переменных ху еще не достаточно для записи целевой функции, поскольку в ней должен быть отражен факт наличия начальных затрат на создание программных модулей каждого типа. Введем поэтому переменные х.^01}, I е П. Величина х^ равна 1, если ПМ ¡-го типа

участвует в формировании комплекта ПО, и равна 0 - в противном случае.

Формально задача выбора оптимальной системы ПО представляет собой двухуровневую задачу унификации и имеет вид

0

£ х + £ { £ сЛу + 8 у( £ ху)} ^ шт;

¡еП ¡еХ ¡еП ¡еП (х)(хуу)

х! > signхij, i е и, у е X;

Ьу(х1 у ,•••, хту) > Ьу, k = к, У е х;

хI е {0,1},Ху е {0,1,2,...,},I е П,у е X.

(8)

(9) (10) (11)

Рассмотрим один частный случай сформулированной задачи, зада-

,х

ваясь функциями Ьщ (х1 ухту ) конкретного вида.

Будем считать, что комплект (х1 у. ям ТС у-го вида, если

£ ху < Q

¡еП

у

щ)удовлетворяет требовани-

(12)

£ ауху

V ¡еП

\( Л

£ хЬ'

у

> Ьу.

(13)

где Оу ( еП, у е X) - целые неотрицательные числа, а h (д) - неотрицательная не возрастающая функция, равная 1 при д=1.

Первое ограничение естественно рассматривать как ограничение на число модулей в комплекте ПО, а второе трактовать, например, как ограничение на эффективность комплекта. При этом вид левой части второго ограничения указывает на то, что эффективность комплекта складывается из эффективности входящих в него ПМ.

0

£ х + £ {£ сху + ёу(£ ху)} ^ шт;

¡еП ¡еХ ¡еП ¡еП (х)(ху)

х

I > signху, г е П, у е X; £ ху < Q у, у е X;

¡еП

/ \ ( \

£ ауху h £ хЬ'

V ¡еП V ¡еП у

> Ьу,у е X;

(14)

(15)

(16)

(17)

*,е{ОД},*&-е {0,1,2,...,},/е е X. (18)

Технологическая схема подготовки данных и решения двухуровневой задачи унификации приведена на рисунке 3.

}ммного обеспечения

Номенклатура программных модулей

■ результаты унификации (типы 11М после унификации)

- результаты унификации (типы ПО после унификации)

Рис. 3. Технологическая схема решения двухуровневой задачи унификации ПО ТС

Двухуровневую задачу унификации можно решить путем комплексного применения метода динамического программирования и метода ветвей и границ. Этот алгоритм предполагает ряд существенных допущений в рассматриваемой задаче. Существует еще один подход - снижение вычислительной сложности за счет декомпозиции двухуровневой задачи на две одноуровневые и применения простых алгоритмов их решения.

На верхнем уровне сокращается количество типов ТС, а затем унифицируются ПМ, применяемые в заданных ПО. Динамика потребностей в новых образцах техники приводит к непрерывной замене одних систем другими, что влечет за собой необходимость создания нового ПО для этих систем. Сложившаяся практика, когда вначале осуществляется перспективное планирование развития систем, а затем на основе этих планов предусматриваются работы по унификации, не отвечает современным требованиям. Результаты раздельного решения оптимизационных задач, соответствующих такой схеме, трудно использовать на практике: рекомендации по унификации не всегда являются оптимальными и их подготовка запаздывает относительно сроков разработки изделий. В этом случае сократить номенклатуру уже созданных ПМ крайне сложно, так как она связана с номенклатурой ПО для ВС ТС, находящимися в эксплуатации.

Следовательно, необходим комплексный подход к анализу задачи управления процессом поиска рационального соотношения между моментами постановки систем на производство, модификацию, замену существующей версии ПО, и суммарной стоимостью многоуровневых параметрических рядов этих изделий.

Список литературы

1. Кульба В.В., Миронов А.С., Товмасян А.В. Формализованные модели предпроектного анализа при разработке модульных СОД // Методы анализа и синтеза автоматизированных систем управления. М.: ИПУ. 1981. Вып. 25. С. 30-38.

2. Ларкин Е.В., Привалов А.Н. Проектирование программного обеспечения вычислительной среды тренажерных систем. Тула: Изд-во ТулГУ, 2010. 259с.

3. Привалов, А.Н. Применение унифицированных программных модулей при разработке тренажёрных систем // Программные продукты и системы. Тверь. 2009. №4. С.45-52.

A.N. Privalov, J.I. Bogatyreva

DESIGN SOFTWARE SYSTEM BASED ON EXERCISE OF STANDARD MODULES

Problem of development of special program maintenance of training systems on basis of unified program modules is considered. Models of optimization of special software on criterion of minimum of redundancy of program modules are formulated. Mathematical models of unification of program modules are formulated

Key words: Training system, software, unified program module, synthesis of optimum standard modules, problem of unification of program modules.

Получено 07.03.12