Министерство образования Российской Федерации Московский Государственный Технический Университет им. Н.Э. Баумана

Министерство образования Российской Федерации
Московский Государственный Технический Университет
им. Н.Э. Баумана
Факультет «Информатика и системы управления»
Кафедра «Теоретическая информатика и компьютерные технологии»
Дипломный проект
на тему «Имитационно-обучающий тренажер по
демонтажу блоков АЭС»
Студент: Гуляев О.В.
Группа: ИУ9-121
Руководитель: Домрачева А.Б.
Москва, 2012 г.
Оглавление
Список иллюстраций ...............................................................................................................3
Перечень используемых терминов и сокращений ..............................................................4
Введение ..................................................................................................................................5
1
Исследовательская часть ..............................................................................................7
1.1
Обзор средств моделирования ................................................................................7
1.1.1
Графические и физические движки .................................................................7
1.1.2
Интегрированные среды разработки ..............................................................9
1.2
Обзор Unity3D ..........................................................................................................10
1.3
Описание объекта моделирования .......................................................................12
1.4
Артефакты моделирования ....................................................................................13
1.4.1
Графические артефакты ..................................................................................14
1.4.1.1 Низкая полигональность моделей ...........................................................14
1.4.1.2 Отсутствие рельефного текстурирования ................................................14
1.4.1.3 Отсутствие теней ........................................................................................15
1.4.2
Физические артефакты ....................................................................................16
1.4.2.1 «Пружинность» соединений твердых тел................................................16
1.4.2.2 Взаимное проникновение сталкивающихся твердых тел ......................16
1.4.2.3 Раскачивание плит настила при движении роботов по ним .................17
1.4.2.4 Моделирование гусениц робота колесами .............................................18
2
Технологическая часть.................................................................................................20
2.1
Программные решения ...........................................................................................20
2.1.1
Движение компонентов робота Brokk ...........................................................20
2.1.2
Коллайдеры динамических тел ......................................................................23
2.1.3
Моделирование работы захватов ..................................................................24
2.2
Руководство пользователя ИОТ..............................................................................26
2.2.1
Запуск приложения..........................................................................................26
2.2.2
Управление камерами ....................................................................................27
2.2.3
Работа со сценами ...........................................................................................31
1
2.2.4
Окно симулятора..............................................................................................31
2.2.5
Управление роботом Brokk .............................................................................32
2.2.6
Управление аварийными состояниями блоков ............................................40
2.2.7
Отображение действий пользователя ...........................................................40
2.3
Руководство администратора ИОТ.........................................................................42
2.3.1
Управление настройками симулятора...........................................................42
2.3.2
Консольные команды ......................................................................................43
3
Конструкторская часть .................................................................................................44
3.1
Описание конструкции шахты реактора ................................................................44
3.1.1
Аварийные состояния блоков.........................................................................45
3.1.2
Технология демонтажа ...................................................................................46
3.2
Применение паттернов проектирования ..............................................................46
3.2.1
Применение паттерна Mediator в слоевой архитектуре симулятора .........47
3.2.2
Применение паттернов Publisher, Subscriber и Singleton для реализации
шины обмена событиями ...................................................................................................47
3.2.3
4
Применение паттерна State в диаграмме состояний пульта Brokk ............50
Организационно-экономическая часть .....................................................................51
4.1
Введение...................................................................................................................51
4.2
Расчет трудоемкости проекта .................................................................................51
4.3
Определение количества исполнителей проекта ................................................57
4.4
Календарный график выполнения проекта ..........................................................58
4.5
Определение сметы затрат .....................................................................................60
4.6
Расчет затрат ............................................................................................................60
4.6.1
Затраты на выплату заработной платы ..........................................................60
4.6.2
Затраты на оборудование ...............................................................................62
4.6.3
Затраты на организацию рабочих мест .........................................................62
4.6.4
Накладные расходы.........................................................................................63
4.6.5
Суммарные затраты .........................................................................................63
4.7
Заключение ..............................................................................................................65
Список литературы ................................................................................................................66
2
Список иллюстраций
Рисунок 1.1: Среда разработки Unity ..................................................................................11
Рисунок 1.2: Робот Brokk и его основные компоненты .....................................................13
Рисунок 1.3: Блоки с различной полигональностью ..........................................................15
Рисунок 1.4: Применение карты нормалей для текстуры шара .......................................15
Рисунок 1.5: Модель колес робота с зазорами между колесами ....................................19
Рисунок 2.1: Параметры HingeJoint соединения двух звеньев манипулятора робота ...22
Рисунок 2.2: "Колеса" робота Brokk.....................................................................................22
Рисунок 2.3: Варианты коллайдеров графитового блока ..................................................23
Рисунок 2.4: Захват-манипулятор и цанговый захват ........................................................24
Рисунок 2.5: Схема цангового захвата .................................................................................25
Рисунок 2.6: Окно графического интерфейса .....................................................................27
Рисунок 2.7: Элемент выбора камер ...................................................................................28
Рисунок 2.8: Расположение двух камер на экране симулятора .......................................29
Рисунок 2.9: Расположение трех камер на экране симулятора .......................................30
Рисунок 2.10: Расположение четырех камер на экране симулятора ...............................30
Рисунок 2.11: Включенная свободная камера ...................................................................31
Рисунок 2.12: Элемент выбора сценария ...........................................................................31
Рисунок 2.13: Окно симулятора с консолью .......................................................................32
Рисунок 2.14: Пульт управления Brokk ................................................................................33
Рисунок 2.15: Соответствие имитируемых пультов и роботам Brokk ..............................33
Рисунок 2.16: Схема пульта Brokk ........................................................................................34
Рисунок 2.17. Схема геймпада Logitech Dual Action ...........................................................34
Рисунок 2.18: Схема кнопок клавиатуры ............................................................................36
Рисунок 2.19: Элемент управления аварийными состояниями блоков ..........................41
Рисунок 2.20: Подсветка пульта Brokk.................................................................................42
Рисунок 3.1: Шахта реактора ................................................................................................44
Рисунок 3.2: Целый и треснувший блоки ............................................................................45
Рисунок 3.3: Изъятие массива из трех слипшихся блоков ................................................45
Рисунок 4.1: Диаграмма Ганта .............................................................................................59
Рисунок 4.2: Структура затрат на разработку ПП ...............................................................64
3
Перечень используемых терминов и сокращений
ИОТ
Имитационно-обучающий тренажер
Движок
Программные средства для графического и физического моделирования
ИСР
Интегрированная среда разработки
Unity3D
Игровая трехмерная ИСР, разработанная Unity Technologies, включающая в
себя графический и физический движки
Brokk
Серия моделей демонтажных роботов
Коллизия
Столкновение двух и более твердых тел
Коллайдер
Физическая форма твердого тела
Сцена
Моделируемое пространство шахты реактора
FPS
Frames per second, количество кадров в секунду, основной критерий
быстродействия графического движка
Геймпад
Игровое устройство ввода с кнопками и рычагами
4
Введение
Рост специализированных технических задач, связанных с работой в сложных
условиях (демонтаж зданий и сооружений, выбойки огнеупорных материалов и прочие),
привел к появлению на рынке дистанционно управляемых машин, способных к
функционированию в заданных режимах. Так, например, шведская машиностроительная
компания Brokk AB предлагает пользователям компактные электрогидравлические
дистанционно управляемые машины Brokk, предназначенные для демонтажа.
В связи с увеличением количества направлений практического использования таких
машин возникает необходимость моделирования (эмуляции) действий робота для
решения широкого спектра практических задач.
Целью данной работы является разработка программного комплекса,
моделирующего работу оператора робота Brokk для:
–
обучения персонала работе по удалению просыпей и разборке кладки реактора;
–
проверки выполнимости операций технологического процесса разборки кладки
реактора;
–
разработки оптимального алгоритма разборки кладки реактора.
Объектом моделирования служит трехмерная инженерная модель блока Белоярской
АЭС АМБ-100.
Представленная ниже расчётно-пояснительная записка содержит следующие
разделы: исследовательскую , конструкторскую, технологическую части и
организационно-экономическую часть.
В исследовательской части приводится описание объекта исследования дистанционно управляемые машины Brokk, обоснование выбора средств имитационного
моделирования – среды разработки Unity3D, описание возможностей среды, обзор
артефактов, возникающих при моделировании, анализ результатов моделирования.
В технологической части описываются программные решения для моделирования
объектов, реализованные при разработке программного комплекса, а также
представлены руководства пользователя и администратора программного комплекса.
В конструкторской части описаны фрагменты трехмерной инженерной модели
объекта исследования, приведена структурная схема программного комплекса,
5
перечислены некоторые архитектурные решения и приемы объектно-ориентированного
программирования, использованные при разработке программного комплекса.
В организационно-экономической части рассматривается оценка трудоёмкости
разработки программного проекта. Рассчитывается продолжительность работ и
необходимое число исполнителей. Построен план-график выполняемого проекта с
использованием диаграммы Ганта. Так же в этом разделе произведён расчёт сметной
стоимости проекта.
Всего пояснительная записка на _ страниц, в том числе_ рисунков, _ таблиц, _
страниц приложений. Графическая часть проекта содержит _ листов формата А4, в том
числе… (подставить числа)
6
1 Исследовательская часть
Для разработки ИОТ был использован среда Unity3D, включающий в себя средства
графического и физического моделирования. Unity3D предоставляет, с одной стороны,
возможности физического движка, просчитывая столкновения твердых тел, не давая
одним твердым телам «проходить» сквозь другие, воздействуя силой тяжести на твердые
тела, и, с другой стороны, предоставляет API для управления этими возможностями.
В данном разделе проведен обзор различных сред графического и физического
моделирования, рассмотрены используемые возможности движка Unity3D, некоторые
детали предметной области ИОТ, необходимые для описания процесса исследований, и
анализ и устранение графических и физических артефактов, возникающих в процессе
моделирования.
1.1 Обзор средств моделирования
Проведем обзор различных средств моделирования, которые могут быть
использованы при разработке ИОТ, и выберем оптимальный вариант среди них. Выбор
будет производится согласно следующим критериям:
–
значимые для данной задачи функциональные возможности;
–
языки программирования, используемые для реализации программной логики;
–
поддерживаемые форматы графических моделей;
–
поддерживаемые графические платформы и операционные системы;
Рассматриваются как варианты с единой ИСР, так и варианты комбинирования двух
различных графических и физических движков.
1.1.1 Графические и физические движки
Все перечисленные в данном разделе графические движки имеют возможность
работы с трехмерными графическими моделями, т.е. являются трехмерными.
OGRE (Object-Oriented Graphics Rendering Engine) - объектноориентированный графический движок с открытым исходным кодом, написанный на C++.
Автором OGRE является Стив Стритинг.
7
Таблица 1.1: Возможности графического движка OGRE
Графические платформы
Direct3D, OpenGL
Операционные системы
Windows, Linux, Mac OS X
Форматы графических моделей
.mesh, существуют инструменты для
перевода из других форматов
Физические движки, библиотеки которых
PhysX, Newton Game Dynamics, Bullet, Open
портированы под движок
Dynamics Engine
Языки программирования
C++. Существует порты для C#, Java, Python,
Ruby.
Microsoft XNA - набор инструментов с управляемой средой времени
выполнения (.NET), созданный Microsoft, облегчающий разработку и
управление компьютерными играми.
Таблица 1.2: Возможности графического движка Microsoft XNA
Графические платформы
Direct3D
Операционные системы
Windows
Форматы графических моделей
.fbx, .dae, .3ds
Физические движки, библиотеки которых
PhysX, Newton Game Dynamics, Bullet, Open
портированы под движок
Dynamics Engine
Языки программирования
С#, Visual Basic .NET
Irrlicht – графический движок, разработанный Николасом Гебхардом.
Таблица 1.3: Возможности графического движка Irrlicht
Графические платформы
Direct3D, OpenGL
Операционные системы
Windows, Linux, Mac OS X
Форматы графических моделей
.obj, .3ds, .dae
Физические движки, библиотеки которых
Newton Game Dynamics, Havok
портированы под движок
Языки программирования
C++. Существуют порты для С#, Visual Basic
.NET, Java, Python, Ruby.
8
Все физические движки, поддерживаемые перечисленными графическими движками,
имеют возможность моделирования физики твердого тела и соединений твердых тел, что
необходимо при физическом моделировании в ИОТ.
Недостаток использования пары «графический движок – физический движок»
заключается в необходимости интегрирования их возможностей при программировании.
ИСР, рассмотренные ниже, избавляют от такой необходимости.
1.1.2 Интегрированные среды разработки
UDK (Unreal Development Kit) – инструмент для создания игрового ПО, разработанный
компанией Epic Games.
Таблица 1.4: Возможности ИСР UDK
Операционные системы
Windows, Mac OS X, iOS, Android
Форматы графических моделей
.max, .fbx, .obj, .dae, .blend
Редактор сцены
Присутствует
Физический движок
PhysX
Языки программирования
C++, Java
Unity3D – инструмент для создания игрового ПО, разработанный компанией Unity
Technologies.
Таблица 1.5: Возможности ИСР Unity3D
Операционные системы
Windows, Mac OS X, iOS, Android
Форматы графических моделей
.fbx, .dae, .blend
Редактор сцены
Присутствует
Физический движок
PhysX
Языки программирования
C#, JavaScript, Boo
Учитывая описанный выше недостаток подхода использования пары «графический
движок – физический движок», средство разработки выбирается между UDK и Unity3D.
Для разработки был выбран Unity3D, поскольку он предоставляет возможность
программирования на языке C#, что облегчает и ускоряет разработку.
9
1.2 Обзор Unity3D
Unity3D - ИСР для разработки игрового ПО, объединяющий в себе графический и
физический движки (см. Рисунок 1.1).
В качестве физического движка в Unity3D используется PhysX, который позволяет
использовать при разработке в Unity3D возможности физики твердых тел, мягких тел,
моделировать соединения и т.д.
3D-модели объектов разрабатываются в 3ds Max в формате .max, конвертируются в
формат .fbx и импортируются в Assets движка Unity3D. (описать форматы в приложении
или указать ссылку на источник с их описанием)
Unity3D имеет средства для программирования логики работы игровых объектов.
Программирование реализуется с помощью скриптов, которые могут присоединяться к
игровым объектам. Скрипты можно писать на следующих языках: JavaScript, C#, Boo.
Разработка ведется на языке C#. Скрипты компилируются под платформу Mono.
Основой скриптов является событийная модель, реализуемая вызовом функций,
реализуемых в классах-скриптах. Основные функции приведены в таблице Таблица 1.6.
Таблица 1.6: Основные функции скриптов
Сигнатура функции
Описание функции
void Awake()
Вызывается при создании игрового объекта.
void Update()
Вызывается при отображении каждого кадра.
void FixedUpdate()
Вызывается каждый квант времени, величину кванта
времени можно изменять.
void OnCollisionEnter()
Вызывается при возникновении коллизии двух объектов.
void OnCollisionStay()
Вызывается при пребывании двух объектов в состоянии
коллизии.
void OnCollisionExit()
Вызывается после окончания коллизии между
объектами.
Каждый игровой объект может содержать в себе несколько компонент. Выделим
наиболее важные из этих компонент:
10
Рисунок 1.1: Среда разработки Unity
– Transform - описывает положение объекта в пространстве - перемещение, вращение, а
также масштабирование объекта.
– Mesh – описывает графическую форму объекта как триангулярную сетку.
– Rigidbody - описывает твердое тело игровое объекта - его массу, физический материал,
гравитацию и т.д. В общем случае графическая форма тела и его коллайдер (если он
существует) не совпадают друг с другом.
– Collider - один из возможных видов коллайдеров, которые описывают форму твердого
тела объекта. Перечислим виды коллайдеров:
a) Box collider - прямоугольный параллелепипед
b) Sphere collider - сфера
c) Capsule collider - капсула
d) Mesh collider - коллайдер, который строится по графической форме объекта. Имеет
свойство convex, при активации которого коллайдер строится по выпуклой
оболочке графической формы с максимальным количеством треугольников в
размере 256.
e) Wheel collider - колесо, используемое для моделирования перемещения
транспортных средств.
11
– Joint - одно из возможных соединений, действующих между двумя твердыми телами.
Перечислим некоторые виды соединений:
a) FixedJoint - соединение двух тел без степеней свободы.
b) HingeJoint - шарнирное соединение с одной угловой степенью свободы.
c) ConfigurableJoint - наиболее обобщенный вид соединения с возможностью
настройки всех шести степеней свободы.
– Script - скрипт, таких компонент может быть несколько.
– Camera - камера, изображение с которой можно получить.
К любому из этих компонент есть доступ через игровой объект с помощью скрипта.
Моделирование объектов, их действий и поведения осуществляется с помощью
возможностей Unity3D, включая реализацию дополнительной логики с помощью
программирования скриптов Unity3D.
1.3 Описание объекта моделирования
Основной моделируемый объект – робот Brokk, компактная электрогидравлическая
дистанционно управляемая машина Brokk, предназначенная для демонтажа (см. Рисунок
1.2).
Робот Brokk состоит из ходовой части, состоящей из гусениц и выносных опор, и
манипулятора, состоящего из нескольких сегментов.
Гусеницы могут вращаться в прямом и обратном направлении, обеспечивая возможность
движения вперед, назад и вокруг своей оси. Выносные опоры при движении ходовой
части находятся в поднятом положении, а опускаются при движении манипулятора, чтобы
обеспечить устойчивость робота и предотвратить его заваливание вперед.
Манипулятор состоит из вращающейся вокруг вертикали оси, а также четырех
сегментов с одной степенью свободы, приводимых в движение гидроцилиндрами.
Большое количество сегментов позволяет точно позиционировать последний, четвертый,
сегмент, который служит базой для навесных инструментов, или насадок.
Навесными инструментами робота могут служить отбойные молоты, промышленные
магниты и т.д. В симуляторе будут моделировать три насадки – захват-манипулятор,
цанговый захват и циркулярная пила.
12
Рисунок 1.2: Робот Brokk и его основные компоненты
1.4 Артефакты моделирования
Использование средств разработки игрового ПО, подобных Unity3D, предполагает
возникновение артефактов моделирования, которые можно разделить на графические и
физические. Их наличие не только снижает точность моделирования, но и может
привести к принятию неверных решений.
В данном разделе ставится задача анализа возникающих в результате моделирования
артефактов и выбора пути их устранения.
При описании артефактов моделирования могут быть упомянуты программные
решения, перечисленные в разделе 2.1, и конструкция шахты реактора, описанная в
разделе 0.
13
1.4.1 Графические артефакты
1.4.1.1 Низкая полигональность моделей
Полигональность трехмерной графической модели – количество треугольников, из
которых состоит сетка модели. Чем выше полигональность, тем из большего количества
треугольников состоит сетка. В компьютерной графике существует технология,
называемая тесселяцией, с помощью которой возможно увеличить
количество многоугольников в полигональной трёхмерной модели, используя кривые
Безье. В Unity3D тесселяция не применяется, и сетка модели соответствует сетке,
смоделированной в 3ds Max.
Чем выше полигональность модели, тем больше времени тратится на рендеринг этой
модели графическим движком, что сопровождается снижением FPS. Поэтому для
моделей, представленных в большом количестве на сцене, необходимо уменьшать
полигональность. Такими объектами, в первую очередь, являются блоки. Исходя из этих
соображений, была проведена оптимизация, в ходе которой у моделей блоков была
уменьшена полигональность (см. Рисунок 1.3, слева блок до оптимизации, справа после).
Однако следствием такой оптимизации является возникновение графического
артефакта, ухудшающего визуальное восприятие оптимизированных моделей, а в случае,
если эти модели используются в игровых объектах, имеющих также твердое тело с
коллайдером типа Mesh Collider, то может уменьшаться точность физического
моделирования, поскольку Mesh Collider строится по графической форме модели.
Таким образом, для каждой модели необходимо определить, как часто она будет
использоваться на сцене, и если она будет использоваться часто, то необходимо понизить
ее полигональность, имея в виду ухудшение визуальных качеств модели.
1.4.1.2 Отсутствие рельефного текстурирования
Текстура — растровое изображение, накладываемое на полигональную сетку 3D
модели для придания ей цвета, окраски. Текстура также может содержать в себе карту
нормалей, описывающую отклонения нормалей поверхности, что придает модели, на
которую накладывается такая текстура, эффект рельефности (см. Рисунок 1.4, слева шар с
текстурой без карты нормалей, в центре карта нормалей, справа шар с текстурой,
содержащей карту нормалей).
14
Рисунок 1.3: Блоки с различной полигональностью
Рисунок 1.4: Применение карты нормалей для текстуры шара
Текстурирование для моделей объектов в ИОТ не используется, что снижает их
визуальное восприятие.
1.4.1.3 Отсутствие теней
В Unity3D источники света представляют собой игровые объекты, располагаемые в
пространстве сцены, с компонентом Light. Источник света может быть направленным, в
этом случае интенсивность освещения, поступающего от него, не меняется с расстоянием.
Такие источники освещения моделируют бесконечно удаленные источники света, такие
как солнце. У ненаправленных источников света, например у точечных, интенсивность
15
освещения уменьшается с увеличением расстояния до них. В свойствах источника света
указывается, будут ли объекты на сцене отбрасывать тени от света, поступающего от них.
Тени, отбрасываемые от направленного источника света, имеют одну направленность,
поскольку источник света бесконечно удален, что является ненаглядным при
моделировании. При использовании отбрасывания теней от ненаправленных источников
света существенно понижается FPS, что ухудшает качество моделирования. По этим
причинам в ИОТ тени не используются.
1.4.2 Физические артефакты
1.4.2.1 «Пружинность» соединений твердых тел
Соединения твердых тел в Unity3D, моделирующее степени свободы движения тел
относительно друг друга, например HingeJoint, работают по принципу пружины. Так, при
установке значения параметра Target Position для соединения HingeJoint фактически
увеличивается жесткость моделирующей соединение пружины, вследствие чего
управляемое твердое тело, например сегмент манипулятора, опускается или
поднимается.
Такое моделирование соединения создает затухающие колебания движимого
твердого тела, как если бы он располагался на пружине. Также, например, при падении
робота Brokk набок на одну из частей выносных опор, робот начинает «подпрыгивать»,
поскольку давление на выносные опоры сжимает пружины используемых в них
соединениях HingeJoint.
В реальном роботе сегменты манипулятора движутся за счет изменения давления в
гидроцилиндрах, и подобных колебаний не возникает.
Полностью устранить данный артефакт невозможно, однако путем установки
оптимальных значений для параметров Spring соединения HingeJoint (см. раздел 2.1.1)
можно достичь уменьшения колебания тела.
1.4.2.2 Взаимное проникновение сталкивающихся твердых тел
Физический движок Unity3D работает на основе событийной модели. Событием
является, например, столкновение двух твердых тел. Для возникновения событие
необходимо соблюдение некоторых условий – для события столкновения твердых тел это
взаимное проникновение коллайдеров друг в друга. Соблюдение этих условий
проверяется в рамках рабочего цикла движка. Частота итераций рабочего цикла задается
16
квантом времени. Чем меньше этот квант времени, тем выше точность физического
моделирования, поскольку больше событий будут порождаться вовремя. Однако
установка кванта в слишком малое значение отрицательно сказывается на
производительности, поскольку возрастает нагрузка на CPU.
Поскольку нет возможности установить квант времени рабочего цикла физического
движка бесконечно малым, то в любом случае будут наблюдаться неточности
физического моделирование, в частности, эффект взаимного проникновения твердых тел
друг в друга, который возникает из-за слишком позднего фиксирования факта их
столкновения.
Чем выше скорость твердого тела, налетающего на другое твердое тело, тем больше
будет заметен эффект взаимного проникновения, поскольку у физического движка будет
меньше времени, что зафиксировать факт возникновения коллизии.
При взаимном проникновении твердых тел возникает эффект их отталкивания друг от
друга из-за приложения к каждому из тел силового импульса. Направление импульса
сонаправлено с нормалью плоскости сечения их столкновения. Чем на большее
расстояние произошло проникновение, тем большую величину имеют отталкивающие
импульсы. На соотношение отталкивающих импульсов твердых тел влияют их массы. Чем
меньше масса твердого тела относительно другого, тем больший импульс будет к нему
приложен.
Таким образом, устранение артефакта проникновение тел осуществляется, с одной
стороны, установкой кванта времени физического движка в меньшее значение, не
влекущей за собой существенного падения производительности, и, с другой стороны,
настройки соотношения масс твердых тел с целью балансирования применяемых к ним
отталкивающих импульсов.
1.4.2.3 Раскачивание плит настила при движении роботов по ним
Плиты настила лежат на арматуре карусели. Арматура карусели является твердым
телом с коллайдером Mesh Collider. Из-за неточности разработанной графической модели
карусели и погрешностей физической симуляции положении плиты на арматуре является
нежестким, и при движении роботов по ней она начинает «раскачиваться». Эту проблему
можно устранить, установив массу плиты очень большой, тогда действие со стороны
гусениц роботов на плиту будет уменьшено. Однако плиты настила необходимо в
процессе демонтажа поднимать с помощью захвата-манипулятора, и в случае увеличения
17
их массы поднять их будет невозможно, если их масса увеличена на несколько порядков,
или робот будет заваливаться вперед из-за действующей на него силы тяжести со стороны
захваченной плиты, если масса плит будет увеличена на 1-2 порядка.
Решением данной проблемы является динамическое управление массами плит.
Для плит существуют два значения массы: m, масса по умолчанию, и M, увеличенная
масса. Когда плиты лежат на настиле, их масса равна M. В момент захвата плиты роботом
ее масса становится равной m, чтобы робот смог поднять ее. Сделать массу обратно
равной M сразу после отпускания роботом плиту нельзя, т.к. плита может быть поднята
над другими объектами, и тогда она упадет на них, имея большую массу M, что вызовет
слишком сильное расталкивание объектов, на которые она упала. Поэтому масса M
устанавливается для плиты по прошествии некоторого промежутка времени.
1.4.2.4 Моделирование гусениц робота колесами
Движение гусениц робота смоделировано с помощью колес, моделируемых
коллайдером Wheel Collider (см. раздел 2.1.1). Первоначальная модель колес
предполагала по два больших колеса для каждой гусеницы (см. Рисунок 1.5). У такой
модели есть недостаток – между колесами гусеницы находится горизонтальный зазор, и
при наезде гусеницы на выступ, который попадет в этот зазор, дальнейшее движение
гусениц назад или вперед будет невозможно или затруднено. Также наблюдается
визуальный эффект, заключающийся в частичном «проваливании» центральной части
гусеницы в другой объект, возникающий из-за зазора между колесами.
Для решения этой проблемы была разработана модель колес, в который
применялось больше колес меньшего радиуса и они располагались в два ряда (см.
Рисунок 2.2).
18
Рисунок 1.5: Модель колес робота с зазорами между колесами
19
2 Технологическая часть
В этом разделе рассмотрены программные решения, необходимые для моделирования
объектов, а также приведены руководство пользователя и руководство администратора.
2.1 Программные решения
Зачастую для моделирования объектов возможностей, предоставляемых физическим
движком, оказывается недостаточно, либо моделирование получается неточным по ряду
параметров. Для решения этой проблемы применяется дополнительное
программирование с помощью скриптов Unity3D. Рассмотрим некоторые из этих
программных решений.
2.1.1 Движение компонентов робота Brokk
В среде Unity3D робот Brokk смоделирован следующим образом – каждой его
компоненте, которая может двигаться, соответствует игровой объект с компонентами
Rigidbody и одним из соединений. Движущимися компонентами в роботе Brokk являются:
– Левая и правая часть выносных опор. Каждой из частей можно управлять отдельно.
Изначально выносные опоры находятся в поднятом положении, но осуществлении
действий манипулятором их необходимо опускать.
– Ось манипулятора. Обеспечивает поворот всего манипулятора вокруг вертикальной
оси.
– Сегменты манипулятора. Каждый из сегментов приводится в действие
гидроцилиндром.
Проанализировав данные компоненты робота, нетрудно заметить, что все они имеют
одну угловую степень свободы. Исходя из этого, в качестве соединения выбрано
HingeJoint, шарнирное соединение. Для каждого шарнирного соединения определяются
следующие параметры:
– Axis, ось вращения твердого тела.
– Limits, включающий в себя пределы угла вращения твердого тела (𝛼𝑚𝑖𝑛 , 𝛼𝑚𝑎𝑥 ).
– Spring, описывающий пружинный «привод» соединения – значения параметров
упругости и демпфера пружины, а также параметр Target Position, соответствующий
углу вращения, на который соединение устанавливает управляемое им твердое тело.
20
– Connected Body, параметр, присутствующий во всех соединениях – твердое тело, к
которому присоединено управляемое твердое тело.
При создании объектов сцены, в частности роботов, соединения между их
компонентами создаются программно с заданием параметров Axis, Limits и Spring.
Для вращения рассматриваемых компонентов изменяется параметр Target Position.
При его изменение пружинный «привод» автоматически приводит твердое тело в нужное
положение. Target Position при каждом обращении к функции движения изменяется на
малую величину, что обеспечивает плавность движения компонент.
Иллюстрация параметров HingeJoint приведена на рисунке Рисунок 2.1. В этом
примере второе звено манипулятора (Body) соединено с первым звеном.
Иначе моделируется движение гусениц робота. Каждая из гусениц приводится в
движение с помощью моделей колес, реализованных с помощью коллайдера
WheelCollider. Для обеспечения максимального правдоподобия моделирования гусениц,
каждая из них смоделирована двумя рядами колес, в каждом из которых несколько колес
(см. Рисунок 2.2).
Компонент WheelCollider содержит ряд параметров, описывающих поступательное и
боковое трение колеса, радиус, массу колеса, а также два параметра, с помощью которых
осуществляется движение колес – Motor Torque и Brake Torque, движущий и тормозящий
моменты вращения соответственно, а также Rpm – текущее значение количества
оборотов колеса в минуту.
При поступлении команды движения гусеницы вперед для каждого колеса
выставляется некоторое значение Motor Torque, а Brake Torque обнуляется. После
движения колес Motor Torque обнуляется, а Brake Torque приобретает значение,
необходимое для предотвращения отката робота (если он, например, находится на
наклонной плоскости). Результатом выставления Motor Torque в некоторое значение
является увеличение Rpm. Чтобы установить скоростные пределы для движения гусениц,
перед сообщением колесу Motor Torque осуществляется проверка Rpm на максимальное
значение. Если оно достигнуто, вращательный момент колесу не сообщается.
21
Max angle
Body
Target
position
Axis
Connected
body
Min angle
Рисунок 2.1: Параметры HingeJoint соединения двух звеньев манипулятора робота
Рисунок 2.2: "Колеса" робота Brokk.
22
Движение гусеницы назад осуществляется аналогичным образом, кроме того, что
вращательный момент Motor Torque применяется с обратным знаком.
2.1.2 Коллайдеры динамических тел
Объекты, которыми манипулирует робот, имеют сложную графическую форму,
которую нужно аппроксимировать коллайдером. Рассмотрим в качестве объекта
графитовый блок.
Коллайдер Mesh Collider строится по графической форме объекта (см. Рисунок 2.3,
блок слева, синий контур).
Рисунок 2.3: Варианты коллайдеров графитового блока
Физический движок может фиксировать коллизии с объектом, коллайдер которого –
Mesh Collider, если этот объект не движется. Однако, например, если на него действует
сила тяжести и он падает вниз, то коллизия с поверхностью, на которую он должен упасть,
не будет зафиксирована, и он «провалится» сквозь нее.
При использовании Mesh Collider со свойством Convex коллайдер строится по
выпуклой оболочке графической формы (см. Рисунок 2.3, средний блок, зеленый контур).
Коллизии с таким коллайдером уже могут детектироваться в динамике. Однако,
поскольку коллайдер был построен по выпуклой оболочке тела, то становится
невозможным помещать другие объекты в отверстие блока, но доставать блоки из кладки
реактора необходимо с помощью цангового захвата, который распирает наконечники в
отверстии.
23
Решением является аппроксимация коллайдера блока с помощью нескольких
коллайдеров Box Collider, представляющих собой прямоугольные параллелепипеды (см.
Рисунок 2.3, блок справа, зеленый контур). Данное решение уменьшает точность
аппроксимации графической формы, но позволяет осуществить захват блока, а также
улучшает производительность симулятора, поскольку количество блоков на сцене –
несколько тысяч, а просчет коллизий с Box Collider осуществляется физическим движком
намного быстрее, чем с Mesh Collider.
2.1.3 Моделирование работы захватов
В данном разделе рассмотрено моделирование работы двух навесных инструментов
– цангового захвата и захвата-манипулятора. Различие между ними состоит в том, что
цанговый захват захватывает объект, когда наконечники расходятся друг от друга, а
захват-манипулятор – когда наконечники сходятся друг к другу (см. Рисунок 2.4, захватманипулятор слева, цанговый захват справа). Работа обоих захватов смоделирована
практически идентично, с учетом упомянутого различия между ними, поэтому
рассмотрим один из них – цанговый захват.
Цанговый захват состоит из неподвижной базы, прикрепленной к последнему
сегменту манипулятора, цилиндрической вращающейся оси, к которой присоединены два
наконечника, способные двигаться друг от друга или друг к другу (см. Рисунок 2.5).
Движение оси и наконечников смоделировано с помощью соединения HingeJoint
аналогично выносным опорам и сегментам манипулятора робота Brokk (см. раздел 2.1.1).
Рисунок 2.4: Захват-манипулятор и цанговый захват
24
База
Коллайдеры
наконечника
Вращающаяся
ось
Триггерный
коллайдер
наконечника
Наконечник
Рисунок 2.5: Схема цангового захвата
Физическая форма наконечника смоделирована с помощью двух Box Collider и одного
триггерного Box Collider. Триггерные коллайдеры – специальный вид коллайдеров
Unity3D, не участвующих в расчете коллизий. Однако факт попадания других коллайдеров
в зону, занимаемую триггерным, можно отследить с помощью функций-событий,
OnTriggerEnter() OnTriggerStay() OnTriggerExit()
аналогичных рассмотренным в разделе 1.2 функциям
OnCollisionEnter() OnCollisionStay() OnCollisionExit()
Как было сказано в разделе 2.1.2, графитовый блок состоит из четырех Box Collider (см.
Рисунок 2.3, вариант блока справа). Захват блока осуществляется при выполнении
следующих условий:
1 Триггерный коллайдеры обоих наконечников захвата касаются противопоставленных
коллайдеров графитового блока, т.е. либо 1 и 3, либо 2 и 4 коллайдеров. Этим
25
условием моделируется эффект распора наконечниками цангового захвата внутренних
стенок отверстия блока. Условие на противопоставление коллайдеров обеспечивает
корректность захвата – нельзя захватить блок, расперев его в «углу» отверстия.
2 В недавнем времени было произведено разведение наконечников цангового захвата.
Это условие контролируется с помощью таймера, установленного на значение,
близкое к нулю, который запускается после окончания разведения наконечников
захвата. При нулевом значении таймера захват не осуществляется. Это условие нужно
для того, чтобы предотвратить ситуацию, когда наконечники захвата установлены с
помощью манипулятора робота или оси захвата в положение, при котором
выполняется условие 1, но разведения наконечников не было произведено.
При выполнении обоих условий блок захватывается путем создания соединения
FixedJoint между блоком и одним из наконечников насадки.
Отсоединение блока от цангового захвата происходит при сведении наконечников,
при этом созданное соединение FixedJoint уничтожается.
2.2 Руководство пользователя ИОТ
В данном разделе приведено руководство пользователя ИОТ – описан графический
интерфейс пользователя, а также управление роботами Brokk.
2.2.1 Запуск приложения
Запустить приложение можно в двух режимах:
– Запуск только модуля симулятора, в котором осуществляется моделирование
демонтажного процесса. Для этого перейдите в меню «Пуск» и запустите ярлык
«Симулятор».
– Запуск обоих модулей – симулятора и графического интерфейса. Для этого перейдите
в меню «Пуск» и запустите ярлык «Симулятор. Пользовательский интерфейс».
При запуске только модуля симулятора пользователю недоступен графический
интерфейс, в окне модуля симулятора запускается сценарий по умолчанию, после чего
пользователь может приступить к управлению роботами Brokk.
26
При запуске обоих модулей в окне графического интерфейса отображается окно
графического интерфейса (см. Рисунок 2.6).
Рисунок 2.6: Окно графического интерфейса
В имитационной модели предусмотрены два режима работы: режим симуляции, в
котором пользователь управляет роботом, отрабатывая технологическую
последовательность разборки кладки реактора, и режим воспроизведения, в котором
пользователь просматривает записи отработанных технологических операций,
выполненных другими пользователями.
При запуске только модуля симулятора автоматически устанавливается режим
симуляции. При запуске обоих модулей по умолчанию включается режим имитации. Для
переключения между режимами имитации и воспроизведения следует воспользоваться
кнопками «Имитация» и «Воспроизведение» в левом верхнем углу окна графического
интерфейса (см. Рисунок 2.6). Чтобы начать имитацию, необходимо выбрать сценарий из
списка и нажать на кнопку «Старт» в правом верхнем углу.
2.2.2 Управление камерами
Этот элемент позволяет управлять камерами, с которых осуществляется обзор
трехмерной модели. На нем справа располагаются кнопки, отвечающие за камеры, а
слева отображается схема размещения камер на экране (см. Рисунок 2.7).
27
Приложение позволяет одновременно отображать на экране картинку от одной до
четырех камер.
При этом на картинке отображается схема, в какой зоне экрана показывается, данные
какой из камер в какой области экрана отображаются.
Рисунок 2.7: Элемент выбора камер
При включении всего одной камеры она отображается на весь экран. При включении
двух камер они отображаются друг над другом, деля экран пополам (см. Рисунок 2.8). При
отображении трех камер одна из камер занимает нижнюю половину экрана, а две другие
делят пополам верхнюю половину экрана (см. Рисунок 2.9). При отображении четырех
камер они делят равномерно делят экран сеткой 2x2 (см. Рисунок 2.10).
Для добавления на экран картинки с дополнительной камеры нажмите на кнопку с
названием камеры. Камера добавится на трехмерную модель, а кнопка останется в
нажатом состоянии. Для удаления камеры с экрана нажмите на кнопку камеры,
присутствующей на экране. Камера будет удалена с экрана. В списке камер можно
выбрать стационарные камеры, камеры, закрепленные на роботе, а также свободную
камеру.
Свободная камера предназначена для того, чтобы осматривать взаимное
расположение объектов на трехмерной модели в сложных случаях, когда стационарные
28
камеры и камеры, закрепленные на насадках, не позволяют получить нужного обзора.
Управление свободной камерой осуществляется при помощи клавиатуры и мыши.
Клавиши w,a,s,d отвечают за перемещение вперед, влево, назад и вправо соответственно.
Движение мыши отвечает за поворот камеры. Для включения управления свободной
камерой необходимо удерживать нажатой левую кнопку мыши в окне симулятора, при
этом в окне симулятора отображается стрелка, показывающая, что свободная камера
включена (см.).
При работе с реальной системой управления роботом при выполнении
технологических операций свободная камера доступна не будет, поэтому при включении
отображения со свободной камеры в режиме имитации будет периодически выдаваться
предупреждение, что данный режим работы не соответствует реальному режиму работы.
При этом на записи действий пользователя будет отображено, в какие периоды времени
он использовал свободную камеру.
Рисунок 2.8: Расположение двух камер на экране симулятора
Управление камерами работает как в режиме имитации, так и в режиме
воспроизведения.
29
Рисунок 2.9: Расположение трех камер на экране симулятора
Рисунок 2.10: Расположение четырех камер на экране симулятора
30
Рисунок 2.11: Включенная свободная камера
2.2.3 Работа со сценами
Для загрузки новой сцены используется элемент управления сценами (см. Рисунок
2.12). Активация элемента управления сценами осуществляется нажатием кнопки «Выбор
сценария» на основном приложении. В режиме выбора сценария симулятор находится в
режиме паузы, остальные элементы управления заблокированы.
Рисунок 2.12: Элемент выбора сценария
Этот элемент управления предназначен для загрузки и сохранения сцен.
Для запуска сценария необходимо выбрать сценарий из дерева сценариев и нажать
на кнопку «Старт».
2.2.4 Окно симулятора
На основном окне симулятора отображается вид на объекты шахты реактора, в
соответствии с выбранной конфигурацией камер (см. Рисунок 2.13). В верхней левой части
31
окна расположена консоль, отображающая информационные служебные сообщения
системы и имеющая командный интерпретатор в нижней части консоли (см. раздел 2.3.2).
Для того чтобы показать или скрыть консоль, нажмите кнопку «~».
Рисунок 2.13: Окно симулятора с консолью
При касании роботом какого-либо объекта на сцене данный объект подсвечивается
красным цветом. Это сделано для упрощения контроля роботом.
2.2.5 Управление роботом Brokk
Управление роботами в приложении имитирует управление реальными роботами
Brokk с пультов управления Brokk (см. Рисунок 2.14).
Управление роботом BROKK возможно при помощи клавиатуры, а некоторые
действия также можно осуществлять с помощью геймпадов.
В приложении моделируются три робота Brokk. В связи с ограниченным количеством
элементов управления на клавиатуре и геймпадах, в любой момент времени возможно
одновременное управление только двумя из трех роботов.
Симулятор в помощью элементов управления клавиатуры и одного из двух геймпадов
имитирует пульт Brokk (см. Рисунок 2.15) С помощью кнопки «V» можно переключить
первый имитируемый пульт на неподключенный к имитируемому пульту робот, с
помощью кнопки «.» можно переключить второй имитируемый пульт на
32
неподключенный робот. Таким образом достигается возможность управления всеми
роботами.
Рисунок 2.14: Пульт управления Brokk
Имитируемый
пульт
Робот Brokk
Имитируемый
пульт
Робот Brokk
Робот Brokk
Рисунок 2.15: Соответствие имитируемых пультов и роботам Brokk
На рис. Рисунок 2.16 представлена схема пульта Brokk с указанием названий
элементов управления, а на рис. Рисунок 2.17 схема используемых геймпадов Logitech
Dual Action также с указанием названий элементов управления.
33
Рисунок 2.16: Схема пульта Brokk
Рисунок 2.17. Схема геймпада Logitech Dual Action
В табл. Таблица 2.1 представлено соответствие элементов управления пульта Brokk,
геймпада и клавиатуры.
Таблица 2.1: Соответствие элементов управления
Пульт Brokk
Геймпад
Клавиатура
34
Пульт Brokk
Геймпад
Клавиатура
B1 вверх
L_Up
2
8
B1 вниз
L_Down
W
I
B1 влево
L_Left
Q
U
B1 вправо
L_Right
E
O
B1.LL
5
1
7
B1.LR
7
3
9
B2 вверх
R_Up
S
K
B2 вниз
R_Down
X
,
B2 влево
R_Left
Z
M
B2 вправо
R_Right
C
.
B2.RL
6
A
J
B2.RR
8
D
L
S0 отжатие
T
P
S0 нажатие
R
[
S1
Y
]
S1 Extra on
Левый shift
Правый shift
S1 Extra off
Левый ctrl
Правый ctrl
S3 высокая скорость
F6
F12
S3 средняя скорость
F5
F11
S3 низкая скорость
F4
F10
S4 инструмент
F1
F7
F2
F8
F3
F9
5
-
одинарного действия
S4 инструмент
двойного действия
S4 инструмент
двойного действия с
повышенным рабочим
давлением
S5 управление
2
ходовой частью и
манипулятором
35
Пульт Brokk
Геймпад
Клавиатура
S5 управление
3
6
=
1
4
0
R1 увеличить поток
9
F
;
R1 уменьшить поток
10
G
‘
манипулятором
S5 управление
ходовой частью
На рис. Рисунок 2.18 более наглядно показано распределение кнопок клавиатуры по
двум имитируемым пультам Brokk.
Рисунок 2.18: Схема кнопок клавиатуры
Далее будет описан процесс управления одним роботом Brokk.
Для того чтобы начать управление роботом, необходимо включить пульт управления,
а затем завести робота.
Пульт управления в любой момент времени пребывает в некотором состоянии,
обусловленном положением переключателей на нем. Подробнее с логикой работы
пульта Brokk можно ознакомиться в [1].
Для того чтобы начать управление роботом, необходимо включить пульт управления,
а затем завести робота. После этого пульт управления робота перейдет в состояние
«Управление манипулятором» - «Инструмент одинарного действия».
Пульт управления имеет три режима функционирования робота:
– Управление ходовой частью
36
– Управление ходовой частью и манипулятором
– Управление манипулятором
Существуют также три режима функционирования насадки робота:
– Инструмент одинарного действия
– Инструмент двойного действия
– Инструмент двойного действия с повышенным рабочим давлением
Переключатель «Extra» меняет интерпретацию горизонтальной оси правого рычага
пульта управления, перенаправляя команды насадке.
Кроме того, существуют три скоростных режима, влияющих на скорость вращения
сегментов манипулятора:
– Высокая скорость
– Средняя скорость
– Низкая скорость
Также существует возможность увеличивать и уменьшать поток, подаваемый на
гидроцилиндры, результатом чего станет изменение скорости движения
манипулятора и насадки.
У робота можно увеличивать и уменьшать поток, подаваемый на гидроцилиндры,
результатом чего станет изменение скорости движения манипулятора и насадки.
Соответствие действий робота элементам управления приведен в табл. Таблица 2.2.
Для каждого имитируемого пульта выделен отдельный геймпад. В колонке «Клавиатура»
есть две подколонки, в которых написаны клавиши для каждого из двух имитируемых
пультов.
Таблица 2.2: Соответствие действий робота элементам управления устройств ввода
Действие робота
Пульт Brokk
Клавиатура
Геймпад
Включить пульт
S0 отжатие
T
{
Завести двигатель
S1
Y
}
Выключить пульт
S0 нажатие
R
P
Переключить на режим
S5 управление
4
0
1
5
-
2
«управление ходовой частью» ходовой частью
Переключить на режим
S5 управление
37
«управление ходовой частью
ходовой частью и
и манипулятором»
манипулятором
Переключить на режим
S5 управление
3
9
F1
F7
F2
F8
F3
F9
3
«управление манипулятором» манипулятором
Переключить на режим
S4 инструмент
«Инструмент одинарного
одинарного
действия»
действия
Переключить на режим
S4 инструмент
«Инструмент двойного
двойного
действия»
действия
Переключить на режим
S4 инструмент
«Инструмент двойного
двойного
действия с повышенным
действия с
рабочим давлением»
повышенным
рабочим
давлением
Включить режим «Extra»
S1 Extra on
Лев. Shift
Прав. Shift
Выключить режим «Extra»
S1 Extra off
Лев. Ctrl
Прав. Ctrl
Переключить на режим
S3 высокая
F6
F12
«Высокая скорость»
скорость
Переключить на режим
S3 средняя
F5
F11
«Средняя скорость»
скорость
Переключить на режим
S3 низкая
F4
F10
«Низкая скорость»
скорость
Увеличить поток
R1 увеличить
F
:
9
G
“
10
B1 влево
Q
U
L_Left
B1 вправо
E
O
L_Right
поток
Уменьшить поток
R1 уменьшить
поток
Опустить левые выносные
опоры
Поднять левые выносные
опоры
38
Опустить правые выносные
B2 вправо
Z
M
R_Right
B2 влево
C
>
R_Left
B1 вверх
2
8
L_Up
B1 вниз
W
I
L_Down
B2 вверх
S
K
R_Up
B2 вниз
X
<
R_Down
Движение гусениц вперед
B2.RL + B1.LL
A+1
J+7
6+5
Движение гусениц назад
B2.RL + B1.LR
A+3
J+9
6+7
Поворот оси манипулятора
B1 влево
Q
U
L_Left
B1 вправо
E
O
L_Right
B1 вверх
2
8
L_Up
B1 вниз
W
I
L_Down
B2 вниз
X
<
R_Down
B2 вверх
S
K
R_Up
B2 вправо
C
>
R_Right
B2 влево
Z
M
R_Left
B2 влево
Z
M
R_Left
опоры
Поднять правые выносные
опоры
Движение левой гусеницы
вперед
Движение левой гусеницы
назад
Движение правой гусеницы
вперед
Движение правой гусеницы
назад
налево
Поворот оси манипулятора
направо
Поднять третий сегмент
манипулятора
Опустить третий сегмент
манипулятора
Поднять второй сегмент
манипулятора
Опустить второй сегмент
манипулятора
Поднять четвертый сегмент
манипулятора
Опустить четвертый сегмент
манипулятора
Движение насадки в
«прямом» направлении (при
39
включенном режиме «Extra»)
Движение насадки в
B2 вправо
C
>
R_Right
B2.RR + B2 вверх
D+S
L+K
8 + R_Up
B2.RR + B2 вниз
D+X
L+<
8+
«обратном» направлении
(при включенном режиме
«Extra»)
Расширить зону действия
манипулятора
Сократить зону действия
манипулятора
R_Down
Первое действие насадки
B1.LL
1
7
5
Второе действие насадки
B1.LR
3
9
7
2.2.6 Управление аварийными состояниями блоков
Для отображения схемы размещения блоков в различных состояниях на модели
используется элемент отображения состояний блоков (см. Рисунок 2.19). В процессе
симуляции пользователь имеет возможность изменить состояние блоков реактора.
Для изменения состояния блоков необходимо на элементе контроля состояний
блоков выбрать соответствующий блок и в верхней части элемента управления выбрать
его состояние. В случае, если задается слипшийся блок дополнительно следует указать
блок, с которым произошло слипание. Аварийные состояния блоков рассмотрены в
разделе 3.1.1.
2.2.7 Отображение действий пользователя
В процессе симуляции также отображаются действия пользователя, которые он
совершал в процессе отработки технологической последовательности. Это делается путем
подсветки элементов управления на пультах Brokk, которые соответствуют нажатым
пользователем элементам управления на клавиатуре и геймпадах (см. Рисунок 2.20,
подсвечен правый рычаг).
40
Трещиноватый
блок
Трещиноватые
слипшиеся
блоки
Слипшиеся
блоки
Рисунок 2.19: Элемент управления аварийными состояниями блоков
41
Рисунок 2.20: Подсветка пульта Brokk
2.3 Руководство администратора ИОТ
В данном разделе приведено руководство администратора ИОТ – описаны
управление настройками модуля симулятора и консольные команды симулятора.
2.3.1 Управление настройками симулятора
Настройки симулятора находятся в файле simulatorSettings.xml. Каждому
настраиваемому параметру соответствует теги, между которыми указано его значение.
Ниже приведено содержание файла по умолчанию.
<?xml version="1.0"?>
<ApplicationSettings xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<DisplayWidth>1024</DisplayWidth>
<DisplayHeight>768</DisplayHeight>
<QualityLevel>2</QualityLevel>
<BlockLayersNumber>1</BlockLayersNumber>
<ConsoleEnabled>true</ConsoleEnabled>
</ApplicationSettings>
Перечислим параметры:
– DisplayWidth – ширина экрана симулятора. Целое положительно число или «auto»,
чтобы ширина выставлялась равной ширине дисплея, на котором располагается окно.
– DisplayHeight – высота экрана симулятора. Целое положительно число или «auto»,
чтобы высота выставлялась равной высота дисплея, на котором располагается окно.
– QualityLevel – уровень качества изображения, целое число от 1 до 10. С увеличением
числа качество изображения растет.
42
– BlockLayersNumber – количество слоев блоков в шахте, целое положительное число.
Параметр предусмотрен, поскольку при увеличении количества слоев блоков
производительность симулятора падает.
– ConsoleEnabled – «true» для включенной консоли, «false» для выключенной консоли.
Если консоль выключена, то ее нельзя отобразить на экране.
При некорректном вводе какого-то из параметров или повреждении структуры файла
с настройками при запуске симулятора в консоль выводится сообщение об ошибке.
2.3.2 Консольные команды
Как было сказано в разделе 2.2.4, консоль позволяет вводить команды. Список
доступных команд с их параметрами представлен в табл. Таблица 2.3.
Таблица 2.3: Консольные команды
Команда
Описание
Параметры
re
Перезапустить сценарий
cnslvl
Установить уровень
Указывается уровень сообщений:
сообщений, выводимых в
0 – сообщения стека вызовов
консоли
1 – отладочные сообщения
2 – информационные сообщения
3 - предупреждения
4 – ошибки
rotc
Повернуть робот по часовой
Указывается имя поворачиваемого робота:
стрелке
collet – робот с цанговым захватом
grip – робот с захватом-манипулятором
saw – робот с циркулярной пилой
rotcc
Повернуть робот против
см. команду rotc
часовой стрелки
dstrplt
Уничтожить плиту настила
Указывается номер плиты от 0 до 27
dstrcap
Уничтожить крышку
Указывается номер крышки – 0 или 1
контейнера
mkcrk
Сделать блок трещиноватым
Указывается номер блока
43
3 Конструкторская часть
В данном разделе описаны фрагменты трехмерной инженерной модели объекта
исследования, приведена структурная схема программного комплекса, перечислены
некоторые архитектурные решения и приемы объектно-ориентированного
программирования, использованные при разработке программного комплекса.
3.1 Описание конструкции шахты реактора
Рассмотрим моделируемое пространство – шахту реактора (см. Рисунок 3.1).
Блоки
Внешний
протектор шахты
Плита
настила
Карусель
Контейнер
для отходов
Стояк СУЗ
Рисунок 3.1: Шахта реактора
Внешний протектор шахты располагается в реакторном помещении. Внутри
протектора располагаются около 20 слоев графитовых и чугунных блоков вместе со
стояками СУЗ, располагающихся от верхнего слоя блоков до самого нижнего. Для
демонтажа кладки реактора необходимо послойно удалять блоки из кладки, отпиливая
верхние части стояков СУЗ, чтобы они не мешали удалению текущего слоя кладки.
44
3.1.1 Аварийные состояния блоков
Большинство блоков в шахте реактора находятся в различных аварийных ситуациях. В
программе моделируются следующие аварийные ситуации:
– Трещиноватость блока
– Слипание нескольких блоков
Здесь и далее под трещиноватым блоком будет понимать блок, который при попытке
захвата его цанговым захватом имеет вероятность треснуть, развалившись на несколько
частей, в зависимости от давления на него со стороны цангового захвата (см. Рисунок 3.2).
Рисунок 3.2: Целый и треснувший блоки
Рисунок 3.3: Изъятие массива из трех слипшихся блоков
45
При слипании несколько соседних блоков в пределах одного или нескольких слоев
слипаются в единый массив (см. Рисунок 3.3). Здесь и далее под слипшимся блоком будет
понимать блок, содержащийся в массиве слипшихся друг с другом блоков. Поскольку
манипулятор робота Brokk имеет ограничение в грузоподъемности, то невозможно
поднять достаточно крупный массив слипшихся блоков. В этом случае необходимо
ударами насадок разбивать эти массивы на массивы меньшего размера, которые уже
можно поднять.
3.1.2 Технология демонтажа
Опишем предлагаемую технологию демонтажа в виде пошагового алгоритма.
1 В шахту реактора с помощью крана опускается карусель с настилом, затем три робота
Brokk и два контейнера для отходов.
2 Начало извлечения блоков очередного слоя, сопровождаемое опусканием карусели,
если номер демонтируемого слоя кратен трем.
3 Робот с захватом-манипулятором поднимает очередную плиту настила и кладет в
сторону, робот с цанговым захватом и робот с циркулярной пилой подъезжают к
открытым блокам.
4 Извлекаются все блоки под отодвинутой плитой, при необходимости спиливаются
верхушки стояков СУЗ, мешающих извлечению блоков. При заполнении контейнера с
отходами он извлекается краном из шахты, после чего пустой возвращается на настил.
5 Робот с захватом-манипулятором возвращает плиту на место, и, если блоки были
извлечены под каждой плитой, то переход к шагу 6, иначе к шагу 3.
6 Если были демонтированы все слои, то карусели, роботы и контейнеры извлекаются
из шахты, иначе переход к шагу 2.
3.2 Применение паттернов проектирования
В данном разделе рассмотрено применение паттернов проектирования ([3]) при
решении проблем проектирования объектной модели модуля симулятора. Для
графического пояснения вводимых структур используются UML-диаграммы ([2]).
Описания классов с помощью диаграмм классов в дальнейших подразделах данного
раздела в большинстве случаев представляют собой сокращения – рассматриваются
46
только те поля, методы и свойства классов, которые представляют интерес в приводимых
примерах.
3.2.1 Применение паттерна Mediator в слоевой архитектуре симулятора
3.2.2 Применение паттернов Publisher, Subscriber и Singleton для
реализации шины обмена событиями
В определенный момент проектирования объектной модели симулятора встал вопрос
о том, как организовать связь между различными объектами, т.е. позволить им
отправлять друг другу некоторые сообщения.
Возможным вариантом является хранение в каждом объекте информации о том, кому
он должен отправлять сообщения и от кого принимать. Схематично возникающая
ситуация отображена на Рисунок 3.4.
Рисунок 3.4: Децентрализованный обмен сообщениями
Однако данный подход увеличивает связность объектной модели, что затрудняет ее
дальнейшую разработку и расширяемость.
Необходим объект, который будет заниматься сбором и отправкой сообщений.
Преобразованная схема обмена сообщениями изображена на Рисунок 3.5.
Как видно из схемы, объекты 1, 2, 3 и 4 более не связаны друг с другом, а посылают
друг другу сообщения через некоторый новый объект.
Этим объектом является EventBus. EventBus представляет собой singleton, что
обеспечивает глобальную точку доступа к нему. EventBus содержит в себе списки двух
типов объектов – публикаторов (паттерн publisher), публикующих события, и подписчиков
(паттерн subscriber), получающих сообщения. Соответственно, если объекту требуется
47
посылать некоторые сообщения, то он должен реализовывать интерфейс IEventPublisher,
единственный метод GetEvents() которого получает список сообщений, публикуемых
объектов на данный момент. Если объекту требуется принимать сообщения, то он должен
реализовывать интерфейс IEventSubscriber, где в методе OnEvent(IEvent) происходит
обработка входящего сообщения. Диаграмма классов EventBus, IEventPublisher и
IEventSubscriber приведена на Рисунок 3.6.
Рисунок 3.5: Централизованный обмен сообщениями
class Class Model
«interface»
IEv entSubscriber
Ev entBus
-
mInstance: EventBus
mPublishers: List<IEventPublisher>
mStartEvent: StartEvent
mSubscribers: List<IEventSubscriber>
+
+
+
+
+
+
AddPublisher(IEventPublisher) : void
AddSubscriber(IEventSubscriber) : void
EventBus()
GetInstance() : EventBus
RemovePublisher(IEventPublisher) : void
RemoveSubscriber(IEventSubscriber) : void
Run() : void
+
OnEvent(IEvent) : void
«interface»
IEv entPublisher
+
GetEvents() : List<IEvent>
Рисунок 3.6: Диаграмма классов EventBus, IEventPublisher, IEventSubscriber
Интерфейс IEvent позволяет создавать любые сообщения, чтобы потом их можно
было посылать через шину. На Рисунок 3.7 приведена диаграмма классов с интерфейсом
IEvent и двумя классами-сообщениями – StartEvent, который в первую очередь
48
посылается всем подписчикам шины, и InputEvent, информирующем о том, что были
нажаты некоторые элементы управления на пульте Brokk.
Для доступа к единственному экземпляру EventBus используется статический метод
GetInstance(), который при первом вызове создает экземпляр.
class Class Model
«interface»
IEv ent
InputEv ent
StartEv ent
-
mControls: List<BrokkControls>
+
+
+
GetControls() : List<BrokkControls>
InputEvent(List<BrokkControls>)
ToString() : string
+
StartEvent()
Рисунок 3.7: Диаграмма классов IEvent, InputEvent, StartEvent
Для добавления и удаления публикатора в список публикаторов шины событий
используются методы AddPublisher() и RemovePublisher() соответственно, аналогично для
добавления и удаления подписчика.
EventBus каждый квант времени запускает метод Run(), в котором сначала всем
подписчикам рассылается сообщение StartEvent (некоторым подписчикам это
необходимо как средство для синхронизации или отработки дополнительной логики), а
затем идет сбор сообщений со всех публикаторов, и эти сообщения потом отправляются
всем подписчикам. При такой логике работе подписчик может получить сообщение,
которое ему не нужно, поэтому в начале метода OnEvent(IEvent) ставятся охранные
условие, проверяющие тип входящего сообщения.
В качестве примера использования шины события можно привести объекты Brokk и
ControlPanel, представляющие собой робот и пульт управления, соответственно.
Поскольку ControlPanel отображает реальный пульт, то этот объект является
публикатором, поскольку при активации элементов управления пульта посылаются
управляющие сигналы роботу. Brokk при этом является подписчиком на эти управляющие
сигналы.
49
ControlPanel генерирует действия BrokkAction в соответствии со своим внутренним
состоянием и активированными элементами управления пульта BrokkControls, и затем
посылает объекту Brokk сообщение ActionEvent, содержащее в себе действие, которое
роботу необходимо осуществить. Список осуществляемых роботом действий представлен
в перечислении BrokkAction. Например, при получении сообщения с действием
BrokkAction.MoveTruckLeftForward робот двигает вперед левую гусеницу. Диаграмма
классов для примера приведена на Рисунок 3.8.
class Class Model
«enumeration»
BrokkAction
MoveTruckLeftForward
MoveTruckRightForward
MoveTruckLeftBackward
MoveTruckRightBackward
Brokk : IEv entSubsriber
-
mLeftTruck: Truck
mRightTruck: Truck
+
+
-
Brokk()
OnEvent(IEvent) : void
ProcessActionEvent(ActionEvent) : void
ActionEv ent : IEv ent
mAction: BrokkAction
+
+
ActionEvent(BrokkAction)
GetAction() : BrokkAction
«enumeration»
BrokkControls
ControlPanel : IEv entPublisher
+
+
-
ControlPanel()
GenerateActions(List<BrokkControls>) : List<BrokkAction>
GetEvents() : List<IEvent>
L1Up
L1Down
L2Up
L2Down
Рисунок 3.8: Диаграмма классов Brokk, ActionEvent, ControlPanel
3.2.3 Применение паттерна State в диаграмме состояний пульта Brokk
50
4 Организационно-экономическая часть
4.1 Введение
Разрабатываемое в рамках дипломной работы программное обеспечение является
имитационно-обучающим тренажером по демонтажу блоков АЭС. Этот инструмент
позволяет проводить моделирование демонтажа кладки реактора в режиме реального
времени.
Разрабатываемый тренажер предназначен для верификации технологии демонтажа
блоков АЭС, для решения задач оптимизации рабочего процесса демонтажа, а также для
отработки персоналом операций, осуществляемых при демонтаже. Актуальность
разработки тренажера следует из актуальности проблемы демонтажа блоков АЭС.
Целью данного раздела является расчет сметы затрат на проведение НИОКР
разработку и тестирование имитационно-обучающего тренажера.
4.2 Расчет трудоемкости проекта
Рассчитаем трудоемкость проекта. Разработка ПП разбивается на следующие этапы:
техническое задание; эскизный проект; технический проект; рабочий проект; внедрение
(см. Таблица 4.1):
Таблица 4.1: Основные этапы разработки ПП
№ этапа
1
Название этапа
Техническое задание (ТЗ)
Общий состав работ этапа
Предпроектное исследование.
Разработка ТЗ.
2
Эскизный проект (ЭП)
Уточнение структуры и формы представления
входных и выходных данных. Разработка
алгоритма решения задачи. Разработка
структуры программы.
Разработка пояснительной записки.
Согласование и утверждение технического
проекта.
3
Технический проект (ТП)
Разработка алгоритмов (общих алгоритмов и
51
структуры данных, структуры основных и
вспомогательных модулей и др.), выбор среды
программирования.
4
Рабочий проект (РП)
Описание программы на языке
программирования.
Разработка, создание и утверждение порядка и
методики испытаний, корректировка
программы.
5
Внедрение (В)
Разработка программной документации.
Подготовка и передача программы и
программной документации для
сопровождения и изготовления, оформления и
утверждения акта о передаче ПП на
сопровождение. Передача ПП заказчику.
Рассчитаем трудоемкость каждого из указанных этапов.
Трудоемкость разработки программной продукции зависит от степени новизны
разработки, сложности алгоритма ее функционирования, объема используемой
информации и вида ее обработки, уровня используемого алгоритмического языка
программирования.
По степени новизны разрабатываемая программная продукция может быть отнесена
к одной из четырех групп (см. Таблица 4.2):
Таблица 4.2: Классификация степени новизны разрабатываемой ПП
Название
Описание
группы
А
Разработка программных комплексов, требующих использования
принципиально новых методов их создания, проведение НИРС и т.п.
Б
Разработка программной продукции, не имеющей аналогов, в том числе
разработка пакетов прикладных программ.
В
Разработка программной продукции, имеющей аналоги.
Г
Разработка программной продукции, основанной на привязке типовых
проектных решений.
52
В данном случае разрабатываемая программа относится к уровню «В».
Трудоемкость разработки программной продукции 𝜏ПП может быть определена как
сумма величин трудоемкости выполнения отдельных этапов разработки ПП:
𝜏ПП = 𝜏ТЗ + 𝜏ЭП + 𝜏ТП + 𝜏РП + 𝜏В
где 𝜏ТЗ – трудоемкость разработки технического задания на создание ПП; 𝜏ЭП –
трудоемкость разработки эскизного проекта; 𝜏ТП – трудоемкость разработки технического
проекта ПП; 𝜏РП – трудоемкость разработки рабочего проекта ПП; 𝜏В – трудоемкость
внедрения разработанного ПП.
Трудоемкость разработки технического задания рассчитывается по формуле:
𝜏ТЗ = ТЗРЗ + ТЗРП ,
где ТЗРЗ – затраты времени разработчика постановки задач (проектировщика) на
разработку ТЗ, чел.-часы; ТЗРП – затраты времени разработчика программного
обеспечения на разработку ТЗ, чел.-часы.
Значения ТЗРЗ и ТЗРП рассчитываются по формулам:
ТЗРЗ = 𝑡З КЗРЗ ;
ТЗРП = 𝑡З КЗРП ,
где 𝑡З – норма времени на разработку ТЗ на ПП в зависимости от функционального
назначения и степени новизны разрабатываемого ПП, чел.-часы; КЗРЗ – коэффициент,
учитывающий удельный вес трудоемкости работ, выполняемых разработчиком
постановки задач на стадии технического задания (в случае совместной с разработчиком
ПП разработки технического задания КЗРЗ = 0,65); КЗРП – коэффициент, учитывающий
удельный вес трудоемкости работ, выполняемых разработчиком ПП на стадии
технического задания (в случае совместной с разработчиком постановки задач КЗРП =
0,35).
В данной работе решаются задачи повышения эффективности труда персонала,
поэтому разрабатываемое в ходе дипломного проектирования ПО можно отнести к
функциональному назначению ПП «Техническая подготовка производства». Учитывая
также, что по степени новизны продукция относится к группе «В», расчет времени на
подготовку ТЗ будет следующим:
ТЗРЗ = 31 ∙ 0,65 = 20,15;
ТЗРП = 31 ∙ 0,35 = 10,85.
53
Следовательно, подставив полученные значения в исходную формулу для расчета
трудоемкости разработки технического задания, получим:
𝜏ТЗ = 20,15 + 10,85 = 31.
Т.е. трудоемкость разработки технического задания составляет 111 человеко-часов.
Трудоемкость разработки эскизного проекта рассчитывают по формуле:
𝜏ЭП = ТЭРЗ + ТЭРП ,
где ТЭРЗ – затраты времени разработчика постановки задач на разработку эскизного
проекта, чел.-часы; ТЭРП – затраты времени разработчика программного обеспечения на
разработку эскизного проекта, чел.-часы.
Значения ТЭРЗ и ТЭРП соответственно рассчитываются по формулам:
ТЭРЗ = 𝑡Э КЭРЗ ;
ТЭРП = 𝑡Э КЭРП ,
где 𝑡Э – норма времени на разработку эскизного проекта на ПП в зависимости от
функционального назначения и степени новизны разрабатываемого ПП, чел.-часы; КЭРЗ –
коэффициент, учитывающий удельный вес трудоемкости работ, выполняемых
разработчиком постановки задач на стадии эскизного проекта; КЭРП – коэффициент,
учитывающий удельный вес трудоемкости работ, выполняемых разработчиком ПП на
стадии эскизного проекта.
Установив необходимые значения переменных и коэффициентов, исходя из
оговоренных выше соображений, рассчитаем ТЭРЗ и ТЭРП :
ТЭРЗ = 67 ∙ 0,5 = 33,5;
ТЭРП = 67 ∙ 0,5 = 33,5.
Подставляя полученные значения в исходную формулу, вычисляем 𝜏ЭП :
𝜏ЭП = 33,5 + 33,5 = 67.
Следовательно, трудоемкость разработки эскизного проекта составляет 108 человекочасов.
Трудоемкость разработки технического проекта 𝜏ТП зависит от функционального
назначения ПП, количества разновидностей форм входной и выходной информации и
определяется как сумма времени, затраченного постановщиком задач и разработчиком
ПП:
𝜏ТП = (𝑡ТРЗ + 𝑡ТРП ) ∙ КВ ∙ КР ,
54
где 𝑡ТРЗ и 𝑡ТРП – нормы времени, затрачиваемого на разработку технического проекта
постановщиком задач и разработчиком ПП соответственно, чел.-часы; КВ – коэффициент
учета вида используемой информации; КР – коэффициент учета режима обработки
информации (при разработке технического проекта КР = 1,10).
ПП проводит моделирование объектов шахты реактора АЭС. По соответствующей
этим данным норме времени на выполнение работ при разработке ТП по управлению
организацией и оплатой труда определим 𝑡ТРЗ и 𝑡ТРП :
𝑡ТРЗ = 21 и 𝑡ТРП = 9 человеко-часов.
Значение коэффициента КВ определяют из выражения:
КВ =
КП 𝑛П + КНС 𝑛НС + КБ 𝑛Б
,
𝑛П + 𝑛НС + 𝑛Б
где КП , КНС и КБ – значения коэффициентов учета вида используемой информации
для переменной, нормативно-справочной информации и баз данных соответственно; 𝑛П ,
𝑛НС и 𝑛Б – количество наборов данных переменной, нормативно-справочной информации
и базы данных соответственно.
Специфика задачи подразумевает работу с переменной информацией, поэтому
коэффициенты КНС и КБ в данном случае не учитываются. КП для группы новизны «В»
равен 1,00.
Подставив полученные значения, рассчитаем трудоемкость разработки технического
проекта 𝜏ТП :
1,00 ∙ 1
𝜏ТП = (21 + 9) ∙ (
) ∙ 1,10 = 33.
1
Таким образом, трудоемкость разработки технического проекта составляет 33
человеко-часа.
Трудоемкость разработки рабочего проекта 𝜏РП зависит от функционального
назначения ПП и точности проводимого моделирования. Трудоемкость 𝜏РП вычисляется
по формуле
𝜏РП = (𝑡РРЗ + 𝑡РРП ) ∙ КК ∙ КР ∙ КЯ ∙ КЗ ∙ КИА ,
где 𝑡РРЗ и 𝑡РРП – нормы времени, затрачиваемого на разработку рабочего проекта на
алгоритмическом языке высокого уровня разработчиком постановки задач и
разработчиком ПП соответственно, чел.-часы; КК – коэффициент учета сложности
контроля информации; КР – коэффициент учета режима обработки информации; КЯ –
коэффициент учета уровня алгоритмического языка программирования; КЗ –
55
коэффициент учета степени использования готовых программных модулей; КИА –
коэффициент учета вида используемой информации и сложности алгоритма ПП.
Значение коэффициента КИА определяют из выражения:
КИА =
К′П 𝑛П + К′НС 𝑛НС + К′Б 𝑛Б
𝑛П + 𝑛НС + 𝑛Б
где К′П , К′НС и К′Б – значения коэффициентов учета сложности алгоритма ПП и вида
используемой информации для переменной, нормативно-справочной информации и баз
данных соответственно.
Из справочной таблицы для статистических проектов получаем:
𝑡РРЗ = 17 и 𝑡РРП = 80 человеко-часов.
С учетом специфики проекта, используя справочные таблицы, получим значения
коэффициентов:
КР = 1,36; КК = 1,16; КЯ = 1; КЗ = 0,8; К′П = 1,20; 𝑛П = 1; К′НС = 0; 𝑛НС = 0; К′Б = 0;
𝑛Б = 0.
Подставив все полученные значения в формулу, рассчитаем трудоемкость разработки
рабочего проекта 𝜏РП :
𝜏РП = (17 + 80) ∙ 1,16 ∙ 1,36,∙ 1 ∙ 0,8 ∙ 1,20 = 147.
Таким образом, трудоемкость разработки рабочего проекта составляет 147 человекочасов.
В данном случае при разработке ПП стадии «Технический проект» и «Рабочий проект»
объединяются в одну, и ее трудоемкость 𝜏ТРП составляет:
𝜏ТРП = 0,85𝜏ТП + 𝜏РП .
Таким образом, 𝜏ТРП = 0,85 ∙ 33 + 147 = 176 человеко-часов.
Трудоемкость выполнения стадии «Внедрение» рассчитывается по формуле:
𝜏В = (𝑡ВРЗ + 𝑡ВРП ) ∙ КК ∙ КР ∙ КЗ ,
где 𝑡ВРЗ и 𝑡ВРП – норма времени, затрачиваемого разработчиком постановки задач и
разработчиком ПП соответственно на процедуру внедрения ПП, чел.-часы.
Используя ранее определенные значения коэффициентов и определяя 𝑡ВРЗ и 𝑡ВРП из
справочных таблиц, находим трудоемкость стадии внедрения 𝜏В :
𝜏В = (8 + 16) ∙ 1,16 ∙ 1,36 ∙ 0,8 = 31.
Таким образом, трудоемкость стадии внедрения составляет 31 человеко-часа.
Общие затраты труда на разработку и внедрение ПП определяются следующим
образом:
56
𝜏ПП = 𝜏ТЗ + 𝜏ЭП + 𝜏ТП + 𝜏РП + 𝜏В = 31 + 67 + 147 + 31 = 276.
Общее значение трудозатрат для разработки ПП равно 276 человеко-часов. При 8часов рабочем дне, на разработку ПП необходимо 35 рабочих дней. Если считать, что
среднее число рабочих дней в месяце составляет 22, то трудоемкость разработки данного
ПП составляет 1,6 месяцев или 50 календарных дней.
Полный перечень работ с разделением их по этапам выполнения проекта
представлен в таблице Таблица 4.3:
Таблица 4.3: Этапы выполнения проекта
Этап
№ работы
Содержание работы
Трудоемкость,
чел/дни
I
1
Составление технического задания.
2
2
Сбор информации о существующих
2
методах и разработках.
II
3
Изучение технической литературы.
3
III
4
Разработка архитектуры
2
программного комплекса.
5
Разработка модуля симулятора.
11
6
Разработка модуля графического
9
интерфейса
IV
7
Написание сопроводительной
3
документации.
8
Проведение испытаний.
3
4.3 Определение количества исполнителей проекта
Для оценки возможности выполнения проекта имеющимся в распоряжении
разработчика штатным составом исполнителей рассчитывается их средняя численность,
которая при реализации проекта разработки и внедрения ПО определяется
соотношением:
𝑁=
𝑄𝑝
,
𝐹
57
где 𝑄𝑝 - затраты труда на выполнение проекта (разработка и внедрение ПО), F — фонд
рабочего времени.
Величина фонда рабочего времени определяется соотношением:
𝐹 = 𝑇 ∙ 𝐹𝑀 ,
где Т — время выполнения проекта в месяцах (как правило, устанавливается
заказчиком проекта), 𝐹𝑀 — фонд времени в текущем месяце, который рассчитывается из
учета общего числа дней в году, числа выходных и праздничных дней:
𝐹𝑀 =
𝑡𝑝 ∙ (𝐷𝐾 − 𝐷𝐵 − 𝐷П )
,
12
где 𝑡𝑝 — продолжительность рабочего дня, 𝐷𝐾 — общее число дней в году, 𝐷𝐵 —
число выходных дней в году, 𝐷П — число праздничных дней в году.
Таким образом, фонд времени в одном месяце составляет:
𝐹𝑀 =
8 ∙ (365 − 104 − 12)
= 166 часов/мес.
12
Время выполнения проекта (Т) — 1,6 месяцев. Следовательно, величина фонда
рабочего времени составляет 266 час.
Затраты труда на выполнения проекта, рассчитанные в предыдущем разделе,
составляют 276 чел/час. В соответствии с этими данными, среднее количество
исполнителей равно:
𝑁=
276
= 1,05 чел.
266
Поскольку число исполнителей не превосходит одного более чем на 10%, округляем
его в меньшую сторону. Таким образом, получим число исполнителей проекта N = 1.
4.4 Календарный график выполнения проекта
Для иллюстрации последовательности проводимых работ проекта применяют
ленточный график (календарно-сетевой график, диаграмму Ганта). На диаграмме Ганта на
оси Х показывают календарные дни (по рабочим неделям) от начала проекта до его
завершения. По оси Y - выполняемые этапы работ.
Список работ с их описаниями представлен в таблице Таблица 4.4.
Таблица 4.4: Описание работ
Номер
Наименование
Должности
Число исп-ей
работы
работы
исполнителей
58
Продолжительно
сть Ti, дни
1
Составление
Разработчик,
2
2
технического
проектировщик
Разработчик
1
2
Изучение
Разработчик,
2
3
технической
проектировщик
Проектировщик
1
2
Разработчик
1
11
Разработчик
1
9
Написание
Технический
1
3
сопроводительной
писатель
1
3
задания.
2
Сбор информации
о существующих
методах и
разработках.
3
литературы.
4
Разработка
архитектуры
программного
комплекса
5
Разработка модуля
симулятора.
6
Разработка модуля
графического
интерфейса.
7
документации.
8
Проведение
Тестировщик
испытаний.
Построим диаграмму Ганта процесса разработки. Этапы 7 и 8 могут выполняться
параллельно. Диаграмма представлена на рис. Рисунок 4.1.
Рисунок 4.1: Диаграмма Ганта
59
После распараллеливания этапов 7 и 8 общее количество календарных дней,
необходимых на выполнение задания стало равным 44.
4.5 Определение сметы затрат
Затраты на разработку программного продукта (далее – ПП) могут быть представлены
в виде сметы затрат, включающей в себя следующие статьи (см. Таблица 4.5):
Таблица 4.5: Структура сметы затрат на разработку ПП
№
Наименование статьи
Удельный вес, %
1
Материальные
10
2
Заработная плата
3
Отчисления на социальные нужды
4
Амортизационные отчисления
30
5
Прочие затраты
15
45
Итого
100
4.6 Расчет затрат
Затраты на выполнение проекта состоят из прямых затрат (на заработную плату
исполнителям, затрат на закупку или аренду оборудования, затрат на организацию
рабочих мест), и косвенных затрат (на т.н. накладные расходы):
𝐾 = СЗАРП + СОБ + СОРГ + СНАКЛ ,
где СЗАРП - заработная плата исполнителей, СОБ - затраты на обеспечение
необходимым оборудованием, СОРГ - затраты на организацию рабочих мест, СНАКЛ накладные расходы.
Рассчитаем все составляющие затрат на разработку ПП.
4.6.1 Затраты на выплату заработной платы
Затраты на выплату исполнителям заработной платы линейно связаны с
трудоемкостью и определяется следующим соотношением:
СЗАРП = СЗ.ОСН. + СЗ.ДОП. + СЗ.ОТЧ. ,
где СЗ.ОСН. — основная заработная плата, СЗ.ДОП. — дополнительная заработная плата,
СЗ.ОТЧ. — отчисление с заработной платы.
Расчет основной заработной платы (оплаты труда непосредственных исполнителей):
60
СЗ.ОСН. = Тзан × Одн ,
где Тзан — число дней, отработанных исполнителем проекта, Одн — дневной оклад
исполнителя.
При 8-и часовом рабочем дне он рассчитывается по соотношению:
Одн =
Омес ∙ 8
,
𝐹𝑀
где Омес - месячный оклад, 𝐹𝑀 - месячный фонд рабочего времени.
С учетом налога на доходы физических лиц размер оклада увеличивается, что
отражено в формуле:
Oмес = O ∗ (1 +
Hндфл
),
100
где O — «чистый» оклад, Hндфл — налог на доходы физических лиц в размере 13% .
Результаты расчета с перечнем исполнителей и их месячных и дневных окладов, а
также их трудозатратах и рассчитанной основной заработной платой каждого
исполнителя приведены в таблице Таблица 4.6.
Таблица 4.6: Затраты на основную заработную плату сотрудников
№
Должность
«Чистый»
Дневной
Трудозатраты,
Затраты на
оклад, руб.
оклад, руб.
чел. – дни
зарплату, руб.
1
Проектировщик
50000
2272,7
7
15904
2
Разработчик
50000
2272,7
27
61344
3
Технический
25000
1136,4
3
3409
30000
1363,6
3
4090
писатель
4
Тестировщик
итого
84747
Следовательно, общие затраты на заработную плату исполнителям проекта составят
СЗ.ОСН. = 84747руб.
Расходы на дополнительную заработную плату учитывают все выплаты
непосредственным исполнителям за время, не проработанное на производстве, но
предусмотренное законодательством. Величина этих выплат составляет 20% от размера
основной заработной платы:
СЗ.ДОП. = 0,2 ∙ СЗ.ОСН.
Расходы на дополнительную заработную плату составят:
61
СЗ.ДОП. = 0,2 ∙ 84747 = 16 950 руб.
Отчисления с заработной платы состоят в настоящее время в уплате единого
социального налога. Налоговым кодексом РФ определяются ставки налога для
отчисления в пенсионный фонд РФ, фонд социального страхования, фонды обязательного
медицинского страхования (федеральный и территориальный фонды). На момент расчета
рассматривается закон о снижении суммы ставок ЕСН с 34% до 26%, поэтому для расчета
принято решение считать суммой ставок 26%.
Отчисления с заработной платы составят:
СЗ.ОТЧ. = (СЗ.ОСН. + СЗ.ДОП. ) ∙ НСОЦ = (84 747 + 16 950) ∙ 0,26 = 26 440
Таким образом, общие затраты на заработную плату составят:
СЗАРП = 84 747 + 16 950 + 26 440 = 128 137 руб.
4.6.2 Затраты на оборудование
В совокупные затраты на реализацию проекта также необходимо включить стоимость
оборудования. Оборудование, необходимое для работы разработчиков ПП перечислено в
таблице Таблица 4.7.
Таблица 4.7: Затраты на оборудование
Наименование оборудования
Количество, шт.
Общая стоимость, руб.
Ноутбуки
2
50 000
Следовательно, затраты на оборудование с учетом того, что оно может быть
использовано в дальнейшем после разработки ПП, составят 12 000 руб.
4.6.3 Затраты на организацию рабочих мест
Расчет затрат, связанных с организацией рабочих мест для исполнителей проекта,
проводится на основе требований СНИПа (санитарные нормы и правила) и стоимости
аренды помещения требуемого уровня сервиса.
В соответствии с санитарными нормами расстояние между рабочими столами с
видеомониторами должно быть не менее 2 м., а между боковыми поверхностями
видеомониторов - не менее 1,2 м. Площадь на одно рабочее место с терминалом или ПК
должна составлять не менее 6 кв.м., а объем - не менее 20 куб.м.. Расположение рабочих
мест в подвальных помещениях не допускается. Помещения должны быть оборудованы
62
системами отопления, кондиционирования воздуха или эффективной приточно-вытяжной
вентиляцией.
Исходя из данных требований и учитывая количество сотрудников, площадь рабочего
помещения должна составлять не менее 20 кв. м. При этом выбор географического
расположения рабочего помещения значения не имеет. Средняя цена аренды офисов
класса B в пределах Москвы составляет 5000 рублей за кв. м. в год. Затраты на аренду
помещения вычисляются исходя из соотношения:
СОРГ =
СКВМ
∙ 𝑆 ∙ 𝑇𝐴𝑃 ,
12
где СКВМ - стоимость аренды одного кв. метра площади за год, S - арендуемая
площадь рабочего помещения, 𝑇𝐴𝑃 - срок аренды (календарный) в месяцах.
Следовательно, затраты на аренду помещения на время выполнения проекта
составят:
СОРГ =
5000
∙ 20 ∙ 2 = 16 667 руб.
12
4.6.4 Накладные расходы
Накладные расходы, связанные с выполнением проекта, вычисляются в соответствии
с расходами на основную заработную плату. Обычно они составляют от 60% до 100% от
их размера.
Величина этих затрат Снак характеризует зарплату «неосновным» исполнителям:
Снак = Кнакл ∙ Сз.осн.
Таким образом, накладные расходы составят:
Снак = 0,6 ∙ 84 747 = 50 850 руб.
4.6.5 Суммарные затраты
Подставив результаты, полученные в процессе вычислений затрат в формулу
𝐾 = СЗАРП + СОБ + СОРГ + СНАКЛ ,
определим суммарные затраты на реализацию проекта:
𝐾 = 128 137 + 12 000 + 16 667 + 50 850 = 207 654 руб. ≅ 208 тыс. руб.
Для наглядности проиллюстрируем структуру затрат на выполнение проекта в виде
таблицы и круговой диаграммы (см. таблицу Таблица 4.8 и рис. Рисунок 4.2):
63
Таблица 4.8: Структура затрат
Наименование статьи
Затраты, руб.
128 137
Заработная плата
Материальные
28 667
Прочие затраты
50 850
ИТОГО
245654
Затраты
Прочие
23%
Амортизация
5%
Заработная плата
59%
Материальные
13%
Рисунок 4.2: Структура затрат на разработку ПП
64
4.7 Заключение
Разрабатываемое в рамках дипломной работы программное обеспечение является
имитационно-обучающим тренажером по демонтажу блоков АЭС. Этот инструмент
позволяет проводить моделирование демонтажа кладки реактора в режиме реального
времени.
Разрабатываемый тренажер предназначен для верификации технологии демонтажа
блоков АЭС, для решения задач оптимизации рабочего процесса демонтажа, а также для
отработки персоналом операций, осуществляемых при демонтаже. Актуальность
разработки тренажера следует из актуальности проблемы демонтажа блоков АЭС.
Разработка диаграммы Ганта показала, что в рамках данного проекта имеет смысл
привлекать дополнительных исполнителей. Это позволит некоторую долю работ
проводить параллельно, а также позволит использовать более квалифицированных и
высокооплачиваемых работников в задачах, соответствующих их навыкам, а более
низкоуровневые задачи возложить на соответствующий им персонал с более низкой
заработной платой. Например, написание технической документации и тестирование
лучше поручить соответствующим работникам, чем загружать этой работой
дорогостоящих проектировщика и разработчика.
Данный проект носит научно-исследовательский характер, коммерческая
эксплуатация ПП на данном этапе не планируется.
Проведенные в данной главе расчеты показали, что:
– Общие трудозатраты на выполнение проекта составляют 276 человеко-часов.
– В случае привлечения к работе над проектом 4 исполнителей, календарное время
разработки ПП равно 40 дням.
– По результатам расчетов, первоначальная стоимость проекта равна суммарным
затратам на разработку данной системы и составляет 246 тыс. руб.
65
Список литературы
1. Brokk AB. Brokk Manual.
2. Арлоу Дж., Нейштадт А. UML 2 и Унифицированный процесс. Издание 2-е.
Издательство: Символ-плюс, 2007 г.
3. E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable ObjectOriented. 1 edition. Software Addison-Wesley Professional, November 10, 1994
4. Unity3D документация. http://unity3d.com/support/
66